BUG: READ CHAR

[ Table of Contents ] [ List of Example Programs ] [ READCHAR Disk Image ]

I started working on the MetricConversion1 example program from page 80 (Listing 6-4) of the book, Pascal Primer, by David Fox and Mitchell Waite, but ran into a bug with the Atari Pascal Language System.

The program has a simple menu and the user can select from four single-character choices. The user's menu selection is handled with a READ(Select); statement, with Select being a variable of type CHAR. That part seems to work. The user's selection is honored and in three cases, the program goes to the correct subroutine (procedure) to perform the selected task. The fourth choice exits the program.

In each of the three choices that performs a task, each subroutine has a READLN(VariableName) statement, with the VariableName being of type REAL.

The problem is that the menu selection CHAR read from the READ(Select); statement gets appended to the front of the REAL read from the READLN(VariableName) statement. For example, if you select option '1' at then menu and then enter "987.654" as the REAL number variable, the program ends up with "1987.654" in the REAL number variable. Ugh.

CHRTEST1

Here is a simplified testing program.

Compile D2:CHRTEST1.PAS. Link D2:CHRTEST1,FPLIB,PASLIB/S. Run D2:CHRTEST1.COM.

Enter a '9' at the first prompt and '123.456' at the second prompt.

As you can see, the CHAR output is correct, but the REAL output is incorrect.

CHRTEST2

Here is a second testing program, changing the CHAR variable to a STRING variable.

Compile D2:CHRTEST2.PAS. Link D2:CHRTEST2,FPLIB,PASLIB/S. Run D2:CHRTEST2.COM.

Enter a '9' at the first prompt and '123.456' at the second prompt.

Using a STRING variable seems to work correctly, but it requires hitting the RETURN/ENTER key to enter the menu selection.

Imagine that you are creating a computer role playing game like Ultima that uses a couple of dozen keyboard keys as commands.

The program should accept commands WITHOUT hitting the RETURN/ENTER key so that user input is fast and non-blocking. This bug seems to disallow this type of functionality.

CHRTEST3

Here is a work-around using a "PEEK" and a "POKE". It requires the compiled PEEKPOKE module code from the PMDEMO.PAS example program from Appendix F of the APX Atari Pascal Language System User Manual to be on disk drive D2.

Compile D2:CHRTEST3.PAS. Link D2:CHRTEST3,D2:PEEKPOKE,FPLIB,PASLIB/S. Run D2:CHRTEST2.COM.

Enter a '9' at the first prompt and '123.456' at the second prompt.

On the Atari 8-bit, the shadow register at address 764 holds the last key pressed or 255 if no key has been pressed. I can read the input from there and then reset it back to 255 again. When I enter a '9' at the keyboard, address 764 is updated with the internal keycode 48, which is then output to the screen. Additional information on the Atari 8-bit internal keycodes can be found in an article titled "Reading The Keyboard Codes" by Orson Scott Card, published in COMPUTE!'s Third Book of Atari.

Is this a kludgy work-around? Maybe, but it works with a few caveats. First, there is no keyboard "click" when you enter the value at the first prompt. Second, it returns an internal Atari 8-bit keycode rather than the CHARACTER entered, or even the ATASCII (Atari 8-bit ASCII) code. Both of these could easily be fixed by handling this in a procedure call and a few additional lines of Pascal code.

I'll try using this solution for now.