1403 printer emulation and card reader validation, week ending March 2, 2014

DOCUMATION / 2501 CARD READER TESTING

I went over the input board for chip one, anchoring leads more firmly, reflowing connections, tracing and validating the quality of the connections on the board itself, and testing the continuity under vibration of all the wires attached to the board. I suspected one of the address bits was flaky, so dealt with them as well.

If there is a problem with the 'wrong' chip replying due to flaky addressing, it might be on one of the other boards. Will reflow their addressing pin connections while I am at it. As well, I am building a replacement board 1 in case that is necessary. This throws away another day.

After building an entirely new board for chip 1 and wiring it in, I started testing it and of course, of course, the interface isn't right yet. It has a new behavior where it wedges into some state that requires me to power down both the Documation and the interface in order to reset it. The data stored in memory is puzzling as it is different from what is on the card, although I can sort of see the existence of the card data patterns.

More traces and investigation, plus I may need to work over input board two in case it is causing the problems for board one and the overall interface. Fortunately, I did zero in on the wiring mass where the cables from the reader are split out and routed to the various boards. Moving the wires slightly induced dramatic and immediate disturbances in the signal, while tapping the boards did not.

Input chip two board being prepared for new interface implementation

I am rewiring this, using a new perforated prototype board to connect and distribute the signals. This will give me good access for tracing signals in addition to the value it will bring in more solid connections.

New distribution board in upper right, anchoring external cables and allowing testing access

Having concluded the complete replacement of board 1 that carries the card column signals and the rewiring of the cables and termination, I found exactly the same bits flaking on and off. This leaves four boards - the latch board, my most likely suspect since it holds the values that should not be fluctuating, the timer pulse board, and the two MCP23017 boards for input 2 and the outputs. This is really frustrating.

Took out both board 2 and the latch board, in order to rewire them and make sure all contacts were solid.
I couldn't find anything on the board itself to explain why a couple of bits that should stay latched are flickering, but it could be a flaw in one of the chips I used - they were grabbed from a big bag of recycled chips when I first built the board to test its usefulness.

I built a new board, using IC sockets and all new components, with better anchoring for the signal connections to the board. While doing that, I combined the function of the latch board and of the pulse generator board into the single new one.

New latch and pulse generator board, with signal lines in place

At the same time, I cut away most of the wiring, which has quite a few soldered joints from when I had been replacing portions piecemeal or swapping just part of the wiring. This way, I can plan out and wire everything cleanly. This unit is pretty key to the system's usefulness, since the card reader is quite central to many tasks.
I want it to be very dependable, even if it means I have to redesign and rebuild this another one or two times. my only frustration is that completion of the card reader checkout is such a lengthy process, since I have quite a bit left to do on the rest of the system too.

Power supply quality was an increased focus in this go-around, including a very large capacitor at the inlet to the interface chassis and then a cascade of capacitors out to the individual chips. All in all, this took about ten hours of careful work and checking. From that point, I decided to redo the output box and all the remaining pieces, to really get this interface where I want it.

The lamps and card pick driven by the output box, whose connector is now installed on the interface box more directly, plus big power filtering capacitor in upper right of image.

During the disassembly of the output box, I think I discovered the flaw that was causing my flaky behavior, causing one or more of the chips to sporadically respond with the wrong data. The clock line inside the output box was a cold solder joint - as assembled it looked like a good mirror like solder joint, but after I removed other parts, I could see that the copper clock signal wire was just sitting around the base of the soldered wires.

With sporadic 'glitch' like malfunctions, it can be very difficult to find the culprit since the occurences aren't frequent enough or certain enough to capture. Unless I know a bit more, I couldn't have put a logic analyzer trap sequence in place to capture the glitch. It was why I had to rebuild and to look at any part that conceivably could be causing problems.

I am traveling this week on the east coast, thus the completion of the interface rebuild will wait until I return. I feel confident that I should be able to move ahead once that is done, as I have a very clear and definitive problem that would produce the problems.


APL TYPEBALL FOR SELECTRIC

I spotted a selectric typeball for APL on ebay, not perfect because it was the 987 version for the normal typewriter coding (correspondence) and not the BCD coding version 988 that would work directly with the 1130, but I tried to buy it anyway. I would have had to do some translation on the fly, but only when the APL typeball was mounted, requiring some kind of switch or flag to inform the machine of the need.

Somebody else bought it before I could complete the transaction, however, so I am still seeking a way to run APL/1130 with my console printer. Strangely, ebay reports it as a buy-it-now sale for well less than the amount that was listed, thus the seller seems to have ended it early and way below what I was going to pay.

Rear of my 1130 replica, with typewriter mechanism just waiting for its APL type ball

HP 2673A / IBM 1403 PRINTER DEVELOPMENT

I continued coding the Arduino controller for the printer, adding in the remaining elements, improving the user interface, and preparing to connect it to some pushbuttons that will complete the emulated 1403. A real 1403 has buttons used by the operator - start, stop, check reset, carriage stop, carriage space and carriage restore. The Arduino can send appropriate codes to implement these, asking the fpga logic to process the first two and sending HP command strings to ask the 2763A to execute the remaining four as appropriate.

As I plan for those buttons, I will consider using a keypad with arrow keys to replace the use of the little joystick on the LCD shield. That way, I could avoid the slow analog to digital conversion process along with relieving the usability challenges of the tiny existing handle. I have many digital I/O pins open on the Arduino, as well as the ability to tie to the interrupt system to make this even more efficient.

