[Coco] RS232 Schematics, was DriveWire survey

[CoCoList for Color Computer Enthusiasts]

On 5/11/2014 10:30 PM, CoCoList for Color Computer Enthusiasts wrote:
> On Sun, May 11, 2014 at 11:02 PM, CoCoList for Color Computer Enthusiasts <
> coco at maltedmedia.com> wrote:
>
> Jim,
>
> I ran into the same issue.  The solution I found was to use a CPLD as a
> dual-interface memory between the Coco bus and the uC.  The CPLD can be
> clocked fast such that each device thinks it has exclusive access to the
> register.  A write from the Coco side triggers an interrupt on the uC
> side.  You could do the reverse as well if NMI was available.  If not,
> having the Coco device driver poll a status register would work.
>
> I haven't tested it, but my thought was that an SPI-type interface would be
> potentially easier.  Have the Coco load up one or more registers, and then
> trigger a transfer via a control register.  The interface board (probably
> just a single CPLD) would clock those bits out an SPI interface to the uC,
> loading what is received back into those registers.  A status register
> would indicate to the Coco that the transfer was complete.  Given how slow
> the Coco is, it's possible this transfer would happen within a single
> instruction cycle.  For bulk data reads, the status register could also
> indicate if the uC's data buffer was empty, or if it had more data to
> transfer - in that case, the Coco could keep triggering a read loop until
> the status cleared.  Make a simple SPI command protocol, and your uC can do
> arbitrary things on behalf of the Coco driver.
>
> I am completely swamped for the next 2-3 weeks, but now I want to test this
> out.  Unless someone beats me to it, I'll try to mock something up and post
> my results.
Someone has already created such a solution:  65SPI 
(http://sbc.rictor.org/io/65spi.html) (I have the VHDL and a converted 
Verilog of the internals if you'd like them)

But, I'm not a fan of this long term, as it requires everything be 
rewritten to use this.  It'd be OK for a first solution, but I think 
longer term, people would prefer that they could use older SW with this 
newer device.

Still, this will work.  I also see a nice Wifi SPI solution (cc3000) and 
WizNET makes a nice SPI Ethernet (Wiz5100).  Both require a bit of 
lifting on the 6809 side to set things up, but the bulk of the heavy 
lifting is done on the cc3000 or WizNET (4 TCP/IP channels, WPA/WPA2 for 
Wifi, etc.)

Long term, though, I think an FPGA with level shifters and some dual 
port IO would be best.

Basically, create a dual port RAM, with a few registers having special 
functionality:

On data recv registers, when the host (Coco) reads the register, set the 
register value to 0, and IRQ the uC that the register was read (so the 
uC can load more data into it)

So, have an IRQ register on the uC side.  Each bit of the register shows 
which register was written or read, and the uC could handle them all at 
once, clearing the status for each one and then waiting for more to happen.

The downside to this is the need for 2x the number of registers (for 
each byte in the Coco address map, there is an 8 bit write-only register 
and an 8 bit read-only register).  So, for the 6551, that's 64 flip 
flops needed.  Not horrid, but if one tries to handle a few peripherals, 
you're moving into FPGA-land quickly.

Still, if the Coco community says "Well, Jim, SPI would be good enough 
for the interface", then these parts are easy to assemble. And, Boisy, 
this would be the easiest way to hook the Arduino into the Coco, but it 
would potentially comsume the SPI port on the Arduino, which could be 
bad.  For the Raspberry Pi folks, it turns out that the Pi has an SPI 
port on board: 
https://learn.adafruit.com/adafruits-raspberry-pi-lesson-4-gpio-setup/the-gpio-connector. 
Sadly, the Pi is a master-only mode device... :-( Sadly, all the 
Linux-type boards (Pi, Beaglebone, etc.) all support master only mode, 
which is a showstopper if the goal is to bridge to a larger CPU and then 
use the myriad of USB drivers to get Wifi, printer, flash, etc. :-(

But, other options might exist.  In any case, Matt, I'd suggest we 
concentrate on 65SPI first, as that opens a lot of doors, and it's a 
pretty easy interface.

JIm