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.