[Coco] RS232 Schematics, was DriveWire survey

[CoCoList for Color Computer Enthusiasts]

On May 12, 2014 1:48 AM, "CoCoList for Color Computer Enthusiasts" <
coco at maltedmedia.com> wrote:
>
> On 5/12/2014 12:11 AM, CoCoList for Color Computer Enthusiasts wrote:
>>
>> Forgive my ignorance here..  There are 40 pins on the bus connector but
>> when you ignore power ground and stuff nobody needs its probably ~30 that
>> matter.
>>
>> Does that translate to needing 30 latches, or is that not how it works?
>
> Realistically, it is not.
>
> The pins on the Coco bring out address lines and data lines.  THere are 8
data lines and 16 address lines (There's an EXMEM line, which I assume does
memory expansion, but I'll ignore it for now).
>
> That's pretty common for 64k 8 bit CPUs.
>
> Along with a handful of other signals (Read/Write, enable, Clock), you
can use those lines to address 64K of RAM. The reason this works is that
the address lines and the data lines make up a matrix.  the CPU stuffs a
set of bits on the address bus to indicate the location it wants, and then
writes or reads over the data bus. Thus, the total number of addressable
"latches" could be as high as 65536 * 8 (8 bits per byte, 2^16 bytes
addressable).
>

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.

Now I think I'm understanding that we are not in that realm of response
time, and instead we need to be decoding the address lines and have the
data ready to go in the intermediate CLPD.  The program running on the pi
would not be decoding addresses and dealing with data lines itself.
Apologies again if its insane to think we could do that part on the pi,  I
really do have no sense of reality here :)

Thanks for explaining it, I think I'm on track now.  The clpd is taking
care of the precise timing needed to play on the bus and has "buffers" for
the register space, so really the timing on the pi doesn't matter all that
much.

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.

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.

I keep forgetting to sign these.  Its Aaron