nesdev.org

Really all you need is somebody with the original FDS programming docs, since those will be the ones documenting the header. That's a lot of possible points to check, really. Of course the question is finding somebody willing to give away that stuff (so far I've seen lots of docs from the Western s...

Changes to the wiki, as previously discussed, have been merged: http://wiki.nesdev.com/w/index.php/Family_Computer_Disk_System I can't do anything more to assist at this time. Thank you, Koitsu, for taking your time and effort to help out with this. This wiki is indeed a group effort. I'm going to ...

A full dump of the data on the disk would contain gaps which are a large number of 0s, followed by a 1 bit to end the gap and start the next block. Assuming the gap is byte aligned, You'd have a bunch of 00 00 00, and then 80 followed by the block. After the block's data you'd have the 16bit CRC an...

What we probably want then is to get someone from No-Intro to do that, as they do full FDS dumps. They even include the missing CRCs and GAP data, too. That's where I got my source of comparing SMB2J with mine to see what was originally there. I haven't found any with full FDS disk dumps containing...

Yeah, at first I thought that last byte was related to the release year (note how games with the same value were released around the same year generally), but there are several counterexamples to prove otherwise =/ What's really weird was the Zelda I proto bytes I listed yesterday for those five: &...

We'd probably want more rewritten dumps to be 100% sure though. Heck, even several dumps from the same game, to see in what they differ. Sadly, we risk that information being quite pointless if we don't also know the circumstances under which they got rewritten either... (we'd have to go with patte...

My wiki page has been updated, specifically the "Price" field, as well as the "Game name" field. It turns out the "Game name" field is actually 3 bytes long and correlates with the 3-letter abbreviation on the packaging (ex. LNK for Zelda 1, PTM for Kid Icarus, etc.). ...

As for the manufacturing and rewriting dates not honouring the format -- not surprised. Yes it's possible whoever made them made a mistake by encoding the value as the literal 2-digit year number in BCD rather than the offset from 1925. I got ahold of the Zelda 1 prototype. It makes the same mistak...

Okay. I've updated my list of the last five unknown bytes after the $49, $61, $00, $00, $02 string. I've made some noteworthy observations. I've also divided like categories into sets. Here they are: Observations: 1) This list is divided into like bytes of the 1st, 3rd and 5th, bytes 2) The 3rd byte...

I'm not so sure I even believe that $49=Japan, since the FDS was never released outside of Japan to begin with, so why would they just start the number at $49? I even checked things like EUC tables to see if maybe $4961 would turn out to be 日本 but it doesn't (it's $C6FC $CBDC). Now this is 100% spe...

I honestly must say that I like it, Koitsu. Good job on that new info sheet. The reason why this is such a big deal to me is simple: I recently made a brand new FDS SRAM save patch of SMB2J (I had an older one done by somebody, before I picked up on the 6502) and I've changed everything in the heade...

I figured out what "UNKNOWN (ALWAYS THE SAME VALUE): $49, $61, $00, $00, $02, 5 BYTES" means from reading freem's link. Those bytes are always the same because those 5 bytes represent country code. (All FDS licensed games were released in Japan.) This is why they always started with "...

I have a question. Right after the "UNKNOWN (ALWAYS THE SAME VALUE): $49, $61, $00, $00, $02, 5 BYTES" and before the disk rewritten date, where are the other 5 unknown bytes I assumed are some sort of ID? But thank you for the documents. I am grateful for your time. I'm just a little conf...

koitsu wrote:Shanem contacted me in PM about this. I've found some Japanese site that describes the block format in verbose detail (all bytes from what I can tell), so I'm having it translated and will post it here.

You are awesome. Thanks, Koitsu!

Maybe then we can also add it to the Nesdev wiki, too.

It's possible the firmware is using that byte (this wouldn't matter in emulation since as long as disk reads are emulated it will work, it's all done in software). What happens usually if you try to boot from side B? Did you actually change the value of that byte to make sure it isn't ignored? (e.g...