Roger Merchberger wrote: ... I never used a 99/4 of any flavor, but I recall hearing a very different explanation why the stock BASIC was so slow. The graphics chip had nothing to do with it; as far as I know there is no way to run code on the graphics chip (it is a simple raster+sprite engine). No, the real reason was that the BASIC was a two-level interpreter. TI didn't have the time/resources to write a BASIC interpreter in native assembly, so they procured a BASIC interpreter written in an abstract machine code, kinda like p-code, such that TI would then just have to write an assembly level program to interpret the "p-code". I'm sure they made other enhancements to this BASIC interpreter in order to support the unique features of the hardware, though. This approach wasn't all that uncommon. The IBM 5100 did something like that (although the "p-code" was the instruction set from a real IBM machine). The early Dr. Dobbs were full of homebrew BASIC interpreters, and many took this two-level interpreter approach, motivated more to save space than anything else. Finally, the "SWEET16" interpreter Woz wrote into the original Apple II ROMs was intended for this type of speed/space trade off.

I've never used a TI99/4A either, I do have one somewhere, but I've never done anything with it. I assume the grahpics chip is a TMS9918 or similar. In which case you can hang RAM off that, it doesn't appear in the main CPU memory map, but is accessed thorugh some registes in said chip. I'd heard that on an unexpanded 99/4A _all_ the RAM was on the video chip, your BASIC program was stored in said RAM, and the interpretter (in ROM, in the CPU address space) had to read your program via the video chip registers. This (a) made the machine very slow and (b) made it impossble to program in machine code. -tony

On 1 Oct 2007 at 20:23, Alexandre Souza wrote: Believe it. The standard unexpanded TI 99/4A had 256 bytes of SRAM local to the CPU: http://www.nouspikel.com/ti99/titechpages.htm Cheers, Chuck

On 2 Oct 2007 at 19:05, Tony Duell wrote: Yup, 32 bytes/16 words at a toss. And the usual subroutine linkage used a BLWP (Branch and Link Workspace Pointer or "Bullwhip") which set a completely new register frame for each subroutine. So that didn't make for a lot of spare processor-local RAM. Using 256 bytes of RAM at the late date of the 99/4A was screwy implmentation if there ever was one, though I suppose that some can think of some kind of advantage to this. Cheers, Chuck

On 2 Oct 2007 at 15:33, Brent Hilpert wrote: Agreed. But 128 words still doesn't leave much room for variables beyond those that can be stored in the registers of each frame. There's a comment on one of the 99/4A sites that 1,024 bytes of RAM were originally planned, which is more reasonable. I doubt that TI saved very much by using the 256 byte part. Cheers, Chuck

Brent Hilpert wrote: Well the hand writing was on the wall after 1975 since in hindsight we know that 16 bit computers with 32kw is just too small for any programs after about 1975. Look how hard it was to cram advent on a 32K pdp8. Ben.

On 1 Oct 2007 at 16:11, Roy J. Tellason wrote: I don't know--for its time (1976), a 16-bit CPU with hardware multiply and divide isn't too shabby. A bit slow because its 16-word register file (relocatable) was kept in main memory (operations referencing a register were directed to the appropriate location by a pointer registrer called the Workspace Pointer). Not exciting, true, but there were certainly more boring MPUs out there at the time. TI did make an I2L version of the TMS9900, but the most I was able to get from the local TI sales rep was a bunch of datasheets--and no samples. I gathered that the I2L version was reserved for the defense industry. Cheers, Chuck

On Monday 01 October 2007 15:19, Mark Meiss wrote: Does there exist an emulator that can make use of the disk images? It strikes me that you're probably not going to find a COBOL compiler or heavy-duty productivity software in the collection, but the games might be interesting to some. Cheers, Chuck

On 01/10/2007, Roy J. Tellason <rtellason at verizon.net> wrote: They were odd little machines. I used several; my school equipped its computer lab with them. Each with its own cassette recorded and black & white TV. (!) The BASIC was dog-slow and integer only, IIRC. There was a better BASIC as a cartridge, but it cost too much. They were pretty much the first ever 16-bit home micro, but it was a crippled 16-bit chip - as detailed in another message in this thread. They did have good keyboards, were solidly built and I believe the graphics chip was, for its time, decent and capable. However, they were obliterated in the UK market (and I suspect worldwide) by the cheaper, faster, more capable and more flexible Sinclair and Commodore machines. Even the less successful 8-bit machines like the Dragon 32/64, Oric-1/Atmos & Amstrad CPC464/664/6128 sold masses more. The TI99s were relegated to the ranks of the obscure, along with the Camputers Lynx, Memotech 512, Elan/Flan Enterprise, Tatung Einstein and so on. Even the MSX did better and /nobody/ over here bought /those/. I suspect that made them /very/ cheap by the end of their life, and that's why my school bought 20 or so of them. -- Liam Proven ? Profile: http://www.linkedin.com/in/liamproven Email: lproven at cix.co.uk ? GMail/GoogleTalk/Orkut: lproven at gmail.com Tel: +44 20-8685-0498 ? Cell: +44 7939-087884 ? Fax: + 44 870-9151419 AOL/AIM/iChat: liamproven at aol.com ? MSN/Messenger: lproven at hotmail.com Yahoo: liamproven at yahoo.co.uk ? Skype: liamproven ? ICQ: 73187508

On Mon, 1 Oct 2007, Chuck Guzis wrote: Since the 990/4 Mini was based on a TMS9900, Probably not much. Dont know if its enough to run DX10 though. Peter Wallace

Chuck Guzis wrote: I can't state so categorically but my understanding is that they were very much the same. Going back to a conversation of a few weeks ago, when we were developing/running Verex/Thoth at UBC ca 1980 it was on a 990/10. The next major step in the project was to develop a distributed kernel for multiple processors. To this end, 3 bare single board computers based on the 9900 chip were ordered and received from TI. Something makes me think they were called "990/5"s. I remember making up a front panel for the 3 of them with reset buttons and a few status LEDs to go in the rack with the /10. The idea, of course, was to use the 9900s because we already had the compilers,etc. generating code for the 990/10. (Cheriton left before we actually got into using them at the software level and the distributed kernel would become the VKernel at Stanford on other hardware). Also, the description of the 9900 in Osborne's "An Introduction to Microcomputers, Vol II" ('76) fits well with my recollections of the 990/10. To my knowledge the 9900 chip was not crippled; rather (going from what others have described) the design and implementation of the 99/4 home computer failed to make effective use of it. I didn't follow micros too much in the early 80s but I remember wondering at the time why the 99/4 was doing so poorly when it had that great processor in it. I quite liked the 990 architecture with the workspace pointer. Yes, there was the overhead of accessing registers in memory, but there were also savings. The workspace pointer essentially became the stack/frame pointer. Procedure calls, interrupts and process switches were quick because there were only 3 machine registers to save (PC,WSP,PSW). Stack variables and parameters were referenced in instructions as registers, thus saving on instruction length/memory accesses to retrieve addresses/offsets, etc. For use with "modern software design", i.e.: stack-oriented high-level languages, I thought it was a quite effective architecture.