RE: Cat Box

On Fri, 24 Jul 1998, David Shoemaker (Comforce/RhoTech) wrote:

> I assume (not knowing just how the logic board works) that it poles the
> values of the switches as it needs them. As such unless we want to rewrite
> the CB code we would need to make the switch states available to the CB CPU
> all the time. That is why I thought it might work to just put a flip flop
> out there to pretend it was a switch that we set through the PC parallel
> port (with associated multiplexing ect).
>
> Same deal with the display outputs. We need to hold there states so that
> the PC can get at them when it needs them.
>
> If we could figure out a way to get a handshake of data from the PC to CB
> then we could avoid the buffering of the various signals completely. But I
> don't understand the CB logic board / code well enough to figure out how to
> do that.
>

        Why do you need to handshake? The original CB had no handshaking
of its switches. THe user flips the switches whenever he wants to.
There is no latching required.

        Are you saying that you can only send pulses along the Parallel
Port and not, for example, bring a line high?

> I figured as we don't have that many i/o's on the PC PP do to all the
> switches / displays at once we would have to do a loop of:
>
> Let user select function on PC
> Update switch settings latches as needed to do this function (or
> step of function)
>
> Read in the display
> Translate display data to screen in some manner (mucho easy
> on my part).

        This is a different story. If there aren't enough IOs, then we
need some sort of scheme to write the control signals to the logic board.

        Why not do it serially (i.e. using the Serial Port?) and have the
software continuously send the settings as part of some loop. There would
be another line to handshake the data, for a 3-wire interface -- CLK,
DATA, and WORD. WORD signals a new control word, and CLK clocks the
individual bits of data into the CATBox. Word can be a 1 CLK pulse, or
something else...

        Let me know what you think. If you like it, set the format for
the bits as you see fit, and then I'll decode them accordingly.

> The nice thing about doing it with the PC is if we have to do something that
> takes a few steps (like setting up the test pattern in the vector display as
> described in 20 steps in the CB manual) it could all be automated with one
> menu selection.

        Yup.
 
> The line drivers were kind of a given yea. The PP can only sink/source 3 or
> 4 TTL loads per line I think. I have a PP programming manual around
> somewhere I am going to have to dig out.

        That's not a problem. I'm not worried about the PP driving the
cable (Parallel Ports are designed to drive standard parallel port cables)
but I'm more worried about the MACH driving the cable to send data to
the PC. I screwed up on the Exorcisors, and thought that the MACH could
easily drive a 1 ft. ribbon cable, but that is not the case. Crosstalk
and, perhaps, transmission line effects, garble the signals before they
get to the CCPU board.

> Looking at the Schematic they appear to just cause the change in data to be
> based on either the rising or falling edge of the signal. If you want to
> check the schem yourself it is the top right part of figure 11.2 (page 40).

        Not a problem. Those can go in the MACH easily.

Joe
Received on Fri Jul 24 16:46:25 1998