Internal 64 K RAM memory expansion

[apersson850]

Inspired by a post by Matthew, I decided to write this post about the internal memory I once built into my console.

Inspired by an article about somebody who installed 64 K RAM in the console, but really only used half of it as a 32 K RAM expansion, I decided to do the same modification.

But I thought it was a pity to install 64 K without being able to use all of it. After some thinking, I came up with a design which would fulfil this specification.

1. Provide an internal 32 K RAM expansion, just like a card in the expansion box, but on a 16-bit bus with no wait states. A memory access would be two clock cycles (minimum for the TMS 9900), not six.
2. Allow the 32 K RAM expansion inside the console to be disabled by software. To avoid using any memory addresses for this paging, unused CRU bits (base address >400) in the console would handle the paging. When the internal 32 K RAM was disabled, reading/writing to addresses where it resides would instead reach the PEB in the normal way. Thus a 32 K RAM expansion card in the PEB would be able to co-exist with the internal expansion, bringing the machine to 96 K RAM (CPU access) plus 16 K RAM (VDP access).
3. Splitting the 64 K RAM in 8 segments, where the four segments at the same addresses as internal ROM, DSR space, command module space and memory mapped devices space (plus internal 256 byte RAM) could be mapped in and overlay the console memory. This would allow for example copying the internal ROM to RAM, then enabling the RAM and immediately you have an internal monitor you can change as you like. For other applications, this makes it possible to have a contiguous 64 K RAM address space, if you need that for some purpose.
4. Not allow write-through to the RAM. If you are unfamiliar with the concept, it means that if you read from ROM when RAM is disabled, you read the ROM. But if you write to the ROM when RAM is disabled, you actually do write to RAM. Thus you can copy a ROM location to a RAM location by a MOV @here,@here. Very convenient, but since the 99/4A have memory mapped devices in the address space at >8000 - >9FFF, I didn't want writing to any of these devices to pass through to RAM.
5. Provide hardware to generate an extra wait-state if the program reads from the VDP. This would allow software that doesn't adhere to the rules for inserting extra instructions to delay such reads to still function as intended. You don't have to follow the rules when using the 8-bit slower memory in the PEB, but it's different when running from fast memory.
6. Make it possible to fit the whole thing by piggy-back mount on ICs already in the console. The metallic clamshell should still be possible to mount.
7. At power-on, or after a reset, the machine should start with internal RAM expansion active at >2000 - >3FFF and >A000 - >FFFF. The remaining parts of RAM should be disabled. The VDP read wait state generation is also off after a reset.

Block diagram of the expansion.

Circuit diagram of the expansion.

Photo of the install.

 

The documentation is actually not 100 % accurate any more. I realized after a while that it would be better if I could disable the 8 K RAM expansion separately from the 24 K one. There's one unused gate in U006, so I moved the CRU bit for VDP delay by one, and used two bits for the 32 K RAM section. One for >2000 - >3FFF and the other for >A000 - >FFFF. It would be possible to split the 24 K part in more segments too, but that required more ICs, so I didn't consider it worth the effort.

 

Anyway, this implies that software running with code and WS in 8 K RAM has access to two 24 K RAM segments (if you also have a memory card in the PEB). Or opposite, when code and WS is somewhere in 24 K RAM, you have access to two 8 K RAM pages in low memory expansion. Note that with an expansion like this, you don't have to worry about where you have your workspace. All memory is as fast as the standard RAM pad at >8300.

[matthew180]

Pretty cool! Thank you for the description and photos. I think you win the "most modded" contest for sure. I wonder how much faster assembly code runs on your system? Have you done any tests or benchmarks?

[Willsy]

Pretty cool! Thank you for the description and photos. I think you win the "most modded" contest for sure. I wonder how much faster assembly code runs on your system? Have you done any tests or benchmarks?

I think I read on Thierry's site just the other day that WS and code in 16 bit 0 wait state memory is ~50% faster. WS in fast ram and code in slow (8-bit) RAM is ~30%.

[apersson850]

