mystified about Input command

[Ranger03]

On your average Apple II or C64, Input allows you to enable player input. Here, there is no such thing.

 

2 problems:

 

1. How the hell do you make a game with no input statement? and

2. what the **** was TI thinking?

[jrhodes]

Instead of INPUT, try CALL KEY(0,K,S) where K is the variable of what ascii key value was pushed and S is the state; 0=no key being pressed at time of scan, 1=new key pressed, -1=same key pressed.

To detect joystick input, use CALL JOYST(1,X,Y) or CALL JOYST(2,X,Y) to read the X and Y position joystick's 1 or 2.

INPUT is designed for interactive user input, for example at a menu where they push 1 for easy or 2 for hard, or say in text adventure, to get the next string of text to interpret from the player.

If using Extended Basic, a better way to get input from the user is ACCEPT AT, which you read about in the attached XBref.pdf

basicref_ti99.pdf

XBref.pdf

Edited July 8, 2018 by jrhodes

[marc.hull]

On your average Apple II or C64, Input allows you to enable player input. Here, there is no such thing.

 

2 problems:

 

1. How the hell do you make a game with no input statement? and

2. what the **** was TI thinking?

BASIC has an input statement. It may be different from what your used to. It's called INPUT in TI BASIC as apposed to other languages that use the term INPUT, INPUT or more rarely INPUT. Are you sure you didn't mean INKEY ??

[+OLD CS1]

I always lamented the lack of a GET or INKEY command on the TI.

[marc.hull]

I always lamented the lack of a GET or INKEY command on the TI.

CALL KEY is INKEY more or less. Maybe better/maybe worse. IIRC get is a record command ?

[+OLD CS1]

CALL KEY is INKEY more or less. Maybe better/maybe worse. IIRC get is a record command ?

 

The syntax is:

 

10 GET A$

 

or

 

10 A$=INKEY$

 

IIRC, GET is a "blocking" command (in some dialects) which will wait for a key press while in others it and INKEY$ just return a null string if no key is pressed.

 

To me the benefit of both is the immediate conversion to a character versus CALL KEY's ASCII value. I was exposed to them before CALL KEY and I was just used to using them but adapt and survive, we do.

 

Oh, I believe there is a GET# command for file operations, but I never used such a construct so I have no knowledge of its operation. (EDIT: I lied, seriously lied, I actually used GET# quite a lot for character-by-character in file handling. DUH!)

[RXB]

 

The syntax is:

 

10 GET A$

 

or

 

10 A$=INKEY$

 

IIRC, GET is a "blocking" command (in some dialects) which will wait for a key press while in others it and INKEY$ just return a null string if no key is pressed.

 

To me the benefit of both is the immediate conversion to a character versus CALL KEY's ASCII value. I was exposed to them before CALL KEY and I was just used to using them but adapt and survive, we do.

 

Oh, I believe there is a GET# command for file operations, but I never used such a construct so I have no knowledge of its operation. (EDIT: I lied, seriously lied, I actually used GET# quite a lot for character-by-character in file handling. DUH!)

Hmm how do you get only things like CALL KEY(3,K,S) and how do you get status?

Also XB has CALL KEY(1,K,S) or CALL KEY(2,K,S) for split keyboard scans.

And isn't CALL KEY(4,K,S) for Pascal?

 

RXB has things that kick the crap out of GET A$ or A$=INKEY$ as

CALL KEY("",0,K,S) ! does nothing till you press any key

CALL KEY("YNyn",0,K,S) ! will only respond to the keys listed in the string and ignores all others.

CALL ONKEY("YyNn",0,K,S) GOTO 210,210,280,280 ! similar to normal keyscan but if keys in string are used it uses the GOTO lines per the letter pressed.

[+OLD CS1]

Hmm how do you get only things like CALL KEY(3,K,S) and how do you get status?

Also XB has CALL KEY(1,K,S) or CALL KEY(2,K,S) for split keyboard scans.

And isn't CALL KEY(4,K,S) for Pascal?

 

RXB has things that kick the crap out of GET A$ or A$=INKEY$ as

CALL KEY("",0,K,S) ! does nothing till you press any key

CALL KEY("YNyn",0,K,S) ! will only respond to the keys listed in the string and ignores all others.

CALL ONKEY("YyNn",0,K,S) GOTO 210,210,280,280 ! similar to normal keyscan but if keys in string are used it uses the GOTO lines per the letter pressed.

 

No preference for GET or INKEY$ over CALL KEY, just always wanted an easier way to do

 

CALL KEY(0,K,S)

A$=CHR$(K)

 

Nothing more, nothing less. I like how RXB extends the key detection paradigm in a way I would have liked all those years ago. Now it is more of a looking-back nostalgia for me as I clean up the last of my work in BASIC and commit myself to assembly.

[Ranger03]

inkeys was always difficult for me to implement. Thus my abuse of the Input a$ command

[Casey]

TI BASIC has INPUT. The only difference between it and most other BASICs is the use of the : to separate a prompt from the variable rather than a ; or ,.

 

