Hi to all TI-99 users,

I just completed a re-write of the cartridge slot system of the TI consoles. There are no new features but this is a long-due cleanup of the complex code that attempted to incorporate all features in itself.

From now on we have three slot options "single" (default), "multi", and "gkracker". When the cartridge port (aka gromport) is set to single, only "cart" is offered to mount a cartridge. For "multi", cart1, 2, 3, and 4 are available. gkracker offers a single own "cart" (where the cartridge to be dumped is plugged into).

With this rewrite I was finally able to remove a lot of emulation magic from the gromport by creating these different slot devices. Anyway, the real console has only one slot, and extenders were needed to get more slots. So this is now properly reflected in the emulation. You get the additional slots only when the extender is plugged in.

Example


versus



RPK and softlist are both available, you can take cartridges from either one, even mixed in the multi expander. The softlist still needs some more entries; until then you need to use the RPKs.

The GRAM Kracker device now loads its ROM from a zip file ti99_gkracker.zip in the rompath (so no more pseudo cartridge). It stores the NVRAM contents in the nvram/ti99* folder as gromport_gkracker.

There is a configuration option to enable or inhibit a system reset when plugging in a cartridge. For the previous implementation an emulator reset was mandatory because of the runtime addition of PCB devices. This is not necessary anymore since the PCBs are now modeled as simple C++ objects, thus removing this emulation artifact.

Michael

Yeah, about this:



That's GCC 4.7.0 on Linux.

Er ... I still have gcc 4.6.2, no 4.7 in my openSUSE repos yet.

So would it help to declare the destructor of ti99_cartridge_pcb as virtual and add destructors for each subclass?

I think this is a precautious and general error message; the subclasses here mainly differ by implementation, not by state. (Anyway, says "might".)

Michael
(still loving Java)

You only need to declare a virtual destructor on the base class. Derived classes implicitly get default virtual destructors generated if the base destructor is virtual.

Too late, already added the destructors.

Try to recompile now. My gcc 4.6.2 does not seem to know this parameter, so I don't see a difference.

Michael

Looks good on 4.7 now, thanks