Page 1 of 2
Difficulty on making an FDS project?
Posted: Mon Nov 28, 2016 10:25 pm
by hawken
I'm looking in to this, is there a massive technical difference between a normal NES rom style project and an FDS project?
Re: Difficulty on making an FDS project?
Posted: Mon Nov 28, 2016 10:32 pm
by rainwarrior
I don't think it's that different than building regular NES code.
You could create a cc65 linker config that would build an FDS file instead of an NES file, and otherwise it's kind of just writing for a "special" mapper.
Re: Difficulty on making an FDS project?
Posted: Tue Nov 29, 2016 12:25 am
by lidnariq
Massive difference? No.
The biggest difference is the change in memory handling: hardware cartridges are always "make 2ⁿ byte slice #x of memory available starting at address y·2ⁿ", while the FDS instead supports arbitrary (and nonuniform) sized slices and arbitrary starting locations.
If you're planning on making an NROM class thing, it's probably equivalent. But if you actually use the FDS filesystem beyond just the initial load and for save games, you might want a different workflow involving making all the individual files and then compiling them together.
Re: Difficulty on making an FDS project?
Posted: Tue Nov 29, 2016 6:39 am
by Pokun
I made a simple FDS program that loads some graphics and initializes palette and nametables but doesn't turn on the PPU. It just plays a note on the square 1 channel for testing. It doesn't load anything beyond the initial load or anything so it's basically an NROM on a single disk side.
I used asm6, and it doesn't have a linker or anything AFAIK, so to solve the arbitrary starting locations problem I assembled each disk file separately (I call the assembled files "file0.o", "file1.o" and so on since they basically work like object files), then I include them in a "header.asm" source file (which contains all the disk- and file-headers) using the .incbin directive at the proper locations. Finally I assembled the "header.asm" last into an FDS image.
Maybe there is a better way?
Edit: BTW there is a way to trick the BIOS to skip the Kyodaku screen so you can boot faster, but I haven't tried it and I didn't want to do it in a basic example template.
Oh and the FDS_HOOK subroutine was written per Chris Covell's recomendations, but I'm not sure why it's needed. I guess those values it reinitializes could be overwritten somehow.
Re: Difficulty on making an FDS project?
Posted: Tue Nov 29, 2016 6:54 am
by Gilbert
A few years back, I'd tried converting
my short demo to FDS.
I've just attached the archived source from my HDD. It's been a while so I haven't checked the integrity of the files, but just drop asm6.exe into the same folder as the files and launch the batch file and things should be done.
Instead of using copy/b actually one may also use asm6 itself to combine the files together (by using incbin and db for header stuff and the like).
Re: Difficulty on making an FDS project?
Posted: Tue Nov 29, 2016 7:09 am
by ccovell
Pokun wrote:Edit: BTW there is a way to trick the BIOS to skip the Kyodaku screen so you can boot faster, but I haven't tried it and I didn't want to do it in a basic example template.
Once you have a working program and want to try it, make a new
Code: Select all
file on the disk that gets loaded [b]last[/b] upon bootup, whose load address is $2000. It should be about 256 bytes long, and have these 8 bytes repeating:
$90 00 00 00 00 00 00 00
The FDS BIOS/Copyright screen will be skipped.
Re: Difficulty on making an FDS project?
Posted: Tue Nov 29, 2016 10:26 am
by lidnariq
ccovell wrote:Code: Select all
file on the disk that gets loaded [b]last[/b] upon bootup, whose load address is $2000. It should be about 256 bytes long, and have these 8 bytes repeating:
$90 00 00 00 00 00 00 00
[/quote]Does that effectively just enable NMIs? and why 32-ish repeats?
Re: Difficulty on making an FDS project?
Posted: Tue Nov 29, 2016 1:45 pm
by loopy
To keep the BIOS busy until the next NMI hits, I presume.
Re: Difficulty on making an FDS project?
Posted: Wed Nov 30, 2016 2:12 am
by hawken
Thanks for the comments, there won't be any saving or loading, more of a self playing demo disc.
Re: Difficulty on making an FDS project?
Posted: Wed Nov 30, 2016 2:12 am
by hawken
Gilbert wrote:A few years back, I'd tried converting
my short demo to FDS.
I've just attached the archived source from my HDD. It's been a while so I haven't checked the integrity of the files, but just drop asm6.exe into the same folder as the files and launch the batch file and things should be done.
Instead of using copy/b actually one may also use asm6 itself to combine the files together (by using incbin and db for header stuff and the like).
Thanks for sharing this, will take a look
Re: Difficulty on making an FDS project?
Posted: Fri Dec 02, 2016 4:39 am
by Pokun
ccovell wrote:Pokun wrote:Edit: BTW there is a way to trick the BIOS to skip the Kyodaku screen so you can boot faster, but I haven't tried it and I didn't want to do it in a basic example template.
Once you have a working program and want to try it, make a new [ CODE ] file on the disk that gets loaded
last upon bootup
So a PRG file then, how does the BIOS determine in what order to boot the files? Is it the file number, file ID or the order the files comes on the disk maybe?
Re: Difficulty on making an FDS project?
Posted: Fri Dec 02, 2016 7:06 am
by ccovell
Location $0029 in the disk header is the "Boot ID Limit". The FDS Bios should automatically load all files that have an ID (file header location $02) less (?) than this limit, before handing control over to the booted game.
Re: Difficulty on making an FDS project?
Posted: Fri Dec 02, 2016 7:20 am
by Pokun
Yes but you said the kyodaku-skipping file must be loaded last. So that means it should have a higher ID than all other files that loads at boot (but still lower than the value in Boot ID Limit)?
Re: Difficulty on making an FDS project?
Posted: Fri Dec 02, 2016 9:49 am
by tepples
Yes, as I understand it. Its ID should be one less than the limit.
Re: Difficulty on making an FDS project?
Posted: Tue Aug 25, 2020 10:21 pm
by aquasnake
loopy wrote: ↑Tue Nov 29, 2016 1:45 pm
To keep the BIOS busy until the next NMI hits, I presume.
Code: Select all
/* PPU IO */
#define PPU_CTRL1 0x2000
#define PPU_CTRL2 0x2001
#define PPU_STATUS 0x2002
#define PPU_SPR_ADDR 0x2003
#define PPU_SPR_IO 0x2004
#define PPU_VRAM_SCRL 0x2005
#define PPU_VRAM_ADDR 0x2006
#define PPU_VRAM_IO 0x2007
#define PPU_SPR_DMA 0x4014
#define PPU_TV_SYS 0x4119
/* For PPU_CTRL1 */
#define PC1_NAME_MASK 0x03 // mask of name table area
#define PC1_NAME0 0x00 // use name0
#define PC1_NAME1 0x01 // use name1
#define PC1_NAME2 0x02 // use name2, reserved
#define PC1_NAME3 0x03 // use name3, reserved
#define PC1_INC32 0x04 // add 32 by every access of ppu
#define PC1_SPR_PAT1 0x08 // sprite use pattern 1
#define PC1_BG_PAT1 0x10 // background use pattern 1
#define PC1_SPR_BIG 0x20 // set the sprite size 8*16
#define PC1_RESERVE 0x40 // reserved, unused
#define PC1_NMI 0x80 // nmi enable
/* For PPU_STATUS */
#define PS_VRAM_WFLAG 0x08 // vram write flag
#define PS_SPR_OVER8 0x20 // sprite over 8 on one scan line
#define PS_SPR0_HITFLAG 0x40 // #0 sprite hit flag
#define PS_VBLANK 0x80 // vblank flag
#define reg(_addr) (*((volatile unsigned char*)(_addr)))
void waitforvsync(void)
{
nes_timer = 0;
while(!nes_timer);
}
void nmi_enable(unsigned char en)
{
if(!en)
reg(PPU_CTRL1) &= ~PC1_NMI;
else
reg(PPU_CTRL1) |= PC1_NMI;
}
// incert this to your code, wait until the NMI is triggered
while(!(reg(PPU_STATUS) & PS_VBLANK));
// delay 1 frame for the NMI routine is done
waitforvsync();
...
...
...