Completing 2310 and 2501 device implementations

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

Restructuring the GUI

The 2310 function is converted and ready for testing. The virtual disk drive pops up a window with a picture of a disk cartridge to its right, the name of the PC file that is mounted on the virtual drive. Two lamp blocks are in the window, Disk Unlock and File Ready, which harken to the two lamp blocks on the keyboard panel of the 1130.

When it starts, the file name is **empty**, Disk Unlock is 'lit' and File Ready is dimmed out. Clicking on the 2315 cartridge icon brings up a file open dialog where the user selects a suitable file. The file is opened, validated, the file name is displayed, the Disk Unlock lamp is dimmed out and the File Ready lamp is 'lit'.

I then worked on completing the 2501 card reader function, building a window that pops up when the device is activated. It has an icon of a punched card and the name of the PC file to its right (or **hopper empty** when no file is open). A button, Prog Load and a lamp block, Ready, are on the next row. Finally, three checkboxes run across the bottom row - one to set up the last card status and two to choose between 029 and binary file modes.

The 2501 device is more complex, with more state information in the model and more fpga interactions. I also must decide whether to expose some of the state as output on the GUI window - such as card deck size and current card being processed.

I have icons for the other PC file types to open for the remaining device types - punch cards, a sheet of printout and core memory - which will be placed in the windows for those device types.

Restoration work on 1442, plotter and more development of new GUI

1442 CARD READER/PUNCH RESTORATION

I did some filing down on the UV curable plastic I bonded on the punch drive wheel to replace the cracked segment. I was pleased to find that it could be worked as promised. Next step is to be sure it is built up higher than the target diameter, so that my machining will all be subtractive to yield the intended surface.

I need to build a jig that will keep the outer face of the wheel, the perimeter that will contact cards, at the right distance to a rotary grinding tool. Then, I can slowly rotate the wheel to move the built-up sections along the repaired arc, grinding them down at the right diameter. The final step will be to coat some grit balls with the UV resin, place them on the repaired arc and cure them in place with UV.

The original wheel is a ceramic that has big grit balls embedded on the outer face. These grit 'balls' are the gripping mechanism to pull the card along. As long as I have the replacement section so its initial diameter is the same as the original's diameter in between grit balls, and make the balls the same size, it should all work.

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

Restructuring the GUI

Worked on the logic to fire up a device handler when the Device menu is selected, or to stop it when the user wants it deactivated. Each handler puts up a control panel window which will contain buttons and status displays. As a test of the concept, I built up the 2310 disk drive panel and am still tweaking it.

Now I am splitting the logic for all my devices into the model, controller and view portions - laborious but the heart of the restructuring. Models hold the device state, controllers communicate with the fpga and views control the on screen GUI elements.

RESTORING CALCOMP 565 IN GUISE OF IBM 1627

My connector arrived last night and looks perfect! It fits the connector on the rear of the plotter, although I want to clean up the contacts and pins a bit to make sure it is solid. I am still waiting for a quote from the metalworker for the task of removing the dent in the plotter drum.

New connector tested for fit

Iconized menus on the new GUI

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

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.

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

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

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.

CALCOMP 565 RESTORATION AND 1627 CONVERSION

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!

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

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

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.

RESTORING CALCOMP 565 PLOTTER

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. 

plotter work on SAC Interface: new board, GUI enhancements

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

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.  

Have new fpga board working correctly

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

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.