FDS Disk Lister Version 2

I've made an updated version of my 2002 program that runs on a real Famicom+FDS system.

This program is useful for checking the actual contents of unlabeled or perhaps mislabeled disks that you might buy used.  This version adds a game name database. So, for most released games, the lister will print its name.

Download the FDS Lister here!

You'll get the most out of this program if you run it on real FDS hardware with a working drive.  How to do this is beyond the scope of this page, but you can use a device like the FDSStick or SD Magic Wild Card to get it running on the Famicom, then switch over to the real FDS drive. Or, use the FDSStick to write my FDS Lister to a fresh FDS disk.

My updated program starts up basically the same as my old one: It'll show a title bar at the top, asking you to eject the Lister disk and insert a game disk.  It'll then show a simple display of the contents of the disk, using the FDS BIOS' built-in disk "directory" subroutine.
Old version archived here:[link] 

Press the Start button, and my program will change into a deeper listing mode, which partly bypasses the BIOS for file reading.

One of the limitations of the FDS BIOS for listing disks is that some useful information in the FDS disk header cannot be displayed.  In addition, "hidden" files on certain disks will not be shown in the simple listing mode.

This deeper mode can show the "disk version" field stored at the end of the disk header, as well as interpret the "manufacturing/copyright" date field and "(re-)written" date field, so you can track game versions of your disks.

The deeper mode will also do its own reading of the files & headers on the disk, and compare them with the file number stored at the start of the disk.

As seen in the image to the left, if the number of files in the header doesn't match the actual number of files found (either more or less) then it'll print the two numbers beside each other. This can be an indicator that a) there is a hidden file, b) the physical surface of the disk has some errors or dying data, c) your drive belt is wearing out, or... d) maybe my program has some bugs in it.

Hidden files will also be indicated by a red square in the file list.

For those wanting to do a bit of analysis of their disks and their drive itself, pressing A+Start will put the FDS Lister into a further detailed GAP analysis and display mode.

(The "GAP" is blank padding before disk data in order for the FDS hardware to lock on to magnetic flux timing.)

This mode will report/show the gap sizes at the start of the disk and between files. (GAP numbers are not in any direct byte/msec format.) It will also attempt to run a speed test of the byte data coming in from the disk.

The visual gap / disk layout display is useful for seeing differences between officially-written disks, home-written disks, emulators such as the FDSStick, etc.  For example, in the picture to the left, two official Disk Writer-exclusive games (Kaetekitta Mario Bros. and Wrecking Crew) appear to have a much shorter initial gap ($195B using my counter) than most factory-written FDS disks (shown here are two MahJong titles), which usually have a gap in the $4000s.

In short, this is a visual way to identify games which possibly are Disk Writer variants, or home-written copies passed off as official ones.  (Besides also kinda being visually interesting.)

In this same mode, you can see a display of the "Average CPU cycles between bytes" for the current disk being read.  This is one way to check that your FDS drive is running at the correct speed, or to identify disk surface errors, or a dying drive belt.  Be sure to use a known, working, officially-written FDS disk to do your testing, and observe the values returned in green.

The theoretical ideal data rate for FDS disks is said to be 96400 bits per second, or 12050 bytes/sec.  Inverted, that's 1 byte every 82.988 microseconds.  With the Famicom CPU having a clock period of 559 ns/cycle, there should be a new byte coming in to the FDS RAM adaptor every 148.46 (~hex $94) CPU clock cycles.

At an average of 1 byte every 147-150 CPU cycles that I get on my newly-"calibrated" disk drive, that comes pretty close to the ideal data rate of 148 listed above.

To the left you can see a test that I was doing comparing a working FDS drive to the drive in my Twin Famicom that was starting to fail to load files.  It was returning speeds around $90-$91 (too fast??).  I minutely adjusted the drive speed pot under the rubber flap of the drive motor until it gave sane readings of around $95-$96.  Perhaps, then, this can be one way that people can recalibrate or extend the life of FDS drives whose speeds are starting to drift.

There is one more mode in my FDS Disk Lister, but it is in there only with a use-it-at-your-own-risk warning. Thus, I'm not going to tell you how to access it.

This mode, with no friendly user interface, will do a blind raw scan of the FDS disk and store the first 16K bytes it reads from the extreme beginning of the disk surface.  You can page through a visualization of this scan using the left or right buttons on the pad.  Features such as the large gap area (of all black or all white pixels) at the start of the disk, as well as file headers surrounded by similar short gaps can be identified here.  (The data is visualized as strips going down the screen, starting from the top-left.)

By pressing the up/down buttons on the joypad, you can change the scale of the scan, to "zoom out" and get a greater picture of a disk the next time you insert it for scanning.

Don't set the scale value too high, or else your drive will sit there scanning for many passes of the game disk.  But hey, I warned you.  Use this at your own risk.

This raw scan feature was implemented just to satisfy my curiosity about what lay on the disks' surfaces at the beginning of their data spirals.  It also turns out to be a roundabout way of diagnosing surface errors on bad disks -- those that might just generate an "Error #XX" in the other reading modes.

For example, I had one SMB2 disk that wouldn't load, and running it through this raw scan showed that a large chunk at the beginning of the disk had been wiped out to all 00s somehow.  Another example was a disk that had errors mid-way, and the disk itself started making some noise.  We can see in the image to the left that from a certain spot in the disk, it's unreadable: the checkerboard pattern suggesting that the RAM adaptor is completely confused by the data coming in from the drive.