Questions about TMS9985 & TMS9995

[Ursus]

Hello ?,

it's not an essential question, but I'm trying to understand the history of the TI-99 and the relationship between the individual processors better.
In the years 1976 to 1981 various processors of the 9900 family came out. I have tried to compare some data here. If I have made mistakes, please tell me. ?

 

• TMS 9900: TI-990/4 minicomputer, TI-99/4 (A) and SGCPU
• TMS 9980A / TMS 9981: TM-990/189 SBC
• TMS 9940 (1979):?
• TMS 9985 (never released): originally planned for Dimension 1&4
• TMS 9995: Tomy Tutor, TI-99/2 & TI-99/8, Geneve
• TMS 9500: TI-99/4B, TI-99/5
• TMS 99105: SGCPU (only planned)
• TMS 99110:?
• TMS 99120 (never released)

 

TMS 9985:
The following drawing can be found on page 52 of the TI-99_4 New Technician Guide (Reduced pp 001-080).pdf:

This drawing clearly shows that the TMS9900 was not the planned processor. Thanks Toucan & CB Wilson that I can see the original drawing.

https://atariage.com/forums/applications/core/interface/file/attachment.php?id=695856

 

If I have understood correctly, the 9980 series is the “stripped down” 9900 series - 16 bit processor with 8 bit data (9980) instead of 16 bit data (9900) (similar to Intel 8086 and 8088 ???) ??
The 9940 is a variant with internal RAM / ROM. The 9985 should become a (2x?) faster 9980A based on the 9940 with internal RAM / ROM? ?
Am I correct with the assumption that the internal 256 bytes were the CPU RAM that was mounted on the mainboard of the TMS 9900 external? 

 

Why wasn't the TMS 9980A used instead of the TMS 9985 with an external RAM & ROM, like the TMS 9900?
This already existed. The topic has already been addressed "briefly" in the following thread #99:

Is there any new information?

 

TMS 9995:

I read somewhere that the GPL should integrated in the hardware of the 9985. It was not successful, which is why the TI Basic had to be interpreted twice with the 9900.
The TMS 9995 came out in 1982 with the Tomy Tutor and was also intended for the TI-99/2 and TI-99/8. Fabrice has one of the two working TI-99/5 and it had a TMS 9500 (9995 without internal RAM). There was probably only a handful of the TMS 9500 (I think it was built into the TI-99/4B).
Was it possible with the TMS 9995 to solve the problems with the GPL?

 

Thank you and best regards
Michael ?

[+mizapf]

The TMS9980A is also limited in its address space, having only a 14-bit address bus (16K). It has only 8 interrupt levels (compared to the 16 of the 9900), and 11 CRU bits (for CRU addresses 0000-0FFE).

 

The TMS9980A has an internal data bus multiplexer (16->8) which is implemented by circuits on the main board of the TI-99/4A. Note that the byte order of the 9980A and the 9995 is high/low, while the data bus multiplexer of the TI-99/4A has the order low/high.

 

The 9980A uses the same microprograms as the 9900 and does not provide any pipelining features, as does the 9995. Even worse, the 9980A performs read-before-write even though it would not be required to do it due to its 8-bit bus. The 9995 seems to be true redesign of the microarchitecture, as it does not use read-before-write and thus provided a significant performance boost, together with its command pipelining.

 

I'm somewhat confused about this "interpreted twice" of TI BASIC that I already saw before. This is not the best description of the process. GPL provides a kind of virtual machine, one could say, and TI BASIC runs on this machine. The BASIC program is certainly interpreted by BASIC, so the BASIC program is not interpreted twice in this sense.

 

The TMS9995 has no particular connection with GPL; the adapted microarchitecture and the four additional instructions do not contribute anything with respect to GPL.

[Ursus]

@mizapf thanks ?

49 minutes ago, mizapf said:

The TMS9980A is also limited in its address space, having only a 14-bit address bus (16K). It has only 8 interrupt levels (compared to the 16 of the 9900), and 11 CRU bits (for CRU addresses 0000-0FFE).

This means that the TMS9985 would have solved the problem with the 14-bit address bus, since it has the same number of address lines as the TMS9990, but the TMS9985 would have had fewer interrupts than the TMS9990. I only have a single drawing with the TMS9985 and then there also seem to be less INT when I see it correctly.

 

