Knocking down issues in the 2310 and 1053 device implementations

1053 CONSOLE PRINTER RESTORATION

When testing the 2310 adapter logic, it is increasingly difficult to tell when the system is locked up due to an error in my adapter and when it is just the damned typewriter, since it sprung the return/forward movement cable yesterday. I have to either get this fixed or get my mirror driver working so I can see what it thinks has been typed and detect stalls.

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

My 2310 adapter logic works up until the point where the diagnostic utility issues the XIO Init Read with check for the first sector of the disk. I post the operation complete status, my adapter triggers IL2, but then it doesn't try any XIO Sense Device commands.

This suggested that I should look at my ILSW posting to verify that the interrupt routine is getting the proper response. If it doesn't recognize the interrupt as coming from my drive, it won't issue the sense command. That didn't seem to be a problem, but when I looked at the saved DSW I realized I was returning 0x4880 for the operation complete sense word, when it should have been 0x4800.

This wasn't caused by any of my logic for the adapter, which meant that some other logic in the fpga was raising bit 8, thus being ORed into the response word when my code processed the XIO Sense Device. This will take a bit of time to find. What I discovered when researching this was that my logic for handling the XIO Sense ILSW was not sound.

When in an interrupt routine, software can issue an XIO Sense ILSW which returns the bit-OR of all devices which have asked for an interrupt on that level. My logic returned the bit-OR of any request but if a device in IL2 issued the command, they got the bits back for all interrupt levels, not just 2. Thus, I need to condition my status bits on both IL request and which IL is active, since that is the only when which will receive a response to the XIO.

For XIO sense ILSW, I have a process responding for each device, adding its bits if any into the ILSW. The process will run anytime an XIO Sense ILSW is executed, but I have to gate its input so that it only sees the bits appropriate to the interrupt level which is currently active.

I made the change to my ILSW logic across all devices in the SAC box. This isn't the answer to why I am seeing the extraneous bit in the DSW - that has to be yet another defect in the logic somewhere.

The 1053 mirroring code instrumentation does not show any action when I am requesting the retrieval of buffered characters. I needed to figure out why this isn't occurring. It appears to be because I was using a signal (armed1) in a process but left it out of the process sensitivity list. Yes, there is a warning message about this, but buried in almost a thousand other messages.

Almost all the messages that come out are irrelevant, but can't be shut off or eliminated through coding changes - a really annoying aspect of the Xilinx toolchain. I suppose I could write programs to capture the warnings, save them with a flag i can set, then filter the warnings out of the subsequent reports for all those I marked as "hide". Seems to be a lot of work to overcome a clear flaw in the toolkit - anything that produces huge numbers of non-warnings is going to lead to problems because no sane person will put in twenty minutes checking the messages on every run of the toolchain. This can occur dozens of times an hour.

My change for the 1053 and ILSW routines were made, but I wasn't sure exactly how the 2310 was misbehaving, but when I came to realize the defect that was impacting the 1053 function, it appeared likely to impact the 2310 as well.

As I pondered the behavior of the 1053, I realized that I am not trying to fetch the data words because I am not seeing the completion of an XIO Write from the typewriter. This means I was looking at the wrong part of the circuitry in my debugging. After I realized this, I could see it was caused by changes I made earlier when I was flailing around looking at the incorrect use of device numbers (when I intended UCW numbers). I was resetting the last XIO function code before it was being sent to the PC, so that the mirror device ALWAYS received a function of 000.

Solid progress on the virtual 2310 and mirror 1053 adapter functions

1053 CONSOLE PRINTER RESTORATION

Right in the middle of my testing with the DCIP diagnostic, the damnable typewriter popped its carrier string off its pulleys, thus leaving the carriage jammed in the middle of the line. Until I fiddle with this and refit the string, no more typed output. That forces me back to hand coded instructions, or single stepping through the appropriate parts of the DCIP program.

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

I found a very subtle error in my 2310 logic. When the machine triggers an interrupt on level 2, the handler will fetch the ILSW to determine which device is causing the interrupt. I was looking at the wrong bits, causing the ILSW data to be presented at the wrong time and to set the wrong bit.

