Early in 1984 our family bought a used Texas Instruments TI-99/4A computer. This had BASIC in ROM and it had 16kB of RAM, which I knew was enough. As opposed to the ZX-81 it had a real keyboard, colour graphics and sound. It came with three game cartridges: Munch Man, TI Invaders and Parsec and we spent many hours with these games. But for me programming was the main subject and I would soon be quite disappointed.
The TI computer had its own BASIC dialect. On the one hand it had many more features than ZX-81 BASIC, but on the other hand, it lacked some features that ZX-81 BASIC did have. And I thought: if the ZX-81 has it, every other computer must have it too. Like the ZX-81, the TI supported just one statement per line, but the IF statement could not have a statement after THEN, but just a line number (and you could specify another line number with ELSE). By the way, this is what ANSI Minimal BASIC specified and many early BASIC version on mainframes and minicomputers had it that way. One particular thing was the command to load a command from tape (or disk) was OLD instead of LOAD. Again, old BASIC versions on mainframes and minicomputers did it that way. You used the NEW command to create a new program and the OLD command to retrieve an old program. If you look at it that way, it is very logical. TI-BASIC also had the OPTION BASE statement from ANSI to specify that you wanted to start arrays at index 0 or 1. Most other BASIC versions did not implement this.
TI-BASIC supported floating point numbers to a high precision and as far as I know they were represented in decimal format. This is not the fastest way to computations. TI-BASIC was in fact slow, but it was definitely faster than the ZX-81. There was a complete set of string handling functions, but not LEFT$, MID$ and RIGHT$. Instead it had SEG$, which is equivalent to MID$.
So far the peculiarities of the BASIC dialect meant getting used to and additional learning, but they did not keep you from doing the things you wanted to do. One more serious thing that you could not do with TI-BASIC was position the cursor at any screen position and print from there. The PRINT statement always printed lines at the bottom of the screen and caused the rest to scroll upward. This is different from all other home computers I know of. Our good friend the ZX-81 had a PRINT AT command to print something at a given position on the screen. The Commodore 64 had no such command, but you could embed cursor control characters in string literals to achieve the same effect. MSX had LOCATE, the BBC Micro had two ways to do it: PRINT TAB(column,row) and VDU 31,column,row. If you wanted to write simple 2-d games, not having such a command is quite a limitation.
You could store data files on cassette tapes and there were quite a few keywords related to that. You could specify if the file was random access or sequential and if the data was formatted as text (DISPLAY) or as binary (INTERNAL). However, there was only one combination of options that worked reliably on cassettes. The other options only made sense for disk files. Writing a simple database program to store name-address records on tape (and reading them back later) was already quite a challenge. An out-of-memory error would stop the program and while you could still print variables, you would be unable to restart the program without losing the variables, hence you could not store your data on tape anymore.
The biggest problem with TI-BASIC was that it has no way to access memory directly or to run machine code. The video chip in the machine had support for a 40-column text mode and for hardware sprites, but there was absolutely no way to get to them without buying additional ROM cartridges. Basic on the Commodore-64 did not have sprite support either, but at least you could poke your way around it.
Now TI-BASIC did have some commands for graphics and sound (and also to access the keyboard and joysticks) and using these it was possible to write some nice looking games in BASIC. You just had to limit the number of moving objects to one or at most two and keep most of the screen stationary. You could not use sprites, but you could redefine the character bitmaps (the only place in Basic where you used hexadecimal notation). There were a few listings of such games in the magazines that came with the computer and I ended up porting some of them to the ZX-Spectrum later. You could even draw graphs on the screen by carefully manipulating character bitmaps (without access to bitwise AND an OR) and this was quite a challenge.
TI-Basic had the following calls for graphics and sound:
So you could not print a string at any given screen location using PRINT (which sucked), but you did have CALL HCHAR and CALL VCHAR to print characters at any given screen position. CALL HCHAR could drawn a row of many characters, but only of identical characters. If you wanted to print a string of different characters, you had do do it in a loop, like this:
110 FOR I=1 TO LEN(SR$)
120 CALL HCHAR(ROW,COL+I-1,ASC(SEG$(SR$,I,1)))
130 NEXT I
The problem with this was that it was slow. If you wanted to regularly
print a status line with number of lives and score or if you wanted to
print messages in a game, you could see the string being drawn from
left to right and this made the game quite sluggish.
Using CALL CHAR you could change the bit pattern of any character code between 32 and 159. Character codes 32..127 were for the normal ASCII set, but the lowercase characters just showed as small capitals. Your program was normally typed in all upper case. With the command CALL CHAR(96,"FF818181818181FF") you changed the shape of the lowercase A to a square. Very few BASICs had dedicated commands for this and if character bitmaps were stored in RAM, you usually had to poke them. By using character codes 96 to 159 for graphics you could still have upper case and the most important character sets in their normal way. It was possible to plot graphs on the screen, it was just painfully slow and horribly complex to do it.
The slowest call was CALL GCHAR, which could read the character code that was stored at any given position on the screen. Conceptually this was just reading a single byte from video RAM, so how hard could it be? I once wrote a program to read the entire contents of the screen into a two-dimensional array and to write everything back to the screen and this took nearly ten minutes. Why they put a delay loop in that call, I have no idea. On the ZX-Spectrum this operation took only 2 minutes (using SCREEN$ to read a character from the screen) and as it has a bitmapped screen, it had to do much more work, like matching each 8x8 pixel pattern against the character table.
The architecture of the TI-99/4A is responsible for the fact that you cannot run machine code programs on the machine if you do not have additional RAM installed. There simply is no RAM on the bus, except for 256 bytes that is needed to store the register sets.
The machine uses the TMS9900 CPU, which is a 16-bit CPU. The CPU can address 64kBytes of memory, just like most 8-bit machines. The external data bus of the CPU is 16 bits, but most of the bus in the machine is 8 bits wide, so each access will take two cycles. Only the 256-byte scratchpad RAM is truly 16 bits.
The CPU has only three programmer-visible registers: the program counter, the status register and the work space pointer (WSP). The 16 general-purpose registers of the instruction set are not real internal registers, but instead they live in RAM at the address pointed to by the WSP. That's what the 256-byte scratchpad RAM is for. By updating the WSP you can switch contexts really fast, but you could only store 8 complete register sets in the scratchpad RAM. In theory you could run very tiny programs in this RAM, but BASIC does not let you poke it anyway. Even if it would have let you do it, the BASIC interpreter more than needs this RAM for its own purposes. The instruction set is very advanced, having two-address operations and also multiply and divide.
What about the 16kB of RAM that the machine has? This is connected to the video chip, a TMS9918A (or TMS9929 for PAL versions). The CPU has just two I/O addresses to access the chip and the RAM connected to it. BASIC programs, variables and of course the contents of the screen are stored in this RAM. This is much slower to access than directly addressable RAM and you cannot execute code from it. This video chip is the same as was used on the MSX-1 computers. It has a 40-column text mode, a 32-column text mode with 32 sets of foreground and background colors (one for each set of 8 character codes). The bit patterns (8x8 pixels) of each character can be changed in software. Then there is a 256x192 pixel bitmap mode where each row of 8 pixels gets one foreground and one background color. This mode would use up most of the 16kB video RAM. Finally there is a 64x48 pixel mode in which each block gets its own color. Except for 40-column mode each mode supports up to 32 hardware sprites. In TI-Basic and also in Extended BASIC you are stuck with 32-column text mode.
Another feature of the machine is that most of the BASIC interpreter is stored in GROM chips (Graphics ROM). These GROM chips have a much lower pin count than normal ROMs and they provide sequential access. To read from any other address than the next one, you have to first send a command to the chip to set the address (similar to what must be done to access the video RAM). Also these GROM chips only occupy two addresses on the CPU bus.
Those GROM chips were patented, they were not available to other software vendors and they contained a sort of byte code called GPL (Graphics Programming Language). The computer did contain some normal ROM for BIOS routines and the GPL-interpreter. But most of the BASIC interpreter was written in an interpreted language, which made it quite slow.
The machine contained both a cartridge slot and an expansion bus.
One of the most popular non-game cartridges was Extended BASIC, but it was very expensive. This had quite a few advanced features over TI-BASIC and some features that the vast majority of BASIC versions on other machines did not have.
In principle it was possible to load and run machine programs from Extended BASIC, but only if you had the 32 kB memory expansion. TI-Basic could not use the 32kB memory expansion, but Extended BASIC allowed you to spread your program over the 16kB video RAM and the 32kB RAM expansion. The PEB, the 32kB memory expansion and Extended BASIC together would cost more than a Commodore 64 and I did not have the money to purchase them all. And if I had, I would have gone for a different machine altogether.
There were two documented ways to run your own machine code on the TI-99/4A: the Mini Memory and the Editor Assembler.
The Mini Memory was a ROM cartridge that contained (along with ROM) 4kB of battery-backed RAM. It had two unrelated purposes:
The Editor Assembler was a package containing a ROM cartridge, diskettes and lots of documentation. You needed a system with disk drives and 32 kB of RAM, so that was never an option for me. The cartridge provided the usual subprograms to BASIC (to access memory and run machine code) and it had a menu to edit source programs and assemble them to machine code. Most of those functions (editor and assembler) was on disk and not in the cartridge itself.
The video hardware was much more advanced than anything available for home computers in 1981 (when it was introduced) and certainly in 1979 when its predecessor the TI 99/4 was introduced, It had hardware sprites, 15 colors and a bitmapped mode. It was only rivaled by the VIC in the Commodore 64 that was introduced in 1983. The only thing it could not do was 80 column text (which would not be practical on a normal television anyway and neither could the C64). Because it had no mode for 80 column text, it was never a serious machine for business applications and serious word processing. This video chip was versatile enough to be selected for MSX computers in 1984. Due to MSX, successor chips were developed, like the 9938, which were compatible at the software level and had more video modes (including 80-column text) and some hobbyists upgraded their TI machines with these chips.
Its CPU was much more advanced than any 8-bit CPU, but because it stores its registers in RAM, it requires very fast static RAM to run full throttle. The TI-99/4A had only 256 bytes of this fast RAM. Other memory was connected to an 8-bit bus or worse via the video controller. Because it relied heavily on interpreted byte code stored in GROM chips, the speed advantage over 8-bit machines was nullified. Having no significant amount of RAM on the bus did not help either.
A speech synthesizer was available for it as an add-on module. This was useless with TI-BASIC, but in Extended BASIC you could make it say a limited repertoire of words. Many games supported this module as well, for example Parsec. The most useful cartridge to use with the speech synthesizer was the Terminal Emulator cartridge, which was in fact... a terminal emulator program (not very practical on a 32 or at most 40 column screen and without a serial port you could not use it at all). But oddly enough it contained a large subprogram callable from TI BASIC that let you say any words in English.
Even without the speech synthesizer, it had a three tone sound generator, which was not too bad at the time. The chips in the Commodore 64 was better, but it arrived later. The Vic-20 had a proper sound chip as well, but many other home computers had no sound or just a single tone.
The machine had a proper keyboard, but the keys were small and there were comparatively few keys (no dedicated cursor keys). It was certainly better than the keyboards on the ZX-81 or ZX-Spectrum.
The bare machine was very affordable (at least in the USA some time after its introduction, when it competed against the Vic 20), but peripherals and add-on cartridges like Extended BASIC were very expensive. You had to spend much more to purchase the required hardware to use diskettes than with most other machines, such as a Vic 20 or a Commodore 64. The TI was way more advanced than the Vic 20 in every respect (better CPU, better graphics, more RAM), but the Vic 20 let you load machine code games from cassettes, while the TI did not. TI discouraged the development of third party software and that's why it lost. TI made a loss on the machines and they hoped to get a huge profit on software cartridges and peripherals, but that did not work out for them. In Europe the machine arrived comparatively late and the introduction price was way too high, so it was never very popular there.
TI BASIC was adequate for learning to program and for writing simple programs, but unlike other microcomputer BASIC versions it did not let you explore the corners of the hardware and it did not let you run machine code. The Mini Memory was an expensive way to give you access to the hardware and machine code that you got out of the box on machines like the Vic 20 or even the ZX-81.
It you wanted to make full use of the machine, you would need several ROM cartridges, such as Extended BASIC, Editor Assembler and probably others. Only one cartridge could be in the slot at any given time, so you had to power down frequently to swap cartridges.
The TI-99/4A was very different from most other home computers. On the one hand it had very advanced hardware for its time, on the other hand it was crippled by the lack of RAM that was directly connected to the bus. That made it completely impossible to load and run machine code programs from tape on the bare machine. The only way the bare machine could run machine code programs was using ROM cartridges and TI even blocked ROM cartridges from third party vendors in its latest models. This way TI made the platform not very attractive to develop programs for.
While the bare machine was sold cheaply, the required expansion modules to make it a really useful computer (as opposed to a game console) were quite expensive. It was quite frustrating for programmers that they were locked out of many interesting features of the hardware, such as sprites, until they bought expensive additional cartridges. The BASIC interpreter was too slow for many types of games, yet it was impossible to speed up your program with a few simple machine code routines as was routinely done on other home computers.
Because the bare machine depended so much on ROM cartridges and the things that you could do with BASIC were so limited (with no escape via PEEK, POKE and machine code), the machine was more like a game console with BASIC than a real computer. This was even more so because of the lockout feature for third party cartridges in the latest models.