I understand correctly that the 9980A could have used 11 CRU-bits with the addresses 0000-0FFE and could only address the internal components (keyboard, cassettes, ...). The external peripheral devices (PEB, Hexbus, ...) not? Would the 9985 have been able to do this or was no periphery planned at all at the time of dimension 1 & 4? ?

The 9995 seems to be the best 16/8 bit variant of the series in all points, fulfills the points of the 9900 and more.

56 minutes ago, mizapf said:

I'm somewhat confused about this "interpreted twice" of TI BASIC that I already saw before. This is not the best description of the process. GPL provides a kind of virtual machine, one could say, and TI BASIC runs on this machine. The BASIC program is certainly interpreted by BASIC, so the BASIC program is not interpreted twice in this sense.

I'm just new and possible that I got it wrong. I perceived that the TI Basic interpreter was written with GPL and the GPL interpreter with assembler.

[+mizapf]

On the bottomline, the interrupt levels were not so relevant, since TI hardwired the interrupt code lines to 0001 on the TI-99/4A main board, i.e. every interrupt on the TI apart from RESET and LOAD has level 1.

 

As for the double interpretation, this is a statement that has been repeatedly given in history, so it is certainly not your fault, but as I said, it may be a bit misleading. If you study GPL more closely you see that the whole GPL environment looks somewhat like an emulated machine with a very powerful and versatile instruction set.

[senior_falcon]

I think it depends on what your definition of "interpreted" is. Every instruction performed by the TI99 must ultimately run in 9900 assembly code. GPL adds another layer between BASIC/XB and the 9900. Whether you call it an "interpreter" or an "emulator" to me is a matter of semantics. The fact remains that if the BASIC/XB interpreter was written in assembly without that extra layer of GPL code, they would run something like 3x faster and there would be a lot fewer complaints about how slow they are.

[apersson850]

The TMS 9900 was also used in the TI 990/5 version. By Texas Intruments, that is. There were of course external users of these processors in other products.

 

The TMS 9900 was running at 3 MHz in the 99/4A. It's a bit misleading to distinguishing the clock frequency of the 9995 as 12/3 MHz, since it give the impression that it operates at the same speed internally as the 9900. It doesn't, it's 2-3 times faster. If you only look at the crystal, connected to the TIM 9904 clock generator for the TMS 9900, that was a 48 MHz one.

Edited May 17, 2021 by apersson850

[+mizapf]

@apersson850Right, as we discussed in the other thread. I think it only makes sense to compare the CPUs by their internal cycle time, and those cycle times are equal for the 9900 and 9995 (333ns), but the 9995 is much faster because it needs fewer cycles for the same operations.

 

@senior_falconAlso right, but as I said, it may be somewhat misleading to say that TI BASIC programs are double-interpreted. This sounds like some freak idea having to interpret a language twice, while in reality, the machine where the TI BASIC interpreter runs is an emulation that is interpreted.

[apersson850]

Still, one interpretation of another interpretation makes two of them...

[RXB]

17 hours ago, senior_falcon said:

I think it depends on what your definition of "interpreted" is. Every instruction performed by the TI99 must ultimately run in 9900 assembly code. GPL adds another layer between BASIC/XB and the 9900. Whether you call it an "interpreter" or an "emulator" to me is a matter of semantics. The fact remains that if the BASIC/XB interpreter was written in assembly without that extra layer of GPL code, they would run something like 3x faster and there would be a lot fewer complaints about how slow they are.

That would be a insane amount of Assembly and where would you put it?

I am looking at ROM >6000 to >7FFF but all kinds of issues come up as wasted memory issue in lower 4K bank has to stay there each bank.

[Stuart]

16 minutes ago, RXB said:

That would be a insane amount of Assembly and where would you put it?

Most 64K home computers of the period had BASIC written in assembly - usually around 16K - 24K. But they didn't have huge chunks of the memory map dedicated to the peripheral cards, cartridges and memory-mapped devices.

[Stuart]

4 hours ago, apersson850 said:

If you only look at the crystal, connected to the TIM 9904 clock generator for the TMS 9900, that was a 48 MHz one.

But of course changed to a 12 MHz crystal with the 9904A clock generator.

[apersson850]

Yes, you're right. I had forgotten about the difference between TIM 9904 and 9904A.

But again, it shows the futility of comparing crystal frequencies once again, as the output of the two is the same.

[RXB]

1 hour ago, Stuart said:

Most 64K home computers of the period had BASIC written in assembly - usually around 16K - 24K. But they didn't have huge chunks of the memory map dedicated to the peripheral cards, cartridges and memory-mapped devices.

