Amtech RF512C DOS: differences to 1571 ROM (was: Amtech RF512C manipulates reading the ROM image with M-R)

From: Spiro Trikaliotis <ml-cbmhackers_at_trikaliotis.net>
Date: Wed, 6 Oct 2021 16:32:17 +0200
Message-ID: <YV2zcS7r5jYIZUXH_at_hermes.local.trikaliotis.net>
Hello,

here are the differences of the RF512C DOS w.r.t. a 1571 -03 ROM
(that is, a 310654-03 ROM):

The identification text at $8000 is different:

1571 -03 ROM:
00008000: 92 25 53 2f 57 20 2d 20 44 41 56 49 44 20 47 20  .%S/W - DAVID G 
00008010: 53 49 52 41 43 55 53 41 0d 48 2f 57 20 2d 20 47  SIRACUSA.H/W - G
00008020: 52 45 47 20 42 45 52 4c 49 4e 0d 31 39 38 35 0d  REG BERLIN.1985.

RF512C DOS:
00008000: 92 25 43 55 53 54 4f 4d 45 52 1d 50 52 4f 43 45  .%CUSTOMER.PROCE
00008010: 53 53 4f 52 0d 43 45 4c 4c 55 4c 41 52 1d 47 41  SSOR.CELLULAR.GA
00008020: 54 45 1d 56 45 43 54 4f 52 0d 0d 31 39 38 35 0d  TE.VECTOR..1985.

Note that $8000 (checksum) is left unchanged!


Then, at $8FB0, a surprising RTS to skip a function:

1571 -03 ROM:
8FB0 JMP $924E

RF512C DOS:
8FB0 RTS
8FB1 .WORD $924E ; unused leftover from JMP of 1571 ROM

What is this? Well, this is the implementation of the "U0>T" command.
It tests the checksum of the ROM (routine at $924E). If everything is
ok, the routine returns. If not, it jumps to $EA71, which is the error
blinking of the 1571.

They disabled this command, so it will always return.

Why? Because they did not fix the checksum! The checksum test will
always fail!

We will see another patch for this issue later at _at_@@@


Next, there is the patch for M-R at $C0B0-$C0C5. I already described in
my previous post. I will quote it here with some minor fixes, I gave the
address as $40C0 instead of $C0C0:

> The M-R is manipulated.
> 
> Let's look at the original routine:
> 
> 00CAFF  1                       ; store the address low/high at T0/T0+1
> 00CAFF  1  AD 03 02             lda     CMDBUF + 3
> 00CB02  1  85 6F                sta     T0
> 00CB04  1  AD 04 02             lda     CMDBUF + 4
> 00CB07  1  85 70                sta     T0+1
> 00CB09  1
> 00CB09  1                       ; determine the exact command to execute
> 00CB09  1
> 00CB09  1  A0 00                ldy     #$00
> 00CB0B  1  AD 02 02             lda     CMDBUF + 2              ; get relevant command byte
> 00CB0E  1
> 00CB0E  1                       ; test for M-R
> 00CB0E  1  C9 52                cmp     #'R'
> 00CB10  1  F0 0E                beq     _at_cmd_memory_read        ; execute M-R
> ...
> 00CB20  1               _at_cmd_memory_read:
> 00CB20  1  B1 6F                lda     (T0),y                  ; read the first byte at the given memory position
> 00CB22  1  85 85                sta     DATA                    ; remember it
> ...
> 
> That's all we need.
> 
> That is, the routine does the following: Read the LOW byte of the
> address to read from CMDBUF+3 ($0203) and store it at T0 ($6F), then
> get the HIGH byte to read from CMDBUF+4 ($0204) and store it at T0+1
> ($70).
> 
> Now, in the M-R, we read from (T0),Y byte by byte and store it to put
> it into the buffer to return.
> 
> What is patched in the ROM?
> 
> CB20 is changed to:
> 
> CB20 JSR $C0B0
> CB23 NOP
> 
> That is, the read and the store are manipulated.
> 
> Let's look what the routine does:
> 
> C0B0  A5 70       LDA $70      ; high byte of the source address
> C0B2  C9 FF       CMP #$FF     ; is it $FF?
> C0B4  90 0A       BCC $C0C0    ; now, it is lower (that is, != $FF) --> just proceed "as usual"
> 
> C0B6  AD 03 02    LDA $0203    ; get the LOW byte of the M-R source
> C0B9  85 70       STA $70      ; and store it as HIGH byte of the source
> 
> C0BB  AD 04 02    LDA $0204    ; get the HIGH byte of the M-R source
> C0BE  85 6F       STA $6F      ; and store it as LOW byte of the source
> 
> ; from here, this is a copy of $CB20: Read the value and remember it
> C0C0  B1 6F       LDA ($6F),Y
> C0C2  85 85       STA $85
> C0C4  60          RTS
> 
> 
> That is, the ROM manipulates the way the M-R commands read from the
> $FFxx area. Instead of reading from there, the M-R command reads
> starting from $xxFF. So, the last page of the ROM cannot be read with
> the M-R command.
 
Next comes the change at $CB20 that is also included in the code above.


The next change is at $E5B7:

1571 -05 ROM:
000065b7: c3 42 4d 20 44 4f 53 20 56 33 2e 30 20 31 35 37 b1  cBM DOS V3.0 1571

RF512C ROM:
000065b7: c6 44 44 20 44 4f 53 a0 56 33 2e 30 20 31 35 37 b1  fDD DOS.V3.0 1571

Note that they changed the text of "CBM DOS V3.0 1571" to "FDD DOS". For
this, they changed the "CBM" to "FDD", and shifted the space between DOS
und V3.0, so they output routine recognizes an end of the text.

The last change is at $EAE4/$EAE5:

1571 -05 ROM:
EAE4 BNE $EB1F

RF512C ROM:
EAE4 NOP
EAE5 NOP

What is this? It is part of the power-on self test of the ROM checksum.
You might have an idea what they are doing here, right? Yes, the ROM
checksum if wrong. Thus, they patched out the jump to the error (where
the floppy would start blinking), so it does not matter what the result
is.


This is is!

Thus, they did not only patch the drive to not read back the $FFxx area,
they even did it in a very stupid way, patching out the checksum
functions instead of fixing the checksum.

Did they really know what they were doing?

Regards,
Spiro

-- 
Spiro R. Trikaliotis
https://spiro.trikaliotis.net/
Received on 2021-10-06 17:00:02

Archive generated by hypermail 2.3.0.