Date: 2005-10-03 18:03:06
On 2005-10-03, at 16:46, Groepaz wrote: > On Monday 03 October 2005 16:11, Baltissen, GJPAA (Ruud) wrote: > >> Hallo Patryk, >> >> >>> I am not sure if I am missing something very obvious but I >>> just don't understand WTH is the EOR $1801 for and .... >>> >> >> It won't help you but at least it gives you the feeling you don't >> stand >> alone: I don't understand it either. IMHO the EOR should indeed >> fill A with >> zero after the EOR. >> > > mmmh i know little about drive coding, but isnt $1801 an i/o port > which thus > might have changed in between the two instructions? Yes. That's the (factory-default) unused VIA port, which is in this case being used for parallel transfer - typical so-called "speeddos" cable. Theoretically it might change between the LDA and EOR but: a) there is no handshake between them b) the routine is supposed to receive the GCR bytes intact On the first pass it is clear that LDA #$00 : EOR $1801 is more or less equivalent of LDA $1801 and the byte gets stored on the disk via STA $1C01. But all the following passes are then different. Even if the timing between the host and the drive would be so arranged that no handshake is required and LDA gets the previous ($xx) byte while EOR gets the next ($yy) one - I can either get $00 or $xx EOR $yy, where none of those is the expected GCR byte... The problem is that it actually works somehow ;-) Oh yes, I checked the reverse routine and it does: BVC * CLV LDA $1C01 STA $1801 INC $1800 EOR $80 STA $80 BVC * CLV LDA $1C01 STA $1801 DEC $1800 EOR $81 STA $81 BVC * CLV LDA $1C01 STA $1801 INC $1800 EOR $82 STA $82 [...] hence no EORing of the bytes transferred to the parport... -- Democracy, n.: The triumph of popularity over principle. Message was sent through the cbm-hackers mailing list
Archive generated by hypermail pre-2.1.8.