I located some key areas in the standalone DCIP program that I could watch for - where the XIO instructions are issued - in order to spot what is coming back to the utility program. I got out to the workshop and fired up the system to test out these changes and collect more information.

Neither defect was corrected - I continue to get the last XIO function repeatedly even though I should have reset it with the transaction so that it won't recur until the next XIO. I also retrieve null characters (typewriter produces the period for this). Something is happening in my fpga that I am just not seeing, but it is producing the erroneous behavior. It is time to instrument some special signals to see what is happening.

I hand coded a single XIO Sense Device command, issued it in single instruction mode, and watched the PC side loop receiving the same function code forever. My diagnostics showed that the field was indeed still 111 - the code for XIO Sense Device. This confirms that my code will NOT reset this as it should, although why this fails to work remains a mystery. More study and new diagnostic traces were needed.

Finally, the mistake in my logic leaped out of the page at me. The device number as issued from the PC to the transactions is actually the UCW number. The area code used in an XIO to select the specific device is a different number. I had coded my routine with the area code of the disk drive - 0b10101 (20) not the UCW number which implements this device adapter (0b01000 = 8). Doh. Days wasted because I kept seeing the area code and confirming in my head that it matched the virtual disk drive.

I repaired my grevious error and went back to testing. Once it worked, I went through the fpga VHDL code and changed all instances of devno (device number) to ucwno (UCW no) so that I won't slip into the same mistake any other times.

The next issue I found was that the adapter did one XIO Init Read with check, the PC side set operation complete but it didn't seem to proceed ahead from that point. This may be caused by the ratshit 1053 which is now spinning its golfball in place and randomly hanging up until I trigger a manual carrier return. Still, I will change my instrumentation to trace what is happening with my mirror 1053 driver, so that I can get both of these functions moving forward.

I cleaned up the 2310 adapter, so that it is triggering the interrupt at operation complete and then providing the DSW for the sense. I saw a way to change where I trigger the interrupt and reset it, to tighten up the timing. I am not sure what is wrong with the 1053 mirror function - I am arming and disarming the mirror, stuffing words in the buffer but the request to pop and return words from the buffer is no longer working.

The interrupt and reset logic is changed for the 2310 and I spotted and corrected a flaw that was blocking the 1053 logic from retrieving the buffered words. I ran out of time for testing tonight but I feel good with the progress I made and look forward to tomorrow's test time. 

Working on some peripherals

1053 CONSOLE PRINTER RESTORATION

The main erratic behavior left on the 1053 concerns carrier return operations. Sometimes it oozes leftwards and won't disengage. More often, it skips over the left margin stop and is typing from too far to the left of the page. I will keep running this while I debug various SAC adapter functions, hoping that repeated use will relieve any residual stale lubricants and make this perform more consistently well.

PERTEC MODEL 31 DISK DRIVE RESTORATION

In the sunlight, signs of corrosion were more apparent. A spring had a light rust coat and the brushed aluminum front trim was quite oxidized as well. I spotted crumbling insulation at the air inlet to the disk cartridges, an expected problem area. This further reinforces my belief that this drive deserves a tear down to find and fix or replace any such damaged parts. Fortunately, the key parts like the heads, arms and access methods are problem free, as are all the electronics boards.

DIGITAL TSZ07 9 TRACK TAPE DRIVE RESTORATION

I received this tape drive yesterday and did some initial checkout. It seems clean and intact, powers up and passes its self test, and runs through an unload cycle without a tape inside. This morning I stuck in a blank tape and checked on its ability to self load. With that proved out, it was time to try writing and reading tapes.

To test the write and read capability, I started the built in service aid #211, which writes 32K byte blocks on the type all the way to the EOT marker, then reads those backwards to the beginning of tape, reads forward to the EOT, then rewinds. This was done at both 1600 BPI and 6250 BPI densities.

Initially, it failed with excessive write errors - one track errors found while writing the blocks - but I thought that was likely due to the vintage 'new in box' tapes. I ran service aid 222, which was a motion tester, moving the tape back and forth in short yo-yo patterns all the way to EOT and back to the beginning. I then reran test 211 which only found a couple of bad spots during write and then read backwards and forwards at 1600.

Next up was 6250, which is more sensitive to short flaws in the tape because of the higher bit density. It failed, as I expected. When I reran 1600 it also failed immediately, so I took out the tape and re-cleaned the heads and key transport points. That done, I restarted the tests from the beginning. I can hear that there are a couple of bad spots right at the beginning of the tape,then it settles down to long error free writing. Worst case, I will move the load point in about five feet to skip over the known problem areas.

After the cleaning, it ran the 6250 test successfully so all that remains is to test that the SCSI interface works properly. I set the unit to SCSI address 4, to allow it to co-exist on the SCSI chain with my IBM 9348 tape drive. I then moved the drive into the data center shed where it could join the other drive and the P390 system.

P390 SYSTEM CHECKOUT

I hooked the Digital TSZ07 tape drive to the P390 and brought it up to do some testing. I can successfully rewind and rewind/unload but my initial attempts to do any forward spec, write tape mark or other operation met with command reject errors. I discovered these are caused by the default mode of the CMS tape command, which requests the tape drive to set itself to 800 BPI.

Since my drive supports only 1600 and 6250, it correctly responds with the error. When I go back to testing this, which is low priority for me, I will figure out the CMS Tape command options to set the tape for 1600 or 6250. That should clean up the problem.

My IBM 9348 drive decided to spiral downhill and refuse to run its power up diagnostics at all. The first time I turned it on, the diagnostics completed, but when I tried to do so again in order to run it through its complete set, something went wrong. An even lower priority that the Digital drive verification, so this can sit there until I get back to it.

It is quite annoying to have to wait for the default 70 seconds for each screen of the virtual 3270 to clear. I had found a command to shorten the timeout once but I can't locate it in any of the manuals or online references. The cause is that VM/370 used an attention key called CNCL on the 3270, which was used on 'system' type keyboards but wasn't found on most 3270 terminals that end users would access.

This means that the 3270 emulators like Procomm don't include a mapping for that key, which is the only way to immediately clear the screen and see the next screenfull. While there are mapping files to customize things, one has to figure out where those are, how to modify them, and most mysteriously discover exactly what keyword the program uses for the CNCL attention key. Using VM without fixing this turns every session into a long and tedious one, with enforced 70 second delays every time the screen fills with lines.

Still debugging 2310 and 1053 virtual/mirror adapter operation

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

I did manage to wrestle a few minutes free at lunch and went into the workshop to test some more. I have found the condition causing my problems with the virtual 2310 disk drive, but the mirror 1053 driver continues to return nulls (which types as a period on a selectric).

When I blocked the code from pushing any XIO Write characters into the FIFO, the 1053 adapter returned the special code for empty buffer - that part works well. This points me at the retrieval logic which is intended to pop out the character and send it back to the PC.

The 2310 adapter is getting back a modifier value of 0x81 from the XIO Init Read instruction, which is pointing at sector 1 but requesting a verify read, which doesn't actually transfer any data. On the real drive, the sector is read and the checksums are verified, thus it is testing that the data does not have any errors, although it does not transfer any of those words into core. My logic is not doing the right thing when this happens, thus inducing the loop I am experiencing.

I ran out of time and hadn't broken through on either of the problems. It is hard to debug complex logic in short bursts with long intervals separating them.

Dellivery and inspection of Diablo Model 31 disk drive

Another extremely busy day with the day job. At the end of the day, my ebay purchase of a disk drive was delivered and that was the only thing I could spend a brief period of time looking over.

DIABLO MODEL 31 DRIVE RESTORATION

The Diablo disk drive arrived today - potentially a twin for the one that came with my 1130 system. That original Diablo drive had suffered a head crash but appeared to be otherwise intact. The new one has nice clean heads and is in fairly good shape.

Drive opened and card cages raised for inspection

