UberGROM GROM+ROM: what am I missing?

[ckoba]

I'll be happy to take a look myself, the above zip file has the code? Unfortunately it will be a few days before I can, so keep working in the meantime.

 

My first question though, are you sure that you need to cut the GROMs down to 6k? It won't hurt anything to load the full 8k space into the UberGROM, and some cartridges did use them (though I didn't think any real TI ones did).

 

The Classic99 UberGROM support is now complete enough for full cartridges to be configured in Classic99.ini, but since you are debugging a real situation it's better to use GROMCFG as you have been to make sure you are doing the same steps. The only thing still missing is the startup 'recovery' option.

 

Regarding the other notes, normal to have no header on the ROM, that's fine, and also normal and fine to only have the AA header on one of the GROMs.

 

What I would probably do first though is back up one step -- create a Classic99.ini version of the cartridge using the individual files you have created, and make that work first. That way you are eliminating any UberGROM interference issues. If that doesn't work, back up one more step and make it work using the un-split version of your GROM data.

 

That zipfile has the code, and the .dsk that mizapf thoughtfully posted has a GRAM Kracker version of the same (onagi hash).

 

Adding the separate, 6144-byte GROM files as a user cartridge in classic99.ini works, insofar as "SCOTT ADAMS' ADVENTURE" is displayed on the selection screen. My .ini looks like this:

 

[usercart0]

name=Ubergrom test

;rom0=C|6000|2000|C:\Program Files\classic99\MODS\phm3189c.bin

rom0=G|6000|2000|C:\Program Files\classic99\MODS\xaa-fixed

rom1=G|8000|2000|C:\Program Files\classic99\MODS\xab-fixed

rom2=G|A000|2000|C:\Program Files\classic99\MODS\xac-fixed

rom3=G|C000|2000|C:\Program Files\classic99\MODS\xad-fixed

rom4=G|E000|2000|C:\Program Files\classic99\MODS\xae-fixed

 

(The ROM bit is commented out to ensure that it wasn't a factor in the menu display. The cartridge, of course, doesn't work without it, but does work with it).

 

So, in summary, it works fine if it's split into individual files, at the same addresses as mapped into the UberGROM. There's something off about the UberGROM, or at least the way that I'm setting it up (bases on, recovery on, rollover off, flash dev on).

 

The physical UberGROMs I'm using to test with were prepped with ubergrom.hex via the TL866 method and the fuses have been triple-checked. As I said, I've made working cartridges out of GROM-only carts. This is the first GROM-and-EPROM that I've tried.

[Tursi]

I was able to reproduce the problem... this is a lockup bug in the 99/4A init code. Basically, it has detected that you have multiple GROM bases because the contents of >6000 are different between the first and second bases, and it gets screwed up looking for GROM headers.

 

I had previously believed that having any header anywhere would prevent this lockup, but apparently having one in the second GROM (>8000) doesn't work.

 

There are two cures, and I tested both in Classic99. The first is simply to disable bases. GROMCFG won't let you go BACK at that point because the configuration tool itself won't work with bases disabled (it can not longer get to the flash device), but once it tells you BACK PROHIBITED the programming is finished and you can hit QUIT, just do that as the last step. The downside is you can't get a dump of the cart in that state.

 

The second cure is even easier and leaves the rest of the GROM available for other things if you want. Just put the exact same code at >6000 in both the first base and second base, both at >6000. I've made a video demonstrating that.

 

For that, my INI looks like this:

 

[test32]
name=Ubergrom test
rom0=U|6000|2000|C:\classic99\MODS\EA2k.BIN
rom1=G|2000|2000|C:\classic99\MODS\EA2k.BIN
ROM2=8|0000|80000|C:\classic99\MODS\returnpi\p512k.bin