So you can either do:

10 PRINT “PLEASE ENTER SOMETHING”

20 INPUT A$

 

Or:

 

10 INPUT “PLEASE ENTER SOMETHING: “:A$

 

The various Extended BASICs also have LINPUT (for Line Input) which will allow any typeable character to be placed in the variable.

[Ranger03]

so no need to DIM?

[Opry99er]

Only if you're setting up an array.

[Retrospect]

10 N=0

20 CALL KEY(0,K,S)

30 N=N+1

40 IF S=0 THEN 20

50 PRINT N

 

The above program waits for user to press any key, whilst it increments N by 1 each time it scans.

 

10 N=0

20 CALL KEY(1,K,S)

30 N=N+1

40 IF S=0 THEN 20

50 IF K=18 THEN 60 ELSE 20

60 PRINT N

70 CALL SOUND(256,110,30,110,30,650,30,-7,0)

 

This program waits for user to press FIRE on wired remote controller, incrementing N each time it scans, and when it shows value N it makes a fire sound.

 

As you see CALL KEY is the key to player input in games.

[+OLD CS1]

As you see CALL KEY is the key to player input in games.

 

Indeed. I have a standard user input routine I use in my games now which makes use of both the split-keyboard scans for the directional keys and fire button and unit 3 for function keys. Handy.

[Retrospect]

 

Indeed. I have a standard user input routine I use in my games now which makes use of both the split-keyboard scans for the directional keys and fire button and unit 3 for function keys. Handy.

Can you show me an example of Unit 3 for function keys? This would be good for some of my projects.

[+OLD CS1]

Can you show me an example of Unit 3 for function keys? This would be good for some of my projects.

 

This is the Tidbit source of my user input routine. You can extend K$(1) for whatever keys you want to detect in unit 3, just bear in mind over-laps with units 1 and 2 will be detected first, so it is really only useful for FCTN or CTRL keys.

 

 

 

 

K$(0)=CHR$(2)&CHR$(3)&CHR$(0)&CHR$(5)&CHR$(18)   // Left, Right, Down, Up, Fire
K$(1)=" "&CHR$(1)&CHR$(6)&CHR$(15)               // SPACE, AID, REDO, BACK

//
// USER INPUT
//
// P = Player number (used as split keyboard scan mode select)
//
// Needs: K$(0) - Comparison string for split key scan (units 1 and 2)
//        K$(1) - Comparison string for standard key scan (unit 3)
//
// Uses: J, X, Y, K, S
//
// Returns: J = 0     - No key press or joystick
//              [1-4] - Left, Right, Down, Up
//              5     - Fire/SPACE (Select)
//              [6-8] - AID, REDO, BACK
//
UserInput:
J=0 ::
IF P<0 THEN JoyStick
CALL KEY(P,K,S) ::
IF S THEN UnitKeyPress ELSE JoyStick
UnitKeyPress:
J=POS(K$(0),CHR$(K),1) ::
IF J=0 THEN KeyScan ELSE
RETURN
JoyStick:
CALL JOYST(ABS(P),X,Y) ::
IF X+Y THEN JoyPress
KeyScan:
CALL KEY(3,K,S) ::
IF S THEN KeyPress ELSE RETURN
KeyPress:
J=4+POS(K$(1),CHR$(K),1)
DecodeJoySt:
J=J*-(J>4) ::
RETURN
JoyPress:
IF SGN(X) AND SGN(Y)THEN DecodeJoySt
J=ABS(((SGN(X)+3)/2)*SGN(X))+(ABS(((SGN(Y)+3)/2)*SGN(Y))-2*(Y<>0)) ::
RETURN

 

 

[Retrospect]

Thanks Old CS1

 

I never knew the CHR$ or the Unit combination. I'm gonna put that to use .

[+FarmerPotato]

For INKEY$ and the like on other platforms, here is an article by our friend Regena in late 1987.

 

https://www.atarimagazines.com/compute/issue89/The_Beginners_Page.php

 

I'd like to think she wrote out the appropriate CALL KEY code for TI-99/4A, but that the Compute editor removed it.

 

For those who weren't around then: C. Regena was a legendary magazine author, whose mystique was built up by the editor of 99er magazine with tales of how her prolific manuscripts arrived mysteriously signed only "Regena", while actually she was a well known writer for other computer magazines.

 

[+OLD CS1]

For those who weren't around then: C. Regena was a legendary magazine author, whose mystique was built up by the editor of 99er magazine with tales of how her prolific manuscripts arrived mysteriously signed only "Regena", while actually she was a well known writer for other computer magazines.

 

 

I found a C. Regena book in my elementary school library, something about beginning with computers, that helped usher me into where I am today.

[+OLD CS1]

Thanks Old CS1

 

I never knew the CHR$ or the Unit combination. I'm gonna put that to use .

 

