RPKs for Milton Bradley MBX titles fail to run properly on the Mega99 core

[tonedef71]

I have tried to run the RPKs for a couple of MBX titles on the Mega99 core, but so far, either the game fails to run after it has accepted input for startup options such as the number of players (e.g. Sewermania), or the game does run but with corrupted graphics and no speech synthesis (e.g. Meteor Belt).

[zeldin]

Well, isn't that expected because no MBX expansion hardware is connected? I never had the MBX expansion (and it's not covered on Thierry Nouspikel's site), so I'm a little hazy on the details here...

[tonedef71]

Well, isn't that expected because no MBX expansion hardware is connected? I never had the MBX expansion (and it's not covered on Thierry Nouspikel's site), so I'm a little hazy on the details here...

No, the cartridges are not expected to fail. While the MBX expansion provided enhanced user experience features (such as a higher quality speech synthesizer, specialized trigger controllers, a headset with microphone for speech recognition, and a 64-button membrane touchpad), the MBX cartridges themselves ran even without the MBX expansion hardware. You can run these cartridges in MESS/MAME and other TI99-capable emulators to see how well they perform without the optional hardware.

[zeldin]

This is interresting.

Firstly I'm curious how you got the Sewermania RPK to load at all in Mega99; its layout.xml has <pcb type="mbx"> which is rejected outright as unsupported... (It looks like the cartridge contains some form of NVRAM.) Secondly, I couldn't actually get any of these RPKs to work in MAME. I tried both sdlmame 0.263 on Linux and MAME 0.270 (from homebrew) on macOS. They just gave me a blank screen after pressing "2" on the module selection screen. So for me Meteor Belt (the one with a standard PCB so that it could be loaded into Mega99) actually worked better on Mega99 than in MAME... :confused:

One thing that I notice is that the GROM files in both RPKs have weird sizes. The Sewermania one is 35002 bytes, which is 6K*5, so I assume it's supposed to have 5 GROMs. It's just that normally RPKs have 8K per GROM, with the "extra" 2K containing the mix of the second and third page that you get when trying to read a full 8K out of the GROM. As for the Meteor Belt one, it's 28602 bytes, which is neither a multiple of 6K or 8K, so I can't even begin to guess what's going on there.

[zeldin]

The Sewermania one is 35002 bytes, which is 6K*5

Eh, no it's not. I don't know what I was smoking there. It's 6K*5.69694, so that can't be it either...

[tonedef71]

Firstly I'm curious how you got the Sewermania RPK to load at all in Mega99; its layout.xml has which is rejected outright as unsupported... (It looks like the cartridge contains some form of NVRAM.)

It must have been this RPK that I used for Sewermania.

Secondly, I couldn't actually get any of these RPKs to work in MAME.

RPK is actually a deprecated format for MAME; it was used for a while by MAME to support homebrew TI-99/4A cartridges. It may be that newer versions of MAME only support ZIP files containing the rom dump files.

So for me Meteor Belt (the one with a standard PCB so that it could be loaded into Mega99) actually worked better on Mega99 than in MAME.

Meteor Belt is an excellent Milton Bradley example to focus our attention on because it is a straight-forward shoot-em-up game, and I can confirm from personal experience that the original cartridge ran perfectly on my childhood neighbor's original stock TI-99/4A home computer.

To see it run on MAME (via mame ti99_4a -cart meteorbt), use this ZIP file. This ZIP files contains two ROM dumps: a console rom (ends in 'c') and a grom (ends in 'g'; well, 'g3' in this case).

I'm wondering if MAME does anything special under the hood to support these cartridges. It may actually be an exercise in figuring out where to map/overlay in memory the dumped ROM files.

Also, here is a 32K (32768 bytes) ROM dump of Meteor Belt. I wonder if such a size ROM dump would require 32K expansion. Here is a 32K ROM dump of Sewermania.

To correct my earlier claim, I recently read the following: "Terry Turtle's Adventure", "I’m Hiding", "Championship Baseball" need the MBX hardware in order to play them. The other seven MBX titles (Bigfoot, Honey Hunt, Meteor Belt, Sewermania, Soundtrack Trolley, Space Bandits, and Superfly) are playable on a TI-99/4A console without the MBX.

