Most programs that used graphics on the TI 99/4A created them in a character-based mode, somewhat like the text mode graphics that DOS programs would use for years to come (for that matter, there are still DOS-mode programs in the latest versions of Windows that use such graphics).

The biggest difference from other text modes is that characters on the TI were redefinable; you could tell the TI to use any 8x8 two-color bitmap as any character, then print that character on screen anywhere you needed your newly redefined character to appear. There were actually two sets of redefinable characters -- the first 32 characters of high ASCII stayed defined until you rebooted, while the 96 characters of regular ASCII, 32 to 127, could be redefined within a program but reverted to normal any time you returned to the BASIC interpreter prompt.

From BASIC, the call to redefine a character encoded the bitmap as a string of 16 hex digits, which represented the raw data, left to right and top to bottom, probably exactly as it was stored internally. I still have tons of those little graphics lying around as hex strings, though I haven't used a TI in over 10 years.

There was an expansion unit which, among other things, upgraded the display resolution and made character set be 16x16 bitmaps. I never had one, but sometimes in some of the computing magazines of the day, you'd see program listings that used 64-character hex strings to define those characters.

And with TI-99/4A Extended Basic, you got the ability to define 16x16 pixel sprites (in much the same way, by passing big hex strings to some function) The cool thing about sprites on the 99/4A was (unlike sprites on the Atari 400 and Atari 800, or the Commodore 64, contemporaries of the 99/4A) that once set in motion, the hardware would keep the sprites moving all by themselves, even if your program halted. This was the same graphics hardware as that found in the ColecoVision, and I think also, the Coleco Adam. The bad part about this is that collision detection was, pretty awful in Extended Basic, and if more than 4 sprites lined up on the screen horizontally, you'd get some glitches since the sprite hardware couldn't keep up with the video signal generator. You could also do cool animations by redefining on the fly the graphics characters that defined the sprites, so that, for example, asteroids could rotate (remember Parsec? ) as they moved across the screen. The sound chip was pretty cool for it's time too, as I recall, multiple voices. TI also really locked the hardware away from the user though, giving you a peek() command, but no poke(). What a tease.

Another consequence of this weird character graphics thing...There was no way to address a single pixel on the screen. So for example, the TI Logo language was adversely affected by this character graphics design. Logo is most famous for having turtle graphics in which you direct a "turtle" to move around by various commands telling it 'forward so many steps", "right so many degress", "pen up", "pen down" etc., Well, TI Logo implemented this functionality by redefining the set of 256 8x8 characters as the turtle moved around drawing, so that meant that if your turtle drew something that couldn't be fit somehow within 256 8x8 character cells (which were not arranged in a predetermined configuration, thankfully) you'd get the lame message "out of ink". Getting "out of ink" was really not a very difficult thing to do.

Ahh, the TI99/4A, my first computer. The joys of audio cassette storage and those damned plug in cartridges forever causing random resets. Well, at most you'd lose 16k of data.

Actually, it was possible to put the graphics processor into a true bitmap mode, however it wasn't done frequently, and it wasn't supported by BASIC because it was not possible to display characters (at least using the hardware) in that mode.

Log in or register to write something here or to contact authors.