14

The Video Display Processor (VDP) of the TI-99/4A was capable of displaying 32 hardware sprites. These sprites were unusable with the default, built-in BASIC that TI provided. However, an enhanced BASIC (Extended BASIC) was available that provided much needed support for the TI's hardware. Including sprites.

But for some reason, you could only work with 28 sprites instead of the maximum of 32.

So, what was the reason behind this? Was this another ploy by Texas Instruments to cripple what home users could do in an attempt at selling more "TI Branded" software?

2 Answers 2

17

The VDP area for the Sprite Attributes Table is 0x0300 to 0x037f. That is 128 bytes, which is 4 bytes per sprite. Each sprite entry in this table has the sprite's X/Y position, color, index to the character graphic to use, etc.

TI Extended Basic uses VDP 0x0370 to 0x03F0 for XB system use. That overlaps and cuts off the last 16 bytes of the Sprite Attribute Table, thus reducing by 4 the number of sprites that can be used.

Memory is so scarce on the TI that for a higher-level interpreter like BASIC to function, it has to sacrifice some hardware memory areas (like part of the sprite table) for use by the interpreter itself. This was certainly not done to cripple the hardware or similar. When you have a program running inside a program on such limited piece of hardware, that inner program of course cannot make full use of all aspects of the system as the outer program cannot use zero resources.

Also, fun fact, it is theoretically possible to use 3 (actually 4 I believe) sprites with regular TI BASIC, as there are three sprites worth of the Sprite Attribute Table unused, but you have to have the ability to POKE to that memory address, which BASIC did not allow. The sprites also would not be able to move via hardware, as that requires the sprites to be defined starting at 0x0300, but that is not the unused area of the VDP in regular BASIC.

This page shows the memory mappings of TI BASIC, EXTENDED BASIC, and general assembler (IE actual hardware). https://www.unige.ch/medecine/nouspikel/ti99/vdpram.htm

3
  • 1
    The Mini-memory module comes with POKEV and PEEKV subroutines callable from TI-BASIC. This would allow to enale your 3 sprites. Apr 4 at 8:59
  • 1
    Cool! The only thing is that in order for sprites to be moved by the hardware (which is one of the main points of using them) the first sprite must be at the 0x0300 address. With this trick you could use sprites starting at 0x0370. Still would be useful for some things (most important is that you can break out of the 32x24 grid and place a few bitmaps arbitrarily).
    – Dan
    Apr 7 at 1:17
  • 2
    IOW, never ascribe to malice what could adequately be explained by tight hardware limitations.
    – RonJohn
    Apr 7 at 2:40
3

But for some reason, you could only work with 28 sprites instead of the maximum of 32. So, what was the reason behind this?

One reason may have been space.

Of the 16 KiB RAM, build-in TI-BASIC uses 2 KiB for screen handling (including 80 bytes line buffer) (*1), leaving a bit less than 12 KiB for programm and data.

For Extended BASIC it is essential to be able to support programs of similar size as with TI-BASIC - this includes the ability to load (old) TI-BASIC programs. Thus memory requirement should at best not exceed what has been set by TI-BASIC. At the same time it needs memory to hold additional data like:

  • Sprite attributes table
  • Sprite motion table |
  • Some system data area
  • An extended crunch buffer
  • And a new edit buffer for the improved editor

All of this would have end up at ~500 Bytes less memory available. By reducing the the character table (*2) as well as the sprite tables this was reduced to ~300 bytes. In addition some data areas (like line symbol table) wouldd be moved into RAM expansion if present.

So while it seams little, it's safe to assume that they tried hard to reduce the memory footprint.

Was this another ploy by Texas Instruments to cripple what home users could do in an attempt at selling more "TI Branded" software?

Another ploy? Like a secret conspiration? Serious, why on earth should TI do so?


*1 - Plus another ~2KiB for file buffers when a disk unit is installed (more with number of files set above 3)

*2 - Extended BASIC reduced the available glyphs by 16 to 30..143.

7
  • 2
    "Why on earth should TI do so?" I don't think it happened in this instance. But companies have built systems intentionally using underpowered specs and limited expandibility, not just to save on costs but to establish "product differentiation" and limit the expected lifetime of the product. Similar things happen on the software front. I'm not passing judgement on the ethics of such practices, just stating that it does happen. The business side of consumer electronics often leads to decisions that make no sense to end users.
    – RichF
    Jan 12, 2019 at 1:34
  • 1
    Agree that sometimes there's deliberate underperformance of lower-priced products - but for that to apply here, there surely would have needed to be a higher-priced version that allowed 32 sprites. Was there? Jan 12, 2019 at 1:42
  • 1
    Beside, who would pay more for a meager 4 sprites more ... when 28 ist already way past what any other system offered.
    – Raffzahn
    Jan 12, 2019 at 10:18
  • 2
    @user253751 According to Dan's answer, memory constraints meant they needed to use some of the sprite RAM for other things and they did their best to use as little as possible. 28 was the number that emerged when they finished optimizing the code.
    – ssokolow
    Apr 4 at 3:15
  • 1
    13928 bytes free in Extended Basic. I will never forget that number after suffering so much to make magazine games written for 16K machines work on the TI-99/4A. Apr 4 at 9:02

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .