Subject: What if ...

From: "Michael Zapf" <[email-masked]>
Date: Mon, 17 Jun 2013 13:50:38 -0000

... our TI had been built with TI's most advanced 16-bit CPU technology of those times?

In my courses on computer architectures I recently told the students about the impact of having a privileged mode in the processor. BTW, I already integrated some of our knowledge in the course :-) ; for instance, adapting a 16-bit CPU to 8-bit memory circuits, of course, scaling up to a 64-bit CPU and 32-bit memories.

The TMS99000 series, as I was told by Google, had been discussed in the comp.sys.ti newsgroup already 20 years ago, so this is nothing particularly new. For those of you who never heard of that CPU family, the most notable differences between the TMS99000 series and the TMS9900 series are

- special storage called macrostore, with another 64K capacity (can be integrated inside the CPU for more advanced versions)
- map select (two banks of 64 K) using a status register bit
- privileged mode (also indicated by a status register bit) which is required for executing some vital commands

It would not have been a matter of speed alone if we had had the 99000 at hands, but also a complete world of new features, beyond that what we know from the Geneve (which was already a big leap forward, compared to the TI console). 

The privileged mode is required for the commands LIMI, all control commands (RSET, CKOF, ...) and CRU commands. Attempting to use them from user mode would have caused a trap. Entering privileged mode (aka "kernel mode" in the x86 world) would be possible only by XOP, interrupt, and traps (like overflow or privilege violation). 

Many years back, people already considered to use the 99000 for third party projects (see e.g. the SGCPU aka TI-99/4P), but the 99000 CPUs were already difficult to get.

However, today, there is another interesting way: I could imagine (provided that some free time finds back its way to me) that it could be interesting to assemble such a hypothetical computer in MESS. This is not possible right now because there is no 99000 implementation yet. But it's somewhat itching, I have to confess. No costs, only time to be invested. The existing 9995 implementation could be used as a starting point, and then it is just a matter of plugging parts together.

So that's another thing for my queue, and it will stay there for some time, as things look like. But I could imagine to put some ideas on ninerpedia in the meantime about the possible architecture. It could turn out that this could suffice to create a multi-processing, multi-user environment as we know it from the PC world.

Michael

---

From: "Stuart" <[email-masked]>
Date: Mon, 17 Jun 2013 20:10:28 -0000

Hi Michael,

"The privileged mode is required for the commands LIMI, all control commands (RSET, CKOF, ...) and CRU commands. Attempting to use them from user mode would have caused a trap. Entering privileged mode (aka "kernel mode" in the x86 world) would be possible only by XOP, interrupt, and traps (like overflow or privilege violation)."

I read about that in the specs when I was putting together my 99110 breadboard system (<www.avjd51.dsl.pipex.com/tms99110_breadboard/tms99110_breadboard.htm>). But how would priveleged mode actually be used? If you had a 99000 system providing some sort of controlled application (say word processing) to some dumb terminals then I could may be see the point. But using a 99000 system in a similar way to how we use the TI-99 or Geneve - is it of any use?

Interested ...!

Stuart.

---

From: "Michael Zapf" <[email-masked]>
Date: Mon, 17 Jun 2013 22:20:16 -0000

Hi Stuart,

> I read about that in the specs when I was putting together my 99110 
> breadboard system (<www.avjd51.dsl.pipex.com/tms99110_breadboard
> /tms99110_breadboard.htm>). But how would priveleged mode actually be 
> used? If you had a 99000 system providing some sort of controlled 
> application (say word processing) to some dumb terminals then I could 
> may be see the point. But using a 99000 system in a similar way to 
> how we use the TI-99 or Geneve - is it of any use?

I'll have to spend some more thoughts on that, and I'll put that on ninerpedia every now and then. 

Some things which already came to my mind:

You can create a real operating system which manages several user processes, possibly from different users. As with every higher operating system, you can abstract from the hardware and leave immediate access to the operating system. The user programs will lose any direct access. This allows us to design a driver model with drivers running in kernel mode.

The first thing you will notice when writing user programs is that the LIMI command has been taken away. User programs will be unable to change the interrupt mask, even with RTWP or LST because these commands refuse to set certain bits in the status register when executed in user mode. Modifying interrupt masks is something exclusive for the kernel.

Yes, no more access to memory-mapped devices. In such a system, you just cannot allow access to the VDP or other devices. Instead, all such accesses must be done in kernel mode, and this is only accessible via XOP, which finally takes it role seriously as a system call interface. The Geneve MDOS already realizes such a concept, albeit with no protection against circumvention.

You can add a memory mapper circuit for memory paging. To prevent user processes from changing the map, the mapper should be locked and unlocked, maybe with an external command like CKON and CKOF. These commands are privileged, and so a user process will be unable to change memory maps.

All these concepts are somewhat possible without a privileged mode, and some parts (system calls, memory mapping) are realized in the Geneve. But only with a privileged mode you can ensure that the operating system will run in a safe, stable way, and you can enforce authorization and access control which cannot be compromised by a user process.

Michael