[zeldin]

It must have been this RPK that I used for Sewermania.

Thanks. This one does run in MAME, but hangs after name entry like you described.

RPK is actually a deprecated format for MAME; it was used for a while by MAME to support homebrew TI-99/4A cartridges. It may be that newer versions of MAME only support ZIP files containing the rom dump files.

Yeah, I know MAME considers RPK "deprecated", but other RPKs (parsec, munchman, extended basic, tunnels of doom, blasto) run just fine so it's not like they removed support or anything.

To see it run on MAME (via mame ti99_4a -cart meteorbt), use this ZIP file. This ZIP files contains two ROM dumps: a console rom (ends in 'c') and a grom (ends in 'g'; well, 'g3' in this case).

This one runs correctly in MAME, but it also looks like a completely different version. This has 16K ROM (presumably bank switched) and 6K GROM (so a single GROM). The RPK had no ROM and much more GROM. Need to look at it closer later to check the difference.

Also, here is a [32K (32768 bytes) ROM dump of Meteor Belt] (https://forums.atariage.com/applications/core/interface/file/attachment.php?id=455340). I wonder if such a size ROM dump would require 32K expansion.

Nah, the GROMs have their own memory space so they are completely unrelated to the 32K expansion. 32K GROM is entirely possible; the largest GROM cartriges like Tunnels of Doom have 40K. But this dump contains stuff like "Made with Classic99" so I don't expect all of it actually comes from the cartridge. Also the working zip had just 6K of GROM.

[zeldin]

So, I created an RPK from meteorbt.zip by just adding a layout.xml based on the entry in MAMEs ti99_cart.xml (which is the curated list they want you to use instead of RPKs).
meteor_belt_rpk.zip (I had to double zip it because GitHub doesn't let you attach files called ".rpk"...) This RPK runs just fine in MAME. It won't run on Mega99 currently though because I don't support the "mbx" pcb type (which has a larger ROM than standard, and 1K of extra RAM).

I also tried removing the 1K RAM from the layout file, but this makes the game hang after name entry, so apparently this RAM is used by the gameplay logic.

Anyway, it looks like the RPK you have is borked, because it doesn't work even in MAME. Also, I ran strings on the dump inside, and found this:

 ** DISK VERSION BY JNB AUG85 **

So it looks like this is actually the disk version of the game, which someone bizarrely tried to turn into an RPK...

[tonedef71]

... based on the entry in MAMEs ti99_cart.xml (which is the curated list they want you to use instead of RPKs).

Ah, I was wondering how it works in MAME now with ZIP files which simply contain just the ROM dumps. Is this ti99_cart.xml file viewable online anywhere?

(I had to double zip it because GitHub doesn't let you attach files called ".rpk"...)

Well done. Thank you for sharing the RPK. The game supports speech synthesis as well, which I think can be enabled in MAME with CLI parameters like -ioport peb -ioport:peb:slot3 speech, or something along those lines.

At some point, I'm wondering if we could share the layout.xml files for various games so folks can create the RPKs for themselves from their ROMs (presuming their ROMs are already in the right format for MAME).

It won't run on Mega99 currently though because I don't support the "mbx" pcb type (which has a larger ROM than standard, and 1K of extra RAM).

That is disappointing. 😞 Is RPK support for the mbx pcb type on your roadmap for an upcoming release of Mega99? 🙏🏻

I also tried removing the 1K RAM from the layout file, but this makes the game hang after name entry, so apparently this RAM is used by the gameplay logic. 👌🏻 I wonder if all of the Milton Bradley cartridges for the TI-99/4a work similarly. 🤔

So it looks like this is actually the disk version of the game, which someone bizarrely tried to turn into an RPK...

🤨 Yeah, that is quite bizarre. I thought that the Milton Bradley games for the TI-99/4a were only ever released as solid-state cartridges.

Besides MAME (and its derivatives), I wonder if there are other TI-99 emulators which consume these RPK files. 🤔

[zeldin]

Ah, I was wondering how it works in MAME now with ZIP files which simply contain just the ROM dumps. Is this ti99_cart.xml file viewable online anywhere?

I you have MAME installed you should have it on your hard drive already, I have it in /usr/share/sdlmame/hash/ on Linux, and in /opt/homebrew/Cellar/mame/0.270/share/mame/hash/ on macOS. But you can also view it here on github.

Note that the format isn't exactly the same as layout.xml, but it contains basically the same information (plus also checksums so that MAME can verify that your dumps are good).

That is disappointing. 😞 Is RPK support for the mbx pcb type on your roadmap for an upcoming release of Mega99? 🙏🏻

It shouldn't be too difficult to add. The ROM size is the same as the "paged" format (used by Extended BASIC) which I support, and the RAM size is smaller than Mini Memory, so it wouldn't require any resources I don't already have. It's just a matter of figuring out (from the MAME sources) how the bank switching is supposed to work. Now that I know that an actual MBX device is not needed for support to be useful, I could give it a stab.

👌🏻 I wonder if all of the Milton Bradley cartridges for the TI-99/4a work similarly. 🤔

From what I can see this PCB (with the 1K RAM) is used only on the MBX titles. Other Milton Bradley cartridges, like Blasto and Hangman, use a standard PCB.

🤨 Yeah, that is quite bizarre. I thought that the Milton Bradley games for the TI-99/4a were only ever released as solid-state cartridges.

Well, if it's from 1985 like the message suggests, it probably got little to no distribution, since TI had pulled out of the market by then. It could even be some sort of bootleg.

[tonedef71]

... you can also view it here on github.

Thank you for the link. I have installed a MAME distribution that was built for 64-bit Windows, and I don't believe that file is included as part of that distribution.

Note that the format isn't exactly the same as layout.xml, but it contains basically the same information (plus also checksums so that MAME can verify that your dumps are good).

Yes, it does seem to include much more information than RPK's layout.xml file as described on this page.

Now that I know that an actual MBX device is not needed for support to be useful, I could give it a stab.

That is excellent news! I look forward to playing MBX titles on the Mega99.

From what I can see this PCB (with the 1K RAM) is used only on the MBX titles.

That extra 1K of (scratchpad?) RAM is probably used for storing any and all game state, such as the typed-in player names.

For Meteor Belt, I wonder if that three in the extension for that grom file (.g3) has any significance. 🤔

Other Milton Bradley cartridges, like Blasto and Hangman, use a standard PCB.

Ah, I did not realize that Milton Bradley had previously published game cartridges for TI.

Well, if it's from 1985 like the message suggests, it probably got little to no distribution, since TI had pulled out of the market by then. It could even be some sort of bootleg.

I guess the MBX system was ahead of its time and ran out of borrowed time. The few that were made command a lot of money. After giving up on developing a standalone game console, MB had pitched integration of the system to other console manufacturers, but only TI was interested I guess; too bad it came too late. I think the 64-button membrane pad with overlays was a decent idea, because the 12-button membrane keypad on the ColecoVision controllers made several of the ColecoVision titles more engaging. The ColecoVision "Super Action Controllers" were a similar concept to the MBX controllers; the MBX controllers had a cool rotation knob on the stick, and the CV Super Action Controllers had a speed roller dial. 1985 was a tough year for computer/video game manufacturers.

[zeldin]

Yes, it does seem to include much more information than RPK's layout.xml

Well yes, it also includes the information from meta-inf.xml, which is optional in RPKs (it doesn't affect how the RPK is loaded).

For Meteor Belt, I wonder if that three in the extension for that grom file (.g3) has any significance. 🤔

I take it to mean "GROM 3" (address range 0x6000-0x7fff). The console contains GROMs 0-2 (address range 0x0000-0x5fff) with TI BASIC and stuff, so cartridges use GROM 3-7 (address range 0x6000-0xffff). MAME likes to split dumps into one per physical chip, and it looks like they do that for GROMs in their cartridge zip files as well (e.g. Tunnels of Doom contains 5 dump files). RPK requires all the GROM data to be in a single file, with each GROM padded to a size of 8K.

[tonedef71]

it also includes the information from meta-inf.xml

I think I have seen a meta-inf.xml file appear inside of some RPK files, but I have not come across any documentation for that file format.

I take it to mean "GROM 3" (address range 0x6000-0x7fff). The console contains GROMs 0-2 (address range 0x0000-0x5fff) with TI BASIC and stuff, so cartridges use GROM 3-7 (address range 0x6000-0xffff).

Ah, that seems apropos to me (and a clever way to convey configuration data via a filename extension).

RPK requires all the GROM data to be in a single file, with each GROM padded to a size of 8K.

For Meteor Belt to run in Mega99 as an RPK, would that 6K phm3152g3.bin grom file need to be padded to a size of 8K?

[zeldin]

Ah, that seems apropos to me (and a clever way to convey configuration data via a filename extension).

Well, the actual configuration data is conveyed by the offset attribute of the <rom/> element of course, the filename itself is completely arbitrary so this is just a convention. But obviously each dump file needs to have a unique filename to avoid filename clashes, and this is as good a way as any to achieve that.

For Meteor Belt to run in Mega99 as an RPK, would that 6K phm3152g3.bin grom file need to be padded to a size of 8K?

No. Padding is not needed for the last GROM. The point here is that while each GROM only holds 6K of actual data, it occupies 8K of address space due to the way the address decoding works. If you try to read the last 2K you'll just get garbage (it's not random, but a mess of bits from the actual 6K of data). But for a linear dump of the GROM address space this garbage must be included between GROMs so that the next GROM starts at the correct address. So if you have a cartridge with two GROMs, GROM3 at 0x6000-0x77ff and GROM4 at 0x8000-0x97ff, then the GROM dump of the RPK needs to contain GROM3 dump (6K) + garbage (2K) + GROM4 dump (6K) But you don't need any garbage after GROM4 because there is no data that has to be loaded to 0xa000. Usually RPKs contain the actual garbage that the GROM (GROM3 in the example above) covering the address range would produce, but it's not really that important since nothing will try to access this address range anyway. And in the case of Mega99 it will actually on the fly recreate the exact garbage you would get from a real GROM, disregarding the actual data stored in the garbage region of the RPK. So you would get the correct garbage for GROM4 as well. Not that anything cares. :smile:

[tonedef71]

Well, the actual configuration data is conveyed by the offset attribute of the element of course, the filename itself is completely arbitrary so this is just a convention. But obviously each dump file needs to have a unique filename to avoid filename clashes, and this is as good a way as any to achieve that.

👍🏻

No. Padding is not needed for the last GROM. The point here is that while each GROM only holds 6K of actual data, it occupies 8K of address space due to the way the address decoding works. If you try to read the last 2K you'll just get garbage (it's not random, but a mess of bits from the actual 6K of data). But for a linear dump of the GROM address space this garbage must be included between GROMs so that the next GROM starts at the correct address. So if you have a cartridge with two GROMs, GROM3 at 0x6000-0x77ff and GROM4 at 0x8000-0x97ff, then the GROM dump of the RPK needs to contain GROM3 dump (6K) + garbage (2K) + GROM4 dump (6K)

Ah, I understand. Thank you for the thorough explanation.

... in the case of Mega99 it will actually on the fly recreate the exact garbage you would get from a real GROM, disregarding the actual data stored in the garbage region of the RPK.

Some folks might have simply padded with zeroes and called it a day. Recreating genuine/authentic "garbage" data for byte-padding is true dedication to the craft. Well done, sir!

[zeldin]

Added support for cartridges with the MBX pcb. Both Meteor Belt and Sewermania run fine now. Will make a new release later. Here's a non-broken RPK of Sewermania that I made, btw: sewermania_rpk.zip I should probably make a tool for creating non-broken RPKs using ti99_cart.xml and zips. It seems that it's needed with all the broken RPKs around. :wink:

[tonedef71]

Added support for cartridges with the MBX pcb. Both Meteor Belt and Sewermania run fine now. Will make a new release later.

@zeldin You rock! 🎸 I cannot wait to try the next release.

Here's a non-broken RPK of Sewermania that I made, btw:

Thank you!

I should probably make a tool for creating non-broken RPKs using ti99_cart.xml and zips. It seems that it's needed with all the broken RPKs around. 😉

@zeldin Good point. Such a tool would be useful. In the meantime, please feel free to continue to post fixed MBX RPKs to this thread.

So far, you have shared the following fixed RPKs (as reZIPs): meteor_belt_rpk.zip sewermania_rpk.zip