[Coco] RS232 Schematics, was DriveWire survey

[CoCoList for Color Computer Enthusiasts]

On 5/11/2014 10:18 PM, CoCoList for Color Computer Enthusiasts wrote:
> On May 11, 2014 11:03 PM, "CoCoList for Color Computer Enthusiasts" <
> coco at maltedmedia.com> wrote:
>> On 5/11/2014 11:20 AM, CoCoList for Color Computer Enthusiasts wrote:
>>> For a new piece of hardware for connectivity options, would it not be
>>> useful to do it via USB?  In that fashion, with appropriate firmware, it
>>> could facilitate access to a variety of devices (ethernet, wifi,
> bluetooth,
>>> video, audio, joypads, memory/disks, etc) and adjust it's visibility to
> the
>>> Coco (ports, address space, etc) accordingly (via software)?
>>>
>>> Those of us without a multi-pak would appreciate a single cart with
>>> multiple (future potential) options, in a single cart.
>>>
>>> Wifi dongle plugged in - treat as serial (etc) to a Drivewire server,
> flash
>>> memory - treat as FDC (like CocoSDC) and/or HDD (like the SuperIDE), USB
>>> mouse - treat as a hires joystick adapter, video adapter - treat as a
>>> WordPak+, audio adapter - treat as an Orch90...  upon startup, the
>>> cartridge could (eventually) query the USB for device(s) and allow the
>>> enduser to choose functionality of the device(s), or even allow for
> direct
>>> access via user supplied additions to the firmware, onscreen, before
>>> returning control to normally scheduled programming ;)
>> The main problem with USB as a "super interface" is the driver aspect.
>   It's not an unworkable idea, but having given some thought to things over
> the night and day, it is apparent that all such solutions will require one
> component:
>> a Coco bus to uC/CPU bridge.
>>
>> When the Coco (or any system, for that matter) goes to read a byte from
> the bus, the data needs to be there already, because an ARM or AVR won't
> have time to go get it and stuff it onto the bus for the read, unless there
> is a wait state, and wait states are no fun.
>> I'm still noodling how to do that, as each legacy interface expects
> things in a certain way.
>
> Something I've been thinking about for a while is the idea of using gpio
> pins or spi on tiny computers like the raspberry pi to talk to the bus.
> There are big electrical and timing issues of course but I believe you can
> get chips that are a big array of latches, which then can be controlled via
> spi or similar things.
We're thinking the same way.  the device you're describing is a CPLD 
(Complex Programmable Logic Device).  I have a few sitting here.  A 
bigger brother is the FPGA (Field Programmable Gate Array).

For 1 byte-at-a-time things, like the 6551 (the recv register gets a 
byte, there is a bit in the status register that tells you that the byte 
is valid, you read it, and then watch for the next time the bit is high 
(status register, bit 3), things are OK.


>
> Theoretically if the bus lines can be read or set in the right ways at the
> right times, you can emulate *any* peripheral existing or imagined.  I
> suspect the scheme would work with most any computer using a bus type
> connector with just a physical adapter and the right programming behind
> it.  Since the RPI has USB, ethernet , any modern I/o you want then it
> would "just" be a matter of software shims translating between them.
The main problem is the "number" of latches needed.  That's the reason I 
wanted to know the registers for common things.

CPLDs are sold by number of "1-bit latches" (and logic elements, but 
that's not important right now).  So, an 8 bit register (as developers 
know them) is 8 latches (really, flip flops, but someone else can play 
the technical guru here, my explanation will suffice for the topic at 
present)

In the Xilinx space, the CPLDs are 36, 72, 144, and 288 latches.

BUT...  Onc you get into the 144 or the 265 space, you're getting quite 
pricey, and then it's time to move to an FPGA, which offers thousands of 
"latches" for not much more money.  For instance, An XC95288XL is 
$15.00, but an XC3S100 (which has 73000 latches) is only $10.51.

Altera and Atmel have similar solutions, I just picked Xilinx as I am 
more familiar with them
Jim