There is a touch of a mildew smell and some signs of aluminum corrosion on the outer handle from exposure to humidity. I bought it from a seller in Florida which made this a likelihood. It doesn't appear to have affected anything important, although the other brushed aluminum is a bit impacted.

There is a metal restraint that is part of the cartridge receiver mechanism which has a very light layer of oxidation on it, the only place I see any inside the machine. Still, this warrants a strip down, good cleaning and repainting of the restraint and any other surfaces that may be impacted.

Black restraint (upside down U shaped bar) with oxidation visible on surface

The Diablo model 31 can be ordered with a wide range of options, some of which will eliminate the chance that this drive could be media and data compatible with my existing 2315 cartridges and stored software. The drive can run with four linear densities, but for compatibility with the 1130 system this has to be the 'standard' 1100 bits per inch. If so, at the minimum I can swap the heads into the other drive and go.

Another set of options controls which sectoring scheme is used on the cartridges. The 1130 system uses 8 sector markers around the edge, but the Diablo drive could have various alternatives up to 32 sectors. This affects the logic in various ways, such as matching a read/write request to a target sector, and therefore an incompatible option might require me to hack the circuitry.

Unfortunately, the disk drive vendors of the day didn't bother marking the options anywhere on the drives, so I can't just look for a spot that lists which variant I have. I can probably dig through the logic cards and find some indication of the choice made.

Label on drive that came with the 1130 system

Label from newly acquired drive

Setting up IBM 9 track tape to use with P390 server

It was an extremely heavy work day, leaving me only one thirty minute interval to do anything on my hobby.

P390 SYSTEM CHECKOUT

I powered up the P390 system with the IBM 9 track tape drive (9348) attached via SCSI and eventually got OS/390 and the P390 to recognize it. This will allow me to create and read 9 track 1600 and 6250 BPI tapes from DOS, VM and OS systems. This system is sitting in my data center shed, with the tape drive and server under a table, the monitor, keyboard and mouse sitting in between a pair of card readers on the table top.

Console printer being exercised, more debugging for 1053 and 2310 PC drivers

1053 CONSOLE PRINTER RESTORATION

Running the 1053 during all the debugging runs for the various PC based adapters is exercising the gunk out of the typewriter but also exposing remaining erratic behaviors that are either lubricant based or maladjustments:

• index operations, with or without CR, sometimes fail to advance the platen
• the incidence of CR that fail to unlatch has dropped - it almost never happens
• cases where the CR skips over the left margin lever and gets stuck happen occasionally 
• tab appears to work almost every time it is commanded

I still have to repair and replace the ribbon color tape that shifts the ribbon up or down to the red or black halves of the ribbon material. This appeared to be constructed with a tiny projection melting the loop of tape together - something I presumably could reproduce. I will need to experiment on the spare but incorrect length tape I already own.

I will leave the typewriter out of its case and continue to let it run, to see how much better it gets with use.

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

I tracked down and repaired the flaw that hung up the transactional engine when polling for typed characters with the 1053 mirror driver. With that repaired and a few diagnostic changes made to the Python program, it was time to test again.

Somehow, it got worse. My transactional engine hangs up with either the 2310 virtual driver or the 1053 mirror driver. I had to dig into the logic to see what common factor could lead to this. I think I found a flaw, changed the logic and gave it another try.

The engine does not hang any more. I still have a couple of flaws to investigate:

• The FIFO for the mirror 1053 device is either not storing the character written on the typewriter or not retrieving it properly, because I am getting nothing but 0x0000 back which converts to a '.' on the virtual console printer.
• The virtual 2310 disk drive adapter is stuck in a continual retrieval of the last XIO - thus it is NOT resetting the state after the poll as it should.
• When closing the PC file associated with a device such as the virtual 2310 or mirror 1053, we can have an attempt to read or write from the file due to the timing relationship between the file open/close logic and the thread handling the device.

The first two are issues on the fpga side, while the last one can be corrected by some protective code (a 'try'-'except'). I whipped up the changed python code and then went looking through my VHDL for the first two issues. I quickly found a likely issue for the middle issue and a possible cause for the first. 

The third issue is resolved with the Python changes but both of the other two are still occurring. The problem failing to reset the last XIO type is a definite fault somewhere in the fpga logic - wish I could spot it. I made a few tweaks and will see. I did find an issue that could account for the 1053 mirror issues. 

A few more rounds of changes and tests but the results were no better. At this point, I am going to think through all the VHDL logic for the 1053 and 2310 and see if I can redesign it. Often if I start over on a section of the logic that is causing problems, I can bypass the problems.

P390 AND 9 TRACK TAPE DRIVE

I hooked the IBM 9348 tape drive up to the SCSI card in the P390 server, which should allow me to see the drive as a 3420 tape drive for the DOS, VM and MVS operating systems. I have to complete setting up the P390 - the monitor and keyboard are not yet attached - then I can switch on and begin experimenting. 

Progressing on debugging the virtual 2310 disk drive

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

I found a few places to tighten up the logic for the virtual 2310 drive adapter, where a race hazard might cause it to miss the reset of the last XIO function in spite of the PC side having retrieved it. I also made a change to better handle extracting the buffered last character and present it to the PC upon request.

I am moving through the virtual 2310 disk drive logic - verifying function and where needed cleaning up the design. At this point I am in the midst of the XIO Init Read of a sector, with quite a bit still to verify but moving forward which is good.

The changes I made for the mirror 1053 driver is resulting in timeouts on a transaction - I suspect that my logic is hanging the transactional engine in the fpga, due to some flaw in my FIFO pop circuitry. I will look over the code and figure out the issue.

My company laptop on which I maintain the master of the Python program has decided to abruptly cease accessing USB memory sticks, which were my medium of transport to the Linux netbook and the Windows Surface systems. I can still email the file to a desktop system in the den and place it on USB from there.

Debugging away on the virtual 2310 and mirror 1053 device adapters, plus some disk and tape device activity

1053 CONSOLE PRINTER RESTORATION

Every test I run on the 1130 is further exercising the 1053 mechanism, which should work out any stiffness from old lubricants and get me closer to a properly operating, fully restored console printer. Of course, I am still missing the rearward pulling spring on the tab interposer although in operation I am seeing tab operations taking place so this might not be as much of an issue as I assumed.

P390 SYSTEM CHECKOUT

The tape drive is cabled up but until I find a Centronics SCSI terminator I won't be ready to power up and test this. I was sure I had a few but after a couple of hours searching, I decided to just order one and test when it arrives Saturday.

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

I fired up the system and began some debugging. First, I realized that my fpga code is not working properly, to save the character typed into the FIFO and deliver it on request, as I am instead fetching an all zero character from the buffer. I will look into the logic to correct this.

My 2310 disk drive emulation testing showed me that the DCIP standalone utility has issued the XIO Sense DSW to the drive but doesn't like what it is seeing, since it goes into a loop continually sensing. I will have to dig into the program code to see what the utility is expecting to see and therefore what I need to be presenting with my driver logic.

I found a flaw in how I track and update the DSW for the virtual 2310 drive. This is probably a flaw that exists in other virtual drivers as well. Once I am sure this problem is gone, I will wrap the fix to the other devices.

Even with the fix made, something is not working properly. When my Python program requests the last XIO function code from the fpga logic, that act should reset the saved code so that further requests from the software will get a code of 0 until a new XIO is issued by the program.

After thorough review of the fpga logic, that reset has to be occurring. I then looked over the Python code and found two anomalies in the Python code for handling XIO Sense which might be contributing to the problem, although I didn't see the direct mechanism that would induce the symptoms I experienced.  With a new fpga bitstream loaded and new diagnostic output on the PC side, I went back to test.

I had also spotted something wrong in my fpga logic for the console printer mirror adapter which would result in it failing to capture the character written by the XIO Write instruction. I made those changes along with the 2310 adapter fixes and did a combined test of both adapters.

The 2310 test stopped initially on a Not Ready state for the drive, which should not have happened, but once I pushed start the program began merrily issuing XIO Init Read commands to analyze the pack. I had an error message from my Python code to investigate, but this is definitely progress.

