What were T.I thinking?

[am1933]

How difficul would it have been for the good people at TI to have included some decent draw,plot & circle functions in TI Basic-or at the very least in Extended Basic?, I understand there have been some updates with relevant commands but even in 1981/82 some manufacturers were already putting these commands into their own respective versions of Basic.

I would also have imagined that on a 16K machine a circle command would have been less memory intensive than going down the SIN/COS route.

[+OLD CS1]

Probably not difficult, but as I understand T.I. was adamant about sticking to the ANSI BASIC standard. Which no other system did.

[RXB]

TI was also PASCAL based in that they even went out of the way to make a PASCAL card for the TI.

 

The problem is all the games and thinking was text based so graphics were not in mind when the TI was first created.

 

This is why it only had 16K VDP memory and they did not spend much time thinking ahead.

 

The game plan long term was to make the 99/8 and on wards....

[am1933]

TI was also PASCAL based in that they even went out of the way to make a PASCAL card for the TI.

 

The problem is all the games and thinking was text based so graphics were not in mind when the TI was first created.

 

This is why it only had 16K VDP memory and they did not spend much time thinking ahead.

 

The game plan long term was to make the 99/8 and on wards....

Am I not right in thinking that even the 99/8 did not have a simple circle command?, I am pretty sure it had Fill,Draw and Drawto which I supose was a step in the right direction(even if the machine never made it to market).

[Willsy]

I think it's all down to the dumb-as-fuck architecture. The VDP chip *had* to have its own memory, so giving the cpu its own, additional memory would have been too expensive. So they took the crack-smoking decision to run the basic code from vdp memory, leaving no space for high resolution graphics. Therefore they simply ignored the feature.

 

So we end up with a basic interpreter that runs from GROM (not cpu memory) and basic code that runs from VDP with the 16-bit cpu thrashing away accessing it all one 8-bit byte at a time.

 

Even now I just sit and shake my head when I think about it!

[senior_falcon]

Something I have always wondered about is this: would it have been possible to design a computer that used the 9900 and 9918A combination having 64K of RAM on a 16 bit data bus and with the 9900 able to access the full 64K and the 9918A able to access the first 16K. Put another way, does the VDP ram have to be memory mapped or could the 9900 have direct access to it?

[Willsy]

I think the vdp can only access 16k Max. Nevertheless I take your point. I think it would be possible. You could do one of two things I think:

 

Have the VDP and the CPU on opposite phases of the clock.

 

Or place the cpu on hold state when the vdp needs the address and data buses.

 

Both would be difficult though. With the first, you'd have to find an optimum clock speed for both the vdp and cpu to sensibly use. The cpu needs a four-phase clock.

 

With the latter it might be difficult to avoid contention.

 

I think the best design would have been something like 48k RAM, 16k ROM and 16k VDP ram. I think this is what the MSX machines had or something like it.

[sometimes99er]

Hindsight is a wonderful thing. A series of fortunate and unfortunate events. To compare (with other computers) I think you have to also look at the timeline. Here's what I see ...

 

I think it's well documented that the 99 was designed around an 8-bit CPU, but then had to shoehorn the 9900 into the design. And I think other chips like the Z80 was considered.

 

Guess there's always some religious guys involved in a process. And that includes every single one of us. So someone thought ANSI Basic was the way to go. This is prior to June 1979. GPL and GROM are perhaps visionary (think Java), nice, proprietary, faster development, but also turns out to be slow and not cheap.

 

They got this wonderful 9918 chip, but remember it has not got bitmap yet. It takes another 2 years for us to get the 9918A in the shape of the updated 99 (the 4A). That's June 1981.

 

Sprites are not even available in TI Basic, and TI Extended Basic is only released in prototypes by January 1981, but only released later that summer. June 1981 saw TI announce delays in the release of XB.

 

So bitmap might have been an option for XB, and someone probably mentioned it (draw, plot and circles). Turning on bitmap takes pretty much all of the available VDP memory, and that leaves no memory for XB (in the bare configuration). I guess priority was to introduce sprites and make believe it was a step up.

 

