TI Casino

[+InsaneMultitasker]

a few days ago @WhataKowinkydink  mentioned that TI Casino did not work with the nanopeb.  This piqued my curiosity a bit so I poked around at the program.  At first I suspected some assembly language support routine was stomping on VDP memory.   During game play there is a way to create an account to deposit/withdraw your winnings (nifty idea) for next time.  The program was reporting a 'disk read error' most times you tried to create an account.

 

It turns out that the error trap routine was catching a problem with the ASC function, not a file IO error.   When the player creates a new account, the program asks for a password of up to 6 digits.  Unfortunately, the password encoding/decoding is hard-coded for six digits.  If you enter fewer digits, the routine generates an error (the function ASC() cannot process a null string)  which is then trapped by the file IO routine as a disk error, and the user is told there was a file error!

 

The error occurs in line 890 of the program "CASHIER".  The password is saved in a numeric array however, the values are not contiguous and I don't know the repercussions significance of allowing fewer digits.  For example, line 570 concatenates the six password digits as    H$=CHR$(E(1))&CHR$(E(6))&CHR$(E(7))&CHR$(E(8))&CHR$(E(9))&CHR$(E(10))  to validate the password when reading the account.  I don't know if this was all poor coding or an attempt to obfuscate the information to avoid 'cheating' (edit: or even related to randomness aspects within the games )

 

The simple solution is to use 6 digits.   Perhaps some enterprising individual would like to fix the programming and verify there are no other similar errors.  The disk image can be located on the TI Gameshelf along with many other gems. I found TI Casino to be a well done XB program - I even won a bit of 'money' in the process.

 

http://tigameshelf.net/xb.htm

[wierd_w]

Sounds to me that the better solution is to pad a short string (less than 6 characters needed) with some space characters at either the beginning or end.  If the player inputs a short string, inject the correct amount of padding for the function to be successful.  This means the password written and read back will have pad bytes, the function will fire properly, and the user is none-the-wiser. (It will act as if it accepted and used their short password)

 

 

It should be doable with like, 3 lines of code (if even that) with an inline IF statement.

 

 

EG,

IF LEN(INPUT$) < "6" THEN IF LEN(INPUT$) = 1 PASS$ ="     "+INPUT$ ELSE IF LEN(INPUT$)=2 THEN PASS$="    "+INPUT$ ELSE IF LEN(INPUT$)=3 THEN PASS$="   "+INPUT$ ELSE IF....

 

 

Etc.

 

 

[+InsaneMultitasker]

Agree.  I suppose I should mention that the password is not captured with standard routines. If this was a matter of an Extended Basic "accept at" routine and a string, it would make things easy.  The password and money handling routines are (intentionally?) complicated, including data entry, data storage, and file IO.  If I had time and was interested in doing so, I would replace the routines with simple code. 

[wierd_w]

It might be even EASIER to just straight up pad 6 bytes worth of spaces.  This is especially true if there is no upperbound condition for failure on string length.  It would satisfy the requirement (input string > 6 bytes), in fewer decisions.  (input less than 6? Pad 6. End of discussion. Length of 6 guaranteed)

 

 

 

[Omega-TI]

...or jump over the code, thus eliminating the error in the first place.  Who really needs a password in the game?

[+InsaneMultitasker]

4 hours ago, Omega-TI said:

...or jump over the code, thus eliminating the error in the first place.  Who really needs a password in the game?

Thinking about it a bit more, I believe that the password/account is probably more about game 'atmosphere' than a need for a password. 

 

As for the code, for all I know, the six distinct numeric elements play a part with the various games or randomization.  The documentation doesn't specify six digits (that I can see) but the program is clearly geared to six.  It's all XB code and there for anyone to dig into and modify to their heart's content.    As I said...typing six digits is to me the simple 'solution'.

 

 

[+InsaneMultitasker]

Modifying this line in the CASHIER program will inhibit the creation of a password that isn't 6 digits long, and prompts the user to re-enter the password (during creation or access) if it is not 6 digits. 

 

 

[wierd_w]

Elegant.  I like it.

Some other detail changes on the prompt string might be beneficial too, so the user knows what's up.

 

"Please enter your 6 digit PIN."

Edited October 10, 2020 by wierd_w

[+InsaneMultitasker]

34 minutes ago, wierd_w said:

Elegant.  I like it.

Some other detail changes on the prompt string might be beneficial too, so the user knows what's up.

 

"Please enter your 6 digit PIN."

Good call. I had to make some cosmetic adjustments due to how the program redefines special characters.  The error message is displayed only if the user enters <6 digits, and the message is cleared after a successful entry.  Modified program attached below the screenshot.  Lines 1040 and 1041 are the modified code.  Time for me to return to playing with Infocom interpreter code...

 

 

CASHIER  - Modified program tifiles format

 

or for those who wish to just edit their file and/or see the change: