Seeking software for SGI/Sun dial box (was Re: IBM 6094-010 "Dials" protocol?)

[Ethan Dicks]

On Sun, Apr 8, 2018 at 5:48 PM, Glen Slick <glen.slick at gmail.com> wrote:
> On Sun, Apr 8, 2018 at 2:01 PM, Ethan Dicks via cctalk
> <cctalk at classiccmp.org> wrote:
>> On Sun, Mar 25, 2018 at 3:48 PM, Ethan Dicks <ethan.dicks at gmail.com> wrote:
>>> SN-921
>>>   https://upload.wikimedia.org/wikipedia/commons/7/74/Sgi_dialbox_sn-921_front.jpg
>>>
>>> DANAHER CONTROLS Dials DLS80-1022
>>>   https://upload.wikimedia.org/wikipedia/commons/c/cd/SGI_dialbox_DLS80-1022_front.jpg
>>

> What version of the dial box do you have? I have an HP A4362A dial box
> which looks identical to the pictures of the DLS80-1022 dial box.

I have one DLS80-1022 and one SN-921, both badged for SGI.  Because I
did not get the serial/power Y-cable with the DLS80-1022, I started
working on the SN-921 because it just takes +5V on either the serial
cable or a 2.1mm jack and was shipped with a +5V PSU for it and I just
had to pass RxD, TxD and GND back from it.

I have not put together a triple-voltage supply and custom cable for
the DLS80-1022 yet, but that may be in my near future.

I do have the necessary tools to trace out and monitor the comm
circuit on each dial box.

> I just hooked up the HP A4362A dial box to a PC serial port with the
> Y-cable and the +5,+12,-12 AC adapter and I get 9600,N,8,1 dial
> rotation data from the dial box as soon as it is powered on without
> needing to send any commands to the dial box first.

OK then!  My SN-921 is definitely *not* talking.  I will crack it open
and check the upstream of the RS-232 chip and see if the MCU is
generating traffic.  I'm entirely willing to believe the weak link is
either the onboard boost converter for +/-9VDC for comms or the
converter chip itself (not a 1488/1489 pair).  It's also possible I
have a dead unit, but there's more investigation to do.

> It appears that the data format is three bytes per dial rotation
> report. The first byte is the dial number, 0x80 through 0x87. The next
> two bytes are the twos-complement rotation count, MSB first,
> counter-clockwise negative, clockwise positive.

Very handy to know.  I was looking over the Python code and it seems
that there are a number of modes where the host sends some bytes to
modify the behavior of the dialbox before setting up an event handler
to catch bytes sent from the dialbox but I hadn't figured out exactly
what was happening at a bytes-exchanged level.  Your explanation is
entirely clear.

What I _think_ I'm seeing is the Python code sends a mode switch
command to get the dial box to auto-send dial events, so I wonder if
there are any firmware differences with units destined for HP and
units destined for SGI.  They could behave the same way when in the
same mode, but perhaps they are coming up in different modes.  It's of
course quite likely that I have a broken unit and there are no
internal differences.

Thanks for the helpful response!

-ethan