[MojoDodo]

WIP - Patch to add color and level select to Alleyway.

I wanted to do my first patch colorizing something easy.
I figured Alleyway would be a good target. It all fits into 32k rom, and there was plenty of empty space available to play in.

I've learned a lot, getting to grips with asm, .sym files, bgb, beaten dying moon, yy-chr and many others.
 
the rom has been changed to work with GBC only, because I was sloppy with changes at the start of the project.

• Add level select on title screen with a/b
• Colored and rearranged title and win screen
• All bonus levels have custom coloring

I haven't had a chance to test this on a real gbc yet, so if someone wants to take a look and let me know any issues etc, that would be great.

I've got a few more items on my todo list, but I figured it is a good time to get some feedback.

Here is a 6 day link to the .ips file
https://filebin.net/qkoo689udva7yz1s

[kkzero]

Hi, I gave this hack a run on my Everdrive. It works just as fine on hardware as it does on emulator, no real concerns there.

Other things to note:

• Split-second gfx garbage when gameplay loads after title screen.
• Maybe add more contrast between the light and mid tones of some of the palettes, in particular I found the green palette to be a bit too saturated.
• If you decide to do the above, maybe color in the Nintendo logo banner on the "Nice Play!" screen.
• If you're doing GBC-only, add some sort of lockout mechanism for pre-GBC systems. You could start by checking register a at startup, then avoiding the game boot sequence if pre-GBC (if a is not $11). Then maybe load the gfx and tilemap for a fancy "This can only be played on GBC" screen.

This is looking to be a pretty good colorization though! I feel it could easily replace the original.

[MojoDodo]

Thanks, all good points!

[Ok Impala!]

Just tested it. This looks mighty impressive!

As for improvement points:
- The green is indeed a bit too saturated. The border now blends into the core color.
- The purple background didn't seem to fit well with the other colors. I don't know exactly what it is, but it feels a bit "off".

But overall it looks really good. So keep at it! 

I'd like to get in contact with you both about Color hacking of B/W GB games. I'm currently working on a hack for Final Fantasy Adventure, a game that would enormously improve with colors added. I'll send you a PM about this. 

[Titney]

Tried it on a real, unmodified GBC and I love it! The colors really pop.

Contrary to the previous two comments the green does not look too saturated to me (maybe a bit too light rather) but the lack of a clear, darker outline on the green and purple bricks does make them a bit low contrast and hard to see against the background.

Two unfiltered daylight photos to show what I mean:
https://i.imgur.com/ghYKUtK.png
https://i.imgur.com/90gFpE9.png

That is a minor quibble though, and already this hack is good enough that I'd rather play this over the original. Thanks and keep up the good work!

[ProstatePunch]

Yay! Love more color hacks for the GB.

Do you plan on posting this to the main site?

[MojoDodo]

Yay! Love more color hacks for the GB.

Do you plan on posting this to the main site?

Once I get it finished.

I'm adding a high contrast palette switch, and fixing up the visual glitches at the moment.

Thinking about adding some custom block coloring on the regular levels, etc etc.

[MojoDodo]

Ok, I think I'm done with this hack.

link to 6 day copy of ips for anyone who can't wait until it gets added to the main list of romhacks
https://filebin.net/fnqp7sj78ncboy83

This hack includes:

• All Levels have custom colors
• Ending screen has custom colors
• Select start stage with a/b buttons on title screen
• Change color palettes and hi/low contrast blocks with select button on title screen
• Plays ok on DMG, but title and win screen look a bit crap
• Scores can now show 5 digits, and max score is now 65535
• High score saving
• Mario head for lives looks nicer
• fixed bug from original game where if you die as a small paddle on the far right, your next paddle started stuck in the wall
• demo takes twice as long before it starts, so there is more time to select start level

[lilpuddy31]

Hey Mojo, I just tried the patch you just posted, using the MGBA core in RetroArch, the game locks up at the GBC bios screen

[MojoDodo]

Thank you for reporting this.

