Reading EPROM BIOS - programmer format

[Githin]

After a long break.

I am trying to plant a code in the VGA BIOS that I will be able to call later after I bootup in to MSDOS. I tired putting the code in the location where the copyright notice was written - but did not work. BETWIXT has already mentioned the reason for this not to work. I am going to plant this code in some other location - that is currently full of FF. I will also change the checksum found at 5FFF to match the update in code . Is that all is required to get the system BIOS to recognize the VGA BIOS? Is the location of the checksum correct? Is there a software (or method) to calculate the checksum?

Thanks

 

[betwixt]

It's worth a try. Normally, the checksum for the EPROM is zero, the byte at 5FFF is probably there to round the total to zero, bear in mind that only the lower buts are used to verify the EPROM, in reality, the total will have 'rolled over' and back to zero many times. If you add all the bytes together up to, but not including 5FFF (and possibly 5FFE if word rather than byte counting is used), the adjustment is 0-total.

There is a risk of another problem but you will have to experiment to see if it happens: the BIOS may be remapped or copied to shadow RAM at a different address, try to use relocatable code if possible.

Brian.

 

[Githin]

Thanks! Do you know for sure that in the 32k ROM the checksum is stored at 5FFF? Remember, this ROM is 32k, and all the odd bytes are stored in the first 16k and the even bytes are stored after the 16k.

 

[betwixt]

I'm not sure if there is a 'standard' way to do it or a fixed address, it may vary between manufacturers. I know IBM do it by making the checksum zero but maybe not everyone else does. IBM count words rather than bytes which implies the total could be anywhere between 0x0000 and 0xFFFF. If yours is word counted the adjustment would also have to be 16 bits wide and so one byte in each half of the ROM would be used to make up the total. Unfortunately, most EPROM programmers use polynomial CRC rather than simple byte counts so you may have to write a program of your own to produce the 'fudge' figure. All you have to do is sum all the bytes from first to (last-1) and put it's 2's compliment in the final address.

Brian.

 

[Githin]

Okay. The third byte in the BIOS after the 55 AA is "30". From what I found, this 30 indicates that the length of the ROM = 30 * 512 = 6000h. However, the code clearly jumps to locations beyond 6000h. How is that possible? My ROM is storing the odd bytes first and then followed by even bytes. But, I don't see how this makes a difference.

 

[betwixt]

You are correct about the ROM size and it ties in with the checksum adjustment being at 5FFF and I would guess at 5FFE as well. Regarding odd and even bytes, this is just the way the code has been stored in the IC, as far as the main processor is concerned the addresses appear linear and consecutive. Be sure that when you see a jump instruction, you are taking into account the destination address is stored in bytes in both parts of the ROM. Also remember that the physical address is represented in code as a segment and an offset so a jump to offset address 6001 which appears out of range may well be based from a segment address lower than the start of the BIOS, only long jumps which use specify segment and offset should be used to judge if it is within bounds.

There is another reason why jumps may seem to go beyond the ROM range, most ROM and especially EPROM devices are quite slow so in many computers their contents are copied to RAM before use. This can make a dramatic speed difference to video operations. Consider that an EPROM of that vintage may have an access time of 250nS and a RAM may be only 10nS so it makes sense to relocate the program by copying it into faster memory at a different address. The jumps may be into relocated code, not the original.

Brian.