funny trick

[Tursi]

This doesn't seem as bad to me as Fctn = which probably has bitten every TIer multiple times!

 

I was always /really/ careful with FCTN-=, the one that bit me a couple times was that slapping the entire keyboard in frustration could occasionally register as FCTN-=, and reset. I've had Classic99 mis-scan a couple of times and read FCTN-= while typing in BASIC, too, which is why Classic99 has an option for Ctrl-Alt-= for reset instead. With a PC keyboard, the TI 'FCTN' key can be pressed in cases where you don't expect it to (for instance, question mark is shift-/ on a US keyboard but FCTN-= on a TI)

[+mizapf]

I never had a real problem with FCTN-=. I cannot remember that I ever hit it by accident. What happened to me, instead, was that after a whole afternoon of typing in a BASIC program, I typed in OLD CS1 instead of SAVE CS1. This was before I had a memory expansion, so it wiped the memory instantly, no chance for Exit. I don't remember whether I ever typed in that program a second time.

 

Michael

[unhuman]

Back in the day I cheated. Asgard sold "PreScan It!" to fix up programs automagically.

 

 

I had to take a look now, but indeed Pre-Scan control was documented, but in an addendum to the Extended Basic manual. On Whtech the manual is at ftp://ftp.whtech.org/programming/Extended%20Basic/xb.pdf ; look at PDF pages 122-125.

 

I remember it became a kind of dark skill to be able to speed up the startup of Extended Basic programs.

 

Michael

[+InsaneMultitasker]

Prescan can also fool Extended BASIC into allowing FOR/NEXT loops to be coupled with IF/THEN Statements in the same line

[kl99]

I never had a real problem with FCTN-=. I cannot remember that I ever hit it by accident. What happened to me, instead, was that after a whole afternoon of typing in a BASIC program, I typed in OLD CS1 instead of SAVE CS1. This was before I had a memory expansion, so it wiped the memory instantly, no chance for Exit. I don't remember whether I ever typed in that program a second time.

 

Michael

 

I think there was an undocumented exit opportunity by typing "E" (or was it "X")?

 

Edit:

It's SHIFT+E!

(Micropendium 1985 March, User Notes)

Edited February 14, 2013 by kl99

[rocky007]

oh yeah, i hate so much this QUIT function ! it killed me so many hours of works.

Hopefully with Extended Basic, a CALL LOAD(-31806,16) desactive it

[Retrospect]

I think there was an undocumented exit opportunity by typing "E" (or was it "X")?

 

Edit:

It's SHIFT+E!

(Micropendium 1985 March, User Notes)

 

Yeah it does. Just tried it on Classic99. That's something they should have documented. What WAS it with Texas Instruments not documenting the usefull stuff?

[+mizapf]

You can also press normal E, will bring you to "PRESS CASSETTE STOP", then you get an I/O ERROR 56. And the program is gone unless you have a 32K memory expansion.

 

However, in TI BASIC, the program is still there. So again, an issue in Extended Basic without 32K?

 

BTW, with 32K, you get a nonsense error 03 here, so that's another issue. But I remember the I/O error codes got somewhat mixed up in Extended Basic.

 

Michael

[rocky007]

another funny bug from this magazine ( ordinateur indivuel n° 53 )

 

Type in TI BASIC :

 

 

100 CALL KEY(1,K,S)

110 IF S=0 THEN 100

120 PRINT K

130 IF K=0 THEN 160

140 PRINT K ; " NOT EQUAL TO 0 "

150 GOTO 100

160 PRINT K ; " EQUAL TO 0 "

170 GOTO 100

 

Why typing the key "X", you'll get " 0 NOT EQUAL TO 0 " ?

[senior_falcon]

This is an odd one! If you enter 115 K=K*2/2 then K becomes zero and the program works as expected. BUT.. If you make 120 PRINT 1/K the computer locks up instead of issuing a "number too large". Very strange..... But it does make me feel better about the bugs in my own programs!

[Willsy]

Yeah that defies logic as far as I can see. Could it be something to do with RADIX100 representation and rounding to integers?

[RXB]

another funny bug from this magazine ( ordinateur indivuel n° 53 )

 

Type in TI BASIC :

 

 

100 CALL KEY(1,K,S)

110 IF S=0 THEN 100

120 PRINT K

130 IF K=0 THEN 160

140 PRINT K ; " NOT EQUAL TO 0 "

150 GOTO 100

160 PRINT K ; " EQUAL TO 0 "

170 GOTO 100

 

Why typing the key "X", you'll get " 0 NOT EQUAL TO 0 " ?

 

I do not get the problem as when in Keyscan 1 the X=0 is exactly what the XB manual page 201 says it is correct?

You get the same thing in Keyscan 2 for M=0 as that is the same key in split keyboard mode.

[senior_falcon]

The problem is in BASIC. It works properly in XB

[+mizapf]

Also funny: add a line

 

135 PRINT K*1

 

and you see that the IF line acts correctly. The value returned by CALL KEY seems to be an invalid radix 100 number.

 

Michael

[+mizapf]

