[Coco] Timing problem with the CoCo and the WD1773 ?

Warren Hoslet dermunda at hotmail.com
Tue Aug 8 00:30:08 EDT 2006


>Robert Gault wrote:
>
>The important part of this doc is not even/odd bytes. That just uncovers 
>timing problems in the 1773. The critical answer to the problem is
>not to reload $FF40 in the read/write loops.
>
>That means you don't use a loop such as
>readloop lda       $ff4b     get a data byte
>          sta       ,x+       store it in the buffer, point to next cell
>          stb       $ff40     enable halt mode
>          bra       readloop  continue till NMI
>
>Instead you use
>readloop  lda       $ff4b     get data from fdc
>           sta       ,x+       store byte in buffer
>           nop                 one more op code fetch for HALT
>           bra       readloop  repeat till NMI occurs
>
>When you change the read or write loops in this manner, the code no longer 
>is dependent on odd/even bytes. The BLOB no longer is active.
>
-
That doesn't have anything to do with the problem I was referring to. I was 
talking about the loop that you would use to wait for the FDC to indicate 
that it has found the first byte in the sector. This is accomplished by 
testing for the DRQ bit in the Status Register. This is where the 'real' 
problem occurs. If the instruction that tests the Status Register is 
executed at an 'unsafe' address, then the timing problems with the 1773 may 
result in lost data.

The solution that the author came up with was to not use such a loop, and 
just use the HALT mode to wait for the FDC. I don't particularly care for 
this solution because it prevents the system from being able to time-out 
when there is no disk in the drive.

The instruction to reload $FF40 was removed simply because it was no longer 
necessary in the author's modified code. That instruction was there to 
enable HALT mode, but since he now enables HALT before entering the read 
loop there is no need for it. He states that the NOP was added as a 
precaution to allow extra time for HALT to take effect (because it doesn't 
take effect until execution of the current instruction has completed).





More information about the Coco mailing list