Altirra / TBXL odd error

[nebpehtira]

Hi all,

Getting this very odd but consistent error with a simple TurboBasic XL program I'm playing with in Altirra - all thoughts welcome on this one. So, we're in Mode 0, and I've got an on screen form that's gathering some numeric data, and I want to position input "?" prompt to the right part of screen to gather input from each field. Should be dead simple - position the prompt and a simple numeric variable input?

1225 ------------------------------
1226 REM Getting input parameters
1227 ------------------------------
1230 POSITION 15,7:INPUT PO2
1240 POSITION 15,9:INPUT DM
1250 POSITION 15,11:INPUT ENDN2

 

With Altirra in regular screen emulation mode this consistently generates Error 8 at line 1230. However, when in CIO enhanced screen mode, it gives no error and runs fine.  There must be some rookie mistake here, but I honestly just can't see it  - Unfortunately I don't have access to my "real" machine to test it on bare metal.

 

Any ideas?

 

 

 

 

[+MrFish]

It ran fine for me.

 

Can you give some more details about your Altirra configuration (hardware, firmware, etc.)?

 

[Rybags]

The only issue I see is 1250 with variable name starting with END - using statement or function names as the start of variable names is potential for trouble.

[phaeron]

Altirra's enhanced CIO mode is a bit of an odd duck compared to the regular Display Handler, it emulates more of a traditional TTY instead of a screen editor. In particular, it doesn't track logical lines the way that the regular E: device does. I put it in as a more modern way of entering in text like BASIC programs, but you'll run into differences like this when overwriting areas of the screen. Regular screen mode in the emulator disables this and just runs the regular E: handler, so it'll match the behavior you get on the real hardware.

 

One thing that can get you in trouble here is if the area of the screen you're trying to input from was originally PRINTed as more than one physical line in the same PRINT statement. In that case, the E: device has spliced the two physical lines into a logical line, so your INPUT statement may be trying to read from the next line too.

 

[nebpehtira]

9 hours ago, phaeron said:

Altirra's enhanced CIO mode is a bit of an odd duck compared to the regular Display Handler, it emulates more of a traditional TTY instead of a screen editor. In particular, it doesn't track logical lines the way that the regular E: device does. I put it in as a more modern way of entering in text like BASIC programs, but you'll run into differences like this when overwriting areas of the screen. Regular screen mode in the emulator disables this and just runs the regular E: handler, so it'll match the behavior you get on the real hardware.

 

One thing that can get you in trouble here is if the area of the screen you're trying to input from was originally PRINTed as more than one physical line in the same PRINT statement. In that case, the E: device has spliced the two physical lines into a logical line, so your INPUT statement may be trying to read from the next line too.

 

Thanks, Phaeron. That's really useful

The PRINT issue might be the culprit there. I'll check back through the code later and have a look.

[nebpehtira]

Hey all,

Finally, had a chance to look back at this and figured out the problem. These statements were placed on screen so as to fit into field on an on screen form like so:

 

I turned P02 into a string to capture any kind of input then immediately getting the program to spit it back out, and found that the issue is that rather than gathering user input from the keyboard it grabbed the entire row of the screen. I.e. instead of say "1.4" (which would be the sort of expected input range) it grabbed "1.4   | Ideal O2:      |", hence generating a code 8 error, as the program was expecting numeric input.

 

Not sure of the best way to fix this? All ideas welcome

 

 

[+MrFish]

The method I'm using in my font converter to gather a user input font name should work for you.

 

In basic, it uses the Keyboard device for input, the Editor device to display input, and the Screen device to gather the final input.

 

It's pretty straightforward, and allows restricting input and cursor movement (so people can't move the cursor to any location on the screen).