[Coco] RS232 Schematics, was DriveWire survey

[CoCoList for Color Computer Enthusiasts]

On 5/12/2014 1:23 AM, CoCoList for Color Computer Enthusiasts wrote:
> Ok.. I sort of knew about that, was imaging a world where the program
> running on the gp computer would look at the address lines, realize "hey
> its talking to me" and set the data lines accordingly, so the register data
> would just be whatever the program presented on the address lines in
> response to whatever address the coco read.
It is possible to directly access the bus as a peripheral on something 
like an AVR or a ARM if the bus speed is low enough (1-2MHz) and the 
task is simple enough (RS232 might be possible), but as the work needs 
get larger, the time to do them gets less (can't use IRQs on the slave 
CPU, as just doing an ISR puts you over time budget), and on a 16MHz 
AVR, that's 4 instructions from time the address lines are on the bus to 
the time the data must be captured on a write or present for a read.  
It's tough to fit those constraints, and not doable for a GP system with 
an OS.
>
> That is actually similar to how we do this thing called the "Becker
> interface" which you might have seen mentioned here.. Its implemented in
> Gary Becker's FPGA coco and in all 3 of the main coco emulators now.   Its
> just two bytes or registers I guess if I'm getting the words right.. one
> for read/write and one for status.  The emulator or FPGA basically does the
> role of the clpd if I'm following things.  Anything you write to ff40 goes
> "out" and reading ff40 gives you the next byte coming "in".  Non zero in
> ff41 means theres a byte ready to read, and that's all there is to it.  I
> think I have the addresses right but there is a conflict with them anyway
> so forget that bit.
Yes, this a simple "interface"  How does one tell the "host" what it 
wants to do?  Is there a command byte, data byte structure for this 
"Becker" interface?
>
> Would that be easier / smaller than doing a 6551?  There is no timing or
> flow control beyond the status byte, but maybe the clpd could raise the
> interrupt line when the status byte was set by the pi?  Then coco wouldn't
> even have to poll status as it does now.
It entirely doable.

The SPI under discussion would jump start quite a few things, so I 
intend to implement that first.  The SPI can irectly interface with a 
number of things (including WizNET and CC3000 dev boards...

Looking at the SPI code now.  Hmm, looks like I need to get KIP's little 
breakout board...  Kip, do you do your boards in EAGLE?  Any libraries 
available?

Jim