SGI SN-921 dial box working! (was Re: Seeking software for SGI/Sun dial box)
ethan.dicks at gmail.com
Mon Apr 9 19:01:55 CDT 2018
On Sun, Apr 8, 2018 at 5:01 PM, Ethan Dicks <ethan.dicks at gmail.com> wrote:
> On Sun, Mar 25, 2018 at 3:48 PM, Ethan Dicks <ethan.dicks at gmail.com> wrote:
>> I'm going to test this code out when I have a dialbox in hand.
> I have now tried this and am not having success. I have a traffic
> light on the serial cable and I know I'm getting chars out of the host
> and that I don't have TxD and RxD swapped. I'm not seeing any
> responses from the dial box and the python script does all the
> initialization and just sits there. Frobbing the knobs produces no
> blinks on the traffic light and no text from the script.
OK. I got the script working and two things were impediments:
1) One of the SN-921 pinouts running around on the 'net is incorrect,
as I posted. The *correct* place for the ground is DE-9 pin 7. I was
apparently getting enough of a parasitic ground to get chars *from*
the SN-921 but not *into* the SN-921.
As it turns out, it appears the SN-921 as set up for the SGI is mute
except for a single status success byte 0x20. If you send it an INIT
command (also 0x20), it will respond with its success after a fraction
of a second, which leads to another problem...
2) The python script dialbox.py slams the init code and a command to
set the dials to auto-report all at once, before the SN-921 has a
chance to initialize. So to fix that, I added a few extra lines to
send the 0x20 INIT command, pause, check for a 0x20 response (INIT
GOOD) _then_ send the AUTO command (0x50 0x00 0xFF), which sets all 8
dials (one bit per dial) to send back a 3-byte packet when twisted.
With the custom serial cable fixed and the init sequence fixed in the
Python script, I'm now getting the right data stream when I twist any
of the knobs.
I did get a copy of dialbox.c from
http://www.geocities.ws/joekrahn/dialbox.tgz Jim Stephens tracked
down that there was a massive GeoCities scan done in 2009 and the file
I was looking for happened to be scooped up then. There are a number
of dial box and button box command sets in that code which reveals
some of the more complex behavior possible.
Here's a slice of the command byte definitions...
#define DIAL_INITIALIZE 0x20
#define DIAL_SET_AUTO_DIALS 0x50
#define DIAL_SET_AUTO_DELTA_DIALS 0x51
#define DIAL_SET_FILTER 0x53
#define DIAL_SET_TEXT 0x61
#define DIAL_SET_BUTTONS_MOM_TYPE 0x71
#define DIAL_SET_AUTO_MOM_BUTTONS 0x73
#define DIAL_SET_LEDS 0x75
#define DIAL_SET_ALL_LEDS 0x4b
It should be possible to write up a protocol definition from studying
the code. I do not have one of these button boxes so I can't validate
More information about the cctalk