Once I had my own code running to my satisfaction, it was time to move over to the full 3174 controller replacement that was developed by Andrew Kay. I had a few tweaks to make to the code since he built and tested this with just two terminals, a 3278-2 and a 3848, not the 3178 or 3179 terminals that I own.
The keyboard I have is a Data Entry Keypunch type while his terminals have the Typewriter arrangement The consequences of that are subtle in one way, the existence of a downshift key which he doesn't have, and simple due to extra keys PA3 and SKIP.
On the typewriter, there are two upshift keys and a caps lock, since the typewriter has both lower and upper case letters. The IBM keypunches (026, 029 and 129 for example) only have upper case letters. They use the up shift key as a numeric shift, not capitals.
That means the same in many ways - select the upper character on the keycap while upshift is pressed - but on a keypunch there are programs that force a field to be numeric. Therefore, the down shift key is needed to select the lower character when the keyboard is in numeric mode. Also, caps lock is called numeric lock on my keyboard.
I had recorded all the scan codes emitted by my keyboard when pressing the keys, embodied it in a terminal key map file along the lines of his existing 3278 and 3848 files, and adjusted his software to recognize the keys he was missing on his keyboards.
Finally, I tweaked the logic to recognize when the keyboard is in Caps Lock mode, now logically Numeric Lock mode, so that if the down shift key is pressed we ignore the Numeric Lock state. I was ready to fire up the system and test my keyboard. I would need a mainframe to connect to, which I handled by running an instance of Hercules the 360/370/z emulator.
BRICK WALL ENCOUNTERED
Alas, one of the deficiencies running Python in a Windows environment is that some OS related functions that are commonly used by Python coders are Unix based. For example, fcntl is used to manage files, but on Windows the win32 API does only roughly analogous functions and is not code compatible.
The VT100 capability included in the oec product, although not something I will be using, make extensive use of fcntl and many other OS functions for its pseudo TTY implementation. Thus, when I fired up the controller product, it couldn't find those functions and promptly quit.
ADDING A LINUX ENVIRONMENT FOR MY TESTING
I have hit this enough that I need to reestablish a Linux environment for software such as this that fails to run under Windows. As a quick and dirty solution without the small risk and effort of partitioning my laptop to be dual boot, I am setting up a USB stick based Ubuntu system with enough persistent storage to place Python its libraries, Hercules and oec. The large capacity USB stick arrives later today and by tomorrow I will have the alternate environment running.
WORKAROUND TO TEST UNDER WINDOWS
Andrew confirmed that only the VT100 functionality attempts use of the OS specific functions that are missing on Windows. Thus, I only had to comment out the include for VT100 at his suggestion and could bring up the software to begin my testing.
No comments:
Post a Comment