Keypunch interface PC side software coding almost complete, ready to start 029 testing

NEW KEYPUNCH INTERFACE DEVELOPMENT

The software to run in a PC, connected by serial link to the KPgolem interface box in order to drive a keypunch, is fairly complete for all aspects except the portions that send and receive over the serial port. Its user interface is solid and it handles input and output files on the PC well.

Python with its regular expression capabilities makes the extraction of status easy, since the protocol over the serial link is purely in ASCII, equally easily grasped by humans and programs. That was one of the design objectives which makes the programming of the interactions in this software simple.

The language of the protocol is well defined for what the PC sends to the interface and the responses have a few locator beacons, sequences such as 'OK' that can be detected without having to care about the exact format and contents of the rest of the incoming stream to the program.

All interactions are simple transaction pairs - a command sent from the PC to the interface box, which sends back information including confirmation of success, notification of errors, and other data solely based on the command the PC issued. When not responding to a command, the interface box does not send any messages towards the user (PC program).

Serial streams are simply a sequence of characters coming over the link, requiring that the protocol and software establish message boundaries since we think in terms of a command string or line and some response strings/lines coming back. We can receive a line across multiple bursts of serial transmission - getting a part of the line in the first burst, for example, some more in a second burst, then getting the rest of a line plus data from the subsequent line arriving in our third burst.

The program must extract data from the serial link as it arrives, building up a message until we see the characters or conditions agreed upon as a message delimiter. If some data has arrived for a subsequent message, it should be saved while we act upon the one complete message we have aggregated.

There is very little buffering in the serial link hardware on either side, so data must be read out of the port as rapidly as possible, lest the incoming data flood in overwriting some earlier characters before we can read them. The link uses flow control, the characters XON and XOFF (defined ASCII characters) are sent by each side to request the other side to hold off sending more data, then releasing the other side when we have free up room in the serial port buffer.

The keypunch interface box mainly uses this to hold off the submission of new commands until it has consumed its buffer of incoming data and completed those commands. We can send XOFF from the PC if we are slowed down handling the incoming status messages from the keypunch, but its granularity is an entire message at a time, not character by character flow control. Thus, both sides use flow control on big chunks or groups of data. It wasn't worth the trouble to add large buffers and threaded server processes to build fine grained flow control.

By the end of the evening, I had almost all the code completed but not yet tested. The only steps left (beyond debugging) are to call the keypunch connection dialog at startup, and to put in the top level loop which will call my functions that issue the punch or card read commands to the keypunch interface.

The code issues plenty of diagnostic status messages on the bottom status bar portion of the user screen, both error conditions and some progress indicators at startup. It watches for indications that cards are not registered when we are trying to punch or read each card, flashing the not-ready condition and request to register the cards in the status pane area.