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.