ROM Patches

[Loedown]

I don't have a great understanding of this.

Commodore release say WB3.1 and then has someone reverse engineered the ROM code to update certain drivers like SCSI and alike? Wouldn't new patches overwrite certain areas of code in the ROM if the new patch is bigger than the old one? Say original SCSI device is $0000 to $0100 for example and a new patch is from $0000 to $01FF, what happens then, are there pointers like a FAT file system or next address bytes ( track / sector ) like in C64 disks?

New code means new checksum, standard CRC16 or 32 or something else?

I also know in the Amiga units that use two ROM chips like the A4000 that the code was byte swapped, does that mean because you have an odd and even ROM that address $0000 is stored in even and $0001 is stored in odd as an example?

[Sandro]

Originally Posted by Loedown

I don't have a great understanding of this.

Commodore release say WB3.1 and then has someone reverse engineered the ROM code to update certain drivers like SCSI and alike? Wouldn't new patches overwrite certain areas of code in the ROM if the new patch is bigger than the old one? Say original SCSI device is $0000 to $0100 for example and a new patch is from $0000 to $01FF, what happens then, are there pointers like a FAT file system or next address bytes ( track / sector ) like in C64 disks?

New code means new checksum, standard CRC16 or 32 or something else?

I also know in the Amiga units that use two ROM chips like the A4000 that the code was byte swapped, does that mean because you have an odd and even ROM that address $0000 is stored in even and $0001 is stored in odd as an example?

it doesn not matter if the patch is a bit bigger than the old one ,for example if you replace scsi.device, the new one is bigger but fits in the 512k then is ok

remember roms 3.0 and 3.1 are not full at all, there are a few bytes free, I don't remember very well how many but around 5-10k

[Jope]

Usually the rom itself is split into the various modules that it's made of, then those modules are patched or replaced, then the updated modules are put together again to form a rom image. The checksum is calculated during the rebuild process. Scsi.device replacement is a split/rebuild process, because the new scsi.devices are so much larger.

Smaller rom patches, such as the ones blizkick does, operate directly on the commodore build of the rom, and those indeed utiliize the free space left in the rom. The checksum is again computed during patching. An example of an in place patch would be border blank or noclick.

[Loedown]

Thanks to both of you for the answers.

Has anyone actually mapped out the address ranges for each module in a Kickstart ROM?

How do the vectors work I wonder, it must have a TOC or FAT within the ROM itself so it knows where to look for each module?

[Jope]

Each module has a ROMTag in the beginning, thus they are relatively easy to find and dissect from the ROM image.

Resident modules with ROMTags can also live in RAM, exec uses the one with the highest version when it scans these after a reboot. This is how for example the RAM based scsi.device upgrades, and the OS3.9 setpatch rom update works. Even some viruses used to live as resident modules, but they usually don't replace any existing modules, they use this mechanism to survive resets.

Here's some info to get you started.
http://amigadev.elowar.com/read/ADCD.../node023F.html
http://amigadev.elowar.com/read/ADCD.../node035C.html

[Loedown]

Originally Posted by Jope

An example of an in place patch would be border blank or noclick.

Noclick would be easy to implement because you would be removing code not adding it IMHO, so less space to fill as you're removing part of the routine or you could just replace it with NOP.