Windows Interface: Circuit DesignBy Mark David [21030170+]
The circuit as shown above has been completely built and tested with the following exceptions:
- I actually used a SN74LS378 chip (octal flip-flop) instead of the SN74LS377 (hex flip-flop), merely because I ordered the wrong thing. In fact, you could get by with fewer, depending on how many Chromas you want to hook up.
- For inverters, I used spare NAND (tie one input to high) or NOR (tie one input to low) gates.
- I never actually hooked up a second Chroma, since my expander isn't working right now. I did test the Chroma addressing logic, however, and the handshaking using LED's and buttons to simulate a real Chroma.
I don't think any of these differences will actually affect the operation of the circuit.
Starting on the left, the DB-9 connector connects the circuit to the computer's serial port. DSR (Data Set Ready) and CD (Carrier Detect) are both tied high; we're assuming that if the circuit has power that the Chromas are there and operating. DTR (Data Terminal Ready) is pulsed by the Server Object Library during its initialization to MR (Master Reset) on the UART. RTS (Request to Send) is pulsed by the Server Object Library to clock in a new Chroma address bitmap. TD (Transmit Data) will carry the serial Computer-->Chroma data, RD (Receive Data) will carry the serial Chroma-->Computer data. CTS (Clear to Send) will let the computer know when the UART is ready to receive serial data from the computer. RI (Ring Indicator) is not necessary.
The MAX235 (from Maxim) contains 5 RS-232 transmitters and 5 RS-232 receivers. Only 3 receivers and 2 transmitters are actually used - other versions of RS-232 transceiver chips with fewer drivers may be substituted. This chip is necessary merely to convert TTL logic (+5V/0V) to RS-232 logic (-12V/+12V).
The MC74HC4060A (from ON Semiconductor) is a 14-Stage Binary Ripple Counter with Oscillator. It is necessary merely to generate a 153.6 KHz clock, which will drive the UART in both directions. Connected as shown, with a 2.4576 MHz crystal, the Q7 output provides 153.6 KHz.
The CDP1854AC (from Intersil) is a UART (Universal Asynchronous Receiver/Transmitter) and the functional heart of the circuit, converting the serial data from the computer to parallel bytes for the Chroma, and vice-versa. Tying MODE low makes the chip compatible with the standard CDP6402 type UARTs. Tying CRL, PI, WLS1 and WLS2 high and SBS low basically puts the UART into permanent 8-n-1 mode (8 bit bytes, no parity, one stop bit) for serial tranmission and receiving. RCLK and TCLK are, respectively, the receive (from serial) and transmit (to serial) clock inputs, and are driven by the output from the counter. MR (Master Reset) resets the UART's buffers, and is fed from DTR of the serial port (controlled by the Server Object Library) via R2 of the RS-232 receiver. SDI (Serial Data In) is fed from the R1OUT of the RS-232 receiver, in turn fed from the transmitted data of the computer serial output. SDO (Serial Data Out) feeds the T1IN of the RS-232 transmitter, which feeds the data from the Chroma to the computer serial input. T0-T7 are the parallel inputs from Chroma 0, which are converted to serial by the UART and transmitted to the computer (see the FAQS for a discussion of why only Chroma 0 transmits to the computer). R0-R7 are the parallel outputs to the the Chroma(s). !THRL (inverted Transmitter Holding Register Load) is set by the Chroma to Computer Control Logic (see detail below). DA (Data Available) is set by the UART to indicate that a byte of parallel data is ready to be read. This is used in the circuit to signal !XOFULL to the Chroma(s), and inverted to signal CTS (via T2OUT of the RS-232 transmitter) on the computer serial port. !DAR (inverted Data Available Reset) resets DA when signalled, and is fed from !XOACK of all Chromas which received the byte. Design note: I'm hoping here that the acknowledgements from multiple Chromas are relatively close to each other, and that I don't need to keep track of acknowledgements individually from all the connected Chromas. The assumption is that the Chromas will all respond near-to-simultaneously enough that the lag between Chroma 0's acknowledgement and the last acknowledgment is not enough to reset and lose the next byte of data available for them. If this assumption fails, I will need to add some logic to track this; the reason I left it out to begin with was that, even for 2 Chroma's I needed 7 logic gates and thus 2 more chips.
The SN74LS378 (from Texas Instruments) is a simple hex D-type flip-flop, and is used to hold the bitmap indicating which of the (up to 4) Chromas is intended to receive subsequent Computer-->Chroma commands. The Server Object Libray sends a one byte command to specify this addressing: 6+cccc. I used 6 as the Address Chromas command because it's not otherwise used in the Chroma's defined command set. cccc is a bitmap of which Chroma's (0-3) to address with subsequent commands; e.g., 6A (01101010) will cause all commands subsequent to this one (up until the next Address Chromas command) to be sent to Chromas 1 and 3. The bit pattern of R3-R0 is clocked into the flip-flops by the RTS from the serial output, via the MAX235 RS-232 receiver 2 (I've only connected R0 and R1 in the drawing, which is for 2 Chromas). The flipflop outputs are subsequently NAND-ed with the DA signal of the UART to signal to the appropriate Chromas that a byte is ready for them to read.
Design note for multiple Chromas
The circuit as shown is for connecting 2 Chromas. All of the red or blue colored elements can be eliminated if you're only attaching one Chroma — just connect DA on the UART through an inverter to !XOFULL on the Chroma. If connecting 3 or 4 Chromas, you'll need to add another set of the red-colored elements; hopefully it's clear from the diagram how to do this.
The DA signal of the UART, inverted, connects to the CTS pin on the serial port. Thus, the computer will not be able to send any data to the Chroma while the DA signal on the UART is high; i.e., until one Chroma (and, hopefully, the other Chromas as well) have acknowledged the receipt of previous bytes. Actually, my test program ignored this nicety and simply blasted bytes through as fast as it could. Nothing bad happened, so I will probably remove this connection later, when I'm sure I don't need it.
Once CTS is high, the computer will send a serial byte of data through TD on the serial port. This will pass through R1 of the RS-232 receiver to SDI on the UART. When the UART has converted the serial data, it will become available on T7-0, and DA will go high. DA is NAND-ed with, Chroma-by-Chroma, the bits of the flip-flops indicating the Chromas addressed by the most recent Address Chromas command, and used to signal the appropriate !XOFULL pins to the Chroma.
When each Chroma has completed reading the command, it will lower !XOACK. These ACK's are OR'ed together into !DAR on the UART and will thereby clear DA and hence raise CTS on the serial port, signalling the computer that we're ready to receive another command.
Note that Chroma 0 is the only Chroma which can send data to the computer. First, we'll deal with getting the Chroma's byte to the UART. The logic that controls this is in the second diagram, titled Detail: Chroma-to-Computer Control Logic. The 74LS175 consists of four flip-flops which I've serially connected, output to input, to form a shift register. The input to the first flip-flop (D0) is usually high, and thus so are the outputs (Q0-Q3) of all flip-flops. The gate logic detects the state of the Chroma and the UART; only when the conditions are perfect is a new transfer sequence initiated. These conditions are:
- THRE on the UART is High; i.e., the holding register on the UART is empty and ready to receive a byte
- !XIFULL on the Chroma is low; i.e., the Chroma has a byte to send
- none of the outputs (Q0-Q3) of the flip-flops are low; i.e., we're not currently in the middle of a previous transfer sequence.
When all the above are satisfied, the input to Q0 goes low. Due to the 3rd condition, this will happen for exactly one clock pulse. This low pulse travels sequentially through the flip-flops. Q1 is used to trigger !THRL on the UART, and load the byte from the Chroma; Q3 is sent to !XIACK on the Chroma to acknowledge the transfer. (This particular spacing of pulses is used to ensure adequate setup time for the data before and after the !THRL pulse, which executes on the trailing edge). Back on the main diagram, the serial byte will exit the UART through SDO, and pass through T1 of the RS-232 transmitter to RD on the serial port.
The Address Chromas command
Transmission from Computer to Chroma occurs as with any command. Note: as this is an undefined command from the Chroma's point of view, it acknowledges it but ignores it. The (inverted) RTS line of the serial port is then subsequently pulsed by the Server Object Library to load the flipflop Q outputs based on the D inputs, which are fed from R0-R3 (the lower 4 bits of the Address Chroma command) of the UART.
January 14, 2001 - Ah, a bit too much hubris. It took this long to reveal a major design error. The previous version used logic to detect the 6cccc byte which is the Address Chroma command, and change the addressing of the Chromas accordingly. What I neglected to take into account is that, in the Chroma command structure, some bytes are command bytes and some are data bytes. Thus, any data byte whose highest-order 4 bits was a 6 inadvertenly re-addressed the Chromas. Using the RTS line of the serial port, pulsed directly by the Server Object Library, to clock in the Chroma addresses instead solves the problem, and results in a cleaner design anyway (although the MAX233 chip now has too few receivers and I had to upgrade the design to the MAX235 again).
November 14, 2000 - Fini! I thought the Chroma-->Computer communication would be much simpler than the Computer-->Chroma; I was very wrong. As you can see, I had to add a whole lot of logic between the two to handle the handshaking between them, and eliminated the computer's role in the handshaking via RTS. The reasoning behind this is explained in more detail in the Circuit FAQS. Notice also that the change on September 29th to a MAX235 is no longer necessary, as I'm back to 2 signals in each direction. Thus we're now using a MAX233 again. The circuit is now, operational and tested, subject to the caveats detailed above in the general description. On to the construction of the Server Object Library.
October 30, 2000 - The Computer-->Chroma operation is now fully tested and operational on my breadboard! I already know of a couple of design changes I'm going to make in the reverse direction, but I want to test them before I post.
October 30, 2000 - First real design flaw. I was using !XOACK (the inverted Chroma's acknowledgement of a command) directly from Chroma 0 to !DAR on the UART, resetting the DA (data available) signal from the UART. This works fine, until you try to send a command to only Chroma 1 (and/or 2 and/or 3). Chroma 0 never acknowledges - duh - because it was never sent the command in the first place. So I've added logic so that any Chroma !XOACK will reset DA. I will include logic in the server object library to ensure that at least one Chroma is always being addressed, thus ensuring an acknowledgment.
October 27, 2000 - The pin numbers on the Chroma DB-25 connectors were all wrong. Now corrected.
October 14, 2000 - Duh. I was right the first time. Forget the October 10th correction; Q4 is the correct pin to use for the UART clock. Q8 puts out 9600 Hz, but the UART wants to see a clock 16 times the desired bps rate (153.6 KHz); thus Q4. Also I tied SFD and RRD low on the UART just for reliability's sake.
October 11, 2000 - The pinouts on the MAX235CPG have been corrected. R1IN was previously shown as pin 4, now shown as pin 10. SHDN was previously shown as pin 9, now pin 21. Also, !EN is now not connected, as it doesn't seem to make any difference.
October 10, 2000 - The 9600 Hz output of the MC74HC4060A is actually Q8 (Pin 14), not Q4 (Pin 7) as previously shown.
September 29, 2000 - I simultaneously realized that I shouldn't have tied DTR high on the serial port, and that I had not figured out what to do about MR (Master Reset) on the UART. Problem solved. DTR will be pulsed by the Server Object Library during its initialization sequence to reset. But wait! DTR is an RS-232 level signal and my RS-232 transceiver was full! I've switched to a MAX235, which has 5 receivers and 5 transmitters - it's overkill, but it doesn't require any external capacitors. BTW, it was hard to get my hands on one of these; a place in Ohio called Electronic Surplus had 2, so there's one left. If you can't find one of these, there are many other types of these devices, any can be substituted. People with the know-how can also connect the RS-232 signal to TTL using a transistor as an inverting switch between +5V/0V. Jan Axelson describes how to do this in her book, Serial Port Complete.
September 28, 2000 - Whew! This certainly took a lot more time than I thought it would. No doubt that's because I haven't done any of this stuff in 20+ years. Anyway, first draft of the circuit completed.