I used readnes on a baseball rom to split it into prg and chr. I also ripped the prg chip of the same game off the actual cart.
They are nothing alike. They are not even the same size. I played the rom and the cart and they play exactly the same. I tried burning the rom to eprom and I wouldn't play. Then I ripped the original chip to bin then burned back onto an eprom and it worked. I was under the assumption that all roms=prg+chr+header. How can I put roms on eprom if this is not so?
Thank you
What's the number of bytes in the two prg's? Some ROM's have a bit of other stuff, like the title or a trainer.
Scrambled address lines? Scrambled data lines?
Lloyd Gordon wrote:
What's the number of bytes in the two prg's? Some ROM's have a bit of other stuff, like the title or a trainer.
Depending on what I read the chip as it's 32 or 64k. The rom is 16.2k.
Then clearly the game is dumped wrong.
The .nes rom should be a 16 byte header followed by a power-of-2 sized prg rom and a power-of-2-sized chr rom.
also, what game is it exactly? theres one baseball game that was known to have a bad prg rom and nintendo actually made a game-genie style chip to 'fix' the rom so it would actually run!
LN
Its just called Baseball. It's possible the rom is from that game-genied cart but mine is a normal nrom.
Should I make a program to do byte-wise heuristics on a file, so that we can determine whether the data lines coming out of the ROM are scrambled?
tepples wrote:
Should I make a program to do byte-wise heuristics on a file, so that we can determine whether the data lines coming out of the ROM are scrambled?
Do you mean the chip was ripped with a13 set as a14 or some such pin mixup?
Skidlz wrote:
tepples wrote:
Should I make a program to do byte-wise heuristics on a file, so that we can determine whether the data lines coming out of the ROM are scrambled?
Do you mean the chip was ripped with a13 set as a14 or some such pin mixup?
That or, say, D7 swapped with D0. I've seen something like that happen on HuCard rips.
Here's something crazy to try: Open the PRG in a tile editor such as
8TED or Tile Layer Pro. It should look like garbage, but if you can find garbage that repeats, you have an overdump, and you can begin to investigate the address line problem.
tepples wrote:
Here's something crazy to try: Open the PRG in a tile editor such as
8TED or Tile Layer Pro. It should look like garbage, but if you can find garbage that repeats, you have an overdump, and you can begin to investigate the address line problem.
My dump seems to repeat what may or may not be "garbage". When set to GBA in tlp its obvious that it repeats and varies slightly from the rom.
I think I ripped it as 27c256 so 64k instead of 16/32? Minimum nes eprom size was 32k even though nes only handles 16, right? When ripped as 27c128 it turnsout a healthy looking 16k bin. This 27c128 16k dump still differs from the rom. In tlp/hex editors it looks like the same code just offset in places. But why did the rom give 16.2k?
Thanks for everything tepples.
What is the exact size (in bytes) of the ROM image? What is the exact size of the PRG and CHR pieces after splitting? What is the exact size of your rip?
Also, do you know if the ROM is in INES or UNIF format?
Rom=24592 bytes
Rom Prg=16602 bytes
Rom Chr=8195 bytes
Rip=16384 bytes
I don't even know INES and UNIF are. Header types?
ROM format types. Since UNIF unfortunately did not take off within the wider emulation scene, I'd wager that your ROM is in iNES format (if the first four bytes are "NES" followed by $1A then it's iNES, if those bytes are "UNIF" then it's UNIF).
The ROM size is correct at 24592 bytes. That's 16 + 16384 + 8192.
Wherever you are getting 16602 and 8195 bytes from is the weak link in the chain.
LocalH wrote:
ROM format types. Since UNIF unfortunately did not take off within the wider emulation scene, I'd wager that your ROM is in iNES format (if the first four bytes are "NES" followed by $1A then it's iNES, if those bytes are "UNIF" then it's UNIF).
It is iNES.
ccovell wrote:
The ROM size is correct at 24592 bytes. That's 16 + 16384 + 8192.
Wherever you are getting 16602 and 8195 bytes from is the weak link in the chain.
I'm splitting the rom with readnes from
http://www.raphnet.net/electronique/nes_cart/nes_cart_en.php
The terminal output says the proper file sizes but then makes the files too large. It does the same thing with Ice Hockey.
Possibly I need a new way to split roms.
Solved! somewhat...
I opened the rip and the rom in hex editors and found that the only difference was 0d0a in place of 0a. Now 0d0a is the ascii newline character. But 0d was appended to 0a not 0d0a inserted randomly. I don't really know what made this happen but a simple find and replace all made it match the rip exactly.
Any idea of how to get it to not do it in the first place?
Thank you everyone!
Text mode vs. binary mode. UNIX uses 0a for newline; Windows uses 0d0a. Implementations of C standard I/O on MS-DOS and Windows translate 0d0a to 0a when reading a file opened in text mode and 0a to 0d0a when writing a file in text mode.