Looking at the 9918, it had potential in June 1979 to do arcade quality stuff. Along with the 9919 (sound). Only years later TI cloned Space Invaders (a bit of double standard here), which would obviously showcase and sell the computer - big time. I was one !

 

With extended color graphics and bitmap available with the 9918A and the chip being pushed out the door, someone knew it could sell outside, maybe even suggesting their own Z80 prototype, most notable Coleco and MSX took notice. I hope TI made money selling this chip. Guess it may not have compensated for the 99/4A department ending up losing money.

 

So ColecoVision is released in August 1982. Its a cartridge based game machine. No CPU wait states. 4 times more CPU RAM. More than 2 million sold before spring of 1984, then sells modestly until discontinued in 1985.

 

MSX is announced June 1983 by Microsoft. No CPU wait states. At least 64 times more CPU RAM. Built in Basic, Plot, Draw etc. More popular outside the states, and sold 5 million in Japan alone. During the eighties Europe became the largest computer games (as opposed to console games) market in the world, and the extremely popular Commodore 64 and Sinclair ZX Spectrum computers dominated. By the time the MSX was launched in Europe, several more popular 8-bit home computers had arrived.

 

The TI was discontinued in March 1984. 2.8 million sold and most of them after 1981.

 

Atari computers only started to ship with Basic built in with the XL series announced in summer 1983. Atari Basic did not provide direct support for Player/Missile graphics beyond the capability of Peek and Poke. It did support graphics using the statements Color, SetColor, Clear, Plot, DrawTo, Locate and Graphics. Atari 8-bit sold 2 million.

[+OLD CS1]

Something I have always wondered about is this: would it have been possible to design a computer that used the 9900 and 9918A combination having 64K of RAM on a 16 bit data bus and with the 9900 able to access the full 64K and the 9918A able to access the first 16K. Put another way, does the VDP ram have to be memory mapped or could the 9900 have direct access to it?

 

