Profile picture
, 49 tweets, 8 min read Read on Twitter
OK so you know the Famicom Disk System? that neat 1986 floppy drive-add on for the Famicom (the Japanese original the NES was based on)?
I learned some interesting things about the disks today!

So, the disks are a single spiral track made of blocks, of 4 types.
type 1 is a disk header. type 2 just indicates how many files are on the disk, type 3 is a file header, and type 4 is a raw file.
So you'll have a disk that looks like this:
[HEADER] [COUNT] [FILE INFO 1][FILE DATA 1][FILE INFO 2][FILE DATA 2][FILE INFO 3][FILE DATA 3], repeated for as many files as it has.
there's no central directory for filenames and where to find them, and there doesn't need to be and can't be: it's an unseekable spiral.
most types of disks have some kind of index that lists which files are on it in a known place (like track 0, sector 0) and then the drive can seek to that track and read until it finds the right (track) sector number.
so the FDS format is kinda like if you took that format and simplified it down to one single track. You don't do any seeking, you just start reading and wait until you see the right file-info block come by, then you know to start reading.
but to make better use of the entire disk, it's not laid out as a concentric circle, it's a spiral. instead of the head stepping between tracks, it smoothly moves from the outside to the inside (or the reverse, possibly) and reads it as if it was one big track.
so, the interesting things: Like I said, there's a count block, which just says how many files are on the disk. The BIOS routines inside the RAM Adapter (that bit on top that plugs into the famicom) remember this value and only look for that many files.
so if the count block says 8 files and the game asks for file 12, it'll just go "nah, not here!" but that doesn't mean there can't be a file #12 on the disk, of course.
so you can have files on the disk that are invisible. This could be used as a type of copy protection: You have N files on the disk, and put a file at N+1.
Maybe a disk copier only copies the N files the disk says it has, ignoring the invisible files.
then you can write your game to hack the number-of-files-on-disk count in memory (it's a 6502, there is no memory protection here!) and reset it to N+1 and try to read that hidden file. If it's there, great. if it's not, OH NO WE'VE BEEN PIRATED!
so, file info:
the first interesting thing is that files have a number and an ID code, and work differently. number is just 0, 1, 2, 3 on the disk,but IDs can be anything, except that there's a "boot ID" field in the header, which determines which file is loaded first.
interestingly it's not an exact match, it's the first one on the disk with an id lower than the one in the header.
if that's the case, why not just boot the one with the lowest id? I'm not sure.
files have 8 character names. Not 8.3 like DOS, just 8.
Files can only be up to 64k in size, which isn't a problem because the disk itself only stores ~64-84kb a size, and the header and lead-in take up at least 26k of that.
files also have an address and a type-of-RAM field.
This tells the BIOS where in RAM to put the file when loaded.
There's a type-of-RAM field because the RAM Adapter has two types of RAM, in addition to the 2K of ram in the famicom itself.
the c64 had something similar to this: if you were loading a PRG file with
the kernal would read the first two bytes and use that to determine where in RAM to stick the loaded data, instead of at a standard location.
but the real interesting stuff about the FDS is in the disk header. This gives info about the disk itself, and boy did they stuff a ton of weird things in there.
the first weird one is that each disk knows if it's a regular game disk, one from a special event like a tournament, or if it was on sale.
which is followed up by the weird idea that a game disk knows HOW MUCH IT COSTS? sorta. There's a Price field, but decoding it is tricky.
Depending on if this is a fresh disk or a rewritten one, it can know it costs between 500 and 3400 yen.
which also tells you that a disk knows if it's been rewritten: every time a disk is rewritten, it increments the write_count field in the header.
It also stores the serial number of the original disk writer unit used to create it.
So if you brought in a disk to Nintendo, they could figure out which store you bought it at.
Also, some FDS disks had shutters (blank ones for rewriting would, and generally the store-bought ones didn't)

but guess what: disks can tell if they have a shutter or not!
it's also speculated (but unproven) that disks know what color they are.
This isn't out of character for Nintendo: unless you've hacked or painted them, your Switch Joy-cons know what color they are.
and then there's the two final things in the header. one slightly confusing and one hilarious.
The date and the country.
the date is confusing because first of all because it uses binary coded decimal, which is a weird system where you encode numbers into binary by using each group of 4 or 8 bits as a single digit. It's wasteful in terms of space, but easy to display on screen and such.
and this is fine, the NES uses a 6502, a common 8-bit chip with built in BCD features!

except I lied. it doesn't use the 6502. You'll often see it listed as using the 6502...
because it really uses the Ricoh 2A03, which is a modified version of the 6502 to add some features a games console would need, like sound generation and controller polling and such. They also took some parts out, like BINARY CODED DECIMAL
There's also the issue in encoding dates that you have to pick and epoch, which is just whenever your calendar starts. The common AD/CE method starts in 0, and we just count years since then.
These days computers usually start from 1970, and count seconds or milliseconds since.
other computers/systems/programs used 1900 or picked the date of when the company started. So, what does the FDS use? 1900? 1970? maybe 1986, the release date of the FDS? 1889, the founding of nintendo?
NOPE! It uses 1925.
which is only weird until you realize they're using the japanese era dating system.
This is a traditionally used system which dates years by the emperor who reigned during them. the Shōwa era started in 1926, and they don't have a year-0, so 1926 is Shōwa 1.
so a disk released when the famicom disk system itself was released will say it's from year 61, because Shōwa 61 = 1986.
OK. That doesn't seem that weird, just not the sort of thing non-Japanese people would know about.
EXCEPT, as you might guess from the fact that the Shōwa era started in 1926, Emperor Shōwa (aka Hirohito) was pretty old when the Famicom Disk System came out.
So the system is based on Shōwa era dates, and the Shōwa era ended only 3 years later in 1989.
So if you get a game from 1990, like Namco's Xevious, it'll say it's from Shōwa 65, despite that not being a date that exists. Showa 65 is Heisei 2.
We're in the last year and last month of Heisei, btw. It's planned to end on April 30th of this year.
I say "planned" because all the articles about this say things like "the Heisei will probably end on April 30th" because that's the plan, yes.
Hopefully, on April 30th, Emperor Akihito will abdicate, Crown Prince Naruhito will take over, and we'll begin the Reiwa period
it's a plan rather than a definite thing because there's always a chance the Emperor could die before the 30th, and the Reiwa period would start the next day.
It's in relatively good health so that's unlikely to happen but he's also 85, and things happen. Hopefully he doesn't die on the 29th for maximum annoyance, because that would mean all the plans would be off by one day.
in any case, the famicom disk system will not know or care when we begin the Reiwa era, it has no clock or internet connection it could use to find out these things.

So we're onto the last, finally bit of silliness in the disk header.
Each disk, at offset #34 into the header, stores which country it comes from.
Presumably this could be used for some kind of region coding? or possibly to select different language versions of the firmware, or similar.
the only problem is that the famicom disk system was only released in one country, Japan.
And all (legitimate) famicom disks were made in only one country, Japan.
so there's only one valid value for the country field... Japan.

or 73. Yeah, it's 73. I don't know why it's not just 1, or 0, but it's 73.
you might think "wait, isn't 73 in the capital letters part of ASCII? maybe they made it the letter 'J' in ASCII?" which is a very good theory! unfortunately 73 isn't 'J'. It's 'I'.
The final weird thing about famicom disk system disks is that no one seems to be sure how much they can store.
You'll commonly see it quoted as 64k a side, but that's just a round number, and one that's known to be wrong.
calculating how much it can store is tricky because of how it's just one big track. You'd think you could just count up the fixed-size sectors and measure the dynamic-length headers, but there's also a lot of padding and weirdness included that complicates it.
My guess that the absolute maximum size per side is around 92 kilobytes per side, with about 66 kilobytes of that usable.
This is calculated using the 96.4 (+/- 10%) kilobits/second read rate times 7 seconds to read a whole disk (it seems to be somewhere between 6 and 7 seconds) and usable by subtracting... the wrong number. Whoops.
Each disk begins with a lead-in section of at least 26150 bits, I accidentally calculated it using bytes.
so the correct number would be 92k/side with a maximum usable of ~88k
Missing some Tweet in this thread?
You can try to force a refresh.

Like this thread? Get email updates or save it to PDF!

Subscribe to foone
Profile picture

Get real-time email alerts when new unrolls are available from this author!

This content may be removed anytime!

Twitter may remove this content at anytime, convert it as a PDF, save and print for later use!

Try unrolling a thread yourself!

how to unroll video

1) Follow Thread Reader App on Twitter so you can easily mention us!

2) Go to a Twitter thread (series of Tweets by the same owner) and mention us with a keyword "unroll" @threadreaderapp unroll

You can practice here first or read more on our help page!

Follow Us on Twitter!

Did Thread Reader help you today?

Support us! We are indie developers!

This site is made by just three indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3.00/month or $30.00/year) and get exclusive features!

Become Premium

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal Become our Patreon

Thank you for your support!