[Coco] RS232 Schematics, was DriveWire survey

[CoCoList for Color Computer Enthusiasts]

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.

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.

I have no sense of scale with hardware things though... I know the RPI can
do many mb/s throughput via SPI, but I don't know if that puts us in the
realm of keeping up with each line on the bus for each phase of each cycle
or not.  Also don't know if software running on a pi could easily keep up
with the those speeds or couldn't dream of keeping up.  So, maybe a
completely insane idea, or maybe a way to make a "software defined
peripheral".  I really don't know heh..

-Aaron