Famicom Disk System, Adding Drive Emulation

Famicom Disk System, Adding Drive Emulation
by MottZilla on 2008-04-06 (#32355)

I've decided I'd like to add FDS support to my emulator and I'm having some trouble. At first I thought I might do it by trapping JSRs to BIOS routines but then that seemed like too much of a pain than just regular emulation.

But I did write a routine that would go through the image and find whatever file I wanted and load it. This was enough to make it load files for games like Donkey Kong which never do any Disk Access themselves and are just 32K + 8K games.

So anyway, I've got the bios trying to load games with the drive emulated. The problem I'm having is the *.FDS format apparently is retarded and lacks CRC bytes. Apparently after every block it reads two more bytes than exist in the file. Atleast that is what it appears to be. By trying to add in dummy reads I can advance the error messages I've been getting as it gets further into loading.

I guess my question is, are there any good documents for emulating FDS (the FwNES format)? Or does anyone know anything I might be missing? Right now I get Error 25 which is it expects Block Type 4 (file data) and it isn't getting it. I haven't yet checked to see what the log says it is doing. But if anyone has any tips or knows about other problems please let me know. It certainly would have been nice if one of the documents mentioned the missing CRC bytes.

by Disch on 2008-04-07 (#32376)

Yeah... .fds files are missing tons of information which is necessary to really have accurate FDS emulation. Not just CRCs, but the block starting marker, GAP periods, etc, etc. That stuff being absent throws the BIOS off when it's looking for files because it misaligns itself.

To tell the truth I haven't really found many ways to deal with this. Some emus I've looked at work by a really hackish method that doesn't really represent hardware behavior at all (looking for and ignoring specific writes, not advancing the file cursor under so and so conditions).

The way I was thinking of trying was to attempt to reconstruct the disk a bit better internally once I load the .fds file. That is... add the block start markers, and GAPs and CRCs and whatnot. I heard NEStopia does something like this to get a specific game working that would otherwise fail (but I never actually looked). This probably would work pretty well.

We really need a new FDS file format.

by tepples on 2008-04-07 (#32379)

I seem to remember that Animal Crossing for GameCube uses some sort of .qd format for Clu Clu Land D. Does anyone know how it is supposed to work?

by kyuusaku on 2008-04-07 (#32384)

Disch wrote:
That is... add the block start markers, and GAPs and CRCs and whatnot. I heard NEStopia does something like this to get a specific game working that would otherwise fail (but I never actually looked). This probably would work pretty well.

This is easy to do if you don't emulate the CRC accumulator (do any emus do this?) Emulating the accumulator could either force people to use proper new dumps, or it could force people to give old dumps valid CRCs.

Disch wrote:
We really need a new FDS file format.

I use the original unofficial FDS file format: each file is a plain binary of a disk side, sharing a common file name, but a letter/number sequence in it's extension.

This format also passes conceptually since each disk side is an entirely separate volume, not a volume across two sides like a floppy disk or multiple disks like a hard drive. FwNES packages seem to lead people into wrong assumptions about FDS.

by MottZilla on 2008-04-07 (#32431)

Well, I've been screwwing around trying different things, and I decided to just ditch it, and try intercepting BIOS function calls and doing the function myself. So far it has gotten simple games working (and loading instantly). But there's still issues but really I can't think of a better way to do this reasonable with the FDS format. Honestly it sucks and should be replaced. All you should have to do is emulate the drive and how it scans through the disk. You shouldn't have to compensate for missing information. That's just BS. So since I can't do it right I guess I might as well sorta HLE the BIOS calls.

by tepples on 2008-04-07 (#32433)

MottZilla wrote:
So since I can't do it right I guess I might as well sorta HLE the BIOS calls.

GBA and DS emulators get away with HLEing the BIOS. So it just depends on what you want to do: accuracy with arbitrary fds software, or being able to get existing fds roms working most easily.

by Disch on 2008-04-07 (#32437)

Sort of on the subject:

Does anyone know specifically how the CRC calculation works? BT's doc gives the polynomail used and mentions that it's effectively bit reversed due to bits being right-shifted out rather than left-shifted. However I'm still a little fuzzy on the details.

Is the original value of the CRC reg 0? or 0xFFFF? or 0x8000/0x0080 (block start marker)?

Actually, I learn best by example... how about this.... given a 4 byte file "06 07 08 09" what would the CRC be? And would it be stored low byte first?

by MottZilla on 2008-04-08 (#32491)

tepples wrote:
MottZilla wrote:
So since I can't do it right I guess I might as well sorta HLE the BIOS calls.

GBA and DS emulators get away with HLEing the BIOS. So it just depends on what you want to do: accuracy with arbitrary fds software, or being able to get existing fds roms working most easily.

What I want to do, is get most official FDS games working. I.E., Castlevania, Zelda, Kid Icarus, Metroid, and other popular titles like Otocky and such.

Just by intercepting JSRs to LoadFiles and GetDiskInfo, the Castlevania games seem to work as well as simple games. But oddly Zelda (1 and 2) don't work, Metroid and Kid Icarus don't. The Zelda's are more curious as they don't call any of the known routines I need to intercept. Zelda 2 just shows nothing, and Zelda 1 crashes when you try to load a game and also is missing graphics.

I'm not too worried right now because I know there are other bugs in just general emulation that may be related.

by oRBIT2002 on 2008-04-10 (#32578)

We would all need a new FDS fileformat and a human-readable FDS-technical document.

by tepples on 2008-04-11 (#32580)

Was there ever a published spec for Mitsumi's Quick Disk format? It was used by the FDS, as well as Smith-Corona's word processing typewriters, several MIDI samplers, and some low-end home computers of the 1980s.