It seems to be almost the same file as the retail 1.10 BIOS... but there is a slight difference. I dumped it several times after reseating the chip and adapter, tested it OK in KEGA Fusion... but the difference in the code remains... FFFF - I'm going to say that's not a good thing. Is this how bit rot appears on an EPROM? Changes things to the letter F?
FFFF means that particular word wasn't written to. If the ROM works, (and by the look of it, the ROM does work) it's not bitrot but it was actually written that way. The header area you have differences at is not even important to the normal operation of the BIOS. The first 200 bytes of address space on the 68000 processor are something called "vectors" and it means to tell the processor core which addresses are each of the system software routines that handle hardware events such exceptions, interruption requests and other events. Also it happens to contain the initial boot vector for the CPU to jump at after a hard reset and the initial address for the main stack pointer. But point made, except for the bits of the vectors that are actually used by the Mega Drive all the rest is not important at all. The official SEGA checksum routine doesn't check the first 200 bytes of the rom as well, by the way. At the data "31 2E 31 30 4D 7A 4A 20" the value "4D 7A" is the actual ROM checksum. And if it's wrong, the console will crash with a black screen on BIOS boot. I know that, because my hacked ROMs have their checksum fixed, after patching and that value need fixing after I am done or else it will work only on emulators (Emulators do fix the rom checksum automagically, usually). So no, relax and your EPROM is not rotting. Edit2: Actual game cartridges are programmed to change the screen to RED should the checksum routine fails. The CD bios does not change the screen to red, whatever reason they chose to make it work that way is unknown to me.
Just seemed odd that it was supposed to be a standard 1.10 BIOS yet there were some Fs in place of "real data". All Fs would mean the chip is blank right? I figured if things were meant to be random values but turned to FF FF instead, that would be bad. Ahh heck, it's all new to me, people yell bit rot from the towers - guess it must have stuck with me. Thanks for the explanation l_oliveira! Question is, should I erase and reflash the chip or just let it be? :smile-new:
Offhand I'm not sure what bitrot looks like in terms of a dump in a hex editor but the fact that you have two pairs of FF side by side is too coincidental for my tastes. I'd imagine a more random pattern would make sense but I suppose it would also matter how the EPROM was stored and manufactured as well as its proximity to a nuclear reactor.
Leave it's as is, there's nothing wrong with it. Bit rot would cause bits on the EPROM to randomly change from 0 to 1. Blown (shorted) bits have the inverse effect. Blown bits can be seen when you erase the EPROM... They won't change from 0 to 1 after exposure to UV light.
Interesting, I couldn't find it noted anywhere. Oh well! I'll be sure to check any future purchases from Japan and the US for that matter for their proximity to nuclear reactors. Understood, I'll leave it as is and reassemble tomorrow (today) morning! Thanks for the help everyone! :congratulatory:
That's not bitrot. Although I'm not an expert on the MegaCD yet, I believe the MegaCD has some hardware that allows different data to be returned from the vector table region of the ROM area. At runtime, those vectors can be patched to point to new locations. I ran into the same thing when I dumped my MultiMega bios a few years back. As I recall, I had to dump the BIOS using a mirror of the ROM data from a higher memory address when doing the dump through the real hardware in order to get a clean copy.
Damn! That just sounds plain old awful! How does it work if the data is dumped directly off the EPROM in a reader though? The data on the EPROM can't be changed unless reflashed right?
Well if you dumped directly from an EPROM reader, your dump is correct. The dump that's currently out there must be bad then. All I know is, when dumping through the MegaCD hardware, you get different results in the vector table when dumping from the base address than from a mirrored address, so some kind of hardware is sitting in the middle, substituting data from the vector table.
Bitrot is the cells going from 0 to 1 - all 1's = FF So why couldnt that cell be bit rot? ignoring the fact we know it isnt, because of the checksum - I just mean the instantly dismissing it because its FF
The difference corresponds to HINT (level 4 interrupt) vector address: as said by Nemesis above, Sega CD has the ability to "patch" this vector address through a hardware register (This is used to have user programmed interrupt callback). The thing is that, by default (i.e on reset, when no value was written to that register), the returned value is fixed to $FFFF which is what you got there when dumping the Boot ROM through the console hardware. When dumping the Mask ROM directly, you got whatever value was really written in there but since the original value at this address can never be read by the console, it does not really matter. PS: the header checksum does not cover the 68k vector table at the start of ROM, so it can not really be used to determine if a dump is 100% correct or not
I have no idea what the differences actually mean. I can tell you that they do not mean bit rot though! :wink-new: Anyone care to elaborate, unless you already have of course and we've completely missed it.
Its been explained above - dumping via a running console you have a dump that is whats on the rom + a patched value. Basically its the same rom with some data that isnt used anyway.
