Thursday, October 8, 2015

Moving ahead debugging the 1053 mirror adapter


While I was thinking through an implementation of a big buffer to hold data from a mirror device adapter, under the premise that the speed of the data production is fully determined by the real peripheral device and its IBM adapter logic in the 1131, I had a flash of insight.

The bus that devices use to present data and sense status when processing an XIO is constructed as a wired-or bus. That means that all devices have their outputs tied together, but only one will be pulling down the bits that have a '1' value. The others leave their signals high, which is logic level 0.

That means that while I am shadowing the XIO Sense DSW for the device, I have the opportunity to force the 'busy' bit or other sense bits on, but not off. If it makes sense for a particular device and software that the presence of a busy bit will keep the program from issuing additional read/write commands until it goes off, then I could throttle the peripheral by jamming the busy bit into an Sense DSW the program issues, until my PC program has retrieved the currently stored value and free up room for the next.

For the 1053, that will probably suffice on a character by character basis, causing it to slow down the real selectric typewriter but preserving the data. For the mirror 1132 printer, I would have to pretend the carriage is busy after handling each line of print, ceasing my jammed busy bit when the Python program finished retrieving the prior line. For the mirrored Console Entry Switches, I needn't worry because the 'data rate' of flipping switches is low enough that I should never have an overrun on my mirror peripheral.

For this to be feasible, I need a means of switching the pseudo-busy behavior on and off, depending on whether the Python program is mirroring the device or not. I chose to use the transaction Write Special Data with a value of 0 meaning disarm (the default state) and 1 meaning arm this. When armed, this pushes on the busy status of the typewriter as soon as we process an XIO Write command and leaves it merged into the DSW that will be returned to software until the next transaction that fetches the word written by an XIO Write.

My testing uncovered a few minor issues which I fixed up, but it did not appear that the merged DSW was blocking the program from writing additional characters. This could be a flaw in my logic to force in the busy bit, or it could be a miscalculation that assumed any software would look at that bit before issuing a write.

I scrutinized the logic, made some changes and resumed testing. Mirroring is working, sort of, but not sure I am capturing every character. I will put some paper in the typewriter, insert the ribbon, and then compare. The testing will be done tomorrow, it is now after 8PM.

Wednesday, October 7, 2015

Debugging and modifying mirror device logic in SAC Interface Box, plus new (!) disk drive arrives


I realized that the updated fpga logic hadn't been loaded when I ran the tests yesterday, which meant that several of the virtual and mirror devices weren't implemented on the SAC Interface Box side. I did a download of the bitstream to the ztex board flash this morning and ran a quick test to watch my new diagnostic messages.

I fired up the system and found that the logic for the 1053 mirror device was receiving 010 as the last XIO function continually. That is bad for two reasons. First, the software should only issue XIO Write (001) and XIO Sense DSW (111). Second, it should have reset to 000 after the first time I fetched it. This begins once a real XIO is executed against the console printer, so we know that the mirror adapter logic in the fpga is seeing the XIO instructions.

I found a small bug in my VHDL for the fpga which caused the incorrect XIO code 2 to be issued. With that corrected, I got deeper into the code debugging, but was clearly fetching characters that were typed with XIO Write instructions, but I wasn't requesting the data with the right transaction type.

With that fixed, I found I wasn't able to keep up with the typing rate, thus skipping characters. This requires a change to the fpga side to buffer up what is typed, allowing the PC program to fetch it at its leisure. This is a problem unique to mirror devices - whose rate of execution is fully determined by the real peripheral and its adapter logic. Virtual devices withhold the operation complete until they are ready, thus moderating the speed of any program that is properly written to drive that device type.

The solution for the mirror devices is to use the distributed RAM of the fpga chip as a buffer, allowing the mirror device code on the PC to retrieve characters at its own pace. I will establish a single buffer for use by any of the mirror devices, on the condition that only one is active at any time. This restriction will be enforced in the Python program.


My ebay purchase of a Perkin-Elmers VT2222 disk drive, similar to the Pertec drive I am refurbishing, met my expectations. It is a brand new drive, never used, still on its wood shipping pallet. The heads are pristine as is the rest of the drive. I have schematics from a similar, but not identical model, which should still allow me to bring this up and make use of it.

Super clean unused heads

