[justin3009]

So THIS might be one of those cases where I believe it's actually an incompatibility with the game and the CX4 chip, it's what I'm assuming anyway.

Setting the header at 00:FFD5 to be 30 instead of 20 will set the game to be 'FastROM'. Upon doing so, it seems that HDMA and sprites all just break in every possible way. Mainly because the sprites, HDMA and various other wireframe objects all use the CX4 chip to operate. Though I'm entirely unsure why the header change would completely destroy the entire thing since it's still loading the same locations technically at this point, but it seems anything CX4 wise is just broken.

There's not much research on the CX4 chip, and whatever there is is way beyond my head at the moment as I don't think I can really trace anything that's really going on with it. It's all very strange at this point. There could be a feasible work around with sprites by having an actual OAM table in RAM like other games but no clue how to work around it with HDMA and such though.

Anyone have an idea on this area? I'm willing to bet it's a chip compatibility issue but I can't be absolutely sure.

Edit: I've noticed something odd when it's set to FastROM.

Code: [Select]

$05/F8C3 AD 52 7F    LDA $7F52  [$06:7F52]   A:0101 X:0000 Y:0010 P:envMxdIzC
$05/F8C6 CD 8F 08    CMP $088F  [$06:088F]   A:0100 X:0000 Y:0010 P:envMxdIZC
- Good set of code when it's NOT FastROM.

Code: [Select]

$05/F8C3 AD 52 7F    LDA $7F52  [$06:7F52]   A:0101 X:0000 Y:0010 P:envMxdIzC
$05/F8C6 CD 8F 08    CMP $088F  [$06:088F]   A:017F X:0000 Y:0010 P:envMxdIzC
- Bad set of code when it IS FastROM. It seems like whenever it's set to FastROM, it will read that last byte in the LDA as the value it needs to load.. for some reason. It's strange as heck.

Edit: Able to view the CX4 RAM in BSNES. Once it's switched to FastROM, it definitely freaks the hell out horrendously in the CX4 chip RAM. I have NO idea why this would even occur. This is really strange.

[rainponcho]

When you flip FastROM flag, emulator identifies cartridge as plain LoROM/FastROM + no CX4 chip.

Emulators are locked to use SlowROM only for CX4. I'm assuming because no official FastROM CX4 board exists? Bummer.

Code: [Select]

https://github.com/devinacker/bsnes-plus/blob/c36e59a39f61de23c648e1371bb32fb9662a7d66/snesfilter/nall/snes/info.hpp

if(mapperid == 0x20 && rom_type == 0xf3) {
has_cx4 = true;
}


Code: [Select]

https://github.com/snes9xgit/snes9x/blob/master/memmap.cpp

// C4
case 0xF320:
Settings.C4 = TRUE;
break;


[justin3009]

Damn, it was worth a shot at least. Thank you for the heads up on that! Saved me a lot of grief.

[rainponcho]

Maybe you could petition someone to make a FastRom homebrew CX4 board. And/or get emulator devs to support the feature. I'm sure MMX hackers would put speedup to pretty good use.

[justin3009]

Someone was able to modify bsnes+ to enable FastROM and CX4. Turns out it works just fine then! Only problem is pretty much what was stated above. Pretty sure most, if not all, emulators have a hard check for the ROM Type and the CX4 so they'd all have to modify their code to allow for FastROM to work. But it DOES work apparently and it boasts quite a nice performance increase too.

Most of them are open source and it's a very minor source change. Just have to find where it checks CX4 and where it's '20' just do 20 || 30 so it reads both.

[Revenant]

crosspost

(I saw your RHDN thread about this earlier, but I wasn't logged in at work so I didn't reply)

You can enable FastROM without modifying the mapping bits in the header, as long as you still set $420D and use addresses above $800000. The SNES doesn't actually know or care what the contents of the cartridge header are (unless you count the interrupt vectors as being part of the header).

The specific check for $20 when detecting the Cx4 is just a heuristic that bsnes (and possibly other emulators) use to make sure it doesn't get falsely detected for ROMs that don't actually use it. I could modify said check to support $30 as well, but trying that might make it inconsistent with other emulators. It's probably better to just play it safe and keep the values the same as the original games.

[justin3009]

Oh, well damn that's REALLY handy then! Thank you for clearing that up! Confirmed and it does work. This'll help a bit in the long run!

[Lenophis]

The specific check for $20 when detecting the Cx4 is just a heuristic that bsnes (and possibly other emulators) use to make sure it doesn't get falsely detected for ROMs that don't actually use it. I could modify said check to support $30 as well, but trying that might make it inconsistent with other emulators.

Why would the state of other emulators even matter? Why bring it up at all? It's irrelevant. It's up to them to keep up with the times. Not your responsibility to abide their laziness.


You just don't want to do it.

[zfreeman]

Dude, he was deciding that if there's no means to play the ROM hack, would it be worth the effort. Leave your reverse psychology at home.

[tc]

Why would the state of other emulators even matter? Why bring it up at all? It's irrelevant. It's up to them to keep up with the times. Not your responsibility to abide their laziness.


You just don't want to do it.

We're overdue for the hacks used by less accurate emulators to be exposed and explained in a way laypeople can understand.

[slidelljohn]

justin3009:

I have been curious about your progress on this. Were you able to convert mmx3 to fastrom? I always assumed x2 and x3 were fastrom since x1 is. I'm curious about this because I developed some tools to convert gradius 3 to fastrom and I don't think it would take much to alter my tools for them to work on x2 and x3. I have a fully functioning gradius 3 fastrom. It still doesn't speed everything up but it does make a noticeable difference. I'm actually in the process of adding sa-1 to gradius 3 and so far so good but there is still a long way to go. For my tools to work I use text files of the disassembled
assembly data just like how it looks when you disassemble the assembly data in giegers debugger. I have gradius 3 fully disassembled into text files and with the push of a button it changes hundreds of all of the jumps and loads to the rom area below 80:0000 to 80:0000 and up for fast rom access.
Disassembling a rom is actually easy to do it's just time consuming because you have to separate the code from the data.

[justin3009]

Yep, I got it to work no problem.

MMX1 is FastROM but X2 and X3 I believe weren't. It helps incredibly with some of the lag issues, but can't fix them all of course. But it's super nice. I still need to fully implement that on the V4.0 release.

[slidelljohn]

Awesome! Were all of the addresses already 80:0000 and up or did you have to convert them yourself? And do you know if it works on sd2snes?

[justin3009]

I'm not sure if it works on SD2SNES but yes, all the addresses I had to convert into $80:0000+. I missed a bunch I'm sure when it comes to various LDA,x instances and stuff but the main code is read just fine as $80+

[Lenophis]

If you are still looking for an SD2SNES test, I will volunteer. I'll even stream it and upload to Youtube for VOD purposes for ya.

[slidelljohn]

I also have a sd2snes to test it on. I'm actually also curious about the 80+ addresses. I could look through the code and see if anything else needs to be changed. I could even write a QT program to simply the process of converting games like this one to fastrom. I'm sure x2 could use a fastrom boost. Any idea of when you might release this or could you let us test it out?

[justin3009]

It'll be awhile still. Got a lot of bugs to kink out and some things to add before I'm able to release a steady beta.