1053 mirror adapter working correctly, good progress debugging virtual 2310 disk drive adapter

1053 CONSOLE PRINTER RESTORATION

I finally hunted down suppliers of the continuous feed paper that is needed for the 1053 - it is wider than normal page printers but not as wide as the line printers. Easy to find 9.5" and 14 7/8" forms, but I needed 13 7/8" wide pages for the tractor feed of the 1053. A box is $72 with shipping, a bit expensive but the 2400 pages should suffice for quite a while.

All my testing of the virtual 2310 function makes use of the physical 1053 for the operator messages and data output. The continued use is making the behavior of the console printer better, just through exercising it so much. It will still require work and adjustments, but loosening the old lubricants is important too.

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

I traced down the cause of the problem with my 1053 printer mirror adapter, where it was failing to translate Selectric tilt/rotate codes to ASCII. The fix was made and I will retest soon. Still no clue as to why I am getting pairs of characters arriving in a single transaction from the FPGA. More research underway, because I don't see any way this could happen unless the diagnostic program issuing the XIO is packing two characters per XIO Write, which violates the Functional Characteristics declarations concerning the console printer.

I also prepared a virtual disk drive with known contents on various sectors so that I could test out the virtual 2310 disk adapter logic a bit more. This way, I can run the DCIP utility and dump various sectors to how what the first few words returned from the sector match the known contents. Finally, I have recorded the memory location of the disk sector buffer in core so that I can check an entire sector of content without needing to print it all on the 1053 typewriter.

My Python program GUI speaking to the SAC Interface Box and 1130

My test on the mirror adapter worked much better - getting good translations for some characters but still didn't match exactly what was being typed by the DCIP utility. The problem was once again in the same area I had to fix before - in converting the incoming word value into a bit string to look up the ASCII translation. I will change how I do this to a more reliable method.

With the change in place, I can report that the mirror 1053 adapter is working perfectly. It produced a file with exactly what was typed by the DCIP program, but in ASCII on the PC, without interfering at all with the operation of the real physical 1053 console printer.

Mirror adapter for 1053 produced proper output matching typewriter output

On to the testing of the virtual 2310 disk drive adapter next. Armed with the location of the disk buffer, I tried to dump sector 0 of the virtual disk in order to compare it to the known values. I saw two anomalies:

• the disk contents were correct, but alternated with words of a fixed value 0x5803. This means my loop to dump each word of the disk sector is not working properly. I read the sector from the PC file, place it into an array and then walk through the array to do the read or write. I may be setting up the array wrong or walking it wrong. 
• The PC side adapter logic pushed an operation complete status down to the FPGA box, but I didn't seem to react to it until I had reset the 1130 processor. Thus, one of my FSMs in the 2310 logic in the FPGA is not working properly. Once I triggered it via the reset, I saw my box write the data words down to the 1130 IO buffer using cycle steal, just as it should have. 

The first problem is almost certainly in the Python code, while the second is almost certainly in my VHDL for the FPGA. I will walk through the code and see what might be causing both problems - if not patently obvious, I will instrument some tests to help me figure out the flaw in either or both sides as needed.

I think I fixed the second problem and concentrated on debugging the first problem as the night fell. When I emitted diagnostic messages during the routine to read the sector from the PC disk file, I saw that the data was correct from the file but the flaw was in my logic for moving it into an array for pushing into core with the cycle steal mechanism.

The root of the defect is in the way I am handling the difference between the byte size of data from the PC file and the 16 bit words used in the 1130. I need to step by twos when fetching words from the PC file buffer but step by ones when bumping storage addresses for the cycle steal write.