[Coco] RS232 Schematics, was DriveWire survey

[CoCoList for Color Computer Enthusiasts]

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).

In reality, a peripheral only needs enough bytes to handle the work it 
is going to do.  I don't know enough about the Floppy Drive Pak, but the 
RS232 Pak shows up in address ff68-ff6b (4 bytes).  Thus, it uses 4 
bytes of the memory map, and it needs 4*8 bits of flip flops to store 
information.  In a real RS232 pak, the 6551 ACIA provides these 4 
registers, but a CPLD would need to copy this behavior, so it needs 32 
bits of data as well.


So, as a general rule, to emulate something in a CPLD, you need a number 
of flip flops roughly equal to the number of bits of data in the 
interface's registers.
> Maybe I'm not getting it since you mentioned hundreds and you know there
> aren't hundreds of lines on that thing... If you don't mind explaining I'm
> interested I'm getting a "high level" understanding of what involved.
Hopefully the above helps.
>
> Another (to me, the biggest) question: assuming an interface between the
> coco bus and a general purpose computer like a raspberry pi existed, could
> general purpose software (c or whatever) be used to implement all of the
> logic behind such an interface?
Yes.
> Could I write a program that is literally
> reading and setting individual lines on the bus connector any which way it
> wants (within timing constraints of course)?
You could, but it takes a pretty fast CPU to that that.  At 1.78MHz, the 
bus is only active for half that time (250nS), and that's not much time 
on the other side to do things.  It also precludes using a high level OS 
on the other side (latency and all that).  So, the better idea (which is 
what we are describing here), is to implement enough of a "protocol" on 
a CPLD to give some timing flexibility.
> Or are we talking about some
> intermediate form of communication where the program is talking to
> (something) and the coco is talking to (something) but the general purpose
> computer isn't directly manipulating the bus state.
  The "something" is the CPLD.  Think of it as a bunch of small TTL ICs.
> Sorry if that's obvious, I haven't quite figured it out :)
> Like I said before, I am not even sure if the difference in speeds between
> the two systems puts us into the realm of making fully arbitrary
> manipulation of the bus possible.  If it does allow that now or in the
> future.... My god the possibilities are endless LOL.
If we can sort out the timing concern and make that go away, then yes, 
the possibilities are endless.  And, resolving the issue for one 
platform resolves it for all platforms (except maybe the TI, which uses 
a truly weird bus setup, but the 6XXX and the 8080/Z80 setup follow the 
above rules)

Jim