Hardware projects

Creating a video cable

Here are instructions to build a Video Cable to bypass the RF modulator in order to directly connect the console to modern TV sets.

Using a TI console as a keyboard

If you are using an emulator like MESS you can actually make good use of your old TI console: use it as a keyboard.

Geneve projects

Some ideas for an updated boot EPROM (is there still a source for EPROM circuits?) for the Geneve: My idea would be to throw out the whole controller detection mess inside the boot procedure. Some months ago I tried to track down a crash in the Geneve emulation, until I found lots of bugs in the 0.98 EPROM. I suppose much of that has been fixed in 1.0, but things could be improved.

A boot procedure would then look like this:

• Try to load DSK1.LOAD_SYS (offer to skip that by pressing SPACE)
• If not found, try to load it from ramdisk, HFDC, and SCSI. If that fails, error out.
• The LOAD_SYS will provide a customized loader for the respective card, so you have to copy the proper version on the boot device. Even better, for future expansion you can put a suitable LOAD_SYS in that load path. And if all fails, you can still put a disk in DSK1 and override all that.
• Finally, LOAD_SYS will load the Geneve OS (SYSTEM_SYS) from the selected boot device. Yes, and I'd vote for replacing those slashes by underscore.

So there is absolutely no need to play with CRU bits and to apply other voodoo stuff to figure out the controller, as it is done now. And still enough space for a Swan.

The good thing is that one could test this either on emulation, or simply by loading that into some memory pages and pretend we're about to boot. If it works, we can burn a new EPROM.

Various hardware concepts

A hypothetical Super-TI

How would a super TI have looked like if TI had used the most advanced processor in their collection, the TMS99000?

Let's call it the TI-99K.

Why privileged mode?

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.

TODO: Carry on dreaming ...