This changelog takes the method that North American Yellow Version uses to display super gameboy palettes on the gameboy color, and it then backports it into my hack of red version. Here is a link to the github commit that gives a difference report of all the bare essential changes irrespective of whatever else my hack does. Those that are comfortable with asm and git should be able to follow the report and implement the changes. They are far too extensive to elaborate on in a mere message board post. A lot of the code comes from the pokeyellow disassembly and I have tried to add comments where prudent. It's no DannyE full-color hack, but this one maintains backwards compatibility. Unlike the full-color hack this project allows the game to be played on a regular gameboy or a super gameboy in addition to the GBC and GBA.

EDIT: Here is another link that shows a diff report compared to my baseline branch. It will show all the comprehensive changes as I continue to make improvements after the initial merge.

I wanted to just get that out of the way before dumping a history lesson.

For anyone who has played any of the Gen 1 games (USA version) on virtual console, you may have noticed that red and blue are in grayscale while yellow actually has some rudimentary color. Why is that so? Well it seems to boil down to the virtual console emulating the games as if they were being played on a gameboy color.

You see, red and blue were coded specifically to display some nice coloring when played on the super gameboy. A lot of big gameboy releases in the 90's did. But pop red, blue or japanese yellow into a gameboy color and you get disappointment. The hardware bios will detect the game and, treating it like a grayscale game, will assign a 4-color palette to swap out the grayscale. The fact is that GBC and the SGB are just too different when it comes to handling palettes.

Now back in 1999, Nintendo of America realized they had a problem. You see, pokemon yellow was set to release in north america in October and be on every kid's Christmas list. But the gameboy color had already released in north america the previous November! Kids across the western world already got a GBC for last Christmas, and if they didn't they would get one this Christmas to go with with Yellow version. How's it going to look when they pop the newest Pokemon game into their shiny gameboy "color" to see a crappy 4-tone palette? Not good at all.

So the localizers for Yellow had their job cut out for them. What they succeeded in doing was essentially piggy-backing off the game's SGB functions to hack together an ad-hoc method for converting SGB palettes on the fly into something that the GBC can actually recognize. All new palettes had to be made just for the GBC since the SGB palettes look awful and washed out with the GBC's screen and color mixing. Elegant? No. Effecient? No. Works? Yes!

And so it was that if you fire up a north american Yellow cart in a GBC you get the nice coloring that the games were programmed to display on the SGB. Which then lead to my thinking, could Yellow's hacky solution be back-ported into Red and Blue? It's been a tough few months, but I think I've finally succeeded. I know I'm not the first to attempt this. There are scant random postings on old message boards inquiring about this kind of thing, but nothing has ever really come out of it. So I'm the first to really do it as far as I can tell, and as such I wanted to share the code modifications for all to see and use.

Man, I've been waiting for something like this for so long. I'll give it a try as soon as possible.

I've actually been playing your hack (lite branch) with a few personal modifications for a while. Mainly I used the yellow sprites for both Pokémon and trainers instead of the vanilla ones, but unfortunately some Pokémon sprites appear with some corruption artifacts (Mankey, for example). Do you know what could be causing this issue?

Questions about Shin Pokemon should go into the Shin Pokemon thread. Regardless, you might not have updated the UncompressMonSprite function properly.

I've been trying this out on my almost-vanilla blue rom (the only change was adding the GS beta backsprites) and I got it to work, but have noticed a few graphical glitches. These could totally be because I messed up with copying your code, since there were lines I left out (mainly dealing with statexp, but also I got errors when compiling if I included other lines of code that I forget the names of atm--I can check later as I was planning on restarting from scratch in my attempt to fix this). So basically I'm just wondering if you know off the top of your head what could be causing these:

https://i.imgur.com/R33Cu9m.jpg
-Sometimes using an item and exiting the menu causes these black lines to appear in water.
https://youtu.be/emGLi0chG4Q
-The mons that flash across the screen during the credits sometimes briefly mix with the text that came before them (as shown in the vid with Fearow and Abra @ 10-15secs)

Anyway thanks for all your hard work. This is one of the coolest things to happen to red/blue bc of the whole backwards compatibility thing.

Thanks again!

Glad you like it. Now about your questions.

