Saturday, April 30, 2016

Iconized menus on the new GUI


Restructuring the GUI

I continued to build out the main GUI, adding the new menus and doing testing of the View module for the 1131. Here is how it looks with certain signals active (bright yellow) and one of the three button/lamps lit.

Testing updated GUI main panel

I installed small pictures of the peripherals into the Devices menu for esthetic reasons and have tested their appearance.

Icons on Device menu list

When these items are selected from the Devices menu, they will create a window as they activate the device function, or destroy the window if the device is deactivated. The window for a device will contain buttons and other information related to that particular peripheral, such as file names or card counts.

Friday, April 29, 2016

Finalizing GUI appearance for main 1131 screen, investigating Calcomp drum repair


Restructuring the GUI

I converted the main screen to a black background, to appear more similar to the 1131 display panel. I don't have all the signals shown on the physical 1131 panel, otherwise I would make it a copy. In addition, there are some signals that are either not presented on the 1131 or illuminate buttons near the keyboard, rather than light a lamp on the display panel.

I chose to use a black background, light grey blocks for labeling text, and the numeral as they would display on the 1130. That is, they are light grey if off but an incandescent bulb yellow when the lamp is lit.

The top row is the Storage Buffer display, showing the 16 bits of the B register. Just below each four bits is a hex digit translation, as a convenience for the user. The next row has the Interrupt Levels and the cycle stealing flags. Third row shows the clock signals I have on the interface, T0, T2, T4, T6, X0, X2, X4 and X6 as well as Clock Out and Phase A. The final row has the remaining status indications (reset, parity stop, and XIO E1) set up as if they were buttons on the keyboard panel of the 1131.

Main 1131 screen with a few signals simulated as on
I haven't activated the new menus yet that will allow me to select various devices, popping up a window for each as it activates, and perform other functions such as loading core from a file.


A reader of the blog suggested finding people who restore vintage automobiles and asking them if they can handle the drum from the plotter. I first approached a couple of services I found that did metalwork on aluminum classic vehicles, but may also check with the service recommended by the reader.

The first shop I contacted is preparing a rough estimate for me, since they think this is something they can do and would be willing to take on. A ray of optimism strikes my workshop!

Tuesday, April 26, 2016

Dead end with plotter drum fix, but moving ahead on GUI restructuring


Debugging the resilient high speed link between fpga boards

This is going to be a priority since I can't properly test my paper tape interfacing if the link to the slave fpga board isn't solid. Since I am restructuring the entire GUI program at the same time, I have to keep the 'old' GUI around in order to do the link testing.

Restructuring the GUI

I began moving code from my old GUI program to the new MVC model. The device functionality is the most straightforward to move since it is closest to the model pattern. First up was the virtual 2501, but I ran into design problems stemming from how Python deals with dividing a program into multiple files. In that scenario, there are no global names.

Design is everything with OO code, and then refactoring will clean up the program even more. Since I will build this out of many classes and separate modules, I will put in testing for each bit I build in order to validate how it behaves. This will be faster than completing the entire program and then debugging complex functions such as virtual peripherals.

Another dimension to designing this is the use of threading for the various peripherals. The code that communicates over the USB and to PC based files is in a separate thread per device. However, the GUI interactions have to occur in the main thread. Thus the View part of each device is running in the main thread and getting notifications from the Controller and Model in the device thread.

The challenge exists of updating data in the Model since the requests come from the main thread during some GUI interaction but have to change data that is also being manipulated independently by the device thread Model. I have to figure out a solid thread-safe method for doing this.

I came up with a few methods for this:

  1. Use Queue which is thread safe
  2. Introduce interlocking protocol and data fields that are globally accessible
  3. Stage changes via device methods and use a lock to control collisions
I chose method 3 where I will provide a method to set up a change, add a method to look for existing requests, have the main device loop look to see if there is a pending change, and use a lock to ensure that I can't lose any changes. To do this in the best spirit of Python, I should factor out the code and generalize this so it can be used by all the device handles with minimum duplicated code.

I created the generalized approach and piloted it in the virtual 2501 model, where it looks like it will work fine. Now I have to work on the controller and view modules for the virtual 2501, to process the file open, mode setting, and boot button events and to properly display the status in its window.


