Sorry for the long title. Anyway, long story short, I finally figured out a way to rip Famicom images from Wii VC .wad files via hex editing. I did this with Zelda 1, and now I have a ripped image exactly the same size as an actual Famicom rip, but there's a problem. If I boot it in BizHawk, it tells me FDS block 2 is corrupted, and if I boot it in FCEUX, the Famicom load screen shows up, but it gives me err 23, which is basically the FC saying the same thing. I'm assuming this has something to do with the fact that Nintendo modified the ROM so that it wouldn't need a b-side like the old FDS disk did. Is there a way I can make the file work in an emulator?
You will probably need to compare against a rip from the original disk to be able to tell for sure what's going on.
I did compare against an original rip, but I'm not sure exactly what to make of it. Some parts of it are definitely different, but I'm not sure exactly what those parts mean--I was hoping someone more well-versed than I could tell me about it.
Can you post a picture of a graphical diff?
I'd love to if you could tell me how. I've never done anything like that, my hex editing experience is rather limited.
If you are on windows, Vdiff can be a good utility for identifying differences and showing them graphically.
There are a couple different FDS listing/extraction tools out there, but you could use this one:
http://www.chrismcovell.com/data/FDSListWIN.zipCompare the text output of each disk image, and then you can compare individual files in each image by extracting them (maybe keeping them in separate directories so their files don't mix together is a good idea). This is how you can find out which files differ in the FDS image, and where.
Thanks for the tip--unfortunately, no matter what I do, FDSList tells me my rip has an invalid file number header. I'm starting to feel like a lot more work would need to be done to get this usable than I originally thought...
This sounds like it isn't even the same format.
Also wait, just noticed you said "same size as an actual Famicom rip", did you mean FDS rip? Because if you actually meant Famicom as-is that'd mean it isn't even a disk image, but a normal ROM using the enhanced hardware. What's the exact size in bytes, just to make sure?
I did mean FDS. The size is 131000 bytes. I did some experimenting and found that if I replace the entire first side of the VC rip with the data from an actual rip, the original title will show up, but if I flip it to the B side, it throws an error at me. Even if it didn't, the only main difference between the original and the VC release is the title anyway, and it is the main reason I wanted to look into this, but it's starting to look like it might not even be possible.
I realise I should have said this from the start, but NES/FDS VC .wad files don't just have the ROM in a file inside the wad like N64 titles do; they're built into one of the .app files (which is actually a .dol executable and not a U8 compressed file). Sorry for not mentioning that, I realised it's probably important for this.
Kurausukun wrote:
Thanks for the tip--unfortunately, no matter what I do, FDSList tells me my rip has an invalid file number header. I'm starting to feel like a lot more work would need to be done to get this usable than I originally thought...
This could be many things... if the disk header seems fine but the file number header is wrong, perhaps the disk format of the VC emulator is laid out differently. (Maybe they include the stored CRC or something....)
If you paste here what bytes come at and after $00038 in the FDS image, maybe we could figure it out.
I'm not sure exactly what to look for, but I'll post what I see; starting at 0x00000038, the bytes I see are: 12 4E 02 08 E3 4B 03...
When I was comparing the two files, they looked mostly the same, but it looked like the information on my VC rip was shifted forward a few bytes.
Yes, it looks like 2 bytes (I guess, a missing CRC that the physical disk actually stores) are between each file in the image. The .FDS format doesn't store CRCs.
I'm guessing 124E("*NINTENDO-HVC*" crc), 02 08(#files on disk=8), E34B(CRC for 0208), 03 (start of disk file header)...
So if I wanted to make it work, I would have to, at the very least, delete every single CRC, which would mean I would have to know where each file starts in the image AND which bytes are the CRC? I just want to know exactly what I would have to do and see if it's feasible.
Yes, or modify FDSList.c or another program to skip 2 bytes after every "end of file" marker, and recompile it.
Well there's apparently only 7 or 8 files on the disk, so I wouldn't mind doing it manually... I just don't know how to find them is the problem. Should I just look for when the data looks shifted a few bytes and reason out which ones don't belong/are CRCs?