As shipped from the factory

Back view
Protective paper still covering translucent plastic front panel
Condition is new in box

Shipping documents

Tuesday, October 6, 2015

Debugging of virtual and mirror device adapters, plus new test tool


The enhanced PC side on the Linux laptop is working well now and its non-device functions seem solid. It can simultaneously work with the fpga over the USB link from different threads, such as the continual system status display and the function to load core memory with the contents of a PC file.

I therefore began debugging the device logic. I loaded the DCIP standalone utility (Disk copy and initialize utility) so I could work on both the 1053 console mirror device and the virtual 2310 disk drive.

Of course they didn't work perfectly the first time. I am now injecting diagnostic output into the drivers so that I can see what it is doing and figure out how to fix any defects. I ran out of time today, being pretty busy with my regular job, and will have limited time tomorrow since I visit the CHM on Wednesdays.


I bought an ESR meter kit, the Blue ESR tester designed by Dick Smith, and put it together tonight when it arrived. Now that it is calibrated and working well, I can use it to check out the quality of capacitors on the 1401 systems at CHM as well as for my own projects. Blue ESR Meter description

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. 

Friday, October 2, 2015

Work on SAC box Python side, design investigations, little progress on 1053


Today, I returned to the typewriter and re-affixing the spring without having to disassemble a big chunk of the machine. I had to give up on the angle I had thought would work, since it required pushing the spring in a narrow opening and then twisting it to attach to a tang. No tool I have can provide the kind of twist and pressure needed.

I dismounted one of the feedback microswitches from underneath the machine and removed the cardboard protective cover from another contact assembly at the rear which reports carrier return activation. Now, I have a miniscule opening from the back, with essentially zero visibility inside, but one where I 'might' push a spring and attach its far end.

Next up is finding an angle where the fiber optic camera can see and illuminate inside, as a way of guiding my otherwise blind probing with the spring-on-tool. My lower back complained about all the hunching I have done, interspersed with rotating a heavy selectric mechanism. Time for a break.

I wasn't successful finding a good angle, but I can only spend so much time with the 1053 before the frustration begins to well up. I will work at this in short bursts over the coming days until I make progress.


IPI-3 tape drive interface

The only way I can see the IPI-3 requirements in order to assess the feasibility of developing my own connection for the 9347 tape drive, is to buy it for about $200 from the standards association familias. The tape drive itself was only about that much and then there is the materials costs of building a controller - if it is reasonable to do.

If I can find an IPI-3 card that covers mag tape - the only antique ones I found were specifically disk oriented - then I might consider leveraging such as card. However, that would presume that the specs for communicating with the card were public, which I doubt since IBM had a tendency to declare any drivers, code, embedded processor functionality etc as licensed internal code which is not only subject to licensing, but carries a strict covenant against inspection or reverse engineering.

Other SAC Interface work

I worked on some esthetic and usability enhancements to the Python program today. I don't fire up threads to handle various virtual or mirror devices until a check box is selected to active them. This frees up memory and CPU resource to give better service to the functions that are active.

The Console Entry Switch mirror device is now working, displaying the last value read from the bit switches by program action. This doesn't work for console manual operations such as Load, but captures every XIO Read to area code 7, which are the bit switches.

Design choices for finishing SAC Interface Box and lots of research


Another day studiously ignoring the d****ned spring. By the weekend I should be over my snit and able to take on the fight once again.


Tape drives

I began thinking of how I would provide the tape drive connection to the 1130. I am leaning towards a laptop running Linux, on which to install Python and use a USB to parallel SCSI adapter to hook to my tape drives. I should be able to get something reasonable for a couple hundred dollars. That will let me keep the laptop out near the SCSI Interface Box and the 1130 system.

I also need to model the tape drive device adapters to match any software that might be using the tapes. I don't have any documentation for this in the FE or user manuals, since it was an RPQ (custom feature which had been developed for one customer and could be ordered by others, Request for Price Quotation) and not a standard feature in the price book.

The IBM 1800, which is a sister machine to the 1130, does support the 2401 and 2402 tape drives, with documentation for how to access them in the 1800 documentation. However, the 1800 uses them with an internal adapter at area code 14. The RPQ for the 1130 instead uses the tape drive controller and S/360 channel connectors, which go to a  360 Selector Channel installed in the 1133 Multiplexor box on the SAC.

