21 September 2013, 05:52 | #1 |
Precious & fragile things
Join Date: Feb 2009
Location: Victoria, Australia
Posts: 1,946
|
ROM Patches
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? |
21 September 2013, 06:48 | #2 | |
Banned
Join Date: Feb 2013
Location: spain
Posts: 897
|
Quote:
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 |
|
21 September 2013, 07:23 | #3 |
-
Join Date: Jul 2003
Location: Helsinki / Finland
Age: 43
Posts: 9,861
|
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. |
21 September 2013, 07:37 | #4 |
Precious & fragile things
Join Date: Feb 2009
Location: Victoria, Australia
Posts: 1,946
|
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? |
21 September 2013, 08:31 | #5 |
-
Join Date: Jul 2003
Location: Helsinki / Finland
Age: 43
Posts: 9,861
|
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 |
21 September 2013, 15:55 | #6 |
Precious & fragile things
Join Date: Feb 2009
Location: Victoria, Australia
Posts: 1,946
|
|
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Patches and FastRam | tolkien | support.Apps | 4 | 14 April 2013 14:45 |
Patches for Napalm | PopoCop | request.Other | 2 | 13 February 2009 17:26 |
060 patches ? | extralife | support.Apps | 7 | 11 October 2008 14:38 |
new OS 3.9 patches! | Bamiga2002 | News | 38 | 02 October 2007 22:18 |
SAS C - Can't install patches | jimbob | support.Apps | 5 | 07 October 2006 12:16 |
|
|