[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