RC 2013 WW – Wiring Design, and Protocol Thoughts

Project: The Sound of Violence.

Typical, RetroChallenge has only been “on” for two days and already I’m getting over-excited!

Thursday evening efforts resulted in a completely passive wiring scheme that will support a quick-and-dirty polling (ACK!) signaling protocol and should also allow an interrupt-driven signalling protocol with just a change of the custom host-resident software, if I have enough time to get round to such a change.


Hardware Signalling Overview:

The basic idea is that the momentary-action switches will alter the state of the modem-control signals Clear-To-Send and Carrier-Detect, which can be detected by a user-mode UNIX program. Of course, there needs to be a voltage-source for those signals, so the design uses the host computers own serial-port – the computer asserts Data-Terminal-Ready whenever the O/S serial-port is “opened” by an application program. Fanning-out DTR into *two* returning signals (if some fool presses both pedals at the same time!) should still work on short (< 20ft) cables, as RS-232 standard specifies maintaining the signalling voltage levels across the resistance of 38ft AWG26 cables. We’ll see!

The reference ground signal (SG) is not connected as the host serial-port hardware will pull it to zero volts DC (again, at least stably over shortish cables). There is no need for end-to-end common-ground as there are no other active devices on the cable.

So now to the odd part: the Transmit-Data line looped-back into the Recieve-Data line. I though of this whilst trying to come up with a method of programatically detecting the presence of the PedalBox – any characters transmitted by the host will also be recieved by the host, so we can use an echo-check. There are other devices that could be plugged in – a teletype, a “glass-teletype” terminal (such as a VT220), a printer, a real modem, or even another computer running a terminal-emulator program, and so on. Some of these will also echo back what we send, at least when configured at a matching baud rate. With the above wiring, the RX circuit is automatically clocked at the same baud rate as the TX circuit – in this design they are physically the same circuit! Thus the monitor program can perform an echo-check at multiple baud-rates and framing (1 stop bit, 2 stop bits, 50/110/300/1200 and 9600 baud). The chances of any of the other common serial devices being able to exactly bit-for-bit match what we transmit under those conditions is tiny. I have written a quick-and-dirty mini-program to test and prove that this wiring gives reliable multi-baudrate/multi-framing echo-check results  (via the breakout box, not on real PedalBox hardware because that doesn’t exist yet!).


So here we have a “digital” circuit where the two active signals are completely unclocked, and the “pair” of actually-clocked signals are automatically *passively* self-clocking and self-synchronising. It’s also fully-automatic voltage-level selecting too (so will work on RS-232 12V or RS-423 5V serial ports). Talk about abusing the interface! But in a standard-conformant manner… wierd…


The other advantage of the loopbacked TX/RX circuit is that it could (in principle) be used to enable a *much* more host-friendly interrupt-driven software mechanism. The UNIX/POSIX “termio/termios” API provides a read-timeout (selectable per-read or per-character) with 0.1 second resolution. The software could enable normal half-duplex flow-control on the port, so that data written via write() can only be seen via read() when the CTS line is asserted (-12V or -5V), ie when that pedal is activated. The software should also be able to use the termio/termios facility to request that it be sent a signal when CD changes state, ie: when the other pedal is activated; such a signal would terminate the read() call early, returnng an EINTR error code.

Of course, I’m getting way ahead of myself now, I still need to write the first-gen (polling) software – which just prints messages in response to the observed signalling.

The second-gen software will respond to the signalling by using the Solaris audio-control API. This will need a formula to convert the non-linear volume-level hardware values into a linear scale (darned awkward Sun hardware!). At that point, constructing the final PedalBox hardware would be sensible.

 *If* I get that far, then a look at going interrupt-driven would be possible.



2 thoughts on “RC 2013 WW – Wiring Design, and Protocol Thoughts

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s