Glitch City Laboratories Archives

Glitch City Laboratories closed on 1 September 2020 (announcement). This is an archived copy of a thread from Glitch City Laboratories Forums.

You can join Glitch City Research Institute to ask questions or discuss current developments.

You may also download the archive of this forum in .tar.gz, .sql.gz, or .sqlite.gz formats.

Generation I Glitch Discussion

[Concept]Patching ROM On-The-Fly using ACE - Page 1

[Concept]Patching ROM On-The-Fly using ACE

Posted by: Parzival
Date: 2017-05-20 17:33:23
On the Discord server, I had a thought while fucking around with SmashStack which may prove very interesting if it can be pulled off: "Can we patch ROM on-the-fly with a middleman?"
Now, this sounds fucking impossible, because of things like "ROM is read-only" and "you sound fucking insane, what the hell is SmashStack and why is this post nowhere near properly worded?", but hear me out.
There's some homebrew that most people use with SmashStack, and it's called Riivolution. When the disc is accessed to load data, Riivolution intercepts this call, loads the data to unused RAM, patches it, then puts the modified data where it needs to be. We could do this with Pokemon Yellow. In GBc mode, the game does fucking nothing half the time because it only needs 4Mhz, and the double speed of the GBC fucks with it. This solves multiple problems we'd face, namely "this would slow the game down" and "we can't easily interrupt the game's path of execution and throw data everywhere without fucking shit up". BECAUSE the game's doing nothing, it doesn't matter what we do, as long as we're back in the game's normal operation when it comes time to actually do something. Of course, with ACE, we can influence what "normal" is, which means we could copy the next bits of code needed from ROM to RAM, patch it, then run it, effectively being able to bend the game to our will by copying and patching more code after running the previous batch. We could merely allocate a certain amount of space in, say, SRAM, write code to the allocated space, then put the loop that writes and patches the next batch right after it. Of course, jumps, interrupts and the like will screw with it, but I'll bet my soul that there's a way around that.

Thanks for listening to me shout my insanity at you for like 20 minutes. Do you think this is possible? We've done some amazing shit, but if we can pull this off we can all ascend into godhood, so it's worth a shot, right?

Re: [Concept]Patching ROM On-The-Fly using ACE

Posted by: Caveat
Date: 2017-05-20 17:44:08
If we can wield this thing and use it to execute arbitrary code IN OTHER GAMES, I think this just might be possible!

Re: [Concept]Patching ROM On-The-Fly using ACE

Posted by: ISSOtm
Date: 2017-05-20 20:05:30

If we can wield this thing and use it to execute arbitrary code IN OTHER GAMES, I think this just might be possible!

And then this comes into play ! :D

Re: [Concept]Patching ROM On-The-Fly using ACE

Posted by: Caveat
Date: 2017-05-20 20:45:39
That's what I meant!

If we have the power to transplant code into other games, I think we could modify ROM…

Re: [Concept]Patching ROM On-The-Fly using ACE

Posted by: ISSOtm
Date: 2017-05-21 04:52:58
I just took the time to read the first post - it was 4am yesterday, don't blame me - and I'll share my thoughts.

First, modifying code would be hugely difficult, namely because of all the branching that would have to be patched. Doing this would be very time-consuming, and even double-speed mode would make it very difficult. Imagine, you'd have to turn all branching operations into something else, BUT you can't just look for the corresponding bytes, because they could be operands.

Second problem is, the game may spend most of its time doing nothing - that's actually good programming practice, it saves battery - it's not always the case. Watch the CPU activity meter in BGB, and you'll see sometimes it's full.

Third : the GB's memory is too small to be able to run code like that. Patching data reads is possibly feasible, but not code. "But the GBC has much more memory !" Yes, but it's banked. Meaning, if the code we run is in WRAM bank, say, 2, the data is in bank 1. And while there is unused memory in bank 1 (DEE2-DFA0~B0  <- DF00-DFFE is stack space, but the stack never goes past DFA0 unless using 9F) it's small. 128 bytes isn't enough in my opinion.

Fourth : interrupts. The VBlank interrupt uses WRAM bank 1, so we would have to disable the VBlank interrupt, eventually switch to bank 1 and wait for it.
This does imply patching all functions that wait for VBlank.


Here's my idea, which is somewhat a lighter version of this :
- Copy the modified versions of the routines at start-up in WRAM, including the overworld loop
- Have a loader in SRAM (probably bank 0) that provides functions to read and write to WRAM bank 1 (since code isn't in bank 1)
To know what to copy, we'd need an external storage, right ? Here are my solutions :
- Have a table transferred by serial cable from a cartridge whose SRAM is dedicated to that
- Save such a table in our own SRAM ; I'm not sure if that is really feasible, but for example we could remove the Hall of Fame functionalities to benefit from the whole SRAM bank 0.
  Of course, this also means no glitchmon sprites. But we could patch the sprite decompression routine to never overflow.
- Cartswap !


That's what I think of it. Main problem with this is that unlike the Wii, the GB has no "disc read" handlers, no threaded processing, nothing. We are much more limited, so I think your concept isn't possible, but by restricting ourselves it possibly could.

Re: [Concept]Patching ROM On-The-Fly using ACE

Posted by: Parzival
Date: 2017-05-21 08:16:51
While these are all good points, you've missed a few things, probably because I forgot to put them into the above text wall. Prepare for another one. (My bad. :P)

1. I said SRAM, not WRAM. I was intending to use all of bank 1 (or 0, whatever one HoF resides in), so space and VBlank aren't as much of an issue.
2. I know that the game isn't always sitting on its ass doing nothing, but it still does so A LOT. Like, an insane amount for a GBC game. There's still plenty of time for us to shit out new code.
3. I was thinking about the branching problem, and we could make a modification table somewhere in SRAM that would run as part of the copy routine to make sure we get the right code. For code that isn't modified, we can reuse at least some of it (y'know, anything with a RET at the end) and keep ACE.

Re: [Concept]Patching ROM On-The-Fly using ACE

Posted by: ISSOtm
Date: 2017-05-22 13:05:10
You can't use all of bank 0. Right before HoF are sprite decompression buffers.
And they take a fair share of that SRAM bank.
Maybe you can store some extra code, IIRC there are unused memory segments in banks 1 to 3.

Your solution might be a pain to implement. But since I'm not going to try - I've got other things on my schedule lately - I can't tell for sure.

Re: [Concept]Patching ROM On-The-Fly using ACE

Posted by: TheSixthItem
Date: 2017-06-22 07:12:34
This seems very possible but it sounds like a fucking NIGHTMARE to do. I might look into this but I don't know how far I'll get.