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 ;-)
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...
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.