Friday, September 18, 2015

Improved PC side program for SAC Interface box, 1130 not working


I have to figure out why the keyboard/console printer diagnostic, when mirroring keyboard presses, does not cause a line feed when I push the 0-8-2 key (shifted or numeric version of T). My analysis of the wiring indicates that the character must be read properly, thus this is a problem in the diagnostic program or typewriter.


The Python program on the PC side of the SAC link needs improvement to allow it to handle multiple virtual peripherals simultaneously. My design for this is to use multithreading - one thread per virtual device handler, plus a thread that manages communications on the USB link.

Any thread can request a transaction, which gets the lock to add its work to a queue and then waits on a semaphore. When the USB link thread has completed the interaction, it releases the semaphore to permit the device handler thread to continue executing. A queue entry has the request bytes, the address to store the response bytes, and the semaphore address for when it completes.

In addition to the virtual device handler threads, there is a machine status thread that periodically requests the state of various registers in the 1130 in order to display them for the user of the Python app. Too, I have to accommodate the thread that loads core from a file, because this also talks over the USB link.

With all the code changed and preliminary tests, the box is ready for more comprehensive testing. When I used it to monitor the 1130 status lines, I verified that the machine will not come out of reset, which matches the symptoms I was experiencing. I am expecting it is the fragile wiring deep inside the 1130 where the logic gates swung in close to the resistor panel. I pulled them out to inspect.

No issue I can see, but the machine is still stuck in reset. I will need to troubleshoot this issue, which might be a coincidental failure of a component in the 1130 but is more likely to be a problem I caused by manipulating the resistor panel.


If the 0-8-2 key (shifted T) is not working, you can deduce the contact(s) that are likely oxidized and not working. For example, the T key prints but in numeric mode, the 0-8-2 didn't cause a line feed. My deductions for this symptom are as follows:
  • The output of the keystem for row 0 is produced by bail 14 regardless of the state of the shift (numeric) key. Since the T is recognized, that works. 
  • Bail 5 emits row 3 only when shift is not activated and that works since T prints. 
  • Bail 8 generates row 8 when the shift is active, doing so for many characters which work well so bail 8 is fine. 
  • The remaining contact, latch 20, causes row 2 to be emitted when shift is active, but only for this keystem. Thus, if there is a problem, this would be the cause as this is unique to 0-8-2
  • If row 2 were dropped, the key stem would produce 0-8 while in numeric mode, a value Y character but that didn't print. Lack of a printed Y says that latch 20 is not bad
  • I have to conclude that 0-8-2 is being read properly by the diagnostic but not triggering the index operation (line feed), which is not a keyboard problem

No comments:

Post a Comment