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

[Gene Heskett]

On Sunday 06 August 2006 23:38, Warren Hoslet wrote:
>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).
>
That 'BLOB' bug was actually in the known specs for the GIME chip, and the 
fix was a 3 byte or so addition to the clock module.  No more BLOB.

>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.
>
This is a new bug to me.

>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

I'm not too sure how this affected a coco2 or earlier, but the clock 
patches that were first released by Eddie Kuhns as edition 9 clock modules 
for the various systems did fix it for the coco3's.  I never, ever had a 
boot problem with the earlier machines.  I ran a coco2 that thought it was 
a $20,000 Grass Valley Group E-DISK as personality profile storage for a 
300-3A/B video switcher for 13 years worth of 24/7/365 with no sign of 
that.  At dbl speed all those years.

All those problems should go away rather handily with the current release 
of that OS, now known as nitros9, see it at <http://www.nitros9.com>.  Its 
a free download.

-- 
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.