Well this allowed more devices like SCSI, IDE, MFM, RS232, SAMS, PGRAM, or Triple Tech cards all to be on one computer.

Cartridge port could allow access to 640K of GROM cartridges or GRAM or multiple banks of ROM/RAM.

 

[Ursus]

5 hours ago, apersson850 said:

The TMS 9900 was also used in the TI 990/5 version. By Texas Intruments, that is. There were of course external users of these processors in other products.

At that time there was also AMI as a 9000 producer: https://www.cpu-world.com/CPUs/TMS9900/AMI-S9900P.html   

 

1 hour ago, RXB said:

That would be a insane amount of Assembly and where would you put it?

I am looking at ROM >6000 to >7FFF but all kinds of issues come up as wasted memory issue in lower 4K bank has to stay there each bank.

Please forgive me, unfortunately I am still at a very low level of understanding, but I would like to understand it ?. Is it a question of where a basic interpreter written in assembler could be?
Just for me to understand:
The console ROM is located > 0000-1FFF and is only 8K in size.
The GPL interpreter is > 0024-08FF and the basic interpreter is > 18C8-1C9A.

1 hour ago, Stuart said:

Most 64K home computers of the period had BASIC written in assembly - usually around 16K - 24K. But they didn't have huge chunks of the memory map dedicated to the peripheral cards, cartridges and memory-mapped devices.

(Basic with the C64 requires 8K ROM + part of the KERNAL ROM which I know, but was only very limited.)
 

So there is no other "internal" space in the console for the ROM. Therefore you could only connect it externally. Am I right?
Then only three memory locations remain: DSR, Cartridge and Memory Expansion.
> 6000 to> 7FFF for the cartridge, a maximum of 8K ROM is available or "banking". Did I get it right?
Wouldn't it be possible in part of the memory expansion?

[Ursus]

In which language were the XB, SXB, RXB, ... written? 

[RXB]

2 minutes ago, Ursus said:

In which language were the XB, SXB, RXB, ... written? 

All of them are GPL (Graphic Programming Language) and with out GPL the TI99/4A would not even show a Title screen.

Now XB, SXB and RXB all have 12K ROM also in Cartridge space along with the GROM.

XB has four 6K GROMs >6000 to >DFFF in hex.

SXB has four 8K GROMs >6000 to >DFFF in hex.

RXB has 5 8k GROMs >6000 to >FFFF in hex. Last GROM is REA (Rich Editor Assembler) a upgraded version of EA cart.

[Stuart]

Aren't some parts of XB written in assembly?

[+Ksarul]

26 minutes ago, Stuart said:

Aren't some parts of XB written in assembly?

That would be in the 12K of ROM @RXB mentioned but didn't identify precisely. One other note for those unfamiliar with the TI: the GROM chips are not part of the system memory map as defined by most other computers, they are in addition to the regular memory and do not overlay any of the other memory spaces.

[senior_falcon]

2 hours ago, RXB said:

That would be a insane amount of Assembly and where would you put it?

I am looking at ROM >6000 to >7FFF but all kinds of issues come up as wasted memory issue in lower 4K bank has to stay there each bank.

Without a GPL interpreter, most of the memory from >0000 to >1FFF would be available. Most of the memory from >8000 to >9FFF is wasted. We're up to 16K already. >4000 to >5FFF might be available but you'd have to be careful not to mess up peripherals. Up to almost 24K. (I think apersson has a memory expansion that provides all 64K of memory) You can bank switch all you want  at >6000 to >7FFF. You don't need to reserve the lower 4k in the bank. 128  or 512 bytes would probably be plenty. When changing banks, you just need to have an area that is the same in every bank so XB doesn't get lost.

Edited May 17, 2021 by senior_falcon

[Ursus]

21 minutes ago, Ksarul said:

That would be in the 12K of ROM @RXB mentioned but didn't identify precisely. One other note for those unfamiliar with the TI: the GROM chips are not part of the system memory map as defined by most other computers, they are in addition to the regular memory and do not overlay any of the other memory spaces.

Do I understand correctly that the 8K ROM on the cartridge (if available) is addressed via the memory map > 6000 to > 7FFF,
the GROM on a cartridge, however, via > 9800 & > 9802 and GROM 3-7> 6000 to > F7FF
(GROM 0-2> 0000 to >57FF (is onboard)).

Edited May 17, 2021 by Ursus

