Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

pia_communicator: Incorrect Control Character Handling #8

Open
0cjs opened this issue Feb 25, 2020 · 0 comments
Open

pia_communicator: Incorrect Control Character Handling #8

0cjs opened this issue Feb 25, 2020 · 0 comments

Comments

@0cjs
Copy link
Contributor

0cjs commented Feb 25, 2020

The control character output handling of the PIA communicator is substantially different from the actual Apple 1. Here is the original Apple 1 behaviour:

  • ASCII Control characters ($00-$1F) other than CR ($0D) print nothing and do not move the cursor.
  • CR ($0D) fills the remainder of the current screen line with spaces and sets the cursor to the next line, scrolling the display if the cursor was on the last line.
  • Characters from the upper-case sticks ($20-$5F, space through underbar) are printed as-is.
  • Characters from the lower-case sticks ($60-$7F) print the same glyphs as the upper-case sticks. (Though $7F is an ASCII control character, the Apple 1 treats it as a printable character with the same glyph as $5F.)

(See the link above for references verifying this behaviour.)

pia_communicator passes all control characters directly through to the serial output which produces substantially different behaviour in any standard terminal program because those terminal programs process characters such as ASCII BS ($08) by doing cursor movements that the Apple 1 was incapable of, as well as printing different glyphs for the lower-case sticks.

The obvious fix would be to change pia_communicator to generate ASCII output to the serial port that emulates the behaviour of the actual Apple 1 video system. However, a reasonable argument could be made that not converting the lower-case sticks (excepting $7F) to the equivalant codes in the upper case sticks is not harmful, and potentially useful.

It might (or might not) also be useful to tweak the input handling better emulate the Apple 1 keyboard. pia_communicator already maps lower case to upper case; possibly it should also, for convenience, map backspace to _, the character that WozMon uses to command "remove previous char from input buffer." That, however, may run into issues with other software, such as KRUSADER, which uses backspace (in this case for "cancel line"). I suppose the ideal would be to have some settings in the program to change this on the fly, e.g., ~B<BS> and ~B_ to change the backspace key translation to backspace and underscore, respectively.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant