HOME AUTOMATION Posted May 17, 2018 Share Posted May 17, 2018 Alternate titles I've considered for this topic are: Undeveloped TI BASIC feature?Tokens in TI BASIC?Sprites in TI BASIC.Fault prediction resultsFailure analysis experimentsKeyword entry featureAnyway, going way back, it seems like I became intrigued with finding oversights in games, software, hardware and systems. Such as the trick in Donkey Kong where you can trap the fires by jumping over a peg as the fire passes under you. The Pac-Man trick where you eat a blue monster as it emerges form the center box, causing it to go off the map, than eating it again traping its "spirit" in a loop. The "hiding" places where the monsters can't find you, ever. Many phone hacks, etc.My first TI 99/4a was a floor model, bought for me on X-mas eve, it was the last one, as I was told. Price $1000. The store made them sign a no-refund disclaimer, saying that it was a prototype. Though it did seem to run all software, in some ways it differed slightly. I clearly recall the title screen copyright 1979.String variables Such as: A$="full four lines of text", if concatenated as such: B$=A$&A$&A$&A$&A$&A$&A$&A$&A$&A$&A$&A$&A$&A$&A$&A$&A$&A$"typing PRINT B$&B$&B$&B$&B$&B$&B$&B$&B$&B$&B$&B$&B$&B$&B$&B$&B$&B$&B$&B$ from immediate mode(not in a program), would print out proceedurally until fully complete, possibly locking the user out for hours or even days if a third string is assigned. I could not duplicate this behavior on any other TI.O.K. now that the preamble is over!By trying many unlikely things, I discovered that typing control or undefined function keys in a REM statement from TI BASIC causes RESERVED WORDS to print out if the program line is LISTED. Some of the function keys cause strange character sequences to print, with long delays in between(FCTN V,?).Some reserved words, such as RANDOMIZE (CTRL U) are long enough that attempting to edit a full four line entry of them, results in a single program line, that is longer than the screen table, apparently causing an overwrite of VDP tables and perhaps causing BASIC to alter VDP registers as well. While entering chars on such a long line, sprites appear at times, also the screen can loose horizontal sync, probably from external video being activated (this will cause newer monitors to cut out).If Function 1 (del) is the first key edit, the entire screen scrolls left! using FUNCTION 2 (ins) and entering full lenth edits can cause basic to become crazy, returning messages such as *BAD NAME IN LINE NUMER 44736(RUN), trying to RESEQUENCE such a program causes a strange pattern lockup.Using Function 4 (CLEAR) to leave edit mode can yeild different results than ENTER.Could this be something intended to work like the keystrokes on a timex1000or maybe something interacting from modem control codes? Quote Link to comment Share on other sites More sharing options...
simbalion Posted May 17, 2018 Share Posted May 17, 2018 Hmm, interesting. Are you sure you didn't have the earlier TI-99/4? There were differences between it and the later TI-99/4a. 1 Quote Link to comment Share on other sites More sharing options...
HOME AUTOMATION Posted May 18, 2018 Author Share Posted May 18, 2018 (edited) Hmm, interesting. Are you sure you didn't have the earlier TI-99/4? There were differences between it and the later TI-99/4a. Quite sure, no equation calculator, solid cursor, full keyboard, had the annoying garbage collection rotine, the clock I.C. and VDP had heat spreaders and got quite hot, I also remember the buyer puchased a sister unit (not a floor model) which I recieved as a replacement a year or so later, it had an sn76494 sound I.C.. I blew that out, never could find another. All are long gone, sadly. By the way the REM containing control characters, works on all TI 99/4A's TI BASIC. Edited May 18, 2018 by HOME AUTOMATION Quote Link to comment Share on other sites More sharing options...
HOME AUTOMATION Posted May 18, 2018 Author Share Posted May 18, 2018 WORKING EXAMPLE: In TI BASIC type: 100 REM (space) hold CTRL key down, hold the U key down, wait until the cursor comes to a stop(4 lines), press ENTER, type EDIT 100, when display stops hold the space bar down for a while. voila! Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted May 18, 2018 Share Posted May 18, 2018 I also remember the buyer puchased a sister unit (not a floor model) which I recieved as a replacement a year or so later, it had an sn76494 sound I.C.. I blew that out, never could find another. All are long gone, sadly. Unicorn Electronics has a 76489, if that helps. ...lee 1 Quote Link to comment Share on other sites More sharing options...
HOME AUTOMATION Posted May 18, 2018 Author Share Posted May 18, 2018 Unicorn Electronics has a 76489, if that helps. ...lee Thanks, thats nice to know. I meant to say: Both computers are long gone, sadly. I was a child back then. Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted May 18, 2018 Share Posted May 18, 2018 Thanks, thats nice to know. I meant to say: Both computers are long gone, sadly. I was a child back then. A-a-h. ...lee 1 Quote Link to comment Share on other sites More sharing options...
HOME AUTOMATION Posted May 18, 2018 Author Share Posted May 18, 2018 (edited) A-a-h. ...lee Funny thing, when I read your reply the part # is coverd by a solid color. only by selecting line the can I read the #. I would go on to blow 2 more of these I.C.s out in different TI/994As and in very unique incidents (RATS!). One I replaced with a 76489. All the tones were much lower in frequency. Not good as I used lm567n PLLs to decode the TI's high frequencies to run a small matrix of relays. I learned why recently. I think I learned it here on atariage possibly from Fabrice. Excellent! Edited May 18, 2018 by HOME AUTOMATION Quote Link to comment Share on other sites More sharing options...
+FarmerPotato Posted May 18, 2018 Share Posted May 18, 2018 Funny thing, when I read your reply the part # is coverd by a solid color. only by selecting line the can I read the #. I would go on to blow 2 more of these I.C.s out in different TI/994As and in very unique incidents (RATS!). One I replaced with a 76489. All the tones were much lower in frequency. Not good as I used lm567n PLLs to decode the TI's high frequencies to run a small matrix of relays. I learned why recently. I think I learned it here on atariage possibly from Fabrice. Excellent! The older chips accepted a clock frequency of 447 KHz: TMS9919 SN94624 SN76494 These all have an internal clock divider of 2. The TI-99/4A had an external 74LS161 to divide the VDP clock 3.579 MHz by 8. For external sales (saving a part cost), TI incorporated the divider into the chip in these parts: SN76489 uses 3.579545 MHz internally dividing by 16. SN76489A SN76496 differs in that it also has an AUDIO IN If you put an SN76489A in an older console, it would technically be out of spec, but if it worked at all you would get much lower frequencies (extra divide by . I'm double checking all these details again tomorrow, as I've received a batch of SN76489A from China for FORTI card builds and I'm going to leave out the external divider. 2 Quote Link to comment Share on other sites More sharing options...
HOME AUTOMATION Posted May 18, 2018 Author Share Posted May 18, 2018 WORKING EXAMPLE: In TI BASIC type: 100 REM (space) hold CTRL key down, hold the U key down, wait until the cursor comes to a stop(4 lines), press ENTER, type EDIT 100, when display stops hold the space bar down for a while. voila! As much as I appreciate any participation in my topic. Perhaps I was vague about my main interests here. I am still hoping to elicit some interest in the TI BASIC anomaly that occurs when editing a program line longer than the screen table. Why these reserved words are associated with CTRL and FCTN characters in the first place? Why do they operate in this manor in a REMARK statement? Quote Link to comment Share on other sites More sharing options...
Casey Posted May 18, 2018 Share Posted May 18, 2018 There was a similar discussion about this in COMPUTE! magazine years ago where someone asked about this, though they were referring to Extended BASIC. In that case you don't need to use the REM in front. 10 <CTRL-V> is legal and will print: 10 NEXT Something about the ASCII values of those Ctrl key combinations must be the same as the internal tokens used by TI BASIC and Extended BASIC. Some of the tokens are valid in Extended BASIC but not TI BASIC. 10 <CTRL-B> lists as: 10 :: :: is not a valid token in TI BASIC, so it prints a bunch of weird characters, similar to if you load an Extended BASIC program into TI BASIC and try to list it. Interesting how TI BASIC catches it with an error unless you put REM in front, but Extended BASIC allows the tokens. 1 Quote Link to comment Share on other sites More sharing options...
+FarmerPotato Posted May 19, 2018 Share Posted May 19, 2018 (edited) Alternate titles I've considered for this topic are: Undeveloped TI BASIC feature? Tokens in TI BASIC? Sprites in TI BASIC. Fault prediction results Failure analysis experiments Keyword entry feature Anyway, going way back, it seems like I became intrigued with finding oversights in games, software, hardware and systems. Such as the trick in Donkey Kong where you can trap the fires by jumping over a peg as the fire passes under you. The Pac-Man trick where you eat a blue monster as it emerges form the center box, causing it to go off the map, than eating it again traping its "spirit" in a loop. The "hiding" places where the monsters can't find you, ever. Many phone hacks, etc. My first TI 99/4a was a floor model, bought for me on X-mas eve, it was the last one, as I was told. Price $1000. The store made them sign a no-refund disclaimer, saying that it was a prototype. Though it did seem to run all software, in some ways it differed slightly. I clearly recall the title screen copyright 1979. String variables Such as: A$="full four lines of text", if concatenated as such: B$=A$&A$&A$&A$&A$&A$&A$&A$&A$&A$&A$&A$&A$&A$&A$&A$&A$&A$" typing PRINT B$&B$&B$&B$&B$&B$&B$&B$&B$&B$&B$&B$&B$&B$&B$&B$&B$&B$&B$&B$ from immediate mode(not in a program), would print out proceedurally until fully complete, possibly locking the user out for hours or even days if a third string is assigned. I could not duplicate this behavior on any other TI. O.K. now that the preamble is over! By trying many unlikely things, I discovered that typing control or undefined function keys in a REM statement from TI BASIC causes RESERVED WORDS to print out if the program line is LISTED. Some of the function keys cause strange character sequences to print, with long delays in between(FCTN V,?). Some reserved words, such as RANDOMIZE (CTRL U) are long enough that attempting to edit a full four line entry of them, results in a single program line, that is longer than the screen table, apparently causing an overwrite of VDP tables and perhaps causing BASIC to alter VDP registers as well. While entering chars on such a long line, sprites appear at times, also the screen can loose horizontal sync, probably from external video being activated (this will cause newer monitors to cut out). If Function 1 (del) is the first key edit, the entire screen scrolls left! using FUNCTION 2 (ins) and entering full lenth edits can cause basic to become crazy, returning messages such as *BAD NAME IN LINE NUMER 44736(RUN), trying to RESEQUENCE such a program causes a strange pattern lockup. Here is a related anomaly in TI-99/4 BASIC 10 CALL CLEAR PRINT CHR$(7) EDIT 10 10 The bug was documented as using a "statement used as a command" then editing a line. TI inserted an ERRATA sheet into the 99/4 packing, practically daring you to try it. The effect was that the entire contents of VDP RAM was shifted down by 1 byte. I can understand this in terms of TI BASIC compacting the program in VDP RAM, moving everything up 1 byte, counting down the addresses, but the start address is corrupt and the process goes on and on. First there is a delay. Then you observe the pattern table shifting down 1 pixel row. All the visible chars drop one pixel lower, but not all at the same time. It's slow enough for you to have a thought that your program is gone and memory is being trashed. Then the screen fills with sprites and gibberish, and the really bad stuff begins. Yes, decrementing the VDP address below 0 means it is time to write random values into the VDP registers! LI R0,>FFFF SWPB R0 MOVB R0,@>8C02 SWPB R0 MOVB R0,@>8C02 DEC R0 JMP $-14 Yikes! On a TV output, this means the screen begins to "tear". There are seconds of darkness, then a flash of bright white, followed by pulses of distorted video between which fragments of your program are briefly visible. There is an audible whine from the television set as the video signal pushes it beyond its comfort envelope. In my 8 year old mind this was what FUBAR meant. However, after a time, the madness ceases. The blackness is still. There is a softly blinking spot. The cursor is back! You press enter; nothing improves. You make a syntax error, and the screen is somewhat restored. If you are lucky, there are sprites, which you can play with by typing under them. Just don't type LIST, or the horror may begin all over again. The cursed number 32767 may appear. I still feel a fricasee of dread when I cross its path. Edited May 19, 2018 by FarmerPotato 3 Quote Link to comment Share on other sites More sharing options...
HOME AUTOMATION Posted May 23, 2018 Author Share Posted May 23, 2018 Here is a video of the "token" anomaly on an emu. No a bug, but not quite right. TI-99/4A Thanks recent uploader! Quote Link to comment Share on other sites More sharing options...
+mizapf Posted May 23, 2018 Share Posted May 23, 2018 Hmm, this seemed to fail. TI-99/4, you said? Do we happen to have fixed ROMs in MAME? (This would mean that we have to redump the 99/4.) 1 Quote Link to comment Share on other sites More sharing options...
HOME AUTOMATION Posted May 23, 2018 Author Share Posted May 23, 2018 Here is a related anomaly in TI-99/4 BASIC 10 CALL CLEAR PRINT CHR$(7) EDIT 10 10 The bug was documented as using a "statement used as a command" then editing a line. TI inserted an ERRATA sheet into the 99/4 packing, practically daring you to try it. The effect was that the entire contents of VDP RAM was shifted down by 1 byte. I can understand this in terms of TI BASIC compacting the program in VDP RAM, moving everything up 1 byte, counting down the addresses, but the start address is corrupt and the process goes on and on. First there is a delay. Then you observe the pattern table shifting down 1 pixel row. All the visible chars drop one pixel lower, but not all at the same time. It's slow enough for you to have a thought that your program is gone and memory is being trashed. Then the screen fills with sprites and gibberish, and the really bad stuff begins. Yes, decrementing the VDP address below 0 means it is time to write random values into the VDP registers! I was also unable to duplicate Farmer Potato's above results, using MAME. I've never used a real ti99/4 hands on. The assembly example was educational. Quote Link to comment Share on other sites More sharing options...
+FarmerPotato Posted May 23, 2018 Share Posted May 23, 2018 You have to edit line 10 after doing a PRINT command. Change it or erase it I'll test it on hardware again I don't suppose the Ti-99/4 errata sheet is scanned somewhere? 1 Quote Link to comment Share on other sites More sharing options...
+mizapf Posted May 23, 2018 Share Posted May 23, 2018 (edited) The 99/4 ROMs for MAME do not have a CRC value at their ends, which means we cannot prove that they are genuine. Or they were issued by TI themselves as a bugfix to later consoles. Edited May 23, 2018 by mizapf 1 Quote Link to comment Share on other sites More sharing options...
+FarmerPotato Posted May 23, 2018 Share Posted May 23, 2018 (edited) Ok here is the 99/4 BASIC bug:10 CALLEDIT 1010 CALL CLEARPRINT CHR$(7)LIST1EDIT 11 REM* spectacular VDP RAM trashing* severity seems to depend on whether there was prior stuff in ram. I seem to recall the 99/4 Errata sheet describes it as: "The computer may lock up when, after editing a line, entering a Statement Used As A Command". (As we say now, Challenge accepted!) I tried this in Classic99. I did not see it drop back into a BASIC prompt in 2-3 minutes, like I recall it doing. Classic99 reports lots of illegal VDP register writes. If it scrambles VDP registers really badly, the next Cold Reset doesn't fix them, and the title screen is garbage. Edited May 23, 2018 by FarmerPotato 1 Quote Link to comment Share on other sites More sharing options...
+mizapf Posted May 23, 2018 Share Posted May 23, 2018 Yes, confirmed with MAME. 1 Quote Link to comment Share on other sites More sharing options...
HOME AUTOMATION Posted May 23, 2018 Author Share Posted May 23, 2018 Ok here is the 99/4 BASIC bug: 10 CALL EDIT 10 10 CALL CLEAR PRINT CHR$(7) LIST 1 EDIT 1 1 REM * spectacular VDP RAM trashing* severity seems to depend on whether there was prior stuff in ram. I seem to recall the 99/4 Errata sheet describes it as: "The computer may lock up when, after editing a line, entering a Statement Used As A Command". (As we say now, Challenge accepted!) I tried this in Classic99. I did not see it drop back into a BASIC prompt in 2-3 minutes, like I recall it doing. Classic99 reports lots of illegal VDP register writes. If it scrambles VDP registers really badly, the next Cold Reset doesn't fix them, and the title screen is garbage. I did get your BASIC example to work, most amusing and interesting! Thanx! Quote Link to comment Share on other sites More sharing options...
HOME AUTOMATION Posted May 23, 2018 Author Share Posted May 23, 2018 I hope this isn't to far off forum... I really love this one, too! 1 Quote Link to comment Share on other sites More sharing options...
jrhodes Posted May 24, 2018 Share Posted May 24, 2018 (edited) Does that work on the ti version of pacman? Edited May 24, 2018 by jrhodes 1 Quote Link to comment Share on other sites More sharing options...
HOME AUTOMATION Posted May 24, 2018 Author Share Posted May 24, 2018 Does that work on the ti version of pacman? Afraid not! Quote Link to comment Share on other sites More sharing options...
BuckoBrand Posted February 3, 2019 Share Posted February 3, 2019 Strange... I will have to look into that, Alex. 1 Quote Link to comment Share on other sites More sharing options...
HOME AUTOMATION Posted February 3, 2019 Author Share Posted February 3, 2019 (edited) Strange... I will have to look into that, Alex. The REM w/CTRL characters... or the Pac-Man trick? Edited February 3, 2019 by HOME AUTOMATION Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.