The tape drives are addressed by the Selector Channel at area code 27 and use a different set of XIO functions that are implemented on the 1800. The 1800 would issue an XIO Init Read to read a block from tape, or an XIO Control to rewind, space, erase, etc. The 1130 issues the special Init IO function which points to 360 style CCWs (channel Command Words) and the three word long channel status word information not the 1800 DSW.

This means that if I want to meet my goal of allowing software written to control tapes on 1130s with this RPQ to run properly with my real tape drives, I have to implement the selector channel function, use area code 27 and the special XIO functions, then interpret CCWs and CSWs. I can try to interpolate this from the S/360 documentation on EXCP and 2401 drives, but there will remain some ambiguity.

I am not sure I can fully resolve this without working software to test against, and even then I might miss behaviors that the software doesn't trigger. I could easily implement these with my own area code and defined behavior, but that would mean that any software would have to be written for my devices specially. Any chance of finding a tape sort/merge program and running it to watch the tape drives spin would be thwarted by the incompatible decisions I might make.

Another hiccup I discovered is that while one of my drives has a SCSI interface, I suspect that the newly purchased one that will arrive Tuesday uses an IPI-3 interface. Yikes. No adapters I can find, no converters, no IPI controller cards - nada. I might have to do this one myself on an FPGA, which will be a major pain, particularly when I was close to a turnkey kind of solution with a Linux box that would let Python drive the SCSI tape devices.

Other device types

Other potential devices that I could implement include 2311 disk drives, which attach through a 360 channel installed in the 1133, giving me the same challenge of extracting adequate documentation. Since 2310 drives provide enough storage (five total cartridges online), I wouldn't need the extra logical drives that come from a 2311. Thus, I won't try to implement this.

The 1231 Optical Mark Reader would scan test forms such as the SAT tests and record the results - not very interesting. The Synchronous Communications Adapter (SCA) provided BSC or a similar communications protocol at 300, 1200 or 2400 baud over a Bell Dataset and phone lines. It would allow the 1130 to operate as a remote job entry and printing station, but that isn't interesting enough to me to warrant implementation.

That leaves the 2250 Graphical Display Unit was a vector graphics tube and light pen used for CAD and similar graphical work. It was pretty expensive relative to an 1130 and thus was typically installed on larger 360 systems or only when the 1130 was a remote graphics station hooked to a bigger 360. There is limited software for the 2250 that runs on the 1130, unless you are using it remotely from a 360. I might implement this just for the challenge, especially since it is fully documented unlike some of the other potential peripherals. 

Wednesday, September 30, 2015

New disk drive coming, plus thinking about tape and disk support for SAC Interface Box


I boycotted the spring today.


I found an auction for a drive, similar to my Pertec, that appears to be new, as shipped by the maker and still on its shipping skid. I made an offer which was accepted and expect to receive the drive next week.


I have some design choices to make in order to finish up the remaining IO devices I might put on my system. The various disk drives (Diablo, Pertec, Perkin Elmer, and DEC) all have well defined interfaces that I can manage from an FPGA connected over the high speed link. What is harder will be to drive the two SCSI based tape drives.

I don't want to have to model a SCSI host in the fpga myself - too much work to be worth it - but there are ways I can use an intermediate. First, I could build a board around the NCR 5385 SCSI chip and NCR 8310 driver/receiver chip. Second, I could create an ISA bus from an fpga on the high speed link, then insert and drive a SCSI card. Third, I could find a small PC with SCSI support that would control the tape drives, communicating with it over an easy to implement common protocol such as parallel port. Fourth, I could drive the tape devices from the same PC that runs my Python program,

The NCR chip would require that I study and master that chipset to use it. The ISA bus requires me to implement that plus drive the SCSI card - I would need one with good documentation or a source code version of the driver. If I drove the tape units from the same PC, then the Python program could control them and pass the data. It would be similar to the virtual devices I implement already, except that it would use real tape drives rather than PC files as the source of the data.

I am collecting data on the NCR chips, ISA bus and various driver cards, to help me make the decision. I will also research Python support for SCSI devices. The downside of running on Windows is that SCSI support is ugly and poorly documented, whereas Linux has good support.