Saturday, April 25, 2015

SAC Interface loads IBM 1130 core from PC file


Load 1130 core from PC file

I took the new code out to the workshop to try out my Python code that uses the SAC Interface box to load core memory with the contents of a Simh memory dump file made on the IBM 1130 simulator. I have an image of the DCIP utility which initializes disk packs, which I will use to check out the functionality of this memory load.

I commenced my testing of the capability to load the real 1131 core memory with data from a simh dump file written by the IBM 1130 simulator on the PC.  It worked perfectly on the first shot. I shot some video of the process of loading the core memory from the dump file of the DCIP utility program sitting in the IBM 1130 simulator on a PC, plus I began running the utility to show that the code was good.

I didn't have my console typewriter working which kept me from a more compelling demonstration, but this is a milestone that I didn't want to ignore. The video is visible at Video of PC file loading into core of IBM 1130

Design decisions

It would be most useful if I could sense and trigger interrupt levels 0 and 1, in addition to levels 2-5 which are included on the SAC lines. I did some study of how I might rewrite my 1131 to make this happen. I would have to repurpose two outbound and two inbound signals from the SAC interface, which makes my box a bit less universally usable on other 1130 systems.

I could put in a configuration option in my box that will either use the universal signal meaning for the four chosen lines or use them for IL0 and IL1 support. Two signals are easy to pick, the Meter in and Meter out lines, since I don't care about billing or spinning a usage meter. I have two output signals that I don't need to use, Block Clock Advance and Advance IO Entry, either of which could be re-purposed to request one of the interrupt levels.

The last of the four lines will take more care in choosing, because there is no other easy input signal to commandeer. My choices at this point are CPU Parity Check and one of the X clock states. I am not using all four of the X clock state signals, which is why I could steal that line. The Parity Check signal is only used to signal an error, but it is a rare enough condition that I might be safe ignoring it so that I can borrow the line.

If I update my box to handle the first two interrupt levels, I can then have my box take on the role of the 1132, 1442 and console keyboard devices. Although I have these real devices on my system, I can easily block their action by interrupting the signals that tell the adapters when their area code is specified in an XIO instruction. If the adapter thinks the XIO is for a different device, it ignores it.

I can see how this would be quite handy, because currently I would need to generate an entirely different disk cartridge to run with the 2501 and 1403 devices I am able to emulate on the vanilla SAC interface, but my current systems are configured for the 1442 and 1132. This would let me substitute other physical readers and printers or use virtual devices on PC files.

I think I see the gate/backplane locations for the signals I need to support IL0/IL1, but I also need a way to get that to the driver/receivers for the four repurposed SAC cable lines. This may introduce some undesirable compartment to compartment or even gate to gate cabling. More study is needed.

Upcoming additions to the interface box

Next development tasks for the interface:

  • hardware adapter for my replica 1627 plotter
  • hardware adapters for paper tape reader and punch
  • virtual 2501 card reader in the PC
  • hardware adapter to emulate 2501 using Documation card reader
  • virtual 1403 printer in the PC
Implementing 1627 plotter adatper using SAC Interface Box

I decided to pull out my plotter replica since interfacing this should be fairly simple and only require the use of six of my diagnostic lines. This plotter is built using a Strobe Model 100 drum plotter plus some logic I constructed to change its behavior into that of the Calcomp unit (which IBM relabeled as the 1627).

I implemented the adapter logic that would have been installed inside the 1131 if the 1627 plotter was configured in the system, but my machine did not have this feature. The SAC Interface Box adds that adapter function into the system. This would equally work with my replica or a real 1627 or Calcomp equivalent.

I had to write some code to draw with the plotter, test it on the IBM 1130 simulator in order to load it to the real machine using the interface box. Testing everything took quite a bit of time on Saturday.

Friday, April 24, 2015

SAC Interface fully functional, code added to load simulator files into 1130 core


My adjustments to the logic paid off, giving me correct operation of XIO Sense DSW after the PC program updated the virtual device status in its UCW, and the PC was able to update the data word in the UCW for successful retrieval by an XIO Read instruction in the 1130.

I updated the instrumentation and the PC side program to work on the Sense ILSW logic validation and to check that my shadow memory register (SAR) autoincrements after each read or write. Those tests had to wait until the late afternoon, when I set up and successfully validated the XIO Sense ILSW functionality. The SAR autoincrement is not working properly, something I would look into next..

Looking at the logic, I found a situation that would cause the SAR bump to malfunction, which I corrected. I also instrumented the SAR register onto the lights to let me visually check the correct operation of the autoincrement logic. The test ran perfectly, so that I can set the initial core address and then issue a series of words to be stored in the range of addresses beginning at the value in the SAR and continuing upward sequentially.

