25

The Kickstart 1.3 ROM file that is supplied with Cloanto's Amiga Forever (amiga-os-130.rom) is very slightly different to that which you'd get by dumping a real 1.3 ROM from an Amiga 500.

Specifically:

  • Byte at 0x0019d changes from 0x08 to 0x20 (this appears to be in exec.library)
  • Byte at 0x2af9d changes from 0xb9 to 0xbc (this appears to be in trackdisk.device)
  • The checksum at 0x3ffe8 is updated accordingly

In both cases the ROM version is 34.5.

What is the purpose of these changes?

Improve this question

1 Answer 1

Reset to default
29

The first change is to patch this code:

00fc0196 266E003E                        movea.l         $3e(a6), a3
00fc019a B7FC00080000                    cmpa.l          #$80000, a3
00fc01a0 622C                            bhi.s           $fc01ce.l
00fc01a2 B7FC00040000                    cmpa.l          #$40000, a3
00fc01a8 6524                            bcs.s           $fc01ce.l

This code reads the size of Chip RAM from execbase and checks that it is no greater than 512kiB ($80000) and no less than 256kiB ($40000). If the value is outside the expected range, a full reinitialisation occurs because it's assumed that execbase has become corrupted. This is the source of the bug where reset-proof RAM disks did not survive a reset on machines with more than 512kiB of Chip RAM. The patch changes the maximum expected size to 2MiB ($200000).

I'm not familiar with the code patched in the second change, but it updates the opcode of this instruction:

00feaf9c B0B900008000                    cmp.l           $8000.l, d0

... from B0B9 to B0BC:

00feaf9c B0BC00008000                    cmp.l           #$8000.l, d0

This is clearly fixing a bug where the wrong instruction was used because the value at location $8000 will be random and it makes much more sense to compare against a constant than a random number.

Improve this answer
9
  • 2
    Actually the bug affected all handlers that were supposed to survive a reset (also called reset resident), not just the block-based Ram Drive (RAD).
    – blubberdiblub
    May 4, 2016 at 3:55
  • 4
    Besides the Ram Drive and other legitimate uses of reset residency, it also affected virii / malware that tried to stay resident. For naive users who were unaware of virii on their disks and who would often just use Ctrl+LAmiga+RAmiga to reset between different games, the bug may have slightly contained the spread of those to their other disks.
    – blubberdiblub
    May 4, 2016 at 4:03
  • 1
    A great answer! So the reason Cloanto would have done this is so that they could properly support 1.3 with some of the weird and wonderful options that WinUAE allows you to tweak, such as having an A500-alike with 2MB CHIP RAM, I guess.
    – Richard Downer
    May 4, 2016 at 13:53
  • 3
    @nsanderson: IIRC, there were (at least) two Workbench 1.3 versions, and one of them shipped with a SetPatch binary which also fixed this bug.
    – pndc
    May 6, 2016 at 9:35
  • 6
    No, it was not Cloanto who fixed the ROM, it was Commodore. The 34.5 Kickstart with the fixed code was the one shipped (temporarily, until 2.0 was frozen) with A3000. Commodore clearly noticed the non survival of reset-resistant software since the A3000 was the first system to ship with the ECS chipset (that can do 2MB chip ram). All the machines shipped before A3000 had a maximum of 512KB chip ram.
    – user180940
    Aug 31, 2016 at 20:35

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .