Problem Expanding Super Monaco GP

[TAMarcosTranslations]

Hi all,

First of all I would like to thank Mr. Kaneda for letting me to be part of this community.

My name is Marcos, I am Spanish and I am "working" on this since 2018. Sorry if my English is not great. I am currently working on an ultimate version of Super Monaco GP. In this case it's about the legendary 1992 season. I am trying to improve drivers' portraits as much as I can, visually improving fonts, menus, cars and tracks. Also, I had the idea of creating new tracks such as Kyalami, Paul Ricard or Jerez, but in this very moment I don't know how to proceed. This is not the problem.

So, I am having a hard time expanding Super Monaco GP. Let me explain:

- ROM has Nemesis compression and just weigh after compression 512kb.
- As I explained above, I am improving the quality of the drivers' portraits among other files, respecting the compression, and mostly I get a heavier file compared with original files. Space is very limited, so if I insert a larger file I will overwrite part of the next file and of course, that part will be bogus.
- Hence, I had the "brilliant" idea of expanding the ROM. The limit of Super Monaco GP is 007FFFFF. I manually expanded to 1mb size -00FFFFFF- as the second game, Ayrton Senna's Super Monaco (This romhack is very based on this second part, nonetheless).
- After expanding the rom and inserting some files in new areas, I rewrote their pointers.
- I test on Kega Fusion and ROM works perfectly. No issues at all.
- The problem becomes a pain in the a** when friends of mine tested the ROM in real hardware and other emulators. Game works, but there is a black screen specifically where I inserted data in newest areas.

I read as much as I can, I analysed the ROM everywhere and I don't have a clue what's wrong.
Why does Fusion read these areas of the ROM and respect every change, but not the real hardware and other realistic emulators?
Is there any solution to this?

Thanks in advance.

Best,



TA Marcos Translations

[Kanon]

Not a clue as to what is wrong, I'm doing something similar with a different game and I don't have that kind of problems, and I can't think of a reason. All I can say is: Use Exodus and start debugging.

[danibus]

Don't trust in emulators. I use KFusion and GensKmod every day, but they are just for "play", use Blast'em (more "real") or just test in Real Hardware.

[Gigasoft]

Did you also update the ROM size field in the ROM header at offset 1a4h?

[Eke]

My bet is that you are triggering an address error exception (which is not emulated in Kega Fusion) because some of the pointers you changed now points to a misaligned address, which would cause the CPU to crash on real hardware (and most recent emulators).

You have to make sure any data you are adding and accessing as 16-bit or 32-bit word is stored at an even address (0x80002 for example and not 0x80001 or 0x80003).

[TAMarcosTranslations]

Not a clue as to what is wrong, I'm doing something similar with a different game and I don't have that kind of problems, and I can't think of a reason. All I can say is: Use Exodus and start debugging.

Smart solution. I will check what's wrong with the registers. I am pretty sure that real hardware and other emulators re-address when they check there are odd addresses rewritten. Or maybe I "invaded" a reserved area for the RAM. I don't know yet.

Don't trust in emulators. I use KFusion and GensKmod every day, but they are just for "play", use Blast'em (more "real") or just test in Real Hardware.

I also use Regen, which is very realistic.

My bet is that you are triggering an address error exception (which is not emulated in Kega Fusion) because some of the pointers you changed now points to a misaligned address, which would cause the CPU to crash on real hardware (and most recent emulators).

You have to make sure any data you are adding and accessing as 16-bit or 32-bit word is stored at an even address (0x80002 for example and not 0x80001 or 0x80003).

Every single address that I rewrote is an even address (last digit is always 0):
0x80000
0x802E0
0x80700
0x80B50
0x80FC0
0x81480
0x818F0
0x81CA0
0x82100
0x82610

Thanks for your answers. I am still looking for what it is causing this.

[TAMarcosTranslations]

Did you also update the ROM size field in the ROM header at offset 1a4h?

Yes, I did. As far as I know, real hardware and emulators ignore that information, no matter the ending address you write. Also, FixChecksum corrects this information of the ROM Header.

[TAMarcosTranslations]

I have just checked 68000 debugger in the part of the game where I get a black screen and I got the following information:



https://imgur.com/rbob40l

As you can check, registers A0, A1, A5 and A6, are reserved for RAM areas, meanwhile in my romhack they are using ROM areas. Any solution?

Thanks

[Gigasoft]

The register dumps are taken at different times and are therefore barely useful. Looks like it crashes somewhere around ED1Eh. You need to inspect the stack to find the exact location where it crashed.

[Miquel]

"PC=200" ? That sounds like an exception. Notice that A6 is an odd address in the rom hack.

Al you said points to an misaligned address.