[Coco] bitbanger I/O
KnudsenMJ at aol.com
KnudsenMJ at aol.com
Sat Mar 11 21:57:36 EST 2006
In a message dated 3/11/06 12:29:27 PM Eastern Standard Time,
webmaster at coco3.com writes:
>I assume that a FIRQ can be generated at the beginning of each incoming
>byte if the CD line is connected to the sending device's RTS or some other
>line that indicates that a byte is on the way.
ISTR that the hardware can only shoot an FIRQ on the beginning of each
*bit*, every time the line goes low (active). Oops, I'm not reading your whole
sentence. You are right insofar as any device that has an RTS or CD lead, it
will signal the start of a whole string of bytes, or message.
There was a trick to jumper the RD lead to CD on a simple serial interface,
so the first start bit of the first byte (and every other 0 bit afterwards)
would trigger the FIRQ. That's what I was referring to.
>I found some popular source code for Disk BASIC assembly for receiving at
>38400bps over the bitbanger port but it doesn't use the CD line as far as I
>can tell. I wonder how easy it is to get off-sync even though it watches
>carefully for the start bit. The program masks interrupts during the byte
>receive portion of the code.
The trick would be to keep the CD interrupt enabled to start you off, but
disable interrupts the moment you started to receive.
I want to make my CoCo to PC cable compatible with OS-9, but I'm not sure
if OS-9 can handle masking the IRQ interrupts while receiving a byte then
restoring the interrupts and not cause problems elsewhere in OS-9 like
lockups.
ISTR that OS9 didn't lock up during serial transfers, but the clock would
lose time. Some OS9 serial drivers had the reverse bug, whereby every CD
interrupt was taken as a clock interrupt, so the clock would get way ahead of
time. I think these "features" were long since patched out by the NitrOS gang or
even earlier.
My own serial MIDI drivers (31250 Baud) blocked interrupts during each byte,
but came up for air in between. But they only sent data -- receiving is a
bit tougher.
But generally, OS9 has always had some problems with the Coco non-hardware,
being designed as an interrupt driven OS and running on a machine that
requires interrupts turned off much of the time.
More information about the Coco
mailing list