My change to the 1053 mirror adapter now gets me different symptoms - the fpga side returns 'buffer empty' continually and I didn't see any data characters. That implies that the function to write into the buffer is failing, but I do need to stare at everything to be sure it is all solid.

I am getting an XIO Init Read with a word count of 0 from the standalone DCIP utility - will have to research what the drive will do with this - probably accomplish ECC checking but transfer zero words - which kind of makes sense for a Analyze function of the utility. The reason I am getting all the XIO Sense DSW invocations is the utility watching the sector number, I think. Anyway, my error checking assumed a wordcount of zero is an error but I have to change that.

I had it looping continually on the XIO Init Read operation - this also appears like the prior error, where it acted as if the fpga logic is not zeroing out the prior XIO function code once it is polled by the PC. I need to look more deeply, because that is a pretty basic flaw that must be fixed first.

I also had an error where I had opened and run against the disk file, then closed the file and shut down the virtual disk. When I started the virtual device again and attempted to reopen the file, I took an error. I need to figure out what flaw allowed this and correct it. However, I am done for the night with testing.

ARRIVAL OF SECOND PERKIN-ELMER DISK DRIVE

The drive arrived safe and sound and will be stored while I work on the first of the two. My back is already hurting from wrestling my P390 and tape drives around when I installed the SCSI cable - I can't even move the wood board with the drive inside to a convenient location until I feel a bit better. 

Minor progress on Python code and new disk drive coming

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

I did some testing today and found the muddle of various patches and diagnostic changes I made are getting out of hand. I had to sit down, look over the code and retest it on the PC before I fire up the 1130 again. It is hard to test when you can't count on the code being in the right state at all.

By the end of the evening I had the code in pretty good shape. When I next get a chance to test on the 1130, I should be back to testing the functionality itself.

DIABLO MODEL 30 DRIVE ACQUIRED

I picked up a model 30 drive which is close to the model that came with my 1130 - although my drive had crashed heads. I probably can restore the drive to operation for direct use with the 1130 system and compatibility with all the front loading 2315 type disk cartridges I have on hand. The Pertec and Perkin Elmer drives, on the other hand, use a top loading 5440 type cartridge. While they could hold data and be accessed by the 1130, they cannot interchange cartridges.

Mino

Bit of testing and cleanup accomplished on SAC Interface Box

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

I had a board meeting today, but eventually got out to the workshop and resumed testing. First I tried my new mirror buffer logic in the fpga to allow the devices on the 1130 to go full speed, capturing any data into a 1K word buffer in the fpga for extraction by the mirror device adapter code running on the PC.

I began to write and read to the FIFO but had some problems that need fixing. I also did more testing of the virtual 2310 disk drive adapter, cleaning up a few behaviors. Not sure how much time I will get over the next few days - very heavy work schedule ahead - but even 30 minutes at a time helps move the project forward.

Forced busy bit with mirror device adapters won't work. Restoration on PE disk drive. Other debugging on SAC Interface Box

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

Further testing revealed more flaws with my strategy for the mirror device of pushing the busy and/or not ready bits into the DSW when the program does its XIO Sense Device. The typewriter diagnostic looks for problems and goes into a halt with 'typewriter stuck in busy', a pretty simple thing to detect if you have just received the Operation Complete interrupt since busy is not a valid co-condition.

I think I am going to be forced to build in the big buffer for mirror devices and allow the mirror code on the PC to interrogate and fetch the contents asynchronously with the actual IO adapter driving data and my fpga logic capturing it.

I decided to push in some diagnostics for the 2501 reader and the 2310 disk drive adapters, from the PC side, to let me begin debugging them. Later tonight I will make the alterations to the fpga to implement the mirror buffer.

I loaded the standalone disk utility into the 1130 and my logic is responding. Now to work through the code, debugging and strengthening it. I am running various tests, each time determining another step in the operation of the virtual disk drive.

