This page is a mirror of Tepples' nesdev forum mirror (URL TBD).
Last updated on Oct-18-2019 Download

FDS Internal Checksum Question

FDS Internal Checksum Question
by on (#132412)
I have a question about FDS checksums. It seems that 0x28-2A within FDS ROMs (non-headered) represent some sort of checksum, I assume possibly for integrity purposes. Though a game would run fine if these three bytes are wrong. NESDev wiki labels the 10 bytes in that area as unknown but they really do seem to be some sort of checksum at those three bytes I mentioned above. I have compared Zelda I's 2 revisions on the FDS with those bytes and they all differ at those 3 bytes. Also, build date at 0x1f and 0x2c differ, too. But I know what they represent. Revision # is at 0x14 and 0x2b. So if you have any info on 0x28-2A and what kind of checksum it is, please fill me in. Thanks.

PS. I have discovered that offset 0x2b represents a second build number of some sort. Not listed on the Wiki (the lone byte preceding the second date of the build when you add 1925 + the byte...the last of the 10 unknown bytes. Or the last byte under "Disk info block (block 1)" 10 Unknown).
Re: FDS Internal Checksum Question
by on (#132429)
The checksums/CRCs for Disk files are absent from .FDS files. I'm not sure what, if any, useful information exists in the FDS header. Remember that the .FDS "roms" are an unofficial creation. The actual data on the Quick Disk has more information on it than is represented in our FDS "roms".
Re: FDS Internal Checksum Question
by on (#132430)
MottZilla wrote:
The checksums/CRCs for Disk files are absent from .FDS files. I'm not sure what, if any, useful information exists in the FDS header. Remember that the .FDS "roms" are an unofficial creation. The actual data on the Quick Disk has more information on it than is represented in our FDS "roms".


I agree with you, for the most part. Though it is still interesting, since the "HVC" string onward to KYODAKU (meaning approved in Japanese) is official within Nintendo's original format. I was not referring to the first 16 bytes within headered ROMs. I was referring to the official header. I think up to the boot read file code (byte $0F at 0x19 [unheadered]) within that block is necessary. But the bytes afterward, before the "Created date" is what I'm referring to, here. The 3 bytes before appear to be some kind of manufacturer checksum, though it is unnecessary. I just thought it would be cool if there was a way to find the algorithm to it to see the logic behind it. Right now, it seems to be completely random, which is why I think the last three bytes of that unused string is a checksum of some sort. Here is what I'm referring to, the 10 "Unknown" area on this: http://wiki.nesdev.com/w/index.php/Fami ... block_1.29

(Still I agree with you that emulation of FDS is missing GAP and CRC 'dummy' bytes.)

EDIT: I think I made a sure discovery, here. On the last set of unknown 9 bytes. The 7th one (after the 5 $FFs on any disk) is a second disk side numery system (not as in a Side B one, but I mean since the first one is "1 Disk number (first disk is actually $00)" on the nesdev wiki). Though this one does nothing, not even affect emulation, etc. I compared about 7 2-sided games and 3 1-sided (Zelda I and II, Mahjong Goku, Metroid I and II, Nazoraa Land Dai 2, Knight Move, Karate Champ, SMB1 and SMB2J) to be sure. Side A is always $00 at that 7th unused byte within those last 9 unknown bytes and Side B is always $01.

I hope I wasn't too confusing in what I was trying to get across in saying.
Re: FDS Internal Checksum Question
by on (#132432)
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. swap sides A and B)
Re: FDS Internal Checksum Question
by on (#132455)
Sik wrote:
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. swap sides A and B)


Yes. I actually replaced everything under the "Boot read file code" with $FFs. Those bytes under that boot code (represented by $0F in most games) are really nothing more than header info, up until the KYODAKU. When I switched disk sides using a double-sided game like The Legend of Zelda, it had no effect whatsoever on the game or within emulation. Byte 0x15 (Side number) in the header is responsible for disk sides within the game, and for which disk side is loaded. (When I say header, I always refer to the official Nintendo header. NOT the 16 byte header unofficially attached at the beginning of the ROM image.) It would seem that the 7th byte in that last unused string was really for the purpose of the assemblers. It seems that back then, assembly files were stored on different diskettes and then produced and assembled together at the end. Maybe that was a personal check, since both Sides A and B contain an internal header.

Now, I think I've sort of figured out what those 10 unknown bytes are (from the link I posted above, right after manufacturer permit date and right before created date) within the header. It seems that ALL FDS games have one thing in common with those 10 bytes. The first 5 of those bytes are always going to be $49, $61, $00, $00, $02 within all licensed games. In hex they spell "Ia". Since what's right before and what's following are dates, I believe that these 10 bytes are some sort of ID that any licensed FDS game must have (for integrity purposes). The first five bytes of that sting must be some sort of architecture while the last 5 bytes are the actual ID. Here, take a look at The Legend of Zelda 2 on the FDS. I'll be comparing v1.0 with v1.1:

===========================
Game: Legend of Zelda 2, The - Link no Bouken (Japan) (v1.0) - The internal name is LNK $20
Permit date within the header: 1987, January 14th ($62, $01, $14 in hex this date is in BCD so add 1925 + $62 for the year, according to the nesdev wiki)
[b]10 Unknown bytes
: $49 $61 $00 $00 $02 $00 $25 $02 $18 $00 (first five bytes are Ia string, which ALL licensed FDS games have in common)
Created date: 1987, January 14th ($62, $01, $14 in hex this date is in BCD so add 1925 + $62 for the year, according to the nesdev wiki)

Now let's take a look at v1.1, which was released less than a month later:

Game: Legend of Zelda 2, The - Link no Bouken (Japan) (v1.1) - The internal name is LNK $20
Permit date within the header: 1987, February 13th ($62, $02, $13 in hex this date is in BCD so add 1925 + $62 for the year, according to the nesdev wiki)
[b]10 Unknown bytes
: $49 $61 $00 $00 $02 $00 $26 $02 $19 $00 (first five bytes are Ia string, which ALL licensed FDS games have in common)
Created date: 1987, February 13th ($62, $02, $13 in hex this date is in BCD so add 1925 + $62 for the year, according to the nesdev wiki)

So let's compare the two set of unknown bytes within both revisions, released just 1 month from each other:

v1.0 = $49 $61 $00 $00 $02 $00 $25 $02 $18 $00
v1.1 = $49 $61 $00 $00 $02 $00 $26 $02 $19 $00

See how similar they are? The $25 and $18 went up by 1. Though this is not the case with all revisions. But I think the five bytes following that "Ia" string is some sort of internal ID.

Here are some more games to compare:

Donkey Kong Jr.: .........$49 $61 $00 $00 $02 $06 $75 $04 $84 $01
Nazoraa Land Dai 2 Gou: $49 $61 $00 $00 $02 $06 $71 $04 $80 $01
Super Mario Bros.:........$49 $61 $00 $00 $02 $06 $59 $04 $64 $01

Legend of Zelda I v1.0:...$49 $61 $00 $00 $02 $00 $26 $00 $18 $00
Donkey Kong:..............$49 $61 $00 $00 $02 $00 $45 $00 $43 $00
SMB2J:......................$49 $61 $00 $00 $02 $00 $1b $00 $97 $00

There are more patterns like this, but I just listed some of them. Notice that the 6th, 8th and 10th bytes are all also similar in both pattern sets. There are more 6th 8th and 10th byte differences but they always have a pattern. So, what do you think? Do you see this as an internal manufacturer ID like I do?
Re: FDS Internal Checksum Question
by on (#132471)
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.
Re: FDS Internal Checksum Question
by on (#132475)
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.
Re: FDS Internal Checksum Question
by on (#132477)
Sources:


This is kind of a combination of the 3 docs, and done very quickly. The 2nd doc has some kind of encoding or line break problem as well. If put into a Wiki doc or something formal, I would format this way better, particularly using offsets and sizes on the left, and the description on the right. But anyway...

Code:
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
GAP
DATA: $80
BLOCK CODE: $01, 1 BYTE
CHECK CODE: "*NINTENDO-HVC*", 14 BYTES
MAKER/MANUFACTURER CODE: 1 BYTE
GAME NAME: 4 BYTES
GAME VERSION: 1 BYTE
DISK SIDE: A=$00, B=$01, 1 BYTE
DISK ORDER (DISK NUMBER): USED BY GAMES WITH MORE THAN ONE DISK, 1 BYTE
DISK TYPE: YELLOW=$00, BLUE OR GOLD=$01, 1 BYTE -- OR -- ERR.9: EXTRA DISK NUMBER, 1 BYTE
NUMBER OF FIRST FILE READ: 1 BYTE -- OR -- ERR.10: EXTRA DISK NUMBER, 1 BYTE
BOOT READ FILE CODE: 1 BYTE
  -- The description of this byte is lost due to file formatting or encoding mistakes.
  -- The source material has line breaks where there should be proper characters, and it
  -- just so happens that the mistakes happen at the most important part of the sentence.
  -- All I was able to get:
  -- Defines the file number (possibly file index or file code?) to be read at boot time.
  -- There's a 2nd paragraph after this that is difficult to translate due to formatting mistakes
  -- or file format/encoding problems.
UNKNOWN: 5 BYTES
MANUFACTURING DATE: 3 BYTES
  -- Recorded using BCD encoding, year is from the Showa era/period (starts at 1925)
  -- Format is YEAR, MONTH, DAY.  See nesdev wiki for an example (although year 2010 isn't part of the Showa period! Ha ha ha!)
  -- For info on the Showa era, see Wikipedia
UNKNOWN (ALWAYS THE SAME VALUE): $49, $61, $00, $00, $02, 5 BYTES
REWRITTEN DISK DATE: 3 BYTES
  -- Speculate that this may be an "updated" date for MANUFACTURING DATE above, used when the
  -- game manufacturer releases an updated version of their game.  Ex: first release would have the
  -- same values for MANUFACTURING DATE and REWRITTEN DISK DATE, but a subsequent release
  -- (bugfixes, etc.) would have a newer REWRITTEN DISK DATE.
  -- Same format as above.
UNKNOWN: 1 BYTE
UNKNOWN: #$80, 1 BYTE
DISK WRITER SERIAL NUMBER: 2 BYTES
UNKNOWN: 1 BYTE
TIMES REWRITTEN: WRITTEN IN BCD, 1 BYTE
ACTUAL DISK SIDE (0=SIDE A, 1=SIDE B), 1 BYTE
UNKNOWN: 2 BYTES
CRC: 2 BYTES

−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
GAP
DATA: $80
BLOCK CODE: #$02, 1 BYTE
NUMBER OF FILES: 1 BYTE
CRC: 2 BYTES
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−

−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
GAP
DATA: $80
BLOCK CODE: #$03, 1 BYTE
SERIAL NUMBER: 1 BYTE
LOAD NUMBER: 1 BYTE
FILE NAME: 8 BYTES
LOAD ADDRESS: 2 BYTES (ORDERED FROM BOTTOM TO TOP)
FILE LENGTH: 2 BYTES (ORDERED FROM BOTTOM TO TOP)
FILE TYPE (0-2): $00=PROGRAM, $01=CHARACTER, $02=LICENSE FILE, 1 BYTE
CRC: 2 BYTES
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−

−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
GAP
DATA: $80
BLOCK CODE: $04, 1 BYTE
PROGRAM (DATA) MAIN BODY
CRC: 2 BYTES
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
Re: FDS Internal Checksum Question
by on (#132478)
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 confused. Maybe I read it wrong.
Re: FDS Internal Checksum Question
by on (#132479)
I found a version 0.4 of the first linked document (updated in what looks to be 2011) here. Doing a quick diff between the two files, it seems there's a lot more info in 0.4.
Re: FDS Internal Checksum Question
by on (#132480)
That's a significantly updated doc, but any time you see 不明 it means "unknown".
Re: FDS Internal Checksum Question
by on (#132481)
Shanem wrote:
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 confused. Maybe I read it wrong.

No, you didn't -- the chat window with my translation colleague did not automatically scroll so I missed a bunch of lines. I've updated my previous post to reflect the missing data. Good catch -- thank you (and further points that organising this into a proper Wiki table would be worthwhile. I can do that some time if/when I have the time).
Re: FDS Internal Checksum Question
by on (#132482)
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 "Ia". (I translated using Google Translate to figure this out.)

Here is the Japanese:

 国コード            : 1バイト $49=日本
 不明              : 1バイト $61 地域?


Though the second one claims to be unknown, the first one is definitely defined: "Country Code: 1 byte = $ 49 Japan" (The second unknown byte, $61 is thought to be area code. I'm not able to translate the next byte $00, though it adds a little more than 'unknown')

On to the last 5 bytes, the thing I've been wrestling with. This is what I got from Google Translate, using the newer 2011 doc:

不明(各ゲームの情報?)    : 5バイト = Unknown (Information of each game?) ; 5 bytes

I still feel Google Translate was a little less accurate with that last one. So if anyone knows Japanese, please fill me in on what the last one says instead of "Information of each game". I still think it is an ID of some sort.

EDIT: At least, I think that site agrees that it is not a checksum, unless the translator on Google was inaccurate.

EDIT2: I got to thinking that since $49 $61 spell "Ia" maybe that is the whole country code instead of it being limited to byte $49. I read on Google that Japan can be represented by either JP or JA. (This is just a theory.) But at least we know that $49 is country code. My theory is that Japan in Japanese makes a 'Y'/'I' sound when transliterated??? (Nippon is the word in Japanese for Japan. So if a Japan native tried to say 'Japan', maybe it'd sound like Y/Iapan?) I also guess they think the next byte means area because it starts with an 'a' ($61). Though I still stand by that string standing for Japan.
Re: FDS Internal Checksum Question
by on (#132484)
koitsu wrote:
https://web.archive.org/web/20091023182159/http://www2.odn.ne.jp/~haf09260/Famic/Famdis.htm
Enri reappeared elsewhere on the internet: http://www43.tok2.com/home/cmpslv/Famic/Famdis.htm
Re: FDS Internal Checksum Question
by on (#132485)
How does this work for folks?

http://wiki.nesdev.com/w/index.php/User ... rmat_stuff

If folks like it, and it looks correct, I can move it into the main FDS wiki page. I have a list of the manufacturer codes which I can put up there as well (just haven't done it yet).

Tomorrow I'll bother the couple people I know who do the translation work to see if the "Price" field can be explained more clearly. I'm pretty sure (given what I know of Japanese) I understand what's being conveyed, especially in the case of rewritten/reformatted games, but I'd rather an accurate translation be provided.

That said: the translation of "不明(各ゲームの情報?)" is correct, by the way. The author simply does not know what the bytes represent and is speculating (based on analysis of other FDS images) that they values may represent some kind of game-specific data but he does not know what. The same doc has a lot of other speculative stuff in it, some of it justified/backed up in a way, but other parts are purely speculative.

The bottom line is that at this time nobody seems to know what those bytes represent. I'm sure if you could corner someone at Nintendo Co. who helped design the FDS they could probably tell you what they're for, but good luck with that. :P

Respectfully, I'd recommend simply unplugging the OCD chip in your brain for a while. Meaning don't worry/fret over 5 bytes in a file when (as far as we know so far) has no real impact on the behaviour of the game itself. These are proprietary formats that had no real documentation provided or disclosed anywhere (that we know of) publicly. Possibly someone at one of the companies who made FDS games would have an old Nintendo game submission sheet that might contain some of the fields on it (similar to the SNES/SFC game submission sheets), but who knows.

And finally, about the Ia (that's capital-EYE lowercase-A) thing and all this weird speculation about that it's a representation of Japanese transliterated speech: absolutely not. Not even remotely. It's much more plausible that the value just represents a particular country code. Don't ask me why $49 is Japan. There may be some reason behind it but I simply don't know. For sake of comparison, the SNES/SFC country code designator in the ROM header has $00=Japan, $01=North America, $0D=Korea, $11=Australia, etc. and the reason $00 is Japan is because that's how it was on the Gameboy ($00=Japan, $01=Everywhere else). It's just a number. Hell, for all we know $49 could be the lower 2-digit birth year of some particular Nintendo employee who worked on the thing (no it's not Masayuki UEMURA, he was born in 1943, nor Hiroshi YAMAUCHI (born in 1927)). 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).
Re: FDS Internal Checksum Question
by on (#132486)
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 header to accurately portray the new byte changes (I assigned it as v1.2 and changed other header stuff). It's bothering me because I worked so hard on it for months and wanted everything to be professional and "authentic", right down to the unnecessary bytes. So pretty much everything is done except those 5 bytes, which I'm hesitant to mess with even though they are useless. Well, I have work in the morning. I'll continue comparing those bytes and see if I discover anything new with a few dozen more games.

And I didn't realize it, but I was kind of OCD'ing about it. Thanks, Koitsu. ;)
Re: FDS Internal Checksum Question
by on (#132487)
No problem. I totally understand your need/desire to make the software look professional/display as much detail as possible. Since we don't know for sure what the values represent, I'd suggest just printing the raw hexadecimal values in their linear order, e.g. the equivalent of printf("$%02X%02X%02X%02X%02X", data[34], data[35], data[36], data[37], data[38]). Then at least the user has some idea of what the raw data is, in case it's somehow useful to them.
Re: FDS Internal Checksum Question
by on (#132489)
koitsu wrote:
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% speculation here, but: The original front loader NES has a port on the bottom. Maybe some sort of add-on peripheral was intended. So, when they were designing the FDS header in late 1985/early 1986, they found it necessary to make a country code? Though, this is pure speculation, but that would explain its purpose of being there, if that byte really represents that.
Re: FDS Internal Checksum Question
by on (#132491)
It's very likely that port was originally meant for an American counterpart to the FDS, in fact I assume that's the reason why the audio lines were moved there in the first place (since there isn't any way you could get the disk adapter in the cartridge slot).

Also since we're in speculation mode: maybe they got it off by one and $49 was actually meant to be $4A, and they just didn't notice (or noticed when it was too late)? I mean, that'd give "Ja" as the result (which would make a lot more of sense). Unlikely though, especially since it's probable they'd use all caps if it was indeed ASCII.
Re: FDS Internal Checksum Question
by on (#132519)
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 is a value between $00-$06; never greater than $06
3) The 5th byte is never greater than $02
E) The first byte is always either $00 or $06
4) The 4th byte appears to represent something in decimal, as it never uses A-F
5) The 2nd byte appears to be in hex format, as it makes use of A-F (VERY heavily on Set3)
6) The 2nd byte on all the sets except for 3, 7 and 8 are less than $80. All the 2nd bytes on Set3, Set7 and Set8 are greater than $80.
7) The 4th byte, which is ALWAYS decimal, doesn't care about being greater or less than anything.
8) Set6 and Set7 are the only two sets that use $02 at the 5th byte. Every other set has $00 or $01 for the 5th byte. (Maybe this may make it more obvious in finding a similarity with these disks by observing the 5th bytes of Set6 and Set7?)

EDIT2: WHAT?!?...Look at Family Computer Othello and Golf in Set2. They have the EXACT same data (unless Nintendo made a mistake, like they did with the BCD date of "showa" in Zelda I v1.0; where they use $86 instead of $61 for the year) . Though the above observations are indeed correct... (0_o)

EDIT3: So, judging from what we know that the 2nd byte in sets 3, 7 and 8 are ALL greater than $80 (%10000000), and the other sets are ALL less than $80 (so, $7F %01111111 or less). Is it safe to say that this is some sort of bit check?


EDIT4: I just created a Set9, which is the only known set to actually mix greater than/less than $80 of the 2nd byte. Though this set is just composed of two games.

Set1:

Donkey Kong Jr.: ................................$06 $75 $04 $84 $01
Nazoraa Land Dai 2 Gou: ……………………......$06 $71 $04 $80 $01
Super Mario Bros.:..............................$06 $59 $04 $64 $01
Aspic: Majaou no Noroi (side A):………………$06 $33 $04 $34 $01
Aspic: Majaou no Noroi (side B):……………...$06 $0b $04 $06 $01
Dracula II - Noroi no Fuuin (side A)………….$06 $23 $04 $22 $01
Yumi Koujou Doki Doki Panic (side A).......$06 $13 $04 $10 $01
Armana no Kiseki (side A).......................$06 $18 $04 $15 $01
Armana no Kiseki (side B).......................$06 $07 $04 $02 $01
Deep Dungeon: Madou Senki (side A)..........$06 $45 $04 $60 $01
Dirty Pair: Project Eden (side A)...............$06 $51 $04 $56 $01
Dr. Chaos: Jigoku no Tobira (side A)..........$06 $4a $04 $53 $01
Dr. Chaos: Jigoku no Tobira (side B)..........$06 $06 $04 $01 $01
Exciting Baseball (side A).........................$06 $29 $04 $28 $01
Exciting Basket (side A)...........................$06 $76 $04 $85 $01
Exciting Basket (side B)...........................$06 $4a $04 $53 $01
Exciting Billiard (side A)...........................$06 $52 $04 $57 $01
Exciting Billiard (side B)...........................$06 $05 $04 $00 $01
Exciting Soccer: Konami Cup (side A)........$06 $76 $04 $85 $01
Family Com. Golf: Japan Course (side A)...$06 $78 $04 $87 $01
Family Com. Golf: Japan Course (side B)...$06 $33 $04 $34 $01
Family Com. Golf: U.S. Course (side A).....$06 $56 $04 $61 $01
Final Commando: Akai Yousai (side A)......$06 $36 $04 $37 $01
Hao-Kun no Fushigi na Tabi (side A).........$06 $51 $04 $56 $01
Idol Hotline: Nakayama Miho Tokimeki (side A)$06 16 04 13 01
Kieta Princess (Side A)...........................$06 $62 $04 $81 $01
Meikyuu Jiin Dababa (Side A)..................$06 $72 $04 $81 $01
Moero Twinbee (Side A).........................$06 $05 $04 $00 $01
Monty on the Run (Side A).....................$06 $16 $04 $13 $01
Youkai Yashiki (Side A)..........................$06 $21 $04 $20 $01
Adian no Tsue (Side A)..........................$06 $19 $04 $16 $01

Set2:

Legend of Zelda I v1.0 (Side A):.....................$00 $26 $00 $18 $00
Legend of Zelda I v1.0 (Side B):.....................$00 $43 $00 $39 $00
Donkey Kong:...........................................$00 $45 $00 $43 $00
SMB2J:...................................................$00 $1b $00 $97 $00
Metroid v1.1 (Side A)………………………….............$00 $13 $00 $56 $00
Akumajou Dracula v1.2 (Side A)....................$00 $47 $00 $42 $00
Akumajou Dracula v1.2 (Side B)....................$00 $62 $00 $84 $00
Esper Dream v1.0 (Side A)...........................$00 $41 $00 $98 $00
Family Computer Othello............................$00 $19 $00 $09 $00
Golf.......................................................$00 $19 $00 $09 $00
Tennis...................................................$00 $5a $00 $73 $00
Twinbee................................................$00 $3b $00 $52 $00
Ultraman Club v1.0 (Side A)....................$00 $21 $00 $60 $00
Ultraman Club v1.0 (Side B)....................$00 $67 $00 $79 $00


Set3:

Cocona World (Side B)……………………….............$00 $db $03 $70 $01
Legend of Zelda I v1.1 (Side A):...................$00 $e8 $03 $79 $01
Legend of Zelda I v1.1 (Side B):...................$00 $88 $03 $07 $01
Professional Mahjong Gokuu (Side B)………......$00 $92 $03 $73 $01
Legend of Zelda II v1.1 (Side B):.................$00 $b6 $03 $41 $01
Karate Champion (Side A):……………………........$00 $a8 $03 $31 $01
Karate Champion (Side B):……………………........$00 $b4 $03 $39 $01
Apple Town Monogatari-Little Com. (Side B)..$00 $da $03 $69 $01
Dracula II - Noroi no Fuuin (side B)………….....$00 $9b $03 $22 $01
Deep Dungeon II v1.0 (Side B)....................$00 $ac $03 $35 $01
Dirty Pair: Project Eden (Side B)..................$00 $e7 $03 $78 $01
Esper Dream v1.0 (Side B).........................$00 $9a $03 $81 $01
Exciting Baseball (Side B)...........................$00 $fc $03 $95 $01
Exciting Soccer: Konami Cup (Side A).............$00 $a4 $03 $27 $01
Falsion (Side A)........................................$00 $99 $03 $20 $01
Falsion (Side B)........................................$00 $c2 $03 $49 $01
Family Com. Golf: Special Course (Side A)......$00 $a5 $03 $28 $01
Family Com. Golf: Special Course (Side B)......$00 $e6 $03 $77 $01
Final Commando: Akai Yousai (Side B)...........$00 $82 $03 $01 $01
Ginga Denshou: Galaxy Odyssey (Side A).......$00 $d1 $03 $60 $01
Hao-Kun no Fushigi na Tabi (Side B)..............$00 $d5 $03 $64 $01
Karin no Tsurgi (Side A)...............................$00 $d7 $03 $66 $01
Kick Challenger Airfoot (Side A)....................$00 $ac $03 $35 $01
Kick Challenger Airfoot (Side B)....................$00 $d7 $03 $66 $01
Kieta Princess (Side B)................................$00 $8a $03 $09 $01
Meikyuu Jiin Dababa (Side B).......................$00 $eb $03 $82 $01
Monitor Puzzle Kineko (Side A).....................$00 $d8 $03 $67 $01
Monty on the Run (Side B)...........................$00 $e9 $03 $80 $01
Nazo no Murasume Jou (Side A)....................$00 $b4 $03 $39 $01
Nazoraa Land Zoukan Gou (Side A)...............$00 $a2 $03 $25 $01
Nazoraa Land Zoukan Gou (Side B)...............$00 $d3 $03 $62 $01
Nazoraa Land Zoukan Gou: Quiz (Side A)......$00 $a2 $03 $25 $01
Nazoraa Land Zoukan Gou: Quiz (Side B)......$00 $d3 $03 $62 $01
Seiken Psychocalibur (Side A)......................$00 $a7 $03 $30 $01
Youkai Yashiki (Side B)...............................$00 $f2 $03 $85 $01
Michael English Daibouken (Side A)..............$00 $9a $03 $21 $01
Michael English Daibouken (Side B)..............$00 $e3 $03 $74 $01
Adian no Tsue (Side B)...............................$00 $ac $03 $35 $01

Set4:
Cocona World (Side A)………………………..............$00 $7a $02 $48 $00
Legend of Zelda II v1.0 (Side A):...................$00 $25 $02 $18 $00
Legend of Zelda II v1.0 (Side B):...................$00 $56 $02 $36 $00
Legend of Zelda II v1.1 (Side A):...................$00 $26 $02 $19 $00
Akumajou Dracula v1.0 (Side B)....................$00 $5c $02 $10 $00
Deep Dungeon: Madou Senki (Side B)...............$00 $64 $02 $33 $00
Deep Dungeon II v1.0 (Side A)........................$00 $2a $02 $61 $00
Family Com. Golf Tournament: Japan (Side A)...$00 $32 $02 $57 $00
Family Com. Golf: U.S. Course (Side B)............$00 $49 $02 $90 $00
Fire Rock (Side B).......................................$00 $73 $02 $44 $00
Moero Twinbee (Side B).................................$00 $45 $02 $09 $00

Set5:
Metroid v1.1 (Side B)…………………………........$00 $64 $01 $06 $00
Professional Mahjong Gokuu (Side A)………..$00 $7b $01 $20 $00
Apple Town Monogatari-Little Com. (Side A)$00 $3b $01 $09 $00
Yumi Koujou Doki Doki Panic (Side B).........$00 $15 $01 $27 $00
Akumajou Dracula v1.0 (Side A)................$00 $15 $01 $27 $00
Ginga Denshou: Galaxy Odyssey (Side B).....$00 $42 $01 $23 $00
Monitor Puzzle Kineko (Side B)..................$00 $68 $01 $05 $00
Nazo no Murasume Jou (Side B)..................$00 $41 $01 $00 $00
Soccer.................................................$00 $05 $01 $28 $00

Set6:
Knight Move…………………………………......$06 $36 $06 $79 $02
Bio Miracle Bokutte (Side A).............$06 $25 $06 $66 $02
Bio Miracle Bokutte (Side B).............$06 $2b $06 $72 $02
Famicom Grand Prix II (Side A)..........$06 $23 $06 $64 $02
Famicom Grand Prix II (Side B)..........$06 $29 $06 $70 $02
Kaettekita Mario Bros. (Side A)..........$06 $36 $06 $79 $02
Kaettekita Mario Bros. (Side B)..........$06 $3c $06 $85 $02
Risa no Yousei Densetsu (Side A).......$06 $03 $06 $40 $02
Risa no Yousei Densetsu (Side B).......$06 $09 $06 $46 $02
Ultraman Club v1.0 (Side A)..............$06 $23 $06 $64 $02
Ultraman Club v1.0 (Side B)..............$06 $29 $06 $70 $02
Vs. Excitebike (Side A)......................$06 $21 $06 $62 $02
Vs. Excitebike (Side B)......................$06 $27 $06 $68 $02
Yuu Maze (Side A)............................$06 $13 $06 $52 $02
Yuu Maze (Side B)............................$06 $19 $06 $58 $02
Big Challenge! Dogfight Spirit (Side A)$06 $25 $06 $66 $02
Big Challenge! Dogfight Spirit (Side B)$06 $2b $06 $72 $02


Set7:
Druid: Kyoufo no Tobira (Side A)...............$00 $81 $06 $26 $02
Druid: Kyoufo no Tobira (Side B)...............$00 $87 $06 $32 $02
Neunzehn (Side A)..................................$00 $83 $06 $28 $02
Neunzehn (Side B)..................................$00 $89 $06 $34 $02
Tanigawa Kouji no Shougi ShinanII(Side A)$00 $84 $06 $29 $02
Tanigawa Kouji no Shougi ShinanII(Side B)$00 $8a $06 $35 $02


Set8:
All Night Nippon Super Mario Bros…………...........$06 $9a $05 $25 $01
Idol Hotline: Nakayama Miho Tokimeki (Side A)....$06 $92 $05 $05 $01


Set9:
Ice Climber…………………………………….$00 $4a $04 $17 $01
Fire Rock (Side A).......................$00 $85 $04 $60 $01

Misc:
Family Com. Golf Tournament: Japan (Side B).....$00 $56 $06 $17 $00
Seiken Psychocalibur (Side B)............................$06 $03 $03 $98 $01



Conclusion: There is an obvious pattern, here. I think if this is an ID of some sort, byte 2 is hex and 4 is decimal of something (if not randomly chosen, because they are not consecutive; also I doubt they are one byte checksums of some sort, given the precision I've labeled everything) and byte 5 may be more specific (?). Bytes 1 and 3 may be a set number? Maybe at least bytes 1 and 3 are set numbers of some sort used to define greater/less than values of the hex byte? And maybe set 9, which is unique mixes it up?
Re: FDS Internal Checksum Question
by on (#132552)
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.). The 4th byte actually represents if it's a "normal" game or a game released specially at a particular event or other such things. Interesting to say the least. But the majority of the work went into the "Price" area.

Oh, and about the 5 unknown bytes: I had the translator (who's my neighbour, actually -- he does professional translation for Nikon and had lived in Japan for several years but only recently moved back to the US with his wife) review that. He concurs with my translation/review -- it's purely speculation but the bytes are assumed to be "game information" but nobody knows what.

Anyway if someone could please review the page and give a thumbs-up, I'll move it into the main FDS format wiki page and clean up some of the references/sections.

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.
Re: FDS Internal Checksum Question
by on (#132553)
koitsu wrote:
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 mistake. Let me share the header info using your labels:

Code:
;this is the header of Side A
;Side B's header is identical, except for one byte
;i'll label that difference when I get to it

.db $1d, $0e , $17, $0d, $18, $24, $0c, $18, $27, $15, $1d, $0d, $26, $26, $24, $24 ;this is the Nintendo-HVC string=14 bytes

.db $2a ;the game manufacturer code = 1 byte

.dbw $ff, $ff, $ff ;this is the game name=3 bytes

.db $ff ;this is the game type

.db $ff ;the game version or revision number

.db $ff ; this is the side number

.db $00 ;this is the disk number

.db $00 ;so we seem to have a normal card, here

.db $00 ;speculative byte

.db $0f ; boot read file code

.dbw $86 $02 $03 ;!!! usually, this is where the five $FFs are suppose to be; it seems we have a date here, follow year, month, and day. Just like the 'showa' format except it is a literal year number. same as the mistake in Zelda 1 (but this date is later than the permit date; i'll give my theory at the end

.db $00 ; usually the fourth raw $FF, here

.db $01 ; usually the fifth raw $FF, here

.dbw $85 $12 $28 ;I guess this is the literal permit date (?) it's not in BCD format; here we have December 28th, 1985 as the start date of this project

.db $49 ; country code?

.db $61 ; area code?

.dbw $00, $00, $02 ;unknown

.byte $00 $f1 $ff $ff $00 ; some game specific information. Not in any format matching any of the games I listed, earlier. Also, seems the 4th and 5th byte go unused, here?

.dbw $ff, $ff, $ff ;"rewritten disk" date, according to Koitsu. I guess this is blanked out because it's a proto?

.dw $ff, $ff ; unknown

.dw $ff, $ff ; disk writer serial number

.db $ff    ;unknown

.db $00 ;disk rewrite count

.db $00 ; the disk side. the only difference with the header on Side B is that this is set to $01

.db $fe ;unknown

.db $00 ; the price


Here is the raw data of both disk sides in their header:

Code:
;Side A

.byte $01, $2a, $4e, $49, $4e, $54, $45, $4e, $44, $4f, $2d, $48, $56, $43, $2a, $ff
.byte $ff, $ff, $ff, $ff, $ff, $00, $00, $00, $00, $0f, $86, $02, $03, $00, $01, $85
.byte $12, $28, $49, $61, $00, $00, $02, $00, $f1, $ff, $ff, $00, $ff, $ff, $ff, $ff
.byte $ff, $ff, $ff, $ff, $00, $00, $fe, $00


;Side B


.byte $01, $2a, $4e, $49, $4e, $54, $45, $4e, $44, $4f, $2d, $48, $56, $43, $2a, $ff
.byte $ff, $ff, $ff, $ff, $ff, $00, $00, $00, $00, $0f, $86, $02, $03, $00, $01, $85
.byte $12, $28, $49, $61, $00, $00, $02, $00, $f1, $ff, $ff, $00, $ff, $ff, $ff, $ff
.byte $ff, $ff, $ff, $ff, $00, $01, $fe, $00


Now the reason I shared this was to display Koitsu's layout and to show how the first five unknown bytes are actually used in this. In no published, licensed game are they ever used, the are always 5 bytes of $FF. This game uses where those five FFs should be as "$86 $02 $03 $00, $01". It's pretty obvious to me that since the rest of the BCD date is wrong, up to the published v1.1 of the game, that this is the date of the prototype: February 03, 1986. The permit date was in December according the bytes: December 28, 1985. But, how can I be sure of this? Well, the title screen says 1986! So maybe those 5 bytes were used only for prototype purposes, since every known published game FFs them out.

When I turned it on using Nestopia, I didn't hear any music until I started the game. Also, it looks like some sort of debug thing when I started the game, I was purple and the B button replenished my hearts. Cool finds. Here is a pic with the date as proof:

Image
Re: FDS Internal Checksum Question
by on (#132565)
koitsu wrote:
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.). The 4th byte actually represents if it's a "normal" game or a game released specially at a particular event or other such things. Interesting to say the least. But the majority of the work went into the "Price" area.

Dammit, looking at it, I had forgotten about disk rewrites. This actually is going to be a problem because practically all dumps will be from original disks, but to decode the missing data we'll probably need to get rewritten disks to see how they use it.
Re: FDS Internal Checksum Question
by on (#132566)
Sik wrote:
koitsu wrote:
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.). The 4th byte actually represents if it's a "normal" game or a game released specially at a particular event or other such things. Interesting to say the least. But the majority of the work went into the "Price" area.

Dammit, looking at it, I had forgotten about disk rewrites. This actually is going to be a problem because practically all dumps will be from original disks, but to decode the missing data we'll probably need to get rewritten disks to see how they use it.


You could use the available dump of Donkey Kong, Donkey Kong Jr. and Super Mario Bros., since those dumps were made from copies using diskwriter.

EDIT: Also, Kaettekita Mario Bros. is a kiosk-only game.

EDIT2: Looking over rewritten disks is probably how they found the data to begin with. Also, the Super Mario Bros. dump is missing the KYODAKU.
Re: FDS Internal Checksum Question
by on (#132571)
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 pattern guessing)
Re: FDS Internal Checksum Question
by on (#132573)
Sik wrote:
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 pattern guessing)



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.

Yeah, patterns. Just like the ones I listed above concerning the 5 unknown bytes. I think I got them all. Though, sets 6 and 7 are the only obvious ones. With Side B only going up by $06 in value on the 2nd and 4th bytes, if you saw. Also, all those games are 1988 or later in those sets, which must say something.
Re: FDS Internal Checksum Question
by on (#132578)
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 =/
Re: FDS Internal Checksum Question
by on (#132579)
Sik wrote:
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: "$00, $f1, $ff, $ff, $00"; seems as though byte 3 and 4 there are blanked out. (Remember that the fourth byte is always decimal from those notes I posted yesterday.) Then you see some that share the exact same info. Which is weird, like "Karin no Tsurgi (Side A)" and "Kick Challenger Airfoot (Side B)". There are many more that share the exact same bytes like how these two share. I really don't think this is any checksum or game specific info. I've compared, header info, CHR banks, memory blocks etc and nothing adds up between these two games. I still think it's an ID of some sort. (Those two examples can from Set3.) I've also added some notes to my above ones from yesterday.

Also, I found another dump which uses the diskwriter, which can be compared. The game is called: Clu Clu Land: Welcome to New Clu Clu Land".

Here is its info:
permit date: April 25th, 1986 ($61, $04, $25)
the "IA" string: $49 $61 $00 $00 $02
the five unknown bytes (ID?): $00 $47 $00 $42 $00
date of copy through diskwriter: April 13th, 1993

Here's the other bytes with copy stuff you all can sort out, if you want to verify Koitsu's translated page on the diskwriter (the bytes right after the April 13th stuff I just listed, or $68, $04, $13)

.db $ff, $80, $02, $62, $08, $01, $01, $00, $00

After those 9 bytes dealing with diskwriter are the regular KYODAKU stuff. I'll see if I can find any more of my dumps that use diskwriter. (Note that this is a Side A-only game. No Side B.)
Re: FDS Internal Checksum Question
by on (#132582)
Shanem wrote:
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 the GAP, Block Start, and CRC.
Re: FDS Internal Checksum Question
by on (#132583)
MottZilla wrote:
Shanem wrote:
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 the GAP, Block Start, and CRC.



I have one. Of SMB2J. If it weren't against forum rules, I'd give you a copy. The ROM image is 65, 536 bytes in total.

EDIT: Or if you want any bytes from it to compare, like header etc., I guess I can share the bytes. Though, the dump came from a brand new copy of the game and matches the VC release of SMB2J.

EDIT2: Okay. I just checked and a regular FDS dumped image is 65,500 bytes. So this one is 36 bytes greater. It seems like the only difference is just some $00s dispersed here and there. There's two right after the header:

Code:
.byte $01, $2a, $4e, 49, $4e, $54, $45, $4e, $44, $4f, $2d, $48, $56, $43, $2a, $01
.byte $53, $4d, $42, $20, $00, $00, $00, $00, $00, $0f, $ff, $ff, $ff, $ff, $ff, $61
.byte $07, $23, $49, $61, $00, $00, $02, $00, $1b, $00, $97, $00, $61, $07, $23 $ff
.byte $ff $ff $ff $ff $00 $00 $00 $00 $00 $00 ;these last two are absent for the common SMB2J dump


EDIT3: For those 5 unknown bytes...I don't know why I didn't think of using a raw dump like this one to find if the values add up to something. Ugh...stupid on my part. Still, I don't think it will make a difference as I still think it's some sort of manufacturer ID.


Edit 4: I just set an arena for what we know about those 5 mysterious bytes:

1.) The first byte must be either $00 or $06. Never anything else. So...is this some sort of check like Koitsu's example of Loderunner with the glasses being $03 instead of $01 on his page?

2) The second byte is hex. If $80 or greater it will be in sets 3, 7 or 8. If less than $80 it will be in sets 1, 2, 4, 5, or 6. Set 9 is the only odd set, comprised of just two games.

3) The third byte can be anything for $00-$06, never anything greater. It is only $06 on sets 7 and 8 (games dating 1988 or later). (Incidentally. since these two sets are composed of games ONLY dating 1988 and after, set 7 has $80 or less for the second byte while set 8 has $80 or higher; as mentioned on the second byte commentary right above this.)

4) The fourth byte will always be decimal. Not much else is known about it except that it only uses 0-9 and never higher than $99.

5) This fifth mystery byte looks like some kind of check. Out of all the hundreds of games, it is ALWAYS $00, $01 or $02. Never anything else.
Re: FDS Internal Checksum Question
by on (#132614)
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 and then the next gap.

I have not found any dump which contains this sort of information in it. I've only found the information of what would be there from the Brad Taylor FDS document.
Re: FDS Internal Checksum Question
by on (#132618)
MottZilla wrote:
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 and then the next gap.

I have not found any dump which contains this sort of information in it. I've only found the information of what would be there from the Brad Taylor FDS document.


I'm certain the dump with 65, 536 bytes is complete. It matches the VC release, too. I've ripped it from the WAD to verify (back in 2012).
Re: FDS Internal Checksum Question
by on (#132621)
Changes to the wiki, as previously discussed, have been merged: http://wiki.nesdev.com/w/index.php/Fami ... isk_System

I can't do anything more to assist at this time.
Re: FDS Internal Checksum Question
by on (#132623)
koitsu wrote:
Changes to the wiki, as previously discussed, have been merged: http://wiki.nesdev.com/w/index.php/Fami ... isk_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 see if I can find anything at all definitive with the unknown bytes besides the observations I've made. Even though they're accurate, I still am not 100% sure on anything concerning those bytes. Just that I *think* it's an ID. (Something crazy like the Nintendo employee who authenticated the game or something...Since so many random games share the exact same byte data with no correlation whatsoever. If that unlikely scenario is true, or something dealing with "inside" knowledge, then we may never know unless someone goes to Japan and asks an employee for info. That is, if the creator of the FDS is even still alive.)
Re: FDS Internal Checksum Question
by on (#132625)
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 side but nearly none from the Japanese side).
Re: FDS Internal Checksum Question
by on (#132626)
Sik wrote:
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 side but nearly none from the Japanese side).


The only people I can think of that would have those documents would be some third party game developer, like Pony Canyon. The issue is whether they even still have those docs or not. The most optimistic bet would be to hope that one pops up for auction like on Yahoo Japan or something to that extent. I would say this is the best bet because we've received FDS betas/protos from people like this. The issue is, if such docs do indeed exist, who has them and what they would sell for.
Re: FDS Internal Checksum Question
by on (#132638)
Shanem wrote:
MottZilla wrote:
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 and then the next gap.

I have not found any dump which contains this sort of information in it. I've only found the information of what would be there from the Brad Taylor FDS document.


I'm certain the dump with 65, 536 bytes is complete. It matches the VC release, too. I've ripped it from the WAD to verify (back in 2012).


But it's not complete, there are no GAPs or CRCs. Or are there? I don't have the image from the WAD file. On the Disk Writer machine, the images may have been similar to that format and the current FDS format as the gaps and crcs would be just constructed during writing. It's not like this information is important for the software. But having that data in the image file would make emulation more straight forward. When I started to add FDS support to one of my emulator projects I didn't have clear information on gaps and CRCs. I ended up HLEing the BIOS function call for LoadFiles().

It was less complex than putting together hacks for simulating gaps and avoiding any touching of the CRC.
Re: FDS Internal Checksum Question
by on (#132644)
I love delving into the mysteries of FDS files!

I guess it would be useful to include this disk image which I dumped from the back of a single-sided FDS game: It is a "formatted" but "blank" side B!

http://www.chrismcovell.com/data/Blank_ ... -11-21.fds

It'd be interesting to see what kind of encoding is in this non-game header.

Code:
00000000  01 2a 4e 49 4e 54 45 4e 44 4f 2d 48 56 43 2a ff  .*NINTENDO-HVC*
00000010  ff ff ff ff ff 01 00 00 00 0f ff ff ff ff ff 61  .....a
00000020  11 21 49 61 00 00 02 00 9c 03 83 01 ff ff ff ff  .!Ia........
00000030  ff ff ff ff 00 01 00 00 02 02 03 00 00 32 46 44  .........2FD
00000040  41 54 41 31 00 00 60 00 80 00 04 00 00 00 00 00  ATA1..`.........


Code:
DISK ''  Side B  Files 2  Maker $FF  Version $FF
-------------------------------------------------------
000 $00 '2FDATA1 ' $6000-$DFFF (32768) [CODE] 
001 $00 '2FDATA2 ' $6000-$B953 (22868) [CODE] 
-------------------------------------------------------
| 55726 Bytes Used,  9700 Bytes Free, 85 Percent Full |
-------------------------------------------------------
Re: FDS Internal Checksum Question
by on (#132738)
@ccovell

Those 5 unknown byte look similar to Esper Dream v1.0. What was on Side A of that game, anyway?
Re: FDS Internal Checksum Question
by on (#132796)
I forget now, but it was some 1st-gen or Diskwriter game like SMB1, Volleyball, etc.
Re: FDS Internal Checksum Question
by on (#132825)
koitsu wrote:
Don't ask me why $49 is Japan. There may be some reason behind it but I simply don't know..

Barcode in BCD format ? :?
Re: FDS Internal Checksum Question
by on (#132845)
80sFREAK wrote:
koitsu wrote:
Don't ask me why $49 is Japan. There may be some reason behind it but I simply don't know..

Barcode in BCD format ? :?


I would be interested in knowing what kind of algorithm you used to draw that conclusion. Thanks.
Re: FDS Internal Checksum Question
by on (#132849)
Wait! He's right. They DO all start with 49... http://brog.engrish.com/wp-content/uplo ... image2.jpg

Maybe that's why that guy on the Japanese site drew that conclusion?

But I still doubt that's even a country code for this reason. I own two brand new, sealed FDS disks. One of SMB1 and one of SMB2J. Here are their bar codes: SMb1 = T4902370500134 SMB2J = T4902370500356

If that is indeed the header to a barcode BCD (those 5 unknown bytes following the $49, $61, $00, $00, $02 string) They don't add up to anything and do not follow the outline of points that I listed, earlier.

These two games start with $49 and $02 in it, but where is the 61 in this case? Unless it's BCD for 1986 (25+61). The year FDS was published. So... that would mean first byte of barcode (area code or $49, then $61 [year FDS was publish in BCD], two $00, then the $02, the next byte following all FDS games in barcode after $49).
Re: FDS Internal Checksum Question
by on (#133000)
Shanem wrote:
Code:
...

.db $fe ;unknown



This byte seem to indicate the disk used. $fe = white disk, $ff = blue disk, $00 = yellow disk
Re: FDS Internal Checksum Question
by on (#133068)
Overload wrote:
Shanem wrote:
Code:
...

.db $fe ;unknown



This byte seem to indicate the disk used. $fe = white disk, $ff = blue disk, $00 = yellow disk



@overload
I think you are correct on that. Good find! I wonder what hex number black disks were given? I may need to look up which games used black disks later.

@Everyone

I uploading a similar list to that of page 2 on this topic. This time I will use neater notes and only list games that are same in those 5 unknown bytes which have an obvious pattern or are consecutive with the 2nd and 4th bytes.

Please take a minute to compare 2nd and 4th bytes, here. Reading the notes won't hurt, either.

EDIT: These are NEWER, revised notes.

Shanem wrote:
Observations:

This list is divided into like bytes of the 1st, 3rd and 5th, bytes:
1) The 1st byte in every set is always either $00 or $06.
2) The 2nd byte in every set appears to be in hex format, as it makes use of A-F (VERY heavily on Set3). The 2nd byte on all the sets except for 3, 7 and 8 are less than $80. All the 2nd bytes on Set3, Set7 and Set8 are greater than $80. So, judging from what we know that the 2nd byte in sets 3, 7 and 8 are ALL greater than $80 (%10000000), and the other sets are ALL less than $80 (so, $7F %01111111 or less). Is it safe to say that this is some sort of bit check?
3) The 3rd byte in every set has a value between $00-$06; it is never greater than $06.
4) The 4th byte in every set appears to represent something in decimal, as it never makes use of A-F. This byte doesn't care about being greater or less than anything.
5) The 5th byte in every set is never greater than $02. (The only games that make use of $02 for this byte are games which date 1988 or later. Every other set has $00 or $01 for the 5th byte. )


Here are the similar/sequential/consecutive games from each set:

Shanem wrote:
Set1:
Moero Twinbee (Side A).........................$06 $05 $04 $00 $01
Exciting Billiard (side B).........................$06 $05 $04 $00 $01
Dr. Chaos: Jigoku no Tobira (side B)...........$06 $06 $04 $01 $01
Armana no Kiseki (side B).......................$06 $07 $04 $02 $01
Aspic: Majaou no Noroi (side B):……………......$06 $0b $04 $06 $01

Yumi Koujou Doki Doki Panic (side A)......$06 $13 $04 $10 $01
Monty on the Run (Side A).....................$06 $16 $04 $13 $01
Armana no Kiseki (side A)......................$06 $18 $04 $15 $01
Adian no Tsue (Side A)..........................$06 $19 $04 $16 $01

Youkai Yashiki (Side A)..........................$06 $21 $04 $20 $01
Exciting Baseball (side A).......................$06 $29 $04 $28 $01

Aspic: Majaou no Noroi (side A):………………$06 $33 $04 $34 $01
Family Com. Golf: Japan Course (side B)..$06 $33 $04 $34 $01
Final Commando: Akai Yousai (side A).....$06 $36 $04 $37 $01

Dr. Chaos: Jigoku no Tobira (side A).........$06 $4a $04 $53 $01
Exciting Basket (side B)...........................$06 $4a $04 $53 $01

Dirty Pair: Project Eden (side A)...............$06 $51 $04 $56 $01
Hao-Kun no Fushigi na Tabi (side A).........$06 $51 $04 $56 $01
Exciting Billiard (side A)..........................$06 $52 $04 $57 $01
Family Com. Golf: U.S. Course (side A).....$06 $56 $04 $61 $01
Super Mario Bros.:.................................$06 $59 $04 $64 $01

Nazoraa Land Dai 2 Gou: ……………………......$06 $71 $04 $80 $01
Meikyuu Jiin Dababa (Side A)...................$06 $72 $04 $81 $01
Donkey Kong Jr.: ...................................$06 $75 $04 $84 $01
Exciting Basket (side A)...........................$06 $76 $04 $85 $01
Exciting Soccer: Konami Cup (side A)........$06 $76 $04 $85 $01
Family Com. Golf: Japan Course (side A)...$06 $78 $04 $87 $01


Shanem wrote:
Set2:
Family Computer Othello............................$00 $19 $00 $09 $00
Golf.......................................................$00 $19 $00 $09 $00


Shanem wrote:
Set3:
Final Commando: Akai Yousai (Side B)..........$00 $82 $03 $01 $01
Legend of Zelda I v1.1 (Side B):...................$00 $88 $03 $07 $01
Kieta Princess (Side B)................................$00 $8a $03 $09 $01

Falsion (Side A).........................................$00 $99 $03 $20 $01
Michael English Daibouken (Side A)..............$00 $9a $03 $21 $01
Dracula II - Noroi no Fuuin (side B)………….....$00 $9b $03 $22 $01

Nazoraa Land Zoukan Gou (Side A)................$00 $a2 $03 $25 $01
Nazoraa Land Zoukan Gou: Quiz (Side A)........$00 $a2 $03 $25 $01
Family Com. Golf: Special Course (Side A)......$00 $a5 $03 $28 $01
Seiken Psychocalibur (Side A)........................$00 $a7 $03 $30 $01
Adian no Tsue (Side B).................................$00 $ac $03 $35 $01
Kick Challenger Airfoot (Side A).....................$00 $ac $03 $35 $01

Karate Champion (Side B):……………………........$00 $b4 $03 $39 $01
Legend of Zelda II v1.1 (Side B):.................$00 $b6 $03 $41 $01

Falsion (Side B)........................................$00 $c2 $03 $49 $01

Ginga Denshou: Galaxy Odyssey (Side A).......$00 $d1 $03 $60 $01
Nazoraa Land Zoukan Gou: Quiz (Side B)......$00 $d3 $03 $62 $01
Nazoraa Land Zoukan Gou (Side B)...............$00 $d3 $03 $62 $01
Hao-Kun no Fushigi na Tabi (Side B)..............$00 $d5 $03 $64 $01
Kick Challenger Airfoot (Side B)....................$00 $d7 $03 $66 $01
Karin no Tsurgi (Side A)..............................$00 $d7 $03 $66 $01
Monitor Puzzle Kineko (Side A).....................$00 $d8 $03 $67 $01
Cocona World (Side B)………………………............$00 $db $03 $70 $01

Michael English Daibouken (Side B)..............$00 $e3 $03 $74 $01
Family Com. Golf: Special Course (Side B).....$00 $e6 $03 $77 $01
Dirty Pair: Project Eden (Side B)..................$00 $e7 $03 $78 $01
Legend of Zelda I v1.1 (Side A):..................$00 $e8 $03 $79 $01
Monty on the Run (Side B)..........................$00 $e9 $03 $80 $01
Meikyuu Jiin Dababa (Side B)......................$00 $eb $03 $82 $01
Youkai Yashiki (Side B)...............................$00 $f2 $03 $85 $01


Shanem wrote:
Set4
Legend of Zelda II v1.0 (Side A):...................$00 $25 $02 $18 $00
Legend of Zelda II v1.1 (Side A):...................$00 $26 $02 $19 $00


Shanem wrote:
Set5
Yumi Koujou Doki Doki Panic (Side B).........$00 $15 $01 $27 $00
Akumajou Dracula v1.0 (Side A)................$00 $15 $01 $27 $00


Shanem wrote:
Set6
Knight Move………………………………….......$06 $36 $06 $79 $02
Bio Miracle Bokutte (Side A)..............$06 $25 $06 $66 $02
Bio Miracle Bokutte (Side B)..............$06 $2b $06 $72 $02
Famicom Grand Prix II (Side A)..........$06 $23 $06 $64 $02
Famicom Grand Prix II (Side B)..........$06 $29 $06 $70 $02
Kaettekita Mario Bros. (Side A)..........$06 $36 $06 $79 $02
Kaettekita Mario Bros. (Side B)..........$06 $3c $06 $85 $02
Risa no Yousei Densetsu (Side A).......$06 $03 $06 $40 $02
Risa no Yousei Densetsu (Side B).......$06 $09 $06 $46 $02
Ultraman Club v1.0 (Side A)..............$06 $23 $06 $64 $02
Ultraman Club v1.0 (Side B)..............$06 $29 $06 $70 $02
Vs. Excitebike (Side A)......................$06 $21 $06 $62 $02
Vs. Excitebike (Side B)......................$06 $27 $06 $68 $02
Yuu Maze (Side A)............................$06 $13 $06 $52 $02
Yuu Maze (Side B)............................$06 $19 $06 $58 $02
Big Challenge! Dogfight Spirit (Side A)$06 $25 $06 $66 $02
Big Challenge! Dogfight Spirit (Side B)$06 $2b $06 $72 $02 ;this WHOLE set just increments by 6's for the every 2nd and 4th byte. all games date 1988 or later. Second byte is 7F or less.


Shanem wrote:
Set7:
Set7:
Druid: Kyoufo no Tobira (Side A)...............$00 $81 $06 $26 $02
Druid: Kyoufo no Tobira (Side B)...............$00 $87 $06 $32 $02
Neunzehn (Side A)..................................$00 $83 $06 $28 $02
Neunzehn (Side B)..................................$00 $89 $06 $34 $02
Tanigawa Kouji no Shougi ShinanII(Side A)$00 $84 $06 $29 $02
Tanigawa Kouji no Shougi ShinanII(Side B)$00 $8a $06 $35 $02
;;this WHOLE set just increments by 6's for the every 2nd and 4th byte. all games date 1988 or later. Second byte is 80 or more.
Re: FDS Internal Checksum Question
by on (#133076)
Regarding the byte that some people have said represents "disk colour": this isn't necessarily reliable.

The first version of Erin's FDS document says in Japanese that $00=Yellow, $01=Blue or gold. But then a later (much newer) version of the document says that the byte purpose is unknown.

Then we have people who come along and say $FE=White, $FF=Blue, $00=Yellow.

And now "we have no idea what the value for black disks is".

This is exactly why the byte on the Wiki is labelled "Unknown" with "Speculative" mentions -- there is absolutely nothing definitive so far about it, because there is already conflict in the information: 1) $01 meaning "blue or gold" yet $FF somehow also meaning "blue", 2) author of original document changing their stance on what the byte represented.

What if I told you $00 meant the DiskWriter was manufactured in 1985, $01=1986, $02=1987, $FE=Test/QA unit, $FF=Operating in debug mode? Or $00=Person formatting the disk preferred Mario over Luigi, $01=Preferred Luigi, $02=Never beat Super Mario Brothers, $FE=I just work here, $FF=Field left empty? Ponder it for a bit. :-)

Really what's needed is a humongous (I'm talking multiple hundreds, e.g. 500+) set of disks, where a single person (or maybe a pair) dumping them is able to write down details about the disk (ex. colour) vs. that byte.

And don't forget about the possibility of incorrect or inverted reads as a result of a faulty sector...

P.S. -- Does anyone have code that can be run on the Famicom + FDS that can show an on-screen dump of a sector? You know, something like this? I have maybe 15 FDS games (including some originals) which I could provide data for if such is available. Hmm, actually wait a minute, I'm not sure how I'd even run code on the Famicom with an FDS attached since it takes up the cartridge slot. Grumble grumble...
Re: FDS Internal Checksum Question
by on (#133079)
koitsu wrote:
Really what's needed is a humongous (I'm talking multiple hundreds, e.g. 500+) set of disks, where a single person (or maybe a pair) dumping them is able to write down details about the disk (ex. colour) vs. that byte.

And that still won't be really safe because 1) you'd need to know everything about every disk (including how many times it got rewritten, where it got rewritten, etc.), 2) the disk color is unreliable because a disk could have been rewritten into a game that normally has a different color (and why would Nintendo want to store this anyway?), 3) the parts of the header set by the developers are not really reliable at all, since developers are known to not respect headers quite often (as long as it doesn't make their games unbootable).

The only way to be 100% sure is to get leaked official documentation from somewhere, and that's assuming that one doesn't have any mistakes either.

koitsu wrote:
P.S. -- Does anyone have code that can be run on the Famicom + FDS that can show an on-screen dump of a sector? You know, something like this? I have maybe 15 FDS games (including some originals) which I could provide data for if such is available. Hmm, actually wait a minute, I'm not sure how I'd even run code on the Famicom with an FDS attached since it takes up the cartridge slot. Grumble grumble...

Run the code off a disk, then do a disk swap =P (of course, the question is how the hell do you write to a disk in the first place)
Re: FDS Internal Checksum Question
by on (#133096)
If you can use FDSLoader, you don't need to write to a Disk at all. Instead you connect the RAM adapter to your PC to load your FDS program into memory. Then you connect the RAM adapter back to the FDS drive and you can begin reading disks with your program to see the bytes of data you want to see on each disk.

That would eliminate the need to actually write your program onto a disk, though that's certainly possible too.
Re: FDS Internal Checksum Question
by on (#133121)
I own 200+ original disks and have dumped all of them using a logic analyzer connected to a RAM adapter. I use custom software to build a disk image (includes CRC and precise gap data) and FDS image. This way I get zero errors unless the disk itself is corrupt.

I don't like to rely on images from the web cause there's always the possibility that they could have been hacked. I know for instance a couple of games (Super Load Runner, Super Load Runner II) have 40K program blocks as a form of protection.
Re: FDS Internal Checksum Question
by on (#133126)
koitsu wrote:
Really what's needed is a humongous (I'm talking multiple hundreds, e.g. 500+) set of disks, where a single person (or maybe a pair) dumping them is able to write down details about the disk (ex. colour) vs. that byte.

P.S. -- Does anyone have code that can be run on the Famicom + FDS that can show an on-screen dump of a sector? You know, something like this? I have maybe 15 FDS games (including some originals) which I could provide data for if such is available. Hmm, actually wait a minute, I'm not sure how I'd even run code on the Famicom with an FDS attached since it takes up the cartridge slot. Grumble grumble...

As mentioned, since disks can be rewritten multiple times, the disk type might not match with its data, unless you use brand-new FDS disks (as the no-intro guys do).

FDSLoader can dump disks, and my program TapeDump has facilities for dumping FDS disks via KCS and ParPort. TapeDump's program runs in internal RAM so that a devcart can be swapped out and an FDS RAM adaptor (carefully!) swapped in while the power is on.

Overload wrote:
I own 200+ original disks and have dumped all of them using a logic analyzer connected to a RAM adapter. I use custom software to build a disk image (includes CRC and precise gap data) and FDS image. This way I get zero errors unless the disk itself is corrupt.

I don't like to rely on images from the web cause there's always the possibility that they could have been hacked. I know for instance a couple of games (Super Load Runner, Super Load Runner II) have 40K program blocks as a form of protection.


Yes, that's an interesting way of dumping/reloading games too. I connected the drive data line to my PC and recorded the audio as a cheap way of examining the data (though I wonder what recording rate is sufficient for this data?)
Re: FDS Internal Checksum Question
by on (#133129)
ccovell wrote:
Yes, that's an interesting way of dumping/reloading games too. I connected the drive data line to my PC and recorded the audio as a cheap way of examining the data (though I wonder what recording rate is sufficient for this data?)
A side holds 64 KiB (512 kibit), and reportedly takes 7 seconds to go through, right? so ~75000 bits/second? Depending on the exact wire protocol, anywhere from 88kHz through 192kHz might be sufficient. Some kind of EQ is probably necessary to compensate for the soundcard's lowpass, though.

I wonder whether that means we could reasonably rewrite FDSLOADR to use a soundcard now?