I drove over to the Service King auto body repair shop which advertised that they worked on aluminum car parts, but when I got there they told me that they didn't have the specialized tools to work on aluminum and would instead send that work over to their Fremont location. Wasted trip, have to drive over to Fremont later.

I spoke with them on the phone and was told they would not consider a small job like this. At least I saved the time involved in a drive. Time to look for some alternatives. 

Saturday, April 23, 2016

plotter work on SAC Interface: new board, GUI enhancements


Testing new board and Vivado toolchain results

I used a file set up to load a small area of core, ran it and checked to see if the proper locations were set as they should. Everything worked as expected and I now have the new fpga board up and ready for further progress.

Restructuring the GUI

My current design is a main window that has menus, a dark gray background and emulated lamps similar to the 1130 control panel. It will have several rows of information.

The first row consists of 16 digits, 0 to 15, that represent the state of the B register. Below each nibble, one hex character will be shown making it easy to move between absolute bit positions, binary values and hex values.

The next row (3) displays T clock and X clock values from the SAC interface, that is T0, T2, T4, T6, X0, X2, X4 and X6 as these are the only ones brought out from the 1130.

Row 4 will display the six interrupt levels IL0 to IL5 and a Cycle Steal indicator.

Row 5 has the remaining system status conditions displayed - Clock, Phase A, InhibitCS, XIOE1, ParityStop and Reset.

One menu, Devices, will display a list of devices as icons, allowing any combination to be activated or deactivated by selecting the icon in the list.

The File menu will offer the ability to stop the application, plus open or create actions for files for the various peripherals, but is intended to grow over time to support logging files and other tasks as needed.

I envision a window showing all the files that are available in the main data folder - with a nice icon for card decks, printer listings, disk cartridges and core contents. This will allow the user to drag and drop a file from this window onto one of the peripheral windows, causing the file to be mounted/opened if the device has no current file. This is in addition to the File menu and device oriented button methods.

Any activated device will display its own window with buttons and indications specific to that device. For example, it will allow PC files to be opened or created for virtual/mirror devices, request a Boot from a card reader device, or load a PC file as a virtual 2315 disk cartridge. The user can press an Open button or select the open from the File menu by clicking the menu or using a hotkey combination.

I began coding up the Model classes to hold the state and behavior of the 1131 and the various peripherals. These will be interrogated by the View components to display on the GUI. The Controller component will drive the transactions between the fpga and Python, trigger the View components if there is a change in state, and update the Model components.

Restoring Calcomp 565 plotter and converting it to IBM 1627

I will take the drum to an auto body repair shop, Service King,  that claims to have expertise in repairing aluminium car parts. Hopefully they can restore the cylinder to near-original condition, after which I can do any filling of low spots to get a smooth drawing surface.

If the original drum can't be repaired, there are two options I have been thinking of. First, I can cut off the end inch or two of the current drum, where there is no dent, form a new center section and get this rejoined. Second, I can laboriously remove all the pin-fed paper pins from the current drum, build a replacement drum, drill holes for the pins, insert a threaded rod into all of the removed pins and fasten them to the new drum.

Neither of these are appealing options, with the first a bit more attractive than the second. I would need to add a filler over the joins but this is not very difficult. The more difficult problem will be in making the join of three aluminum sections.

I decided to create an interim pen assembly, using a new solenoid with a make-shift pen, which I can mount on the plotter temporarily to test function. Later, I can have the proper parts machined that matches the Calcomp unit cosmetically as well as functionally.

I have the manuals and other data I need for the restoration and testing of the plotter. I did have to buy a 19 pin cannon female connector in order to connect my restored plotter to my interface electronics. Others have reported paying over $125 for the connector, but I found a new-old-stock connector on ebay for $33 including shipping.  

Monday, April 18, 2016

Have new fpga board working correctly


Implementing mirror 1442 reader/punch

My check box for the mirror mode of the 1442 is too far to the right and cut off on the GUI. Since I am changing the entire structure and interface, that will be resolved at the appropriate time. As I had said earlier, I can't test mirror mode until I have a working 1442 reader/punch. My 1442 has a broken part that needs some special reconstruction.

