silverdr_at_inet.com.pl
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.