I cannot see why not. It would be easy enough to use some address manipulation to not only have the VDP access the first 16k of RAM but *any* 16k block of RAM, map it in and out as needed and arbitrate between the CPU and the VDP. Essentially that is what other systems with shared memory do (Commodore 64's 6510 and VIC-6567, for instance,) with the exception that the video chip in most other systems expects to share memory. The biggest problem we might have would be contention between accessing memory space, but that can be dealt with.Now,

 

Now, in terms of price, it would have added some extra logic if not a new controller chip, so the price for manufacture would have gone up in a time when TI was in no shape to compete in the price arena.

[+mizapf]

The VDP memory is DRAM (organized as 8 chips of 16 K x 1), and the video processor provides a built-in memory controller that cares for the RAM refresh cycles. Beside that, the VDP is a true co-processor with an own clock and autonomous operation. So if TI really wanted to share the CPU RAM with the VDP, they would have had to synchronize memory accesses in a multi-processor environment (CPU/VDP), even worse, with quite different clocks. Just consider the times when the VDP builds the screen and therefore needs exclusive access to the memory - do you really want to idle the CPU until the VDP is done?

[Stuart]

Something I have always wondered about is this: would it have been possible to design a computer that used the 9900 and 9918A combination having 64K of RAM on a 16 bit data bus and with the 9900 able to access the full 64K and the 9918A able to access the first 16K. Put another way, does the VDP ram have to be memory mapped or could the 9900 have direct access to it?

Tricky I think without lots of interface logic. Remember that the 9918A is designed to use DRAM which has a multiplexed high bits/low bits address bus. You've then got to interface that to the 9900 which has a 'straight' address bus. The connections expected on the memory chips are completely different. The 9918A also has to spend time refreshing the DRAM; which would lock out access by the 9900 - not sure how much of an impact that would have though.

[+hloberg]

Atari's Antic shared the memory with the CPU which made for a lot of wait states. In fact, there was a trick where you would turn Antic off (and get a black screen) which would get you about a 20% increase in CPU speed. So, if the 9900 had shared the memory with the VDP I doubt it wouldn't helped much more than the way TI elected to access the VDP.

[+OLD CS1]

Atari's Antic shared the memory with the CPU which made for a lot of wait states. In fact, there was a trick where you would turn Antic off (and get a black screen) which would get you about a 20% increase in CPU speed. So, if the 9900 had shared the memory with the VDP I doubt it wouldn't helped much more than the way TI elected to access the VDP.

 

The VDP and 9900 RAM busses being so different could be a huge stumbling block, anyway. Obviously there cannot be a way to turn off the VDP's access to RAM without turning off the display, but I would suspect (without having crunched the numbers -- here comes an assumption!) that it would be much faster to move data into shared RAM than pump data through the VDP registers. But then, knowing that we apparently cannot over-run the VDP, maybe not. Is there anything in particular which prevents the 9900 from pumping data to the VDP faster than it can handle when the Z80 apparently can?

 

This is an interesting thought, though. The TI's method of handling video memory was a bit obtuse for me having come from the Apple which used CPU RAM as video RAM, and then systems afterward like the VIC-20 (personal chronology) and the Commodore 64 and 128. Now, the Amiga was a different story, and the idea of Chip RAM there seemed to reach back into the past and do it correctly. Of course, now all video cards have independent RAM but with a "window" of space to pass data back and forth.

[Tursi]

One reason that the 9918(A) was a popular VDP was the build-in DRAM controller made it reasonably cheap at the time to add 16k to a system - the refresh logic was a substantial cost back then, and SRAM was far more than DRAM. So there are a number of ways they could have shared the RAM, but the separate busses was seen as a good thing, so you'd be hard pressed to convince the designers.

 

Dual-port RAM would have worked, but pricey. It would have been possible to build interface circuitry to share SRAM, too. Some of the systems out there interleaved video and CPU cycles for zero wait-state access to memory. But the cost savings would have been eaten up. (They likely were by the 9900 and necessary glue logic anyway ).

 

But after working on other systems, I also felt that the separate busses was a painful limitation and would have preferred a unified architecture. Today, with intelligent and powerful VDPs, the separate architecture makes a little more sense.

[Tursi]

 

The VDP and 9900 RAM busses being so different could be a huge stumbling block, anyway. Obviously there cannot be a way to turn off the VDP's access to RAM without turning off the display, but I would suspect (without having crunched the numbers -- here comes an assumption!) that it would be much faster to move data into shared RAM than pump data through the VDP registers. But then, knowing that we apparently cannot over-run the VDP, maybe not. Is there anything in particular which prevents the 9900 from pumping data to the VDP faster than it can handle when the Z80 apparently can?

 

It's mostly the multiplexer circuit to blame - it imposes a 4 cycle wait state on every access, even though the VDP is actually attached to the 16-bit side of the system. Because the 9900 does a read-before-write, every write triggers the wait state generator twice.

[+OLD CS1]

 

It's mostly the multiplexer circuit to blame - it imposes a 4 cycle wait state on every access, even though the VDP is actually attached to the 16-bit side of the system. Because the 9900 does a read-before-write, every write triggers the wait state generator twice.

 

Puta madre...

[JamesD]

Something I have always wondered about is this: would it have been possible to design a computer that used the 9900 and 9918A combination having 64K of RAM on a 16 bit data bus and with the 9900 able to access the full 64K and the 9918A able to access the first 16K. Put another way, does the VDP ram have to be memory mapped or could the 9900 have direct access to it?

Actually, it is possible and there are a couple approaches to implementing it that I can think off the top of my head.

Both methods would require page switching to switch out 16 bit CPU RAM and to enable access to the 16K of 8 bit video RAM.

The VDP could be rigged to access 16 bit RAM but accessing 8 bit RAM would function similar to the current 99/4A setup.

 

Giving the CPU access to VDP RAM could be done in two ways.

 

The fist would be to use dual port RAM for video memory. The CPU and VDP can access RAM simultaneously and at independent clock speeds. I'm not sure dual port RAM existed when the TI was for sale so it's definitely a new implementation.

 

The second approach would work the same as how the VZ200 and several other systems worked. Either the CPU receives wait states when it and the VDP try to access video RAM at the same time or you get sparkles on the display while the CPU accesses video RAM because the VDP receives the wrong data. The CPU buss is isolated from the video RAM unless the CPU tries to access it and the CPU clock has to match the frequency of the video RAM clock. You could look up the VZ200 schematics to see how this is done though it doesn't use wait states which I think most people prefer over sparkles.

[+hloberg]

Well, the way TI handled video RAM, for me, is 6 of 1 or 1/2 dozen of the other. There was advantages and dis-advantages like on the other machines. The Atari used shared memory but that meant that it stole CPU to draw it's screen and in the highest resolution 1/2 the usable memory would be used for display. TI separating the memory avoided these problems but introduced having to push all video changes through a slow 8 bit register.

Getting back to the original question why TI didn't have of some drawing primitives such as circle and box; my biggest complaint was the way TI used the VDP for BASICs tables thus eating into the memory so much that the high-res mode couldn't be used. When TI invented EX-BASIC they should have moved the tables to 8k low memory. It would have eaten into any assembly programs but all the VDP would been usable for high-res.

It really annoyed me that some of the more power features of the VDP weren't even accessible through EX-BASIC.

[+Lee Stewart]

Well, the way TI handled video RAM, for me, is 6 of 1 or 1/2 dozen of the other. There was advantages and dis-advantages like on the other machines. The Atari used shared memory but that meant that it stole CPU to draw it's screen and in the highest resolution 1/2 the usable memory would be used for display. TI separating the memory avoided these problems but introduced having to push all video changes through a slow 8 bit register.

Getting back to the original question why TI didn't have of some drawing primitives such as circle and box; my biggest complaint was the way TI used the VDP for BASICs tables thus eating into the memory so much that the high-res mode couldn't be used. When TI invented EX-BASIC they should have moved the tables to 8k low memory. It would have eaten into any assembly programs but all the VDP would been usable for high-res.

It really annoyed me that some of the more power features of the VDP weren't even accessible through EX-BASIC.

 

When TI released TI Forth in December, 1983, that language did, in fact, provide for use of all that bitmap power—no circle, box or fill-ins, but it did do dots and lines. Of course, that meant learning a new language, which I devoured at the time. Since then, I have learned a lot more in the process of converting TI Forth to my fbForth (file-based TI Forth). fbForth is available in the Development Resources thread as well as in this thread: fbForth—TI Forth with File-based Block I/O. I just posted the manual in that thread here: fbForth 1.0: A File-Based Implementation of TI Forth.

 

I will soon embark upon my next project for fbForth: Hoisting fbForth into cartridge space. This will save on memory and, perhaps, put much of the optional dictionary, which includes the bitmap graphics stuff I mentioned above, into cartridge ROM.

 

One of the things I'm seriously considering is adding some of what you mentioned, i.e., circle, box and fill. I'm really not sure how to handle those yet because, as you probably know, using bitmap graphics with more than a single set of foreground and background colors can be very messy with the color granularity (horizontal dots X vertical dots) as 8 X 1 on a screen of 256 X 192 dots! I suppose I could just ignore it as TI did. When I get to that point, I will definitely need all the advice I can get.

 

...lee

[senior_falcon]

Getting back to the original question why TI didn't have of some drawing primitives such as circle and box; my biggest complaint was the way TI used the VDP for BASICs tables thus eating into the memory so much that the high-res mode couldn't be used. When TI invented EX-BASIC they should have moved the tables to 8k low memory. It would have eaten into any assembly programs but all the VDP would been usable for high-res.

Extended BASIC was compatible with the TI-99/4 which had no bitmapped graphics. Also, although the 4a offered bitmapped graphics, XB was designed to work with an unexpanded console which would not have enough memory for that. I suppose tables could have been put into low memory freeing up space in VDP ram, but then there's another level of complexity. For that matter, for the cost of a little VDP memory they could have given full access to the graphics mode with 256 characters instead of 112 and all 32 sprites with unique pattern definitions.

[Omega-TI]

This is how TI Effed Up the 99/4A

[+hloberg]

Extended BASIC was compatible with the TI-99/4 which had no bitmapped graphics. Also, although the 4a offered bitmapped graphics, XB was designed to work with an unexpanded console which would not have enough memory for that.

True, I hadn't thought of that.

Hind sight and all that I guess what they should have done was when XB detected more memory and a 4a then moved the tables and offered more graphic capabilities. Of course that would have added more complexity and cost. Still, it been nice.

[RXB]

Really the biggest problem was the high cost of RAM and any memory chips.

Thus pushed all computer designs including TI to make a machine on the market that appeared better then others.

Actual performance did not matter as appearance was more important.

 

 

You can blame this clown for most of the bad ideas that killed the TI99/4A

 

http://www.ti.com/corp/docs/company/history/shepherd.shtml

[RobertLM78]

I thought this was a good place to throw this in . I found a TI-99/4A timeline that appears to have been up on 99er.net at one point. I know there's one still up on 99er.net, but this new one looks quite different. Anyway, I thought it might be cool to share (thank Duck-duck-go for the find ).

 

(Note that you have to scroll about a third of the way down the page to get to the TI-99/4A history section).

[matthew180]

How difficul would it have been for the good people at TI to have included some decent draw,plot & circle functions in TI Basic-or at the very least in Extended Basic? ...

Expertly answered in post #5. :-) Basically TI decided that CPU RAM was too expensive at the time (although other systems had some) to include in the console, so the only RAM was VRAM and the BASIC interpreter used it for everything. Thus you can't enabled GM2, move tables around, etc. without blowing your program away or breaking something in BASIC.

 

Something I have always wondered about is this: would it have been possible to design a computer that used the 9900 and 9918A combination having 64K of RAM on a 16 bit data bus and with the 9900 able to access the full 64K and the 9918A able to access the first 16K. Put another way, does the VDP ram have to be memory mapped or could the 9900 have direct access to it?

This can be done, and a lot of coin-op games of the same era did exactly this. One example is the Williams board responsible for games such as Joust, Robotron 2084, Stargate, and Defender memory mapped the video RAM into the CPU address space and is a very elegant design.

 

The first requirement for this to work is memory that is at least twice as fast as any subsystem accessing the RAM. I don't know if dual-port memory existed back then, but if it did it was certainly too expensive for anything practical so it is not considered here. TI's DRAM chips were actually fast enough to meet this requirement in the case of the 6809 used on the Williams board. The 4116 has a read/write cycle of 375ns. The 1MHz 6809 has a 1us period, half of which is used to access memory, i.e. 500ns. Thus, the other half of the clock is used by the video subsystem and neither interferes with the other.

 

The 9900 has a 3MHz clock with a 333ns period, however a *memory* read or write cycle takes almost two full *clock* cycles, or approx 582.75ns, which is easily within the range of the DRAM. The 9918A has a memory cycle time of about 372ns which is using the DRAM pretty much full time. You would actually need 150ns DRAM to be fast enough to multiplex both the CPU and VDP.

 

Second requirement would be a shared clock. The 9918A puts out a "CPUCLK" signal, but it might not be in phase with its internal state machine. However, a system clock could be derived that generates the 10.738MHz required by the VDP and further divides that for the CPU clock. This allows the design to ensure that the CPU is accessing memory on the opposite clock phase from the VDP and enables both CPU and VDP full-speed access to the VRAM without interfering with one another.

 

The nice thing about using 1-bit DRAMs is that the memory can also be configured for different word sizes, i.e. 8-bit for the VDP and 16-bit for the 9900 CPU. The RAM subsystem on the Williams board has an 8-bit bus for the CPU, a 4-bit bus for the blitter circuit, and a 24-bit bus for the video subsystem. So even though the 9900 would need 16-bits and the VDP 8-bits, it is possible to satisfy both requirements using the same memory.

 

If all of that became too complicated, then at the very least 16K of RAM could be paged between the CPU and VDP. The paging could be controlled by the CPU and would probably be best if done in 4K or 8K chunks so you could leave part of VRAM intact (name tables and such) while you paged out other parts (pattern definitions maybe). In this case you would need a refresh circuit out of phase with the CPU access for RAM not paged into the VDP's address space.

 

Finally you could also use fast (70ns - 120ns) SRAM to simplify the design, but this would have been too expensive of an option when the 99/4A was in production.

 

With modern tech, FPGAs, bigger faster RAM, etc. such a system would be much easier and very possible. It might have also been possible back in the day, but there were better ways.