The black lines are likely caused by something overwriting into the tile memory for the water tiles. I suggest you load up the vram viewer in BGB and see what is getting affected and how to trigger it consistently. That will give you a starting point for narrowing down where the bug is located. Unfortunately I can't really help more than that since I don't know what all you've changed.

The credits look like it has more to do with refresh rate than anything. This probably has to do with your display rather than your code.

Mmm. I'm not sure how much the vram viewer would help since the bug shows up pretty rarely, plus I don't think I'd be able to follow the info it would give me. I'm thinking I'll just try to copy your commit from scratch again and see if I can pinpoint what I did. Can you point me to a vanilla pokered repo that can easily take the changes you made for the yellow GBC palettes? If I use pret, there are several files that don't exist. This would give me an easy control variable to test my romhack against.

As for the credits, it's definitely not my display as it occurs on real hardware as well (GBA SP and GBC) and does NOT occur when I play the rom in SGB mode on my CRT.

If the credits thing only shows up in GBC color mode then it probably has to do with palette refresh. I wonder if it does the same thing. In Yellow. I’ll look into this over the holidays because now I’m curious.

As for an unmodified pokered repository, go to pret and start digging way into the history. You should be able to clone it from a 2018 pull request.

Thank you! I'll get to working on this.

Wanted to follow up on this as I believe I have found and fixed the problem. It all comes down to the way the credit sequence itself is coded. Specifically, it's the way the pokemon silhouettes are scrolled to the left.

This function here in engine\HoF_room_pc.asm does the heavy lifting of the scrolling.
--The "h" register contains the new x-position to scroll to (one 8-pixel tile to the left).
--The "l" register contains a vertical line value (usually 32 or 112).
--rLY is a hardware pointer that tells you which vertical line the LCD Driver is currently drawing.
--rSCX is "Scroll X"; a hardware pointer that lets you load the BG tile map to the screen at an x-coordinate offset.

ScrollCreditsMonLeft_SetSCX:
	ld a, [rLY]
	cp l
	jr nz, ScrollCreditsMonLeft_SetSCX
	ld a, h
	ld [rSCX], a
.loop
	ld a, [rLY]
	cp h
	jr z, .loop
	ret

So what this does is it first waits until the gameboy is drawing a specific vertical line on the screen given by "l". Then it sends the new x-position to scroll to directly to the gameboy hardware. Finally it waits until the first line of the new scroll position is being drawn before returning.

This is very different from the rest of the game engine which usually loads new scroll positions into temporary addresses that are involved in automatic update functions. It's normal to write a new scroll position into an hram address called hSCX and then delay by one frame so the Vblank function updates rSCX automatically. But the director wanted the Pokemon silhouettes to scroll by very fast! Doing it the traditional way with frame delays and/or waiting for the Vblank function would create a very smooth and much slower effect. Doing it directly like this gets the fast scrolling that is desired.

There's just one problem though. Waiting for the desired vertical line to be reached does not stop the gameboy from entering its vblank period. This "vertical blank" period is built into the hardware, and it is a period between drawing the final vertical line of the current frame where data is prepared and transferred before the LCD starts drawing the first line of the next frame. This is where graphics data is normally transferred to the LCD driver so as to prevent split images being drawn to a single frame. Whatever x-position value is stored in hSCX is gets transferred to rSCX every time Vblank is entered; that's once between every frame.

ScrollCreditsMonLeft_SetSCX is not updating the hram value at all. So if you enter Vblank while waiting in the loop, whatever information rSCX had is getting overwritten by the outdated position in hSCX. This results in the strange scrolling artifact you showed. They are stray frames with the wrong scroll value. The solution is to keep hSCX updated with each loop as below.

ScrollCreditsMonLeft_SetSCX:
	ld a, h
	ld [hSCX], a
	ld a, [rLY]
	cp l
	jr nz, ScrollCreditsMonLeft_SetSCX
	ld a, h
	ld [rSCX], a
.loop
	ld a, [rLY]
	cp h
	jr z, .loop
	ret

For some reason, this bug only shows up on the GBC and GBA when running a game in color-mode. I can only speculate as to why the DMG, Poscket, and SGB are unaffected. Retail Red and Blue never showed the issue on a GBC because they run in monochrome-mode, and Yellow doesn't show the issue because the way the credits were handled was rewritten.