[RXB]

2 hours ago, Stuart said:

Aren't some parts of XB written in assembly?

Yes the 12K of ROMs in XB are in Assembly.

[RXB]

2 hours ago, senior_falcon said:

Without a GPL interpreter, most of the memory from >0000 to >1FFF would be available. Most of the memory from >8000 to >9FFF is wasted. We're up to 16K already. >4000 to >5FFF might be available but you'd have to be careful not to mess up peripherals. Up to almost 24K. (I think apersson has a memory expansion that provides all 64K of memory) You can bank switch all you want  at >6000 to >7FFF. You don't need to reserve the lower 4k in the bank. 128  or 512 bytes would probably be plenty. When changing banks, you just need to have an area that is the same in every bank so XB doesn't get lost.

True or do like me in RXB 2021 I am working on that resets it back to normal XB mode after I use banks 3 or 4 so it operates normally.

[RXB]

2 hours ago, Ursus said:

Do I understand correctly that the 8K ROM on the cartridge (if available) is addressed via the memory map > 6000 to > 7FFF,
the GROM on a cartridge, however, via > 9800 & > 9802 and GROM 3-7> 6000 to > F7FF
(GROM 0-2> 0000 to >57FF (is onboard)).

Hmmm only TI GROM carts use >6000 to >7FFF these are 6K in size , almost everyone today uses full 8K now not 6K.

I even expanded GROMs >2000 to >5FFF by putting Editor Assembler TI Basic support  into them wasting 2K of space is silly.

TI only used 6K GROMs as the chips were less expensive then 8K GROM chips and they could control what was on them.

But Miller Graphics figured that out and made the GRAMKRACKER for GROM/GRAM.

And later the Supercart came into being using banks of 8K RAM at Cartridge space.

Again why waste space when you can expand it.

[apersson850]

2 hours ago, Ursus said:

Do I understand correctly that the 8K ROM on the cartridge (if available) is addressed via the memory map > 6000 to > 7FFF,
the GROM on a cartridge, however, via > 9800 & > 9802 and GROM 3-7> 6000 to > F7FF
(GROM 0-2> 0000 to >57FF (is onboard)).

ROM on a cartridge is at >6000 - >7FFF. All "special" things are mapped to ports in the >8000 - >9FFF area. That includes console RAM, video, sound, speech and GROM access. It doesn't matter if the GROMs are in the console or in a cartridge. They have the same access port. Since you can have a maximum of 8 GROM on a single port, this means that the cartridges can't have more than 5, as the console has 3.

 

It's not only the GPL interpreter that lives in >0000 - >1FFF space. There is also floating point routines, cassette DSR, interrupt handling, startup code and some other support. It's not like 8 K is available. But more than half should be, yes.

 

Indeed I have a mechanism which allows RAM over the entire address range in my console. By default, only the normal 32 K RAM is accessible, but using CRU bits, I can enable RAM in any of the other four 8 K banks too. Or release the standard 32 K RAM, so that a normal RAM expansion in the box shows up instead. This gives me access to 64 K RAM in the console alone, and 96 K RAM if the memory expansion is present.

 

Did any 8 K GROM exist at all? Devices like the GRAM kracker and Maximem didn't use GRAM chips, but ordinary memory and just simulated GROM with some extra logic around them.

Edited May 17, 2021 by apersson850

[+Ksarul]

1 hour ago, apersson850 said:

Did any 8 K GROM exist at all? Devices like the GRAM kracker and Maximem didn't use GRAM chips, but ordinary memory and just simulated GROM with some extra logic around them.

The TI EGROM devices and the TI GRAM cards used 8K in each GROM/GRAM space, but ignored 2K of that. I would have to take another look at the specs for the Parker Brothers PCROM chips (GROM workalikes) and the Funware GROM used in St. Nick. TI apparently never made real 8K GROMs or GRAM chips of any kind.

 

One other note about GROMs, @Ursus. The TI scans >9800 and >9802 for the first GROM base. It can actually support up to 256 such spaces, although the console startup scan only checks the first 12. The UberGROM cartridge supports use of multiple GROM bases (still only the last five GROMs in each base), with slots available to support up to 15 GROM chip equivalents sliced in any way you want (15 separate GROM bases, 3 groups of 5 in 3 GROM bases, or anything in between). Each base is selected by using the REVIEW MODULE LIBRARY selection on the program selection screen. This selection only appears if multiple GROM bases are in use.