I decided the best initial file format to open on the PC and transfer is the 1130 simulator files stored by SIMH when memory contents are dumped. That way, I can boot in diagnostics or other complex card based files and have them sitting at the idle rest position, transfer the contents to the real 1130, and set its IAR to begin executing at the same spot.

I completed program updates on the PC to open the simulator core files, process the data and issue the appropriate commands to the 1130 to cause them to be loaded in core memory. I have a bit of testing to do tonight, without the SAC Interface Box or 1130 system, but the real testing will take place tomorrow.

Thursday, April 23, 2015

Cycle Steal, Interrupt triggering and many virtual device capabilities working perfectly in SAC Interface Box


I worked on quite a few functions that weren't fully implemented, so that by the time I could work on the 1130 at lunchtime, these were presumably ready and just needed testing.

I believe I found the cause of the delayed fetch data from my testing yesterday and hope to see that confirmed today.

The PC side python code was also cleaned up and augmented. I generalized some of the code to handle virtual devices as well as the GUI triggered actions. I need to work through all of these functions as well, since the code is new or modified.

I discovered some flaws in handling my newly generalized code with functions that previously worked correctly. I set up some instrumentation through the temporary lights in order to find the cause. It was pretty easy to zero in on the flaw in my new generalized code; fixed rapidly and back on track.

Cycle steal fetch now works perfectly. I still have some timing flaw in Cycle Steal Store where I am always writing zeroes instead of the intended data value. Shouldn't take long to track this down and fix it.

I then tested by interrupt requesting logic, but found that regardless of the interrupt number I thought I was triggering, I always turned on IL4. This too should be a simple flaw to find and correct. I went in to eat lunch, work on the flaws and resume testing later today to see if I got it right.

The cause was two fold, both in the python code. Testing proved out well - I could turn on or off each of the four interrupt levels independently for any device. I realized I have a small design problem in how to properly handle the XIO Sense ILSW for virtual devices, since when this command is issued the fpga has no way of knowing which bits in the ILSW are assigned for that device when it requested an interrupt for each level. It may need to be coded in fpga logic for the virtual device,leaving all its other handling to the PC side program.

I did some instrumentation in the python program to test the functions that let me retrieve the last XIO function, modifier fields, WCA and data word for a virtual device, plus the function to set device status and to set up the data word for an XIO Read to retrieve.  This took a while but I resumed testing in the late afternoon.

Initially, I executed an XIO to the virtual device and tried to retrieve the various fields, but all that was returned were 0 values. I took the time to re-instrument the lights so that I could divide up the problem. First, make sure the proper status was being saved in my "UCW" field in the fpga, then I could track down whether it was being returned properly.