EA2K I've posted before, I think... I use it just for emulation testing. It's a copy of Editor/Assembler that has been relocated to run at >2000 instead of >6000, so it's out of the way. I also took the ROM from the zip and replicated it till it was 512k, like you did. It's loaded here so I can test after running GROMCFG. Otherwise I'm using the DSK image that Rasmus posted to get the GROMs.

 

Note that I load EA2k.BIN twice, once with the 'U' line. This really does load it into UberGROM space, but I am only doing that to activate the emulation, I could have loaded anything there. (I've used text files before).

 

The other thing to note in the video is that when I set up the second base (>9804), I don't need to allocate a new GROM page or load from disk, I can just point to the same GROM page that was already loaded.

 

Also note you can build UberGROM images in Classic99, use the Save Device option to back it up, and load that completed image on the real machine.

 

Edited January 26, 2016 by Tursi

[ckoba]

(split-quote is acting weird, so my reply will be in two parts)

 

I was able to reproduce the problem... this is a lockup bug in the 99/4A init code. Basically, it has detected that you have multiple GROM bases because the contents of >6000 are different between the first and second bases, and it gets screwed up looking for GROM headers.

I had previously believed that having any header anywhere would prevent this lockup, but apparently having one in the second GROM (>8000) doesn't work.

There are two cures, and I tested both in Classic99. The first is simply to disable bases. GROMCFG won't let you go BACK at that point because the configuration tool itself won't work with bases disabled (it can not longer get to the flash device), but once it tells you BACK PROHIBITED the programming is finished and you can hit QUIT, just do that as the last step. The downside is you can't get a dump of the cart in that state.

 

This scheme works. I have a working RPI reproduction now. Thank you very much for spending time on root-cause analysis.

 

Questions about this part of the fix:

 

* Turning off bases essentially turns the UberGROM into a single-game cartridge, yes?

* 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 )

[ckoba]

Part two of two (maybe three) of my response (I don't do videos, I like text instructions, so I shan't wait ):

 

The second cure is even easier and leaves the rest of the GROM available for other things if you want. Just put the exact same code at >6000 in both the first base and second base, both at >6000. I've made a video demonstrating that.

 

This makes sense. Console sees same data at a different base, it assumes that it's a single-GROM cart. That I get, and I understand that the data isn't duplicated on the Atmel, it's just the same memory region mapped into a different bank.

 

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?

 

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.

 

Lastly, and this is an architecture question: 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 ...

[ckoba]

Part two of two (maybe three) of my response (I don't do videos, I like text instructions, so I shan't wait ):

 

 

This makes sense. Console sees same data at a different base, it assumes that it's a single-GROM cart. That I get, and I understand that the data isn't duplicated on the Atmel, it's just the same memory region mapped into a different bank.

 

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?

 

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.

 

Lastly, and this is an architecture question: 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 ...

 

(the promised third reply)

 

None of my attempts to get Multiplan (GROM-only) and RPI co-existing on the same cartridge worked. I tried:

 

* putting RPI into base 0 and Multiplan in base 1 (it only saw Multiplan),

* putting RPI into base 0 and base1/slot1 and Multiplan in base2 (it only saw RPI),

* putting Multiplan into base 0 and RPI into base 1 (it only saw Multiplan)

 

... so it appears that GROM multi-carts will work iff they have AA 01 at the first slot? That's unfortunate. Thanks, TI ...

[+Ksarul]

You might also want to look at Gazoo's GPL loader code. He did something in it to get around the limitation you've encountered here. . .

[ckoba]

You might also want to look at Gazoo's GPL loader code. He did something in it to get around the limitation you've encountered here. . .

 

This would be a version of his multicart menu program that supported GPL, which he referred to towards the end? Was that "released" (in the sense that it was attached to a post in one of the fifty-plus pages about the multicarts), or is it something that would need to be extracted from his binary releases?

[Tursi]

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.com/software/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.

[ckoba]

Gazoo's loaders were all hand-coded, they didn't do any scanning, but he did use a power-up routine - see below.

Argh. I'm not competent to hand-code TI assembly. I'm barely competent to wrestle with the GPL goop in Plato's first GROM to understand it's using a powerup routine.

 

 

I'm not entirely sure why it spins in this case, it's been many years since I understood it.

It's okay. Console limitation, but can be worked around because ...

 

 

My own multicart menu program is assembly, but it scans and can launch from both ROM and GROM.

http://harmlesslion.com/software/multicart

 

(snip)

 

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 byte at >6003? Yes, please, very very useful. Something like "if non-zero, the value represents the 8k bank of the ROM we want (assuming Multicart program is at 0 and the final bank)". To handle multi-bank ROMS, maybe set the high bit to signify mapping 16?

 

Again, thank you *very* much for confirming the TI bug and suggesting workarounds. I'll play with your multicart menu later today and see if I can get it to make RPI and Multiplan play nice.

 

(aside: the reason I'm harping on about Multiplan is that it doesn't appear in anyone else's compilation. Same with all of the large cartridges, I think -- Plato, RPI, Logo II, and so forth. Just trying to do my bit for the community )

 

(editt: math)

Edited January 27, 2016 by ckoba

[Tursi]

I tested last night with RPI and A-Maze-Ing, that was when I realized that the ROM switch was needed (so RPI could work). I implemented the byte at >6003 (bank index 00-FF, this allows for up to 2MB of ROM), but I will have to upload it after work, which will probably mean a couple of days again.

 

Return to Pirate's Isle will not work out of the box on a bank-switched ROM because it writes to ROM space frequently (4 times every time it loads a new picture). All of those accesses will need to be patched out, otherwise it will switch banks and crash itself. I can probably help with that too, but I'd need a walkthrough to see the whole game and ensure none were missed. But aside from that it was working.

[ckoba]

I tested last night with RPI and A-Maze-Ing, that was when I realized that the ROM switch was needed (so RPI could work). I implemented the byte at >6003 (bank index 00-FF, this allows for up to 2MB of ROM), but I will have to upload it after work, which will probably mean a couple of days again.

*blink* That was fast. Thank you. No worries on the upload delay -- a couple of days is a drop in the bucket compared to the time these machines have been around lacking a useful multicart solution.

 

Return to Pirate's Isle will not work out of the box on a bank-switched ROM because it writes to ROM space frequently (4 times every time it loads a new picture). All of those accesses will need to be patched out, otherwise it will switch banks and crash itself. I can probably help with that too, but I'd need a walkthrough to see the whole game and ensure none were missed. But aside from that it was working.

Again, argh. I can help run these down, if you want.

[+acadiel]

Return to Pirate's Isle will not work out of the box on a bank-switched ROM because it writes to ROM space frequently (4 times every time it loads a new picture). All of those accesses will need to be patched out, otherwise it will switch banks and crash itself. I can probably help with that too, but I'd need a walkthrough to see the whole game and ensure none were missed. But aside from that it was working.

We encountered that many times while compiling the first 512K multicart. Many (even 8K) ROMs wanted to write to ROM, either as copyright protection, or just bad coding.

[Tursi]

Classic99's debugger makes it pretty easy to catch such cases -- just set a breakpoint as '>(6000-7FFF)' and every write to cart ROM will breakpoint. You can then edit it out in memory (and in a hex editor on the side) and continue. The trick is catching /all/ the cases. It'd be possible to make software attempt to find all hard-coded cases (which are the vast majority), but that's not coming soon. With a walkthrough of commands, I'd be happy to patch up Pirate's Isle for you, just tell me what to type. It looks like only picture loads do it.

 

The new multicart menu software is up too: http://harmlesslion.com/software/multicart

[ckoba]

Classic99's debugger makes it pretty easy to catch such cases -- just set a breakpoint as '>(6000-7FFF)' and every write to cart ROM will breakpoint. You can then edit it out in memory (and in a hex editor on the side) and continue. The trick is catching /all/ the cases. It'd be possible to make software attempt to find all hard-coded cases (which are the vast majority), but that's not coming soon. With a walkthrough of commands, I'd be happy to patch up Pirate's Isle for you, just tell me what to type. It looks like only picture loads do it.

 

The new multicart menu software is up too: http://harmlesslion.com/software/multicart

The multicart software works. I built a Plato cartridge with the ROM in a random bank, and it dialed right in to it and fired up fine (when chosen via "multicart" -- choosing via the TI selection menu fails, as expected).

 

I'll get cracking on RPI later today or tomorrow.

 

Thank you very much for implementing ROM bank selection. Multicart multicart multicart

[Tursi]

The multicart software works. I built a Plato cartridge with the ROM in a random bank, and it dialed right in to it and fired up fine (when chosen via "multicart" -- choosing via the TI selection menu fails, as expected).

Right, the idea for that is you would hide such software from the console menu by hex-editing its header to one so that the multicart menu recognizes it but the TI ROM doesn't. ">A55A" is defined for this purpose (replacing the "AA" in the first byte and the 'version' in the second, which is usually "01").

 

(Edit: although that is a problem for GROM programs that have powerup routines, DSR, or subprograms, and need the AA byte to be valid. In /that/ case, assuming a normal 6k GROM, you would change the header to ">AA5A" (ie: just the version byte), and zero out the link to the program list. You then put a new link at >7800, which is unused by a 6k GROM, and so only the multicart will find it.)

 

Example... I don't have Plato, so I'll use Minimemory as an example, since it has DSR links.

 

The Mini Memory header looks like this:

 

G6000:
AA 01 - header - valid GROM and version 01
00 00 - optional number of programs (unused) and spare byte (or Multicart ROM page select)
00 00 - power up list (none)
60 10 - program list at >6010
61 49 - DSR list at >6149
61 05 - Subprogram (CALL) list at >6105

We can hide it from the TI console menu by changing the header as I described:

 

G6000:
A5 5A - header - TI no longer sees valid but Multicart will

However, this also breaks the DSR entries (SAVE MINIMEM) and subprogram list (CALL INIT, etc).

 

So instead we change the header to AA5A, and zero out the program list pointer.

 

G6000:
AA 5A - header - valid GROM and version changed to 5A - flag to Multicart Menu
00 00 - optional number of programs (unused) and spare byte (or Multicart ROM page select)
00 00 - power up list (none)
00 00 - program list NOW zeroed, no programs for menu!
61 49 - DSR list at >6149
61 05 - Subprogram (CALL) list at >6105

Then at >7800 in the GROM image, we simply put a new header - it has to be a copy of the entire header even though only the program list is examined. But since it's only for the multicart menu, we only put in the program link. (If we are using the ROM page select, that needs to be set in this header as well).

 

G7800:
AA 01 - header - valid header and version 01
00 00 - optional number of programs (unused) and spare byte (or Multicart ROM page select)
00 00 - power up list (none)
60 10 - program list - now we can point to the real one
00 00 - no need to duplicate the other pointers
00 00 - although you can if you like

If the GROM you are modifying is not at >6000, the same process applies, just start 6k in at an >1800 offset. Edited January 28, 2016 by Tursi

[ckoba]

Right, the idea for that is you would hide such software from the console menu by hex-editing its header to one so that the multicart menu recognizes it but the TI ROM doesn't. ">A55A" is defined for this purpose (replacing the "AA" in the first byte and the 'version' in the second, which is usually "01").

 

(Edit: although that is a problem for GROM programs that have powerup routines, DSR, or subprograms, and need the AA byte to be valid. In /that/ case, assuming a normal 6k GROM, you would change the header to ">AA5A" (ie: just the version byte), and zero out the link to the program list. You then put a new link at >7800, which is unused by a 6k GROM, and so only the multicart will find it.)

Plato is a weird cartridge in that it's GROM header already starts at >7800 (it's one of the rare TI 8k GROMs, I guess), because it's an "autostart cartridge" as per page 53 of the Gram Kracker documentation on Mainbyte.

 

I wasn't getting anywhere with Plato by changing the header at >6000 to AA5A (locked at blue screen), nor with various permutations of relocating the contents of >7800 to >6000 and then editing it (garbage at selection screen), so I figured that just seeing it run on iron for the first time in twenty years was good enough for me

 

I've attached Plato, in case you're curious.

plato_courseware.zip

[Tursi]

Odd... most of that area is empty, so I wonder if the original was really 8k... I've seen others like that which make me wonder if the person who dumped them did something weird.

 

You could move the header within that empty space but since it's got no powerup, no DSR and no subprograms, I would just use the A55A header to mask it from the console ROM.

 

It took a little fiddling, but find attached a sample that includes A-Maze-Ing, Return to Pirate's Isle, and Plato as a multi-bank GROM multicart (for testing in Classic99). It demonstrates hacking the headers so that the carts are hidden from the console but still work in the multicart...

 

it also has the beginnings of patches for RPI and Plato both. RPI both writes to ROM (which changes banks) AND expects to be on GROM base 0 - there are patches for both to work in this cartridge, but I suspect RPI has more of both that need to be found. Plato also runs only in GROM 0, so I patched that, but it is patched only as far as the 'load diskette' screen.

 

I didn't include any special docs, you would need to use a hex editor to look at my changes, but maybe it's interesting. It's not UberGROM specific so should work in anything that supports bases.

 

