Hi everyone. Not so long ago, I began to study this infamous multicard. It turned out that all the games in it have a standard
PRG weight -
32 kilobytes (except of The Cheetahmen and Billy Bob).
Unfortunately, in spite of the low weight of these games code, extract all of the game from the collection could not be without problems. Games such as Ooze, Chill Out, Bits and Pieces and some others refused to work as it should, or start up a completely different game.
Each of the games from
Action 52 can be found in these bytes:
4C 12 80 EA EA EA 4C.
But again, some of them do not work properly and become unstable. Please help me with this problem (I collect rare rums, and it is especially important to me).
P. S .: Also I've been looking for a ROM of "The Cheetahmen - The Creation".
Thank you in advance.
Many of the isolated games from Action 52 don't work at all, even when extracted. You may well need to fix them to get around the egregiously bad code that made it in.
Quote:
found in these bytes
4C 12 80 - Jmp to $8012
EA - NOP
EA - NOP
EA - NOP
4C (## ##) - Jmp to (address omitted)
I have to disagree with your interpretation of these bytes.
If you're ripping these games as individual roms, and they're not working properly, then maybe they rely on the boot loader's initialized state of the system in order to function correctly. And setting them up to run without the boot loader (menu handler code) is the problem.
tomaitheous wrote:
If you're ripping these games as individual roms, and they're not working properly, then maybe they rely on the boot loader's initialized state of the system in order to function correctly. And setting them up to run without the boot loader (menu handler code) is the problem.
Yeah, I understand. But how to do it? I am noob in assembler code.
The game Ooze, taken from the Rev A version, it hangs after passing the second level. Taken with the regular version - after first level.
Quote:
The game Ooze, taken from the Rev A version, it hangs after passing the second level. Taken with the regular version - after first level.
Yep. That's Action 52 for ya. And this was the game (Ooze) that you can win a scholarship with...if you take a picture of the game complete screen...which noone can reach...because it's broken.
dougeff wrote:
Quote:
The game Ooze, taken from the Rev A version, it hangs after passing the second level. Taken with the regular version - after first level.
Yep. That's Action 52 for ya. And this was the game (Ooze) that you can win a scholarship with...if you take a picture of the game complete screen...which noone can reach...because it's broken.
I already reach level 5 and receive a picture.
I only ask, how to fix that damn glitch, and how to fix non-working roms.
lancuster wrote:
I only ask, how to fix that damn glitch
Go back in time and give the programmers of that game more money and more time to finish it so that the final result isn't so shitty.
As for games that work normally but not as standalone ROMs, you might have to write some bootstrap code that initializes registers and RAM the same way the menu does. You'll probably have to do some debugging to find out whether the game fails to initialize any registers or RAM locations it relies on.
lancuster wrote:
I only ask, how to fix that damn glitch, and how to fix non-working roms.
"only"
What you're asking is a very large task. Fixing a game could take hours or days, longer if you need to learn something in the process.
I couldn't tell you how to fix a game without first fixing it myself. There's no way to tutorialize this, it's a different problem every time. What's you're really asking for is for someone to do it for you, and you haven't even been very specific about that.
If you want to learn how to do it, understanding 6502 assembly is a bare minimum. Learn to use
a debugger. Learn to take
trace logs, and read them. Learn to use other tools, write Lua scripts to help visualize what's going on, etc.
In particular, if a game works in the Action 52 ROM, but not once you've extracted it, try to trace them both and compare; see where the two traces become different. In particular, look at how the game reads from RAM and what's different in the RAM it reads from. If you find this is too difficult a task, I'd suggest improving your skills by trying to do something simpler first. Pick a smaller ROM-hacking task and use it to learn, do the Nerdy Nights tutorials, make a small NES program, etc. Don't expect to be able to dive into a broken game and be able to fix it before you can do the easier things, it's work that requires a lot of preparation.
Honestly, it would be easier to program this from scratch than try to figure out and fix. Maybe.
rainwarrior wrote:
"only"
What you're asking is a very large task. Fixing a game could take hours or days, longer if you need to learn something in the process.
I couldn't tell you how to fix a game without first fixing it myself. There's no way to tutorialize this, it's a different problem every time. What's you're really asking for is for someone to do it for you, and you haven't even been very specific about that.
If you want to learn how to do it, understanding 6502 assembly is a bare minimum. Learn to use
a debugger. Learn to take
trace logs, and read them. Learn to use other tools, write Lua scripts to help visualize what's going on, etc.
In particular, if a game works in the Action 52 ROM, but not once you've extracted it, try to trace them both and compare; see where the two traces become different. In particular, look at how the game reads from RAM and what's different in the RAM it reads from. If you find this is too difficult a task, I'd suggest improving your skills by trying to do something simpler first. Pick a smaller ROM-hacking task and use it to learn, do the Nerdy Nights tutorials, make a small NES program, etc. Don't expect to be able to dive into a broken game and be able to fix it before you can do the easier things, it's work that requires a lot of preparation.
How to work with RAM difference? I make RAM dump from multicard and rom, but I have no idea how to embed this differences to standalone rom.
By the way. Here is half-working roms, which compatible only with VirtuaNES. Some of this I had to fix graphic banks (that was easy).
admin edit: removed attachment
Please don't post ROMs of commercial games. Even broken ones from defunct companies. It sets a bad precedent.
I'm still waiting for a response. How to embed the differences in RAM to the game?
Holy shit. Really, dude? Demanding things with under a 24 hour response time?
The answer to this question, and probably most others, is in rainwarrior's post above. This isn't like making a peanut butter and jelly sandwich or putting on your shoes.
If that answer doesn't suffice for you, or you're not up to the task of learning, then your two choices become: a) scour the Internet to find someone to do this for you (hint: given the complexity, likely will require you pay them -- even more so because you're working with a *commercial* game title, i.e. it's a bit shady), or b) bail entirely.
Quote:
In particular, look at how the game reads from RAM and what's different in the RAM it reads from.
I have two RAM dump from the Action 52 and from the game. Differences a bunch. What to do with these differences, where to implement?
Wanna do it the easy way? Log all the RAM and register states from right before the game is called, save all of that into the ROM anywhere you can fit 2K+ bytes (if you can't find that much free space, you can expand the ROM through bankswitching) and hack in a small piece of code to set all the RAM and registers to those logged values.
If you only want to restore what's actually necessary, as opposed to the whole 2K+ bytes, then you'll probably have to do what rainwarrior suggested and compare execution logs, to see when exactly the standalone program behaves differently from the normal version and why, and fix each condition that causes a difference.
tokumaru wrote:
Wanna do it the easy way? Log all the RAM and register states from right before the game is called, save all of that into the ROM anywhere you can fit 2K+ bytes (if you can't find that much free space, you can expand the ROM through bankswitching) and hack in a small piece of code to set all the RAM and registers to those logged values.
If you only want to restore what's actually necessary, as opposed to the whole 2K+ bytes, then you'll probably have to do what rainwarrior suggested and compare execution logs, to see when exactly the standalone program behaves differently from the normal version and why, and fix each condition that causes a difference.
"Log all the RAM"... Mmm... How to do that? I've never done it.
Dump the RAM to a file that you can include as a data table in the ROM. Trace the program until it calls the game in question, and then, with the emulator still paused, dump the RAM to a file.
tokumaru wrote:
Dump the RAM to a file that you can include as a data table in the ROM. Trace the program until it calls the game in question, and then, with the emulator still paused, dump the RAM to a file.
But how I trace a broken rom? It stuck after loading 0 level.
And second. Register... is a $8000-$ffff? How I can find this registers?
It's not a RAM state set by the loader. Ooze erases the entire RAM at the start of the game, except for 700-7ff, which is entirely filled with zeros anyway, and 200-2ff, which is the OAM mirror...and is immediately filled with $f8...so, not that either.
dougeff wrote:
It's not a RAM state set by the loader. Ooze erases the entire RAM at the start of the game, except for 700-7ff, which is entirely filled with zeros anyway, and 200-2ff, which is the OAM mirror...and is immediately filled with $f8...so, not that either.
And if I make a patch with the usual and Rev A version of this game? It in any way clarify the situation?..
I used to rip out games with a hex editor, and even Nesticle would run them fine. Maybe you aren't ripping them correctly.
Dwedit wrote:
I used to rip out games with a hex editor, and even Nesticle would run them fine. Maybe you aren't ripping them correctly.
I'm sure I have correctly rip the games. But some of them work well only in the multicard, and without it - switch to another game. I found the game to these bytes: 4C 12 80 EA EA EA 4C. They are every 8000 bytes. How did you do it and what is tested?
lancuster wrote:
I'm sure I have correctly rip the games. But some of them work well only in the multicard, and without it - switch to another game. I found the game to these bytes: 4C 12 80 EA EA EA 4C. They are every 8000 bytes. How did you do it and what is tested?
You've already said this, and it's
already been debunked.
Quote:
You've already said this, and it's already been debunked.
What??? How about the fact that this is the beginning of each game in the multicard?
I think others are claiming that the mere "fact that this is the beginning of each game in the multicard" is by itself irrelevant.
Side note: Anybody else tried playing a52 on a pal unit? it loads incorrecly all over. It's a short-lived amusement.
I played European version. Almost the same thing, but with non-working Alfredo and Jigsaw.
dougeff wrote:
It's not a RAM state set by the loader. Ooze erases the entire RAM at the start of the game, except for 700-7ff, which is entirely filled with zeros anyway, and 200-2ff, which is the OAM mirror...and is immediately filled with $f8...so, not that either.
I found a way out. It turns out that it was necessary to replace D0 19 with D0 16 in the Rev A version of the game. ROM no longer freezes after the second level, but is interrupted after level 6 by a congratulatory message, and level 8 is unavailable without a serious hacking.
And in Bubblgum Rosy it was necessary to replace 8D 38 03 with AD 38 03 at address 117, so that after losing at level 2 there was no incorrect loading of data.