> while testing busy, I've always done it that way, all the code I've ever
> looked at does it that way, but the clean and simple static method seems
> to work fine. The Hitachi book seems geared to direct CPU bus
> attachments where there is not usually the option to "stall" the cycle
> as one can with a port connection, so maybe the diagram showing the
> continous E cycles is misleading here?

I had the opposite problem with a Philips 2681 DUART chip.  The device
includes /RD, /WR, and /CE; since the bus I had wired it to had a /CE1
[as well as /CE2../CE4] and R/W, the chip was simply wired with /CE=/CE3,
/WR=R/W, and /RD=(not)R/W.  Only one slight problem: whenever /RD is low,
any updates to the CPU-readable status registers are disabled.  Consequent-
ly, I had to perform a dummy memory write to ensure that /RD got toggled
before I checked for character-ready.  Odd...

> And does anybody lose any sleep about getting their 4 bit interface out
> of sync due to noise or whatever? I suppose that detecting a stuck
> "busy" bit would be a way to pick this up and reset the module.

I periodically do a variation on the "init" procedure to avoid this problem
since I don't have the R/W signal wired up and can't read status at all.  I'm
curious, though, what the device would do if an attempt were made to read 1/2
byte and write the other half or vice versa; anyone ever done that?