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. 

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.

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

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.

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

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

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.

New fpga board in place, still working on USB firmware to restore communications

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

Restructuring the GUI for the PC side

I really need to improve the graphical user interface of the PC side program. It is drab, crowded, and hard to operate with all the virtual and mirror devices included. I want a clean looking main window, menu control over functionality and separate floating windows as needed for the peripherals.

I will need to improve my knowledge of wxPython immensely to make this happen. I bought a text and am doing some experimenting in the interim.

Testing new board and Vivado toolchain results

I had to wrestle with Java and some other software to get the end to end capability I needed, then fight to update the USB controller processor firmware to support the modes I needed. Had to get the Java development kit, usb libraries configured, and do a few other things before my laptop could talk with the board. Eventually I could load the bitstream and have the board power up successfully. Only then could I move on to test it connected to the rest of the interface box.

The first test was to power up the SAC Interface Box, which takes a noticeable time to load the bitstream from flash because it is so big compared to the previous fpga board, then power on the 1130. If the PC can communicate with the fpga and I see reasonable status, I will move one to actively driving the 1130.

The endpoint couldnt be reached - I have to set up the right firmware into the USB processor chip on the fpga board in order to communicate with it. I think the memfifo demo program provided by Ztex has a firmware load that will work properly, but I remember this took a few days to sort out with the prior board.

Fixing design flaw in mirror 1442 mode, plus other things

The engine is humming along and the oil leak is gone, now that I finished up the replacement of the valve cover and cam chain tensioner gaskets. Pretty easy if the tool isn't fake junk like the first one. Putting the car in with the shop to have the timing belt replaced and do other work that is more elaborate.

Off to help a buddy move collectibles from a house he is selling in Morro Bay and into a nearby storage facility - I will be tied up until next Monday. Considering working on the Python program GUI when I am back in my hotel room each night.

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

Implementing mirror 1442 reader/punch

In a quick review, I noticed that I have used the low bit of the command 6 for two purposes - not ready status and mirror adapter mode. I needed to reassign the bit used to switch between mirror and virtual adapter modes. I chose to use bit 0 to set to mirror mode and bit 1 to set to virtual mode. The other bits I am sensitive to in this transaction are bit 15 (not ready) and bit 3 (end of file).

All the logic is updated in both fpga and PC program, but the only testing I can do, while my 1442 is offline, is to verify that virtual 1442 mode still works correctly.

Plotter restoration preparation, other distractions and a few bits of progress

I finally received the correct and working tool to compress the cam chain tensioner in my daughter's Passat 2.8L, unlike the prior one from ebay that was misshapen junk and wasted many hours. New gaskets on, closing up the car. Only issue to deal with is one nut (holding the power steering fluid pipe in an inconvenient place over the tensioner) which fell down behind the engine but alas not all the way to the ground.

Once I jack up the car and feel around to locate the errant nut, I can finish up the job and have her car free of oil leaks and corresponding acrid smells through the cabin ventilation system. This may wait for tomorrow as the sun is lowering and I have other things to attend to. I also discovered that I mislaid my adapter to hook the 3/8" sized torx socket to the 1/2" sized torque wrench. Trip to the

Still hopping around with a million and one details and tasks related to transitioning to retirement, which chews up plenty of time. With our 30th wedding anniversary coming up, I just booked eight days at the Grand Hyatt in Kauai where we can vegetate in a cabana at the pool. Set it out in November as we have my daughter's wedding in Ireland to handle first this summer.

IBM 1627 NEE CALCOMP 565 RESTORATION

I have been communicating with Tom Mikulic, an enthusiast in Australia who has successfully reverse-engineered the solenoid/pen component for the Calcomp 565 plotter. Since my plotter is missing this piece as well, unless I am extraordinarily lucky and find this somewhere, I will need to make my own.

The part is a barrel with a solenoid coil inside, which is twisted into place on a moving carrier across the front of the plotter. The part has twin prongs that provide the electrical connection between the coil and the moving carrier. Inside the center of the solenoid coil is a hollowed metal slug that is spring loaded downward towards the plotter drum and paper. Inside the hollow slug, various types of pen barrels are placed.

The solenoid, when activated, pulls the pen upward against the spring and therefore the pen tip is off the paper. The spring returns the pen to contact with the paper when the solenoid is unenergized. Signals over the interface command the solenoid to energize or release.

