ENHANCING SPEED OF THE CODE
I went through the code and looked for all the spots where I could reduce the time it took to perform a function or stop the processor from having to execute code unnecessarily. The aim is to ensure that we can keep up with the max rate of 15.5 characters or short movement commands per second that the typewriter can achieve.
The code implements two state machines, one for the typing and short movement operations, the other for the three long/indefinite operations (carrier return, line feed and tab). The code interrogates the timer and compares it to the time when the state machine left the idle state.
At specific durations, it switches the machine to the next state. However, it also outputs signals during some of the states, which can mean we are repeatedly outputting the same signal until the timer comparison moves the machine to the next state. A simple change fixed this - with the code that emits signals only taking place on the first cycle in a new state, saving the old state to detect the 'edge'.
The character lookup was unnecessarily complex, looking through a table of all 44 possible tilt and rotate combinations for the typeball hemisphere to find a match, then using the index of where we matched to pick out a character from the hemisphere glyph table. I created a direct access table with all 64 possible combinations of tilt and rotate values, even though only 44 of them are valid, so that I could pick up the index using the tilt/rotate selection value as the displacement into the table. That avoided the loop reading through a table.
I made many improvements long these lines to reduce the compute load and free up the Arduino for faster response. When I am back I can do some testing to verify whether it can keep up with the stream of characters and short movements.
ADDING IN APL TYPEBALL SUPPORT
One of the stretch goals when I began this project was to emulate both the normal console type element and the special Selectric ball used with APL (A Programming Language). I have a few type 988 balls which would allow the IBM 1130 system to run APL, when put on the 1053 console printer. I believed that adding this to the emulator would be useful.
One of the challenges of the APL character set is that there are many more symbols than the 88 positions on a Selectric type element. Once you consider the 26 alphabetic and 10 numeric characters that must be included, only 52 spots are available for other glyphs. The solution IBM adopted was to overstrike, typing one character from the ball, backspacing, then typing another (or even a third), to combine together to form the intended glyph.
This poses a small challenge to the emulator which sends data to a remote terminal program for display. It isn't using actual paper, thus when the backspace is sent after the first character is typed, the terminal will replace the first character with the second when it is sent rather than combining the two.
This is a minor issue with normal console characters, since overprinting is not done that often with the 1130. Passwords might be obscured by backspacing and typing various characters over the entered password thus making it very hard for an observer to read the password from the paper. The 1053 diagnostic prints a line of O characters, each time backing up and typing a * character. This is used to verify how accurately the spacing and backspacing is operating.
This becomes much more of an issue with APL where overprinting is very common. The meaning of a glyph is going to be impossible to discern if you only see the last character typed into a column and not the prior ones.
This can be solved by developing a custom terminal program to display the output of the emulator. It would retain the characters in the current line, thus when backspacing it would merge the prior column contents with the newly typed character. The program will be displaying the columns as bitmaps avoiding the need to find a unicode glyph for the combinations.
Meanwhile, I had to create the alternative set of glyphs for the 88 positions of the APL typeball. The emulator has a command that can be issued over the serial link that switches between normal and APL elements. I just had to find all the glyphs such as ⊥ and ∆ to put them into the table. As long as unicode had the character, I could transmit it over the serial link.
To make life more interesting, since I was visiting relatives in Myrtle Beach, South Carolina over the past few days, I had to recreate the APL typeball without having it in my hand for direct inspection. I had to look over various online documents and use a 3D viewer to examine a replacement typeball designed by another hobbyist.
No comments:
Post a Comment