If you have both code and workspace in 8-bit RAM, then move both to 16-bit RAM, the speed increase is around 110%.

This is quite relevant when you use the system as I frequently did, i.e. wrote assembly to support high level languages. In such cases, it's much easier to use a workspace that you define with your code, as you don't have to adapt to how the high level language you're running under is using fast RAM in the console. Extended BASIC and Pascal have their own ideas about how to handle that memory. BASIC default WS is >83E0, but the p-system uses >8380, for example. If you have the WS in your own code, you don't care, but you also get the slowest memory for everything in the normal configuration.

[+mizapf]

One particularly visible speed-up is when you run everything inside the 9995's internal RAM, i.e. code and workspace (possible on the Geneve, but not on the 99/8 where that RAM is disabled). Typically, the TMS99xx processors are criticized for using memory access to its registers, but in this case there is only a single cycle for reading or writing, which can't possibly be much faster with hardware registers. Also, the internal RAM cannot be slowed down by the READY line because this line is not checked for internal accesses.

[apersson850]

Yes, and with the TMS 9995 the internal memory is the only one that's possible to access as 16-bit wide. The external data bus is only 8-bits wide.

Are there still TMS 9902 UART ICs available somewhere? E-Bay? I'm asking because while looking at my IC inventory the other day, I realized that I still have a few TMS 9995 and TMS 9901 chips in stock. But no UART intended for CRU use. Reading on this site I'm getting somewhat inclined to do some old-style hardware project again... Communicating with the "thing" is simplest the serial way, though. I could use a generic UART, of course, but they don't fit that nicely into the I/O space of a TMS 9xxx CPU.

 

Regarding "register" access time: When the TI 990/9 was designed, TI decided to go with a memory based architecture since they had developed a memory chip that was just as fast as their CPU technology. Thus they wouldn't gain performance by implementing a conventional limited register set, but gained tremendous flexibility by having a virtually unlimited amount of register files in memory. Today the idea looks stupid, but back in the 1970's it was logical.

The TMS 9900 is then an implementation of the TI 990/9 processor on (almost) a single chip. Add the clock generator and you're ready to go. The TMS 9900 was used in the TI 990/4 and TI 990/5 computers.

[+mizapf]

Saving and restoring of vital information when switching concurrent processes is typically called a context switch, and if you take, for instance, a MIPS architecture, such a context switch could entail at least writing out all 32 registers and loading the 32 registers of the other process. When I was still small, I wondered what TI was talking about BLWP doing a "context switch", as was happening with XOP or interrupts, until I much later learned about other architectures. In that sense, a context switch on a TMS processor is extremely cheap. In fact, although XOP was always referred to as "extended operations" for adding new software-implemented commands, they are actually system calls. If I remember correctly, the TMS99000 enters privileged mode (kernel mode) with XOP.

[apersson850]

The unusual XOP instruction was intended to implement new instructions in software, when programs designed for processors with these functions implemented in hardware were run on machines that didn't have that hardware. Remember that the TI 990 minicomputer series started as a machine with the CPU implemented across several boards with TTL circuits. When the TI 990/10, which had a TTL implementation for the CPU, was upgraded to the TI 990/10A, which used a TMS 99000 CPU, they went from 5½ boards to one. That single board had several special LSI circuits, most in 64 pin DIL enclosures. So the size of the TMS 9900 chip was nothing out of the ordinary at Texas Instruments at that time.

The TMS 9900 does support XOP, but doesn't have any kernel mode. As you wrote, kernel mode was introduced in the TMS 99000.

Edited June 15, 2017 by apersson850

[+mizapf]

As I remember the TI-990 had the full feature set, including kernel mode, and the TMS9900 was, in that respect, a stripped-down version, whereas the TMS99000 got everything back again.

[apersson850]

It depends on which TI 990 model you look at. The TI 990/10 had more of that stuff than the TI 990/9, for example. And it's the TI 990/9 that the TMS 9900 implements on a chip. The TMS 99000 implements the TI 990/10, which then became the TI 990/10A.

TI 990/12 had even more features, like floating point routines in hardware etc.