Weird code in Disk II PROM (bootloader) startup sequence

3 posts / 0 new
Last post
Last seen: 14 min 46 sec ago
Joined: Apr 1 2020 - 16:46
Posts: 855
Weird code in Disk II PROM (bootloader) startup sequence

I was looking into the PROM P5 that is on the 16 sector / track Disk 2 card.

So far I seem to understand what is going on there, except for this code snippet just at the beginning:

C600 A2 20 A0 00 A2 03

which disassembles to this:

C600 LDX #$20C602 LDY #$00C604 LDX #$03

So when the program is entered at $C600, as some authorative sources claim, the first LDX# does not do anything useful, because X is overwritten by the LDX #$03 before the first X value loaded can do anything else.

I am wondering why there may be such an apparently useless instruction in that tight PROM space of only 256 bytes.

Here is my tentative conjecture:

It may have something to do with detecting specific cards plugged into slots and the LDX #$20 may just happen to be a sort of ID for the Disk 2 cards they had to leave untouched when they upgraded the Disk 2 card to DOS 3.3 in 1980.

The same authorative source ("Beneath Apple Dos") says there was a 13 sector to 16 sector / track upgrade, for which both PROMs on the Disk 2 card were changed. Since this tells us there was a legacy P5 PROM with a different program, the above conjecture may be somewhat founded on facts.

Anyone knowing more about this able to enlighten me ?

It may look like nit-picking as this boot PROM obviously works, but this is computer archeology, and archeologists do look into even the tiniest detail they may find. They find a single bone, and around of this single bone they write elaborate scientific papers claiming that they discovered a new branch of homo sapiens, among other shenanigans.

This code snippet above the is "bone" I discovered ;-)



MacFly's picture
Last seen: 24 min 41 sec ago
Joined: Nov 7 2019 - 13:49
Posts: 446
To understand why things were

To understand why things were the way they were, an archaeologist sometimes needs to become a paleontologist and analyze even older fossils.

Your PROM is a later version (P5 PROM 341-0027) - a descendant of the earlier P5 PROM 341-0009. Here's what the earlier version looked like:

LDX #$20LDY #$00LDA #$03STA $3C...DEX...BNE $C604


So, the LDX #$20 did make perfect sense in the earlier version of the card. It was a loop counter. The code was changed for later versions - but they left the first 4 bytes identical to the original controller. Not sure if the first few bytes were officially specified as a means to detect a plugged controller. But back in the day programmers would sometimes just go ahead and harcode such checks anyway. So Apple either knew there would be a problem with some programs if they changed the first few bytes - or they were just careful. That sort of things happened a lot...

Last seen: 3 weeks 2 days ago
Joined: Aug 18 2017 - 16:53
Posts: 164
UncleBernie wrote:

UncleBernie wrote:

> It may have something to do with detecting specific cards plugged into slots


That's true. There is a "firmware protocoll" based on the development of the UCSD p-System (Pascal). The first version used two bytes as signature bytes: $Cs05 and $Cs07 (s is the slot number). I.e. a disk controller was recognized by $03 and $3C. Later they had the Pascal firmware protocoll 1.1 and two more signature bytes at $Cs0B and $Cs0C.


Log in or register to post comments