FDS programming... - NESdev BBS

FDS programming...
by Celius on 2006-06-29 (#14835)

I don't know too much about the FDS, but it looks like programming for it could be very easy, but I'm not too sure how you would get the games on the disks. I've never seen an FDS game, but I imagine that they are pretty big, are they not? Does anybody here have an FDS? Do you program for it? Sorry, I won't be able to respond here for a couple of days. But if you reply, I'll post back on the 3rd, I believe

re
by nensondubois on 2006-06-29 (#14836)

The FDS is similar to the nes exept for the extral sound channel and FDS bios
i have only fdone FDS Hacks as in the error Screen has sprites from mario bros. ect. Sorry if I didn't help

by Disch on 2006-06-29 (#14838)

I'd imagine programming something for the FDS would be considerably more difficult than something for the NES (putting it on media, however, might be much easier... everything else though, becomes considerably more complicated and restrictive).

I think FDS games operate more on a file system rather than just chunks of PRG and CHR like NES ROMs. The first thing you should probably do is read up on some BIOS documentation to find out which files are loaded off the disk and where the game's entry point is (BT's doc had a big chunk dedicated to BIOS operations). Once you understand the jobs the BIOS performs, and how to use it, you should be on your way. You shouldn't even have to bother at all with the FDS registers -- as you can probably use the BIOS for everything (except for sound).

The difficult thing about the FDS is you're basically stuck with "mapper 0" setup the whole time (32k PRG, 8k CHR only). You can have more data in the game, but it can't really be swapped in like it can with mappers. Reading data off the disk is a very slow process... so you'll have to organize everything so that you can load all the stuff you need for a while right up front. Map data, enemy stuff, items, everything the game will use between loading screens has to fit in that 32k block (pretty much making it impossible to have any program of real complexity without being plagued by horrid loading times). You can't just swap out banks and read info real quick, then swap back like you can with mappers.

Plus you have to arrange the info on the disks efficiently. Making the user constantly have to change and flip disks between every level or something like that would suck.

As for game size.... I think you get around 64k on one side of a disk. The biggest FDS games are two 2-sided disks, so they max out at about 256k.

by ccovell on 2006-06-30 (#14864)

I have a couple demos that run on the FDS on my homepage: http://www.disgruntleddesigner.com/chrisc/creations.html Source code is of course available in the archive.

Disch is correct; you can make a 32k prog and have it mostly ignore the FDS part of the Famicom. But your program is pretty much like an NROM game. I don't really see any practical use of making FDS games/demos other than the "technical coolness" factor.

by tepples on 2006-06-30 (#14868)

Or the fact that it may be easier to load homebrew into an FDS RAM cart (you just need an appropriate cable and Brad Taylor's FDS loader) than into a bare Famicom or NES (you need a socketed cart and a flash programmer).

by Celius on 2006-07-07 (#15173)

Oh, I didn't know that it was this different from the NES/FC, I thought it was the same thing, just with disks. Thanks for the replies. I think I may look in to that, but I'll stick with the NES for now .

Okay, I just thought I'd ask this here, and not make people mad by starting another thread. But what exactly IS the Nintendo Block? I've seen pictures of it, but I have no idea what it is. What do you do with it? Does anybody know?

by Disch on 2006-07-07 (#15176)

Celius wrote:
Oh, I didn't know that it was this different from the NES/FC, I thought it was the same thing, just with disks.

Well... you're exactly right, that's really all it is (plus the extra sound channel).

The thing is, disks cannot be accessed in real time (ever try saving a file to a floppy disk vs. saving it to a hard-drive? it takes forever). Because of that it takes upwards of 100+ CPU cycles to read a single byte off the disk. Unlike cartridges which can read a byte from ROM every CPU cycle. I would assume this is due to the disk drive having moving parts which just can't keep up with the speed of the processor. On a cartridge, the ROM is all wired in and can be accessed immediately, but the disk drive has to spin the disk to the right sector, scan the information off the disk, and translate it.

The FDS unit contains 32k RAM which is to be used as your PRG space. Since you can't read-and-run instructions and data off the disk directly (due to it being so freaking slow), how it works is you load "files" off the disk into the 32k PRG-RAM block, which can then be run. You can always read more information off the disk, but again, it's slow. It's not immediate like bankswapping on a mapper.

But pretty much everything else about the system is the same. Once you have your information off the disk in a workable area, it's the same old NES (or FC).

by Bregalad on 2006-07-07 (#15178)

I think that's just the same that happens if you have every played Playstation / Playstaion 2 games (I assume you do). You have to load stuff between screens, and then run everything from RAM (so that when you remove the disk from the console, the game continues to run normally until it tries to load something).

by tepples on 2006-07-07 (#15181)

But then the PS1, PS2, and GameCube have nicer DMA controllers, so that they can keep the game (either menu animations or a different part of the map) running while another part of the game loads into RAM. The FDS is all cycle-timed PIO, meaning that the CPU has to wait for each bit to come in.

by Bregalad on 2006-07-08 (#15203)

I think that allow most games to load while still showing something to the screen, typically an animated "now loading" text, or in RPGs doing a special graphic effect when the battle data is being loaded.