If I am not polling for the button/keypad/arrow input, the user interface can be available even during active printing assuming I have functions that could safely be implemented with the printer running. At a minimum, it could display the values of such configuration variables as page length and the current content of the virtual carriage control tapes.

The 1403 also has a number of lamps that I could implement: print ready, print check, end of forms, forms check, and sync check. Many do not make sense given the different mechanism, others are tough to detect as the HP printer would go offline and stop talking to me if the forms jammed or ran out, rather than informing me first to enable lighting one of those lamps. I will probably only implement the print ready lamp, even if I dummy up the panel to seem to offer the others I would not put any lamp or circuitry inside.

I had hoped to be able to highlight portions of a line on the LCD screen, to implement a numeric keypad in the four row (789, 456, 123, cancel 0 enter) scheme, but technically I can only highlight the entire row at a time. I chose to highlight but blank out the non-selected choices, e.g. the 8 may be the only visible digit in the selected  row if the middle column is active. If I add a keypad, this problem goes away as I don't have to put a soft keypad on screen nor depend on columns to select among choices.

As an intermediate approach, having the navigation arrows and enter button as full size discrete buttons will make use of the soft keypad much less cumbersome, as well as giving me most of the other benefits such as reduced overhead. I have decided to proceed with the navigation buttons but no numeric keypad.

Using only XON/XOFF flow control and loopback control signals, there is no way to determine that the printer is actively receiving our data. I was hoping I can get the printer to send some kind of response back over the link, allowing me to verify operation, but it does not appear that this is possible unless I can overrun the input buffer so rapidly with nulls that it sends an XOFF to slow me. I did some experiments and decided that I can monitor the CTS signal, which will only be high when the printer is online and not busy, as a means of checking the health of the printer link. A similar method is possible with the link to the fpga.

I have added all the code to manage the carriage control tape images, drive the real printer in sync with the imaginary tape but using the similar/not identical virtual forms control (VFC) table. My user interface is in very clean shape. Lots of error checking everywhere to make it solid.

It took a while to get the RS232 set up to communicate with the printer - there are many signals involved, the usage is nonstandard, and the documentation for most serial links doesn't go into enough detail to clarify what is necessary. For example, while HP claimed that it was not using RTS and CTS, even their loopback test failed unless I connected their CTS output back to the RTS input. Finally, I could use a serial port from a PC to drive the printer.

It turned out that my chip on the RS232 voltage shifter board was fried. I wired up a replacement in order to get some testing done on the actual print output. I was missing a couple of capacitors of the right value, otherwise everything was on hand to quickly put together this on a prototype board. My code for managing the virtual carriage control tapes, changing lines per inch and other operational tasks is mostly debugged already as much could be done without the live printer.

RS232 voltage level shiftinjg and connector for the cable to the HP 2563A printer

My new board works well, the printer is responding to the sequences sent to it. I am wiring up the navigation buttons and the 1403 function buttons (start, stop, carriage skip, carriage space, carriage stop and check reset), as well as LEDs for the status lights on the printer panel (print ready, print check, end of forms, forms check, and sync check; of the four, I wired up print ready and end of forms). I am short a few pushbuttons but will finish the wiring when I head over to Anchor electronics tomorrow morning.

After a long run testing the printer, I am satisfied with how I am driving it from the Arduino. Some of the functionality is yet to be fully tested because it will depend upon the 1130 fpga side being ready. The remaining validation includes:
   proper translation of 1403 print codes to ascii and correct printing on the page
   correct handling of pacing and buffer control at full speed and various bottlenecks
   correct support of spacing and carriage tape skipping commands from the 1130

Virtual 1403 printer (HP 2563A) for my 1130 system

I will now turn my attention to the fpga logic work in support of the 1403 printer. I have to complete my Storage Access Channel adapter that uses the SAC mechanism provided by the 1130 logic to handle IO. I need to build the 1403 printer controller logic that interacts with the SAC and with the Arduino. Finally, that printer adapter should be modeling the timing and behavior of a real 1403 model 6, in order to implement a timing accurate emulation.

I did take the time to assemble the board with the pushbuttons onto a shield kit and install it on the Arduino. Sadly, all the prototype shield kits are designed so they cannot fit the pin arrangements of an Arduino Mega, whether the earlier 1280 or any of the newer 2560 models. It is very annoying; there is always a blank or other blockage. I did some cutting and bending, put it in an unnatural orientation, then put the perfboard with pushbuttons atop it. I had to do a notch on the perfboard to clear a few pins, but it is together now. I was busy Saturday evening soldering the various pushbuttons and serial link connections to the pins.

Constructing the control box to make the HP printer work like an IBM 1403 printer on the 1130

The serial link from the fpga to the Arduino will run at 9600 baud, odd parity, as that is fast enough to achieve the full rated print rate of a 1403 model 6, but is slower than the emptying link to the HP printer which minimizes the risk that we will overrun the printer and get into flow control problems. Further, since the signals will run further on this link than the short link from control panel to the printer itself, having a slower speed and parity checking increases reliability of the link.

I began coding the logic to manage the serial link between 1403 adapter and the Arduino. It will connect to the 1403 adapter logic that I had already begun. That adapter has to connect through my generalized Storage Access Channel adapter that in turn talks to the IBM designed SAC interface logic. Quite a bit of coding and testing are required.