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

[Gene Heskett]

On Monday 07 August 2006 14:27, Warren Hoslet wrote:
>>Robert Gault wrote:
>>...
>>
>>The correct explanation of the BLOB (there are others) is on RTSI.
>>www.rtsi.com/OS9/OS9_6X09/TXT  BlobStop.lzh   It is unfortunate that
>> this paper is under OS-9 as the problem has nothing to do with OS-9 but
>> rather is a Western Digital controller problem.
>
>-
>Thanks for pointing me to that information. I knew I had read about it
>somewhere. However, after reading it again and comparing it with my own
>findings, I now believe that it is not completely accurate.
>
>The paper suggests that the problem does not seem to plague systems
> running at 0.89 mhz, but I can reproduce it quite easily on both a CoCo
> 1 and 2 running at normal speed.
>
>It also states that the problem occurs when the instruction which reads
> the status register is executed at an odd address. This is not entirely
> true. If the instruction used is two bytes in length (such as BITA ,U)
> and it is executed at an odd address where the two low bits are 01, then
> the problem does occur. If it is executed at an odd address where the
> two low bits are 11, then it works fine. When a three byte instruction
> (such as BITA >$FF48) is used, then the problem only occurs if it is
> executed at an EVEN address where the two low bits are 00.
>
>This seems to suggest that it is not the address of the instruction which
>performs the test that is critical, but rather the address of the
>instruction which follows it. When the two low bits in the address of the
>following instruction are 11, you've got trouble.
>
>My theory is that the FDC logic which determines when the DRQ should be
>cleared is happening as the 6809 is preparing the address bus to fetch
> the next instruction opcode. When it sees 11 on the two low bits of the
> address bus, it thinks that a read of the Data Register has occurred, so
> it clears DRQ. But this theory has a problem: Why does an actual read of
> the Data Register seem to work correctly at any address?

This is similar to what I found also, although I did not nail it down to 
the two lsb's of the address being 11.  What I'm thinking is that the 
actual cs being applied to the wd177x chip is misstimed somehow, probably 
borderline in going true such that at the instant the 6x09 latches the 
data being read, the bus has not been fully driven by the fdc.  Or maybe 
it has a builtin thing that by the time the 6x09 latches, the data is 
stale and the bus is beginning to go tri-state.

Unforch, none of the docs I have, from both moto and hitachi, actually 
specify very tightly the data latch activation window timing in terms I 
could look at on a scope and make sense of.  While I was watching such 
transactions, I saw enough trash on the bus to last a lifetime, but the 
box was stable.  This was while watching it both during E both clock 
times, and during cs times doing disk access.

The only sure way to define that would be to build a dual one shot, 
triggered by Eclock, and diddle the apparent Eclock time presented to the 
fdc board, or the chip itself.  The dual would allow a delay of a full 
cycle if done right, so one could explore the early Eclock performance of 
the fdc too.

>- Warren

-- 
Cheers, Gene
People having trouble with vz bouncing email to me should add the word
'online' between the 'verizon', and the dot which bypasses vz's
stupid bounce rules.  I do use spamassassin too. :-)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2006 by Maurice Eugene Heskett, all rights reserved.