Antitrack_at_networld.at
Date: 2005-11-15 17:02:00
Quoting Spiro:
> The 1541 takes the byte from port A, UC2, every 26 cycles (when writing
> to disk). Thus, you must write a byte there *before* the next byte is
> latched in.
>
>
> Now, assume at clock 0, the DC took the data from port A. The CPU has at
> most 26 cycles to write the next data there. Assume we write the data
> immediately after clock 0 there, that is, at clock 1.
>
> - clock before 0: PA is written by the CPU with the first byte
> - clock 0: PA UC2 is latched into the shift register, first byte
> - clock 1: PA is written by the CPU with the second byte
> - clock 26: PA UC2 is latched into the shift register, second byte
> - clock 51: PA is written by the CPU with the third byte
> - clock 52: PA UC2 is latched into the shift register, third byte
>
> Thus, you see, between clock 1 and 51, you have 50 cycles to write the
> data on the port. Of course, normally, you cannot use all the 50 cycles,
> as BVC * is not that exact. Wolfgang found out that "counting" 41 cycles
> works reliably.
I think this is very easy, and could be less hardware-oriented to find out
yourself, how many cycles you have left for your own code between reading or
writing two GCR bytes. You can do this without any hardware:
a) Write a reliable GCR Pattern to a normal sector, i.e. fill it with
data like (non-GCR!) $00 $01 $02 $03 $04.... $ff (i.e. 256 bytes)
b) read GCR data directly with some 1541 code:
(search for sync, skip header, wait for data-sync...)
$lda $1c01,
bvc *,
nop nop nop nop nop nop nop nop (test a few nops more or less)
ldx $1c01
Now, m-w akku and x somewhere, and RTS, and m-r them from c-64.
As soon as you see the X register containing not the next expected GCR value,
but one GCR value ahead, you know how many nops and thus cycles you have
inbetween two GCR read or write operations.
Correct me here if my hypothesis is bugging. :-)
Yours,
ATT
--------------------------------------
Ein Service von http://www.networld.at
Message was sent through the cbm-hackers mailing list
Archive generated by hypermail pre-2.1.8.