I'm Michael Zapf (posting as “mizapf” in the MESS forum). My primary interest is to get a clean, bug-free emulation of the TI-99/4A system.

TODO list:

• Clean up the ti99_4x and related drivers
• Driver documentation (so other people may assist me)
• PC99 (other emulator) disk format support Done
• SCSI emulation
• Sync real hard drive with dump
• Complete TI-99/2 emulation
• More expansion cards
• Dual Geneve BIOS Done
• UCSD Pascal system Done
• Check IDE emulation
• Create disk from image
• Fix TI-99/8 emulation Done
• Fix HFDC issues Done
• Reorganize cartridge handling Done
• Create a link from the RS232 emulation to a real UART Done

While we have an emulation of some UART chips, they are all connected to a file as a backend. This means that all write operations go to this file, and input operations … well, so such thing yet. Virtual machine implementations like VMWare include access to real hardware, so this should also be possible here.

An important use case of a connection to a real serial port is to establish a connection between the emulation and the real hardware in order to easily exchange files or to test software that uses serial connections.

There are at least two ways how to implement this:

• Link to low-level driver code and pass on all operations from the emulated device to the real device and back.
• Delegate communication to an external tool which cares for the connection.

The second option is attractive for its platform independence.

In the meantime I designed and created an implementation for this serial connection for the TMS9902 UART in the TI RS232 card. It should be possible to refactor it as an own device or slot device, whatever structure is preferred.

The new cartridge definitions for the TI systems can be found on ninerpedia

It is not trivial to set up the HSGPL; you need a particular loader program. Also, for the SGCPU you need a properly set up HSGPL or it will crash at startup. I collected some instructions and tool to set up an empty HSGPL: setup_hsgpl.zip

I've recently studied the descriptions to software lists a bit more throughly, and also checked the DTD.

I guess that with more and more systems adopting the lists and less using the RPKs, I (or whoever) will not have another option but to implement them for the TI family as well in not-so-distant future. Still, there are some points which are missing or for which I need some more clarifications:

DTD:

• <ram> element for defining NVRAM in the cartridge (easy, just means to add this to the DTD and the parser)

• <pcb>: seems to be covered by <feature>, but one should consider to have this as an own (optional) element as it is a very important information for the cartridge, and hiding it in a generic element is not a good way to go (since the pcb is a mandatory information for my carts)

Usage:

• I need the possibility to handle multiple cartridges at the same time (-cart1, -cart2, …). This is not per se a problem with the software lists, and no problem on the command line, but rather how this should be presented in the UI. A simple software selection will not do; I still need to specify where to mount the cartridge (just as possible now).

• I see that cartridge contents are stored in subdirectories as separate files. Can I also drop zip files there without unpacking (like the system zips in the roms folder)? I don't intend to tell users to download the zips, unpack them in the right location and repack them when sending them to someone else.