** MALFUNCTION MALFUNCTION **

[HOME AUTOMATION]

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.

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 timex1000
or maybe something interacting from modem control codes?

[simbalion]

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.

[HOME AUTOMATION]

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

[HOME AUTOMATION]

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!

[+Lee Stewart]

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

[HOME AUTOMATION]

 

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.

[+Lee Stewart]

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

[HOME AUTOMATION]

 

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

[+FarmerPotato]

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.

[HOME AUTOMATION]

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?

[Casey]

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.

[+FarmerPotato]

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

[HOME AUTOMATION]

Here is a video of the "token" anomaly on an emu.

 

No a bug, but not quite right. TI-99/4A

 

Thanks recent uploader!

[+mizapf]

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.)

[HOME AUTOMATION]

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.

[+FarmerPotato]

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?

[+mizapf]

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

[+FarmerPotato]

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.

Edited May 23, 2018 by FarmerPotato

[+mizapf]

Yes, confirmed with MAME.

[HOME AUTOMATION]

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!

[HOME AUTOMATION]

I hope this isn't to far off forum...

 

I really love this one, too!

[jrhodes]

Does that work on the ti version of pacman?

Edited May 24, 2018 by jrhodes

[HOME AUTOMATION]

Does that work on the ti version of pacman?

Afraid not!

[BuckoBrand]

Strange... I will have to look into that, Alex.

[HOME AUTOMATION]

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