silverdr_at_inet.com.pl
Date: 2005-11-15 21:58:35
On 2005-11-15, at 17:02, Antitrack@networld.at wrote:
> 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. :-)
Well, it seems feasible to me. But why I preferred the more
"analytical" approach is that I don't know how well (or bad) my
drives behave. If they're on the upper or lower tolerance limit or
maybe right in the middle. This kind of empirical approach would
require to perform the tests on a statistically significant number of
drives, exchanging the disks among them in order to be able to draw
more general conclusions...
Now, having said all that, I think I will have to do it anyway :-) Why?
After doing all the math I still have a small puzzle here:
2 BVC *
2 CLV
4 LDA $1C01
4 STA $1801 ; parallel port
6 DEC $1800 ; handshake
3 EOR $84 ; checksumming
3 STA $84 ; checksumming
----
24
2 DEY ; first 320 GCR bytes finished?
2 BEQ closing_bytes_677 ; yes - close it up
3 JMP next_10_GCR_bytes ; no - continue
----
31 cycles altogether?
Which is abt. 20% more than expected and it doesn't seem like being
stretched to the limits as I've seen this code working on a number of
drives and actually never failing without an obvious reason. Then
how? Is it actually utilising the hardware feature Spiro brought to
my attention or were the analytical calculations wrong? If it was
saving 2 cycles on the previous byte then it would still be good 29
cycles on the next...
--
Hardware, n.:
The parts of a computer system that can be kicked.
Message was sent through the cbm-hackers mailing list
Archive generated by hypermail pre-2.1.8.