[Coco] Source code for High Speed Bit-Banger I/O

[Roger Taylor]

At 01:35 PM 4/27/2007, you wrote:

>Roger, I think we need to clarify things further.
>
>The fact that the 6809 can process incoming bits at115.2K baud is a given.
>Maybe I misunderstood your claim, as I took it to mean that the CoCo 
>can be busy flashing the cursor (and I assume checking for 
>keystrokes) while being able to sync with a 15.5 cycle start-bit 
>that can arrive at any moment.
>
>I can envision a simple protocol where the PC would first request 
>attention from the CoCo by issuing a serial BREAK (holding the data 
>line low) for a period just long enough for the CoCo to detect it 
>during an IRQ service routine. The CoCo would then transmit an ACK 
>back to the PC saying "I'm Ready", enter a tight loop to sync with 
>the expected start-bit, and timeout if none is received in very 
>short order.  Once the data starts flowing, the CoCo would dedicate 
>all its time to the reception task until complete.
>
>This kind of background processing could be accomplished with the 
>subroutines I posted. You just need to implement the higher-level 
>protocol on top of them.
>
>I guess I need more detailed info to understand exactly what you are 
>claiming to have achieved (maybe more than you are willing to reveal 
>at this point).


If I give all the details, I'm explaining the entire procedure, which 
I'm sure would make perfect sense then.  :)  First of all, are you 
sure you're not my clone?  :)  I think you, me, and Boisy could make 
one hell of a CoCo network scheme.

I basically modified the COMM example for 38400 bps but came up with 
almost the same code you did for 57600, but at 115200 bps I was 
getting bit errors sometimes.  This was using 2 CoCo's and the same 
exact bit timing (plus exactly the same start bit sync time), which 
is why I asked if you had actually tested the 115.2k ability.  True, 
the 16,15,16,15,16,15,16,15 cycle timing would have been conceived by 
anybody who put their thinking cap on long enough to figure it 
out.  That's about 15.5 cycles between the serial bits in 57600 bps mode.

The theory you described above about the CoCo being in full control 
has already been put to code and exists in every copy of the Rainbow 
IDE already.  It's not useable right now to anyone but me, but 
there's a hidden protocol I used for testing the 115.2k 
abilities.  It first serves a DLOAD'able program to a CoCo 1 or 2, 
then you EXEC the program/protocol whichs puts the CoCo in the 115.2k 
embedded slave mode.  The Rainbow IDE itself has some test protocol 
routines that sends continuous packets to the CoCo, with NO 
delays.  It blasts back packets the nanosecond the CoCo requests them.

I found a solution to another problem which I think you'll encounter 
when you expand on your theory and protocol code.  If you want the 
CoCo to be able to send and receive packets as quickly as the PC can, 
then something else needs to be done.  Notice the delay between the 
CoCo's stop bit and getting in sync with a new start bit for the 
block/packet receive routine.  What's the PC doing during this 
time?  It's sending, and is probably on it's 2nd or 3rd data bit 
already which the CoCo has already missed.  Well, normally it would.

Anyway, I'm glad we're talking about all of this and giving others 
the same idea, and hopefully somebody will come up with something 
very neat before others can get a chance.  I'm very tied up right now 
and have no choice but to complete certain projects before I can make 
a product out of what I've come up with.

Boisy, can your DriveWire product give OS-9 a virtual hard drive 
served from a PC?  If so, I'll skip trying to invent that and go for 
something else useful.