[Coco] Timing problem with the CoCo and the WD1773 ?
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
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.
More information about the Coco