I found some spots where I could change the handling of the UCWs in the fpga, made the changes and tested again. The results were very good. Not perfect, I have a couple of issues to chase down and I still need to work out the mechanism for Sense ILSW, but most functions are working properly.


  • The function code (XIO type) is correctly stored and retrieved for all XIO types
  • The modifier field (bottom eight bits of IOCC word 2 is correctly stored and retrieved
  • The WCA is correctly saved and retrieved for XIO Init Write and XIO Init Read
  • The value in core memory is correctly transferred after an XIO Write
When I attempted to load a new value in the UCW for use with an XIO Read, it did not store the new value. I will narrow the instrumentation down to determine where the failure occurs.

When I attempted to store a new device status and interrogated it with an XIO Sense DSW command, I only saw zeroes in the B register. Again, my instrumentation will help me figure out where the failure is occuring.  In addition to setting up instrumentation, I will be looking over the relevant logic in the fpga to see if I can spot the cause or have a cleaner implementation.  Daylight is fading so my 1130 testing is over for the day.

Wednesday, April 22, 2015

Now handling cycle steal fetch requests and status inquiries from PC to the SAC Interface Box

Today was slightly better than yesterday, so a bit of time became available at the end of the day and I got in to work on the system.


I used my instrumented logic to shake out several functions, so that I can now load the memory address that will be used for cycle steal fetch and store, as well as retrieving the contents of a chosen memory location. I do have a timing bug I had to chase, because I had to fetch twice from the same location in order to receive the value of that core address. If I changed addresses, I still got the contents of the location from the last fetch request.

Status messages are also being correctly processed, sending me the status value being maintained in the box. When I tested a store into a memory address using cycle stealing, I found I was addressing memory but storing zero rather than the data pattern I sent. I suspect this is related to the timing mismatch that causes my fetch to be one request out of sync - likely I am storing before picking up the intended memory contents.

Daylight was waning by this point, but I had some good insights based on the testing. Time to go through my logic, find and fix the 'last fetch not current fetch' issue and be sure my data value is what is passed to the store logic.

I have some more code cleanup for the Python program and more logic I want to add to the fpga, some of which I will do tonight.

Tuesday, April 21, 2015

No work today, ergo no progress. Somehow there is a correlation

There was zero free time today to work on the interface. Finally in the evening I could put some work into the VHDL for the fpga logic, setting up for further diagnostics when I get back out to the garage.

Fellow historic system owner Johannes Thelan has moved his IBM 1800 system into its new home and is beginning its restoration. This system includes many peripherals including 2311 disk drives. There were no ALDs with the system, logic diagrams that are essential to diagnose and repair the machinery.

Fortunately another 1800 owner, Bob Rosenbloom, has the documents for his machine. While it is not identical, lacking mag tape support for instance, its manuals would be close enough to work from. Bob made scanned versions of the manuals available to Johannes.

Monday, April 20, 2015

Transactional logic working and returning data, on the SAC Interface Box

Heavy work day, not too much time to play with the 1130, but I did get some coding and testing accomplished.


I came up with a new design for the logic that sends back word 2 at the end of a transaction, either an echo of what was sent or the requested data, depending on the command type we received. I built it up at lunchtime along with a few other enhancements.

I fired up the systems to test and could see that I am latching up values when I command it to load the shadow SAR, but the values showing on the lights don't seem to match what I expect. Echo works well, but also getting some unique values for certain status words. I am instrumenting the logic to help dig into this further. It is progress, even if slower than I would prefer.

Sunday, April 19, 2015

PC link to SAC Interface Box operating,. now working on validating the commands and responses


Last night I redesigned the logic for the PC link, building up in layers from a solid approach. The innermost logic is a state machine that reads two words from the PC then waits until triggered to write back words or return to idle waiting for the next input. The next level up establishes the transactions, such as 'store in core' or 'trigger interrupt' or 'fetch WCA address'.

The transactions consist of a command word followed by a second word - the command may request an action or it may ask for data. These types are called imperative and interrogative respectively. Each transaction ends with an echo of the first (command) word and either an echo of word 2 for imperatives or some data returned as the second word for interrogatives.

The lowest level machine - to read two words then write a variable number of words - should be set as it is, subject to testing. The next machine, establishing transactions, is the one that also sets up the outgoing data or latches incoming values, so it needs to be more carefully written to work with the lowest machine. The transactional machine waits after it latches in the second word, having set off another state machine assigned to each command. When the other state machine has completed its function, it triggers the transaction machine when then writes back results until done.

Building up the layers involved various FSMs that will produce an output word that is transmitted back to the PC at the end of a transaction. I was most concerned with the FSM to send back status words, as that should be easiest to test. After that, I would work on the machines that load the SAR and SDR shadow registers. Finally, a test of cycle steal fetch and store would be a solid stopping point. For each test, I worked out some diagnostic signals to emit on the temporary lights.

The first test was to watch the link while the Python program sends a status request to the box and the box returns the correct status. I will be able to tell if the innermost link FSM completes or sticks in one state, same with the transactional FSM. I also watched to see what command was latched and the word sent back from the viewpoint of the fpga.

The link was not working and I wasn't sure which side of the link was at fault. After some detailed testng I found a couple of flaws in the fpga logic and successfully get through the innermost FSM, latching in the command and data words. The higher level transaction FSM recognizes the send status command, fired off that state machine, received the completion trigger and wrote both words back.

The problem I am now having is a timeout on the PC side trying to read the second word. It will take a bit of investigation to determine whether I failed to send the second word or whether the code on the PC side is in error. The general functioning of the link and transaction machines seem good.

I did have a problem with the pyusb code on the PC side, which is now fixed. At this point, I sent a Status Request interrogative to the fpga and got back the echo of those two words. I will go through some additional functionality next, first loading the SAR shadow register and then doing a cycle steal fetch and a store.  I had to change the instrumentation in order to diagnose these next steps. It was getting late so the remaining testing time was limited.

The second word returned on each transaction should be either an echo of what I sent for an imperative type ("do this") command, or a value for an interrogative type ("give me this") command. The Status Command is interrogative but I received the same value I sent for word two. The Set SAR imperative command should echo what I sent but it returned all zeroes. Further, I didn't see my diagnostic lights indicating the value I sent for word two.

I have a link operating and the basic transaction completing, but the higher level functions including determining what to write back at transaction end are not yet debugged. Basically just slow careful slogging through the logic, doing tests and reconfiguring until it is all vetted (and fixed where defective).