This part is a combination of machined items, such as the thread-on cap at the top which holds the pen inside the hollow slug. Tom has designed a recreation, built it and uses it to produce output on his Calcomp 565. He is willing to share all his designs and notes, which will allow me to create my own part.

I have also located facilities nearby who will powder coat the cover and front panels to the colors of the IBM 1627. I would be responsible for producing the labels for the control panel and logo plates to stick on the front bar, to make the plotter cosmetically appear as a 1627.

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

Implementing physical paper tape reader/punch (1134 and 1055 equivalents)

The paper tape punch runs under 15 characters per second, which is slow enough to make use of a set of relays to drive the punch solenoids, rather than driver transistors as I had earlier planned to use. The board and the twin relay board driving the motors will be wired up to my 48V DC power supply and to the paper tape devices.

Work on paper tape plotter and other things

My daughter bought a used VW Passat wagon - perfect car for her to commute and bring her large dog along. However, it was leaking oil from the valve cover gaskets, producing smelly smoke that gets sucked into the ventilation system.

I decided to change the valve cover gaskets myself as the quote from the local repair shop was over $1,000 and as a retired person, I can definitely beat that cost. About $100 all together for parts and tools. I will move a bit slow to be sure I don't cause any problems. That plus the continued retirement tasklist pulls me away from the 1130.

After many hours I came to the conclusion that the special tool I bought to compress the timing chain tensioner was junk - I can compress the tension by hand but this tool just wedges into the place, too thick to push between chain and frame to reach the piston it must depress.

The repair cost just jumped up a bit for the replacement tool to compress the piston. New tool coming, but on Monday, so this will have to fester until then. At least I could replace the brittle and broken PCV hose assembly, as lack of PCV suction is one of the reasons that leaks develop.

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

Implementing mirror 1442 reader/punch

On the PC side, I added the logic to inject blanks for mirror mode and to issue the transactions that switch us between mirror and virtual operation. Again, I checked that the virtual function still works.

I can't test the mirror mode myself until my physical 1442 reader/punch is working, but the changes were quite minor thus it has a decent chance of working as written.

Paper tape reader and punch integration

I received all my components last night to hook the paper tape reader and punch units to the slave fpga board. A dual relay board to advance the tape motor of the two units, voltage translation boards for the incoming signals and a signal amplifier/driver board to fire the eight punch channels. Wiring and packaging commenced.

Further study of the units highlighted that I didn't need any voltage translation boards. The switches on the units that detect presence or absence of tape, and that detect holes for the reader, have a common connection that I can hook to signal ground and use pullup resistors on the fpga side to use these at the LVCMOS 3.3 voltage levels of the board.

I do need the signal amplifier/driver to drive the 48V solenoids that punch holes in the paper tape. My first plan was using a power driver board designed to light seven segment displays, able to drive inductive (solenoid) loads to 100ma per channel. However, the spec on the chip is a max of 33V thus I can't use this part with the 1055 punch.

It won't be hard to create my own driver board for the eight channels of punch output, but it will add a few days to the wiring task for the punch. This will be a very simple set of power transistors to conduct the solenoid down to ground when an input signal is present. If I choose a transistor with a beta of 100 and feed it a couple of ma from the fpga board, well within the drive capability of the board, I should be able to pull a couple hundred ma through the solenoid to punch the hole.

IBM 1627 NEE CALCOMP 565 RESTORATION

I removed the foam rubber that sat inside the center of the cylinder, in order to gain full access to the dented section of the drum. One possible  way to get most of the dent out of the drum would be a wooden inverse mold - allowing the outer surface of the drum to nestle into the reverse shape in the wood. I could then press and tap on the dent from the inside to get the surface more or less smooth. If I can restore it so that variations in height are just a few millimeters under the intended radius, I could fill those in.

I may speak with an auto body repair shop that has expertise with aluminum - they may be able to repair this much better than I could. Still undecided on the repair method to try first.

The plotter is missing an important piece. What I assumed was just the pen holder, which rides on two horizontal rails and is moved left and right, also has the solenoid that raises or lowers the pen. Part of many plotted outputs are commands to pull the pen up, reposition and then drop the pen to draw from the new starting point.