Tonight I generated a 1024 deep buffer of 16 bit words, for use by the mirror adapters - either the mirror 1132 or the mirror 1053, whichever is active. I began to 'wire' it in to the 1053 adapter logic - causing the XIO Write commands to push a character into the FIFO and the 'get special data' transaction from the PC to pop out a character.

For the 1132 printer mirror action, with its rate of over 3 line of 120 characters each second, I am going to move the assembly of the print line down into the fpga, so that the mirror adapter will push 60 words (two print columns per word) in ASCII into the FIFO for fetching by the PC program. I will also need a way to designate skip or space operations. Given the high rate, I can't leave it to the Python program to fetch 8 words with cycle stealing for each of 48 character positions of the emitter wheel, just to build out one line of print.

PERKIN ELMER DISK DRIVE RESTORATION

Two early tasks are to remove the 'protective paper' stuck to the front of the drive, and removing the protective lock keeping the disk arm from extending out and being damaged during shipment. Once these are done, I can begin inspecting and cleaning - I am particularly interested in the condition of any foam rubber or other plastics which might have gone bad.

The paper on the front is a problem because the adhesive as become much too set and won't peel off as originally intended. I am alternating soaking with water to remove the paper backing and wiping with IPA to dissolve the glue. It is very slow work to get this off without damaging the paint finish underneath which is visibly new and untouched.

Top rear untouched, top front mostly done, working on front black area

The disk arm is held back by a strong spring attached to a bright blue temporary holder. I removed the spring once I had the drive up in a safe spot inside the workshop. The blue rubber disc seems like it also serves as a protective backstop so I put it on sans spring. I did notice that the rubber on the disc and two spots along the side of the frame were tacky to the touch - thus degrading due to age.

Removing rear cover over positioner and electronics

positioner center rear, power supply right rear, cards left rear

Spring from blue disc at bottom holds arm rearward for shipping

Spring and disc after removal

Arm roller bearings visible with blue disc removed

Disc replaced as safety buffer for arm

I found some documents that cover a slightly older version of my drive but are close enough to be able to restore it from. I bought the second identical drive, also new in 'box' (plastic wrapped, mounted on wood shipping baseplate), and should have that here to restore along with this one. My big remaining item for these are the proper 5440 type (top loading 14") removable cartridges. 

Making progress with mirror 1053 driver testing

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

After my tests today it became obvious that my method of flagging the device as busy was not working to slow down the typing. I looked over my logic and see one thing I can do that might make a difference, otherwise I will need to go back to the idea of keeping a big buffer for the mirror device adapters.

I did verify that the logic is properly translating the typewriter character stream to the right ASCII characters or control codes such as carrier return. Once I solve the problem with the typewriter overrunning my Python codes ability to pick up the typewriter codes, the 1053 mirror driver will be finished.

I set up additional changes for the 1053 adapter and gave it one more try. When I was turning on not ready along with busy, the diagnostic dropped into the NR wait state - proving I am forcing inm the DSW bits for mirrored devices. However, it still issued bursts of characters without pausing for each one, which suggests that the diagnostic program doesn't check the DSW before each character is issued.

In order to debug this further, I will need to put in some hand-coded routines and step through the code on the 1130 to see if it is properly reporting status and picking up every character, if typed at a glacially slow rate. I can then try a rapid loop and see what is happening there.

Moving ahead debugging the 1053 mirror adapter

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

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.

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

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

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.

PERKIN ELMERS REMOVABLE PACK DISK DRIVE ARRIVES

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

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

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

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.

BLUE ESR TESTER ASSEMBLY

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

Testing of SAC Interface box with Linux laptop hosting the Python program, 9 track tape drive arrives, and 1053 mumble mumble mumble

1053 CONSOLE PRINTER RESTORATION

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.

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

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

IBM 9347 9 TRACK TAPE DRIVE ARRIVED

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. 

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

1053 CONSOLE PRINTER RESTORATION

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.

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

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

1053 CONSOLE PRINTER RESTORATION

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.

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

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. 

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

1053 CONSOLE PRINTER RESTORATION

I boycotted the spring today.

PERKIN ELMER (INTERDATA) DISK DRIVE BOUGHT

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.

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

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.