Debugging work on 1053 and on SAC box mirror1053 and virtual 2310 functions

1053 CONSOLE PRINTER RESTORATION

I ran the typewriter diagnostic to test the console printer operation. I found it is still unacceptable:

• Sometimes a line feed sticks on, ejecting line after line
• Some carrier returns don't latch on, returning only partway
• it stalled on some CR operations with the carrier at the left
• sometimes CR movement is very slow (to the left)

One area for repair I spotted was the CR activation microswitch on the underside, which isn't set up properly. I will detach and reinstall it correctly. The line feed issue is still residual crud that stops the interposer from latching frontward on a restore. The CR failure to latch on is an adjustment issue. Not sure what causes the stall, but I will work on these first tasks and then test another time.

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

My fixes to the FIFO usage seem to be working fairly well, as I am now seeing the proper typewriter codes returned to the Python program. My logic is also working properly in detecting empty conditions, when I have fetched all the characters that were in the FIFO. The character stream I see matches what was typed and what the diagnostic should have typed.

Other aspects are not yet satisfactory:

• Sometimes I get back one character at a time, which is what I expect, but in the middle of the test I began receiving pairs of characters. Good would be x9a00 x2100 x4100 x9200 but I might see x9a21 x4192. Since in almost every case the two sides are both valid character codes for the typewriter, I must have a flaw in my fpga logic although the PC side is possible.
• I am not translating the character I received back to ASCII, a flaw in the Python program

I will hunt through the PC and fpga side logic to investigate these odd results and fix the code. Meanwhile, I will switch testing to the disk emulation, loading the DCIP utility and attempting to dump a sector of a virtual disk drive hosted on the PC. This will help debug the virtual 2310 disk drive adapter logic.

My first run failed because I entered the wrong drive number for the utility. My virtual 2310 disk drive is drive D, which is entered as drive 4 to the utility, the internal disk being drive 0. I entered 1 instead, which my logic reported correctly as 'not ready'.

When I tried to run the program again, I found that my incoming data register was jammed with extra bits 0x01F0 so that I couldn't even load core properly from a file anymore. This happened in past days when I was testing as well. Not sure what is happening, but power cycling the fpga, my PC program and the 1130 didn't correct it. I will need to ponder what could possibly be causing this, although I suspect it is either the SAC box or one of the adapters inside the 1130.

The bits that are stuck on align too neatly with chip 3 of my output driver board in the SAC Interface Box. I powered up for another test, found the bits still stuck on, and brought out a VOM to check the voltage levels on chip 3. I touched the +5V feed for the chip and a few other leads on the chip, which looked okay. On a hunch, I tried the the memory load again and found it working fine. This tells me I have an intermittent power issue with the +5V feed on pin 14 to chip 3. I will reflow the solder and verify that the socket to pin mating isn't at fault.

Since I could test again, I loaded the standalone disk utility program DCIP once again and this time, used the correct drive number (4) for my test. I tried a dump of the first sector and was delighted to see that the code appeared to complete a read of the sector and the values began to be typed on the console. The typewriter isn't in good enough shape yet to print out a 320 word sector properly, but even with the first few words printed I could see that I had indeed fetched the beginning of sector 0 of the virtual pack. The status information from the Python program running in the PC looked good as well.

I will have to do some incremental testing before I am convinced that the emulation is all correct, but the fact that I seemingly got through a dump of one sector is very promising. I will take a known disk image from the simulator, with some printed sectors as reference, then do runs on the SAC Interface Box where I can check the in-core buffer to see if the contents are exactly right.

Going back to the 1053 mirror adapter issue, the biggest defect is the failure to translate to ASCII properly, which seems to be due to a subtle python issue since on first blush, the values I saw during operation should have fetched the right ASCII characters. I will need to do some testing with the code to see why it isn't succeeding.