Turbo BASIC XL: omitting ? for INPUT

[+slx]

My son is trying to program an Infocom style text input in Turbo BASIC XL. While it offers a custom prompt using INPUT "prompt";variable ​it will still show the ? prompt.

 

​One method to avoid this would be a custom Input routine using the "K:" device (which would require a lot of programming with the only benefit of being able to avoid non-text characters) or - more kludgy - replacing the ? with the > in the font (he's using a custom font anyway).

 

Any other ideas?

[thorfdbg]

Just replace the semicolon by a comma and TBXL will not print a question mark.

 

[Rybags]

A trick in Atari Basic is to use INPUT #16,

 

Any INPUT directed to a file number other than 0 will suppress printing of the ?

The way the file commands work, the file # value is ANDed with hex 0F after that check is performed.

Edited April 24, 2016 by Rybags

[+slx]

Thanks!

[fujidude]

A trick in Atari Basic is to use INPUT #16,

 

Any INPUT directed to a file number other than 0 will suppress printing of the ?

The way the file commands work, the file # value is ANDed with hex 0F after that check is performed.

 

Does this work because BASIC sees that the channel is not 0 (and so suppresses the question mark) but then when the channel number itself is used the high order nibble is ignored (making the channel 0 after all)?

[Rybags]

There seems to be some checks in place, as having an output attempted to a user opened IOCB could obviously cause problems, e.g. disk file opened as input only as is mainly the case, keyboard which is input only, etc. Also, obviously attempting IO to an IOCB between 8-15 could overwrite memory that shouldn't be touched.

 

It's an imperfect system, if you do INPUT #256 it will generate the prompt so it's likely that Basic only bothers checking if the low byte is zero.

The initial statement processing rejects out of range values <0 and >32767 as many do but beyond that it gets a bit lazy. It then seems to check low byte = 0 to see if a prompt should be generated then does the AND #$F and rejects the IOCB # if it's >=8.

 

Still, it's a handy fix for a feature that's missing, e.g. with most Basics you could suppress the prompt by supplying your own, e.g.

INPUT "Enter your name ",N$ : REM - user supplied prompt

INPUT "",A$ : REM - no prompt

Edited April 27, 2016 by Rybags

[+MrFish]

​One method to avoid this would be a custom Input routine using the "K:" device (which would require a lot of programming with the only benefit of being able to avoid non-text characters)

 

It's not really that much programming to set up a custom input routine. The following is less than 25 lines, and has other benefits like restricting the area of typing and insuring that some input was actually made before continuing -- in addition to accepting only alpha-numerics.

 

Edited April 28, 2016 by MrFish

[Roydea6]

PEEK764.bas

 

I use this routine sometimes when trying to reduce screen clutter. Just change the get #2,KEY to the peek 764 and code for this value..

 

 

[fujidude]

PEEK764.PNG

PEEK764.bas

 

I use this routine sometimes when trying to reduce screen clutter. Just change the get #2,KEY to the peek 764 and code for this value..

 

 

 

I like to use 764 too when looking for single keypress responses.

[Rybags]

In theory an alternate keyboard IRQ which calls the normal one then disables key presses that you don't want to allow might be the most compact method.