Monday, October 5, 2015

Testing of SAC Interface box with Linux laptop hosting the Python program, 9 track tape drive arrives, and 1053 mumble mumble mumble


Last night, I went out with the fiber optic camera and hunted in vain for a view to show me where the spring needs to be attached. After my quota of 30 minutes of utter frustration, I walked away.


I found a good deal, under $150, for a laptop onto which I will install Linux and Python for permanent use with the SAC Interface Box. I just finished a USB Recovery Memory Stick so that if I wish in the future, I can recover Windows 8.1 (and use the free upgrade to Win 10), but right now I can wipe the Windows partition to stick on Linux.

After getting Debian Linux active, I had to retrieve Python along wxPython and other packages I use. The goal is to be able to fire up the same Python program as I did on my Windows 7 laptop, but then augment it with the SCSI support that will let me command my IBM 9348 tape drive. My install kept hanging up before it gave me the list of packages available.

I then downloaded the Ubuntu distribution and applied it to the laptop. I have a few miscellaneous issues to deal with but it is basically functional:

  • Trackpad (including mouse and mouseclick functions) not working
  • wired ethernet controller firmware must be installed
  • laptop hangs on restart or power down, must be manually powered down
I quickly fixed the first two issues, but resolution of the last is going a bit slow due to a spate of similar issues afflicting Linux on various Acer laptops. Fortunately, even if I don't nail this, it simply requires me to press and hold the power button down for a few seconds to complete a power down. 

I installed Python, wxPython, PyUSB, and a few others packages, which cumulatively should permit me to run the PC side Python program on this Acer laptop. It did - the application came up properly, although the appearance is different on Linux than on Windows due to differences between the native Windows graphics widgets and the widgets here. 

I had one problem - the library for USB access did not have sufficient privileges to access the USB link. The solution was to set up a 'udev' rule to give the device open permissions to any user - it matches on the idVendor assigned to Ztex (221a) during bootup and sets the mode appropriately.

My program comes up but then crashes after a few seconds of operation, causing Python to restart the interpreter. This may be because I am manipulating GUI elements from my threads rather than the main program, but it could also be any use of code that isn't thread safe such as my time.sleep.  I need to introduce thread-safe methods into my code. 

Some design thought is appropriate here, lest I just add a mess of patches and workarounds. The main status information from the 1130 is updated once per second, but from a thread which is where my crash is occurring. The solution for this is an event that I can post to cause the mainline process to do the updating of GUI elements - a pretty easy modification of the current code. Other areas of the code may need more subtlety. 

I modified the status update loop to a new threadsafe method, spawning an event that is processed in the mainline to update the GUI elements. Once it is working, I will replicate the mechanism for all the other places that manipulate the GUI from threads. 

By the end of the evening, I had all the GUI updating activities moved to the event processor in the main thread and calls successfully integrated in the various threads handling devices and status monitoring. When I resume testing, I will be working on testing the various devices implemented on the PC:
  • Virtual 1442 card reader and card punch
  • Virtual 2501 card reader
  • Virtual 1403 line printer
  • Virtual 2310 disk drive D
  • Mirror of 1132 line printer
  • Mirror of 1053 console printer and keyboard
  • Mirror of console bit switches

My new tape drive arrived, appearing to be in excellent condition. If I can figure out my solution to this drive's odd IPI-3 tape interface, I expect it will work well. As far as I can tell, IPI-3 was used exclusively by IBM for tape drives - while Sun and SGI has adapters, they were attached to disk. 

There are no manuals or schematics available for the drive either. Parts of its function are implemented with microcontroller software which are a black hole guarded by IBM's legal Kerberos, thus inaccessible and opaque. If I had a schematic I might be able to graft a different controller onto the drive itself, but no luck on that. 

No comments:

Post a Comment