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.