Removing (corrupted) header from a FDS dump

[twipley]

I have a v1.1 Hikari Shinwa (Kid Icarus) FDS dump (md5: 76801589c8ec0cc36ccdc822e3f8e803).

The save area appears untouched, but the header is said to be corrupted. Since I'm not a fan of corrupted headers, I'm thinking I might as well remove it altogether. I know the whole goal here is towards header preservation, but it just seems to me it is better (for now) to have no header than to keep a corrupted one.

a) How am I to proceed? I've heard about various tools, but not of their quality. I want a job well done.

b) As a side note, is anyone aware of the differences between v1.0 and v1.1? I played the game once, and from stage 3-1 to 3-3, every cloud was hidden. A Google search reveals nobody has ever posted about such an issue. I'm not sure which version I was playing on, but perhaps it is a bug that was fixed in v1.1.

[einstein95]

I have a v1.1 Hikari Shinwa (Kid Icarus) FDS dump (md5: 76801589c8ec0cc36ccdc822e3f8e803).

The save area appears untouched, but the header is said to be corrupted. Since I'm not a fan of corrupted headers, I'm thinking I might as well remove it altogether. I know the whole goal here is towards header preservation, but it just seems to me it is better (for now) to have no header than to keep a corrupted one.

a) How am I to proceed? I've heard about various tools, but not of their quality. I want a job well done.

If you were to remove the header of a FDS image, that would make it unplayable in any emulator. The header isn't one like iNES headers, but one that the BIOS of the FDS checks. For that image, the header isn't so much as "corrupted" but more so just has unnecessary values nulled out.

[twipley]

For that image, the header isn't so much as "corrupted" but more so just has unnecessary values nulled out.

Oh. Okay! thanks for the clarification! Good to know. It isn't anywhere as worse as it being corrupted altogether...

I'll just be crossing my fingers the emulator I'm using (nestopia) will not be affected by these nulled-out values. And, that the image is able to offer the real experience, as it would if its header was preserved intact.

[twipley]

Would any software be recommendable to see which header sectors, from a dump, were lost?

And, any accompanying documentation to see the functions of those missing sectors? (for FDS disks)

[einstein95]

Would any software be recommendable to see which header sectors, from a dump, were lost?

And, any accompanying documentation to see the functions of those missing sectors? (for FDS disks)

No tool that I know of, but there is documentation: http://wiki.nesdev.com/w/index.php/Fami ... block_1.29
The "checksum" at the end is actually block 02, or the number of files on the disk.

[twipley]

Well, it seems the 76801589c8ec0cc36ccdc822e3f8e803 dump produces some weird effects. Something is wrong in the sky world (stage 3). Graphics are really off:

When in fact, this is what it's supposed to look like:

[olimar]

Testing out the disk reader I'm working on, I noticed my copy of Hikari Shinwa seems to be v1.0, is this of interest to anyone? I've only seen v1.1 on the interwebs. The disk is of unknown provenance and maybe not "clean" by No-Intro standards though.

Code: Select all

01 2A 4E 49 4E 54 45 4E 44 4F 2D 48 56 43 2A 01
50 54 4D 20 00 00 00 00 00 0F FF FF FF FF FF 61
12 17 49 61 00 00 02 06 97 05 10 01 61 12 17 FF
FF FF FF FF 00 00 00 04

[twipley]

I know next to nothing about all this, but I guess it cannot be any worse. :)

[einstein95]

Testing out the disk reader I'm working on, I noticed my copy of Hikari Shinwa seems to be v1.0, is this of interest to anyone? I've only seen v1.1 on the interwebs. The disk is of unknown provenance and maybe not "clean" by No-Intro standards though.

Code: Select all

01 2A 4E 49 4E 54 45 4E 44 4F 2D 48 56 43 2A 01
50 54 4D 20 00 00 00 00 00 0F FF FF FF FF FF 61
12 17 49 61 00 00 02 06 97 05 10 01 61 12 17 FF
FF FF FF FF 00 00 00 04

The "v1.1" and "v1.0" dumps on the internet are only different in the save data. If you could upload the complete dump, then it could be checked further, but at the moment it seems like it's a better dump than what we have as it doesn't have blanked header data.

Well, it seems the 76801589c8ec0cc36ccdc822e3f8e803 dump produces some weird effects. Something is wrong in the sky world (stage 3). Graphics are really off:

When in fact, this is what it's supposed to look like:

Try setting 0x39 to 0E and 0x10015 to 11. Attached is a IPS patch to convert the No-Intro "v1.1" dump into one with the default initialised save and fixed (I think) file number for side B.

[twipley]

But, do you guys think this might serve to solve the encountered graphical issues? Because I wonder whether the problem is really the dump (including its header), or more so the emulator, the developer of which I could contact.

EDIT: I'll try this out to see if the patch fixes it.

EDIT2:

The "v1.1" and "v1.0" dumps on the internet are only different in the save data.

So, this means the developers made a v1.1 which fixes, absolutely nothing? Strange!

[olimar]

The "v1.1" and "v1.0" dumps on the internet are only different in the save data. If you could upload the complete dump, then it could be checked further, but at the moment it seems like it's a better dump than what we have as it doesn't have blanked header data.

The rom looks substantially different, I haven't played through it to see what changes there are. The disk isn't original (it's on a "NINTENDD" disk) so it could be a hack for all I know. Looks legit at first glance though.
http://home.comcast.net/~olimar/HikariShinwa.fds

But, do you guys think this might serve to solve the encountered graphical issues? Because I wonder whether the problem is really the dump (including its header), or more so the emulator, the developer of which I could contact.

A different header wouldn't affect gameplay.

The "v1.1" and "v1.0" dumps on the internet are only different in the save data.

So, this means the developers made a v1.1 which fixes, absolutely nothing? Strange!

Apparently there isn't any correlation between version numbers and actual game releases, I wouldn't read much into it.

[twipley]

A different header wouldn't affect gameplay.

Do you guys think I'm at a good place looking to fix the reported graphical issues? Or, if I would be better off to somewhere such as emulator (e.g., Nestopia UE) boards?

[einstein95]

The "v1.1" and "v1.0" dumps on the internet are only different in the save data. If you could upload the complete dump, then it could be checked further, but at the moment it seems like it's a better dump than what we have as it doesn't have blanked header data.

The rom looks substantially different, I haven't played through it to see what changes there are. The disk isn't original (it's on a "NINTENDD" disk) so it could be a hack for all I know. Looks legit at first glance though.

Hm, well, this confirms that the v1.1 dumps are actually v1.1, and that the number of files part of the header of side B for v1.1 is indeed incorrect, leading to the graphical problems as one of the BG graphic files isn't loaded into memory.

[KingMike]

I know some FDS games would put the wrong number of files in the header as a copy-protection measure. (ie. it'll say 12 files, then the game will try to load file 13. If it succeeds, it'll assume it's a real copy.)
So I wonder if that could have been an intentional error?

[einstein95]

I know some FDS games would put the wrong number of files in the header as a copy-protection measure. (ie. it'll say 12 files, then the game will try to load file 13. If it succeeds, it'll assume it's a real copy.)
So I wonder if that could have been an intentional error?

Doesn't seem so, the file it doesn't load is a simple CHR file, but the copy-protection methods I've seen load a PRG file. Could easily be wrong though.