The .ips I posted had crc errors in the rom header. Those are fixed in the submitted patch, but even then, the game is running but looks messed up in MGBA.

Looks like I'm not quite done!

Hey Mojo, I just tried the patch you just posted, using the MGBA core in RetroArch, the game locks up at the GBC bios screen

[Satoshi_Matrix]

PLease post some screenshots. I'd love to see what this looks like. I actually played a lot of Alleyway when I was a kid.

[j0nas]

Great job, very well done! 

Thanks for including the .SYM file, this is very interesting to see.

Is there any chance you release the full source code? That would be very much appreciated.

[ProstatePunch]

PLease post some screenshots. I'd love to see what this looks like. I actually played a lot of Alleyway when I was a kid.

Hey Satoshi,

Mojo posted the v1 of this patch already, and there's 4 screenshots: https://www.romhacking.net/hacks/6510/

[MojoDodo]

jOnas - Here is a copy of my scratch.txt file, where I would sometimes write code and data before copying it into bgb. It is all just a bunch of random code or data, but later in the work I started to note down where in the rom I was putting the bits of data etc.

https://filebin.net/944p14o5b6padq9j

I'll also include it in the zip with the next bugfix patch when it is ready.


The map color data, as well as the title screen and win screen is in a format where you specify chucks of data.
each chunk has 2 bytes of address (where the data starts getting written), then 1 byte that has write type and number of bytes, and then the actual data.

For the type / number bytes if the x40 bit is set, then every byte is written the same. if the 0x40 bit isn't set, then you need to specify every byte.

ie, the // nice play below is starting at 9842, write 0xA bytes as 0x02. that will be used somewhere to set the color data for the nice play text on screen to palette 2, which is yellow/gold.

the green laurels line 9884 08 0303070707070303
means at 9884, write x08 bytes with 03 03 07 07 07 07 03 03 as the values.

Then the processing stops if the next byte after a chunk is a 00.

Last time I looked at the code that processes the chunks, it looks like there is also an option to write vertical lines of data on the map as well, but that isn't used as far as I could tell. I could have used it with the color data, so it is a pain I didn't see it before I did all the color maps.

If you have any other questions, feel free to ask.

[j0nas]

Thanks MojoDodo, this is very helpful! 

So, if I understand your workflow correctly, you use BGB's debugger as your main tool and inject your code there. Is that right? I actually expected you would use RGBDS (or something similar) to assemble your code and then insert it into the original ROM with the linker. But maybe it's easier to do it your way.

If you have any other questions, feel free to ask.

Thanks! Maybe it sounds a bit naive (I have quite some Game Boy coding experience but never really changed an existing ROM). You mentioned:

It all fits into 32k rom, and there was plenty of empty space available to play in.

How do you locate the "empty" parts of the ROM? I found the execution profiler in BGB that might help to identify the parts of the ROM that contain code. But I didn't see a data logger that would allow to separate the data (like tiles, maps, music etc.) from the sections that are actually unused. How can you be sure that you don't touch anything important?

[MojoDodo]

In terms of disassembling or just hacking in code on the fly, I'm pretty sure disassembling, spending time reverse engineering everything before starting to make changes is easier and better in the long run. I just wanted to hack away like a lazy guy though, I get enough proper programming in my day job.

To find unused space, I'd just look for areas that were all ff or zero in either the memory browser or in yy-char, and put code in them. I guess it might be possible for a rom to have some big area of blank space that was being used for something (maybe a pause in some uncompressed music), but I didn't seem to hit any.

Open up Alleyway & bubble ghost in yy-char, and you will see what I mean pretty quickly about alleyway having lots of space. In reality, since hw costs aren't an issue, you can just change to a bigger mbc and rom, but keeping to the 32k size of the original is a fun extra challenge.

Sometimes before starting to use some memory location in ram for a new variable, I would put a write breakpoint on it and play for a while to check if it was being used.

[j0nas]

To find unused space, I'd just look for areas that were all ff or zero in either the memory browser or in yy-char, and put code in them. I guess it might be possible for a rom to have some big area of blank space that was being used for something (maybe a pause in some uncompressed music), but I didn't seem to hit any.

