[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