multicarttest.zip

[ckoba]

Plato also runs only in GROM 0, so I patched that, but it is patched only as far as the 'load diskette' screen.

That is this change in the Plato ROM, yes?

 

-000000f0 d8 00 9c 02 06 c0 d8 00 9c 02 06 c0 dc 60 98 00 |.............`..|

+000000f0 d8 00 9c 02 06 c0 d8 00 9c 02 06 c0 dc 60 98 10 |.............`..|

 

(i.e., "dc 60 98 10" instead of "dc 60 98 00")

 

Am I correct in thinking that this sort of bank dependency is caused by the ROM needing to pass control back over to the GROM, and thus needs to know the GROM base address?

 

What, in general (or in specific) should I be looking for when I'm stomping out GROM0 assumptions? "xx 60 yy 00", with xx and yy being (I assume) register load instructions? Was there a "TI standard" way to do this?

 

(I *need* to learn TMS9900 assembly, I think. I'm looking at Logo-II, which also wants to be at GROM0, and I think this is going to be a widespread issue with GROM/ROM combo cartridges)

 

Edit: "98 00" and "98 10". I'm not very swift today.

Edited January 28, 2016 by ckoba

[+mizapf]

Plato is a weird cartridge in that it's GROM header already starts at >7800 (it's one of the rare TI 8k GROMs, I guess),

 

In MESS I had to assign the cartridge type "gromemu" to Plato to make it run. Without ever having a look into the real cartridge, I suppose it has some GROM emulation by normal ROM and a logic circuit. Apart from that, I never saw real 8K GROMs in a 16-pin package.

[ckoba]

In MESS I had to assign the cartridge type "gromemu" to Plato to make it run. Without ever having a look into the real cartridge, I suppose it has some GROM emulation by normal ROM and a logic circuit. Apart from that, I never saw real 8K GROMs in a 16-pin package.