Open up Alleyway & bubble ghost in yy-char, and you will see what I mean pretty quickly about alleyway having lots of space.

Ok, thanks! Looking at Alleyway, I know exactly what you mean. Unfortunately, the ROM I had in mind for my own hack doesn't contain such spaces and you just don't know if you're looking at code, data or junk.

In reality, since hw costs aren't an issue, you can just change to a bigger mbc and rom, but keeping to the 32k size of the original is a fun extra challenge.

That's more difficult than it seems. Take a look at the Game Boy memory map:



In a ROM that is larger than 32KB, only the code in ROM bank 0 (16KB located at $0150 to $3FFF) is always present. If you add an additional ROM bank, it must be switched in before you access it (in the 16KB area from $4000 to $7FFF). It will then replace whatever other ROM bank was switched in before. Consequently, you can only jump to the custom code if the calling routine is located in ROM bank 0. And the custom code running in the additional ROM bank won't have access anything located in the other ROM banks (except ROM bank 0).

The only idea that came to my mind would be:

• Use a cartridge type that has additional ROM banks for the custom code and additional external RAM. Adding the additional RAM will grant access to the area from $A000 to $BFFF. That precious 8KB area should always be accessible and be reliably unused.
• Change the game's startup routine and switch in the additional ROM bank that contains the custom code.
• Copy the custom code to the external cartridge RAM.
• Switch back to the ROM bank the game expects to be present and continue with normal code execution. To access the custom code, jump to its location in RAM.

But that seems like an insane workaround. There must be a better way... 

I get enough proper programming in my day job.

That comment made my day. 

[verme]

Hi everyone, first of all, I'm sorry if this isn't the right place to post this question.
From what I can tell, the process of coloring an original Gameboy game requires a lot of work. so I was wondering if it would be possible to just change the rom header to GBC, and set the background and sprites palettes. I've seen some pirated cartridges that do this, and there was also an old "bunge" flashcart where you could do this. the question is how?

[MojoDodo]

J0nas - You want to use a trampoline function in bank 0.

For one of my homebrew games I used one that takes 2 parameters, the bank # and address of the fn you want to call. It:

• reads the current bank
• pushes that onto the stack
• changes to the requested bank
• calls the requested fn
• when it returns it pop the original bank and switches back to that, then returns

I've also seen similar fns that take a position into a jump table. So you call the Bank9Trampoline with 12, and then it switches to bank 9, and looks in the jump table at the start of bank 9 for the address of fn 12 and calls that.

If you need to make some space, hopefully there are some graphics you can move from bank 0 to somewhere else, otherwise you are stuck moving code around 

verme - Check out gb colorizer https://www.romhacking.net/utilities/30/. It changs the header and injects code to setup the palettes for the background and sprites. I don't think it works for every game, but maybe it will get you started.
January 21, 2022, 04:59:26 pm - (Auto Merged - Double Posts are not allowed before 7 days.)Also check out Beaten Dying Moon https://mattcurrie.com/bdm-demo/

It is an online gb emulator that you can play, and it will create sym file with areas of data and code that are touched during play.

[j0nas]

For one of my homebrew games I used one that takes 2 parameters, the bank # and address of the fn you want to call. It:

reads the current bank
pushes that onto the stack
changes to the requested bank
calls the requested fn
when it returns it pop the original bank and switches back to that, then returns

Neat trick! I didn't realize. That should only require a minimum amount of free space in bank 0. Where do you learn this kind of stuff?

The only downside would be that the routine in the added ROM bank doesn't have access to the data in the ROM bank that was originally switched in. But that's probably not much of an issue, as you could put a copy of that data in the added ROM bank.

so I was wondering if it would be possible to just change the rom header to GBC, and set the background and sprites palettes.

The problem with that approach is that you have to set up all the values in the startup routine and can't change them later on. You can do it that way, but it won't look good. If you want to colorize a game properly, you have to change values at runtime.