I'm looking in to this, is there a massive technical difference between a normal NES rom style project and an FDS project?
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.
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.
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.
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).
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, 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.
ccovell wrote:
[CODE] file on the disk that gets loaded last 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
Does that effectively just enable NMIs? and why 32-ish repeats?
To keep the BIOS busy until the next NMI hits, I presume.
Thanks for the comments, there won't be any saving or loading, more of a self playing demo disc.
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
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?
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.
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)?
Yes, as I understand it. Its ID should be one less than the limit.