Seems to be. I just had a look at the CALL KEY routine in GROM@>3708. Here's a part of the disassembled GPL (from my TIImageTool, next release ):

 

3724: DST >4001,@>834a prepare the radix 100 number

3728: CEQ >ff,@>8375 -1 means no new key

372b: BS GROM@>3742

372d: CHE >64,@>8375

3730: BR GROM@>373d

3732: INC @>834a

3734: SUB >64,@>8375

3737: ST @>8375,@>834c

373a: B GROM@>3740

373d: ST @>8375,@>834b

3740: BR GROM@>3744

3742: DNEG @>834a negate 4001 yields -1 (indicates no new key)

3744: XML >15

3746: BR GROM@>3620

 

This works as long as the value is not 0. The 0 is represented as 00 00 xx xx xx xx xx xx (see Editor/Assembler, page 279). But this routine returns >4000 for 0. The problem is that the floating point routines in the Monitor ROM check for the first word being 0000 on multiply, and very likely also when comparing. Funny thing is that adding a value turns the invalid number to a valid number, while multiplying fails.

 

Michael

Edited February 14, 2013 by mizapf

[Tursi]

Yeah, this '0' error was actually documented in Errata that I had in one of my manuals, and as Mizapf found, it's tied directly to CALL KEY.

 

IIRC, RADIX allows you to have both a positive 0 and a negative 0. Without looking it up and verifying the numbers that Mizapf found, that's what I had always understood the issue to be.

Edited February 14, 2013 by Tursi

[RXB]

The problem is in BASIC. It works properly in XB

 

CALL KEY(1,k,s) or CALL KEY(2,k,s) according to the Basic and XB manual both say split keyboard scan should be X=0 and M=0

 

As the value of X is supposed to be zero for the X key in Split keyboard scan I do not get the problem?

 

 

CALL KEY:

3708 : CALL GROM@>3767 Fetch first value

370B : DST @>8310,>0005 Limit 5

370F : CALL GROM@>3785 CFI for keyboard mode

3712 : CALL GROM@>5770 Fetch numerical variable and scan keyboard

3715 : BS GROM@>3722 New key, then jump

3717 : CEQ @>8375,>FF No key

371A : BR GROM@>3720

371C : DCLR @>834A Status=0

371E : BR GROM@>3722

3720 : DNEG @>834A Status=-1

3722 : XML >15 Transfer status to variable

3724 : DST @>834A,>4001 Repair the 1

3728 : CEQ @>8375,>FF No key?

372B : BS GROM@>3742

372D : CHE @>8375,>64 Key value greater 100?

3730 : BR GROM@>373D No, go on

3732 : INC @>834A Exponent plus 1

3734 : SUB @>8375,>64 Minus 100

3737 : ST @>834C,@>8375 Key value one digit back

373A : B GROM@>3740

373D : ST @>834B,@>8375 Key value in number

3740 : BR GROM@>3744

3742 : DNEG @>834A -1

3744 : XML >15 Transfer key to variable

3746 : BR GROM@>3620 End

 

This is the Basic GPL routine. The only difference between Basic and XB is the Basic version does alot more needless crap.

 

As for a zero having a Floating point value flag of positive or negative then that would be a problem..

Edited February 15, 2013 by RXB

[Omega-TI]

This little trick could be exploited like as a SHORT CUT in programs for NanoPEB users. It would save a few keystrokes if one wanted to change volumes. If it was a menu selection, VOILA, one button and you are there...

 

I'm wondering now if it's possible to write a simple assembly language program to do the same thing? Say this program is on virtual disk, a guy could access it from the BOOT MENU with one key press and instantly be in TI BASIC to do the volume switches.

[RXB]

Using my CRU IO command the TI can see 4 keys pressed at the same time so yea it should be easy to do.

Just scan for the 4 keys and then check IO bits against that to ensure you have the correct keys being pressed.

 

Here is a old RXB version 1005 program that does it:

 

100 DISPLAY AT(1,1)ERASE ALL:"THIS PROGRAM CHECKS FOR UNUSUAL KEYS BEING PRESSED, EVEN IF MORE THAN FOUR KEYS ARE BEING PRESSED AT ONCE"

110 CALL IO(2,16,3,A,B) :: IF A=18 AND B=255 THEN 110 ELSE CALL HPUT(24,3,RPT$(" ",30),24,24,STR$(A)&" "&STR$(B))

120 IF A=146 THEN CALL HPUT(24,3,"FUNCTION KEY")ELSE IF B=191 THEN CALL HPUT(24,3,"CONTROL KEY")ELSE IF B=223 THEN CALL HPUT(24,3,"SHIFT KEY")

130 IF B=251 THEN CALL HPUT(24,3,"ENTER KEY")ELSE IF B=253 THEN CALL HPUT(24,3,"SPACE BAR")ELSE IF B=254 THEN CALL HPUT(24,3,"PLUS/EQUAL KEY")

140 GOTO 110

 

Does not work very well in Classic99 but works great on a real TI.

[Willsy]

Major thumbs up to Rich for the explanation!

 

:thumbsup: :thumbsup: :thumbsup: :thumbsup: