Gazoo's loaders were all hand-coded, they didn't do any scanning, but he did use a power-up routine - see below.
* Turning off bases essentially turns the UberGROM into a single-game cartridge, yes?
Single-game / multi-game has nothing to do with the hardware in this case -- the UberGROM was never developed to be a multicart. If it was, I'd just have implemented bank switching instead of the multiple GROM bases, which have compatibility issues on some carts.
What it does is restrict you to a single base of 5 GROMs, though.
Can this be mitigated by putting a different, GROM-only application into the second base? (I can try this myself, actually, so there may be three replies to this
It should work, but apparently it didn't for you. But you also have to choose something that can work at the alternate base. I'm not sure why your experiments failed, I have successfully created multi-base GROM carts... just not more than basic experimenting. I don't know all the nuances.
However, that effectively renders that bank useless for anything else, right? Does it stop the console from probing the rest of the UberGROM for valid AA 01, or is it just a bug with slot 0 on bank 0 and 1 not having an AA 01?
Depends on your definition of useless, I guess. The full uberGROM is still available to any software that knows to look for it, only the code that builds the selection list has stopped scanning. For instance, I've deliberately inhibited the console scanning to display an entry for my own multicart program (so only one thing shows on the list even though there are multiple valid programs).
Since your case presented a case I was not previously aware of, I don't think I can explain the bug well enough to describe all the conditions. I discovered it many years ago when I made my first multi-GROM cart (the Megaman music demo), and only read the GROMs far enough to understand that it was a problem with the multiple base detection and lack of a header (that demo only used GROM for data, no headers in any bank
). In TI Intern you can see the detection code in the GPL side at >01C1 - it compares 32 bytes from the first two bases. If they are the same, it assumes one base and just scans the 5 GROMs at base >9800. If they differ, it scans 16 bases. But of course this doesn't lock out the hardware it's just for creating that listing.
I'm not entirely sure why it spins in this case, it's been many years since I understood it.
It does render that base "useless" for other GROMs that live at >6000, but in fairness, you have 14 more bases for that.
I'm trying to reconcile this with being able to build a Multiplan cart, five-GROM-only, with the only difference being that AA 01 was in at >6000.
It's probably faster to prove it out in emulation first... not all carts can live at alternate bases because some (like Parsec) assume the GROM access address. I don't think TI ever quite finished the multiple GROM base concept and what we see (and built on) is leftover code from an incomplete idea that was never strictly enforced in later software.
do you reckon it would be possible to create a GROM-and-ROM multi-program cartridge by redirecting the GROM application header to point to a code snippet in an unused area of the GROM that writes the right ROM bank to >6000, then jumping to the original entry point? That's my macro goal here -- it's so wasteful to have one program per cart, and the rest of that 512k is just sitting there ...
Yes, and it's been done.
So long as the ROM side runs in 8k (and never writes to ROM by accident, most don't), it will work fine. The couple of carts that do such things use a GPL power-up routine to set the correct bank in the ROM and then run from ROM - I built a multicart that does that, and Gazoo's XB27 does that. Using a powerup routine means you only need a few bytes of GPL code, but you can certainly write a whole menu in GPL.
My own multicart menu program is assembly, but it scans and can launch from both ROM and GROM.http://harmlesslion....tware/multicart
I built a demo cart a few years ago that used the GPL power-up routine concept to ensure the right bank was selected for the menu to appear, and tweaked the headers of several of the embedded programs so the console could not find them, but my menu could. (There are notes in the readme for the tweaks that it supports, they involve corrupting the 'AA' to something else).
... so it appears that GROM multi-carts will work iff they have AA 01 at the first slot? That's unfortunate. Thanks, TI ...
Unfortunate... a quick test here confirms your results.
My multicart menu program will work in this situation, since it scans all GROMs in all bases without discrimination (and all banks of the ROM too) - however for a combination ROM/GROM cart it'll need a little extra data to select the right ROM bank. (There is a nice unused byte in the cartridge header we could adopt... if it's a GROM we scan we could just use that byte as a ROM select. If that sounds useful let me know and I'll add it - GROM support is new and nobody but me has used it.
The one other thing with building multi-carts is multi-bank ROMs need special handling. They'll assume two fixed banks in most cases, and you'll either need to make sure they are at the right place in the EEPROM (either beginning or end depending on the banking chip, or go through the effort of modifying the program to run from a different pair of banks. The very few I've looked at stuff most of their banking at fixed addresses, making it pretty easy to find them.