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

Warren Hoslet dermunda at hotmail.com
Sun Aug 6 23:38:08 EDT 2006


Does anyone know if there has ever been a definitive explanation of the 
timing problem that occurs on CoCos using a WD1773 floppy controller? I 
think this is referred to as one of the BLOB (Boot List Order Bug) problems 
with OS9 (and Nitros9).

I was having a problem with a sector I/O routine I wrote in which the first 
byte of the sector would sometimes be missed. Strangely, the FDC did not set 
the Lost Data status bit when this happened, so no error was being reported. 
I remembered reading a document several years ago that described a problem 
like this occurring when running OS9 on a CoCo 3 in the double-speed mode, 
but I was running on a CoCo 2 at 0.89 mhz. I searched the web but couldn't 
find any information about this.

After running many tests, I think I can confirm that the WD1773 definitely 
has a problem when the 6809 executes an instruction to read the Status 
Register ($FF48) and the next instruction following it is positioned at an 
address whose two low bits are both 1 (which the FDC sees as the Data 
Register).

For instance, if you execute  BITB ,U  to test for the DRQ bit in the status 
register, and that instruction is located at address $7001, then the next 
instruction will be located at $7003 and the test will sometimes yield Zero 
even when the DRQ bit is set (the read ends up clearing it).  However if 
BITB ,U is executed at $7003, then the next instruction would be located at 
$7005 and everything works fine.

Likewise, if you execute an extended form of the instruction (BITB $FF48) at 
an even address where both of the two low bits are zero ($7004), then the 
next instruction will be located at an address where both of the two low 
bits are 1 ($7007), and again the problem occurs.

I tested this using both a CoCo 1 and a CoCo 2 on all six of the 1773 chips 
I have (manufacture dates range from 1984 to 1987) and they all exhibit this 
problem. When I tried it with controllers using the 1793 or MB8877 
everything works fine.

So if anyone out there ever writes any CoCo floppy I/O routines which need 
to work on a 1773 chip, be sure to note where your DRQ tests are positioned, 
because there is a 25% chance that this nasty bug will bite you. I don't 
know if Tandy (or Micro$oft) was ever aware of this issue, but both versions 
of DECB perform their tests at 'safe' addresses.

I apologize if this is old news, but since I couldn't locate any info about 
it, I thought others should be made aware. I would be interested to know if 
this is a problem specific to the CoCo (or 6809/6883), or if other systems 
that use the WD1773 (Model IV) are similarly affected.

- Warren





More information about the Coco mailing list