Re: Fast GCR decoding?
Date: 2005-11-15 21:58:35

On 2005-11-15, at 17:02, 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

  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.