I think, but cannot prove (because I don't have a Plato module and no easy way to obtain one), that it (and other "autostart cartridges") didn't originally have anything at >7800. I think they were using some weird trampoline logic to transfer control to the ROM.

 

I think this because the GRAM Kracker module has explicit instructions on making the Plato cartridge compatible with it, and it involves relocating the header from >6000 to >7800. Unfortunately, whoever did this procedure on the dump I (and probably you) was/were working filled the original bits (plus more) at >6000 with FF, so there's no way that I can see to reverse the procedure.

 

Summary: I don't think it's an 8k GRAM or GRAM-alike, I think it's not a pristine cartridge dump, and that's why you had to specially assign it in MESS. That's just a WAG.

[Tursi]

That is this change in the Plato ROM, yes?

 

-000000f0 d8 00 9c 02 06 c0 d8 00 9c 02 06 c0 dc 60 98 00 |.............`..|

+000000f0 d8 00 9c 02 06 c0 d8 00 9c 02 06 c0 dc 60 98 10 |.............`..|

 

(i.e., "dc 60 98 10" instead of "dc 60 98 00")

That's correct... base 0 is at 9800, 1 at 9804, 2 at 9808, etc. Only the read data port needs to be patched, as the GROM address is global across the system (because of incomplete decoding on the console GROMs)

 

Am I correct in thinking that this sort of bank dependency is caused by the ROM needing to pass control back over to the GROM, and thus needs to know the GROM base address?

It's related to that, but it's not mandatory. The ROM code could do the same as GROM does and just look at/preserve the GROM base in R13, but it doesn't tend to. The bases feature never officially got supported, so developers were not required to support it. Frankly, if it wasn't left in the console BIOS I doubt any of us would have thought of it.

 

What, in general (or in specific) should I be looking for when I'm stomping out GROM0 assumptions? "xx 60 yy 00", with xx and yy being (I assume) register load instructions? Was there a "TI standard" way to do this?

You have to use an emulator and breakpoint on reads from >9800 (in Classic99 that's set as "<9800"). Since the read could be using absolute addresses or it could be using a register, and could use a number of opcodes, there's nothing you can look for byte-wise.

 

If it's using a register, then you will need to dig deeper to see the patch. The hits in RPI and that one in Plato were absolute addresses, at least, so easier.

 

Note, too, that after my patch, they ONLY work at the new base I selected. I didn't make them generic.

 

>(I *need* to learn TMS9900 assembly, I think. I'm looking at Logo-II, which also wants to be at GROM0, and I think this I

>s going to be a widespread issue with GROM/ROM combo cartridges)

 

Yes, it will. I think there are better ways to spend time than patching ROMs for multicarts though. Do one for the fun of it and just don't worry about the wasted ROM afterwards. Bytes are cheap these days!

[ckoba]

Yes, it will. I think there are better ways to spend time than patching ROMs for multicarts though. Do one for the fun of it and just don't worry about the wasted ROM afterwards. Bytes are cheap these days!

Yeah, you're right. I seem to be having difficulty adjusting to a post-Apple-Chinese-factory mindset ... "Need to squeeze every byte out of this new routine, dammit, because we don't have enough NAND for the OS on the N94!" "But, sir, we're EOLing the N94 next quarter, right?" "You forgot about the refurb lines at (redacted factory in Pudong), idiot!"

 

(sorry, slight rant over)

[+mizapf]

Summary: I don't think it's an 8k GRAM or GRAM-alike, I think it's not a pristine cartridge dump, and that's why you had to specially assign it in MESS.

 

You may be right. That is sad, at least from my MESS view, because we want to keep pristine dumps, not tailored ones. Maybe someone with a Navarone Widget and the Plato cartridge can try to re-dump it?

Edited January 28, 2016 by mizapf

[+arcadeshopper]

 

You may be right. That is sad, at least from my MESS view, because we want to keep pristine dumps, not tailored ones. Maybe someone with a Navarone Widget and the Plato cartridge can try to re-dump it?

 

I can probably do this, I "think" I have a plato cart.. will doublecheck this weekend.

 

Greg

[ckoba]

I can probably do this, I "think" I have a plato cart.. will doublecheck this weekend.

 

Greg

I've got one coming in eventually from eBay ... if you can't find yours, I'll try the Navarone Widget method with it.