Welcome. I forgot to note in the comments that entering the routine with P negative only performs joystick and function key scan. Conceivably, this could be used to do a full keyboard scan and not worry about the over-lap with the split keyboard movement keys functionality. But it also skips the fire button. For some games I removed the negative check which cleared up an ABS() in the CALL JOYST() and the initial IF/THEN.

[GDMike]

Im working on a command word in Turboforth called "LINPUT" so far but I'm still working on it, it uses the stacked values LENGTH POS COLOR

It's use is as follows in graphic mode 1

8 32 ." Date:" RED Linput

It places the string date: at the first column 2nd row then allows you to place 8 characters that are red, opposed to the black on cyan Date: word, in the location after the date: colon with a flashing black cursor and one beep sound with editing options to move back and forth on the line. Any other ideas anyone?

Edited April 25, 2019 by GDMike

[+Lee Stewart]

Im working on a command word in Turboforth called "LINPUT" so far but I'm still working on it, it uses the stacked values LENGTH POS COLOR

It's use is as follows in graphic mode 1

8 32 ." Date:" RED Linput

It places the string date: at the first column 2nd row then allows you to place 8 characters that are red, opposed to the black on cyan Date: word, in the location after the date: colon with a flashing black cursor and one beep sound with editing options to move back and forth on the line. Any other ideas anyone?

 

Might need to see that code to fathom what you are really doing...

 

...lee

[+TheBF]

Im working on a command word in Turboforth called "LINPUT" so far but I'm still working on it, it uses the stacked values LENGTH POS COLOR

It's use is as follows in graphic mode 1

8 32 ." Date:" RED Linput

It places the string date: at the first column 2nd row then allows you to place 8 characters that are red, opposed to the black on cyan Date: word, in the location after the date: colon with a flashing black cursor and one beep sound with editing options to move back and forth on the line. Any other ideas anyone?

 

Here is something to think about as you work.

 

In conventional languages where it's more complicated to pass information to a routine we tend group functionality together into a bigger sub-program because its easier to do it that way.

 

Forth lets us de-construct things as simple routines that can be re-connected together like LEGO.

 

So your LINPUT command is doing a lot of things that are neat.

Consider making a separate command for each of those things. This way each little thing will be re-useable for other programs.

 

- Make a cursor positioning word.

- Make a text color changing word

- Make a string input word

- Make a word to convert a string to a number

 

Glue those together to make LINPUT and as a bonus get a bunch of very useful routines too.

 

(I am betting Willsy has words that do a lot of that stuff somewhere in the system or on a disk block)

 

As an example, I built a "TI-99 work alike" INPUT command for CAMEL99 Forth to assist BASIC programmers, but notice there is one for numbers and one for strings.

And the #INPUT uses the $INPUT routine. And the $INPUT uses the $ACCEPT routine and $ACCEPT uses the Standard Forth ACCEPT routine.

 

That's the Forth way of "factoring" your program into small pieces and re-combining them as needed later AND you can use the pieces at anytime for other stuff.

 

My 2 cents.

 

NOTE: I just noticed #INPUT could be simplified with:

PAD DUP $ACCEPT ?NUMBER 0= 

From CAMEL99 Lib:

\ INPUT.FTH   creates input like TI BASIC
\ *Difference* there is a separate input for numbers and strings

DECIMAL
: $ACCEPT ( $addr -- ) CR ." ?  "  DUP  1+ 80 ACCEPT  SWAP C!  ;

: $INPUT  ( $addr -- ) BEEP $ACCEPT ;  \ BEEP like TI-BASIC

: #INPUT  ( variable -- )   \ made to look/work like TI-BASIC
          BEEP
          BEGIN
            PAD $ACCEPT      \ $ACCEPT text into temp buffer PAD
            PAD ?NUMBER 0=   \ convert the number in PAD
          WHILE              \ while the conversion is bad we do this
             CR HONK ." input error "
             CR DROP
          REPEAT
          SWAP ! ;           \ store the number in the variable on the stack)


\ Usage:

\ VARIABLE A$ 100 ALLOT      \ string variables need more space
\ VARIABLE X
\
\ A$ $INPUT

\ X  #INPUT

[GDMike]

Exactly. I did make, or am making because I've recoded three times, but they are all broken into smaller routines. I'll place the code once it's constructed again lol.. sorry I posted prematurely, but I wanted to get an idea if my layout before writing it up again..your code is super if I had an 80 column screen in mind. I'm coding on real hardware, I didn't mention, but in graphic mode 1, for reason I failed to mention again, graphical due to the nature of setting different characters with color attributes only available in that mode, as I'll be creating the background input box a different color background with foreground a different color from the text prompt colors.. with using another character set. confused..I'll try to post as soon as it's available maybe a week well dang I got to feed kids, take care of the house, let the dog out..blah blah..lol but I got it the forth in my head oh and did you remember testing on real hardware? Those were the days. I do some on classic99 but only in emergency!!

Edited April 25, 2019 by GDMike

[+TheBF]

Replace the number 80 with the screen width variable , whatever it is called in TF, and $ACCEPT will work for whatever VDP mode you are in.

 

But feed the kids first?