Testing new board and Vivado toolchain results

I found an additional parameter - enable flash bitstream - which I put into my source file for the USB firmware. With that installed, I had the board configuring itself from the bitstream and talking well to the Python code.

Next, I solved the anomalous status by finding that one of the two connectors to the ztex fgpa board was loose and making partial contact. With that rectified, I had very good results from single stepping through instructions - all the clock times and status I checked were spot on.

Next, I set up a memory file to load core to verify the operation of the new board. I will take that on tomorrow after I visit the dentist. 

Program on firmware for new fpga board, also working to restructure GUI program

Infected tooth, whole side of face swollen, and waiting for root canal on Tuesday with lots of painkillers. Not accomplishing much else.


Testing new board and Vivado toolchain results

After chasing a long and twisty set of requisites, I finally was able to compile the firmware for the USB module on my ztex fpga board. I had to have a Mingware unix environment on Windows, the Small Device C Compiler (SDCC), the ztex macros, the Java JDK, and all the files organized correctly. With the file generated, I went out to load it onto the board and check for functionality.

The latest file will show up as my SAC firmware and lets me communicate between the Python program and the new board. My B register display is not correct, which suggests that I have some of the assignments of fpga pins incorrect. Basic things like clock, phase A, reset and interrupt levels were correct. I will have to work through this carefully to get it right.

I still have the immensely annoying failure to boot from the bitstream that I loaded into flash. Everything reports back as if it is correct - right USB firmware, lists flash configuration support, shows the file successfully written to flash, but it powers up in the unconfigured mode.

I really wrestled with this problem back on the older version of the ztex board, sitting down with Richard Stofer to figure out what needed to be done by comparing his boards and mine, but at some point it all started working properly. Unfortunately, when the real cause of the problems is not known, and the steps which fixed the problem aren't understood, it is very hard to recreate the solution on the new board. Grrrrrrrrrrrrrrrrrrrrrrrrrr.

Restructuring the GUI

I did use the time to build up my knowledge of the wxWidgets for constructing a GUI, specifically the Python wrapper for the toolkit called wxPython. There are several layers of knowledge buried here - Python itself, wxPython binding, the wxWidgets toolkit/API, and then the underlying details of the GUI environment on Windows/Unix etc.

One of the things I will also be doing during this process is refactoring the code, making it more elegant and Pythonic (an adjective that is important to those that program in this language). Since I am also restructuring to the model-view-controller pattern, there is going to be a bit of code moved around.

Thursday, April 14, 2016

More battles with toolchains for the new fpga board, along with work on the revamped GUI


Testing new board and Vivado toolchain results

I grabbed the special load for the Cypress FX2 USB module that I used with my ztex 2.01 board and installed it on the new fpga card- that should permit communications with the PC program. If it also supports auto bitstream loading on power-up, I will be set otherwise I have some work to do.

I got some version error messages, but forced the usb file on. It no longer is reachable at all from the PC and it does not turn off the 'unloaded' LED on the fpga, but otherwise reports to the ztex utilties that the fpga is configured and everything is good. Clearly not.

This means I have to set up the whole cumbersome toolchain to compile the USB firmware with my desired endpoints AND the ability to autoload from flash at powerup. This was a multi day pain in the rear when I last did it, but it appears I have no choice.

It involves modifying some C code with macros to specify the functionality of the USB device, then compiling it and loading that firmware into the microprocessor inside the Cypress module. Once I get the special C compiler working, the macros installed and setup my C code, I should be able to generate the firmware.

Working on revamped graphical user interface

I did a layout of the new GUI, which will display four lines of status and then have a grid of 10 picture buttons, five across by two, for the peripherals, each with an image of the physical device. Depressing a button will bring up a separate floating window to control that peripheral.

I still have to design the various floating windows for the peripherals, then the trivial matter of writing all the code to implement this. I have two books on wxPython, which I need to get up to a higher level of competence in order to get this looking and working properly.

The code I have has to be refactored and more explicitly built in the Model-View-Controller pattern, as well as the changes to support the new GUI appearance and behavior. This will be a substantial amount of coding and testing but very satisfying when done.