Skeetendo

’Cause all games were better on the GBC

You are not logged in.

#101 2012-11-12 07:13:04

Miksy91
Member
Registered: 2010-10-16
Post 1,241/2,346

Re: Pokemon Red: Palettes

Danny-E 33 wrote:

EDIT: So after taking a look at the disassembly, I have no idea where the save routine is.

I located the save routine easily in G/S/C by simply starting to follow the data pointer by pointer from the point where text data for saving is displayed. You could do the same. Debugging "Hall of Fame" works well too.

Last edited by Miksy91 (2012-11-12 07:13:59)

Offline

#102 2012-11-13 16:56:26

Danny-E 33
Administrator
Registered: 2012-06-09
Post 259/1,134

Re: Pokemon Red: Palettes

Danny-E 33 wrote:

And trying to use calls to 0x1922 when exiting the Box list isn't helpful because the same calls are used for both entering and exiting to the previous menu.

Well, since I don't think finding the save routine will help me, since it will never be called if the B button is pressed, I don't think I'm gonna waste the time to find it.

I don't think there will be a problem using calls to 0x1922 again. I found the address which 0x1922 is called when the Box list text box is closed, although I forgot to write that address down. But that won't be a problem, it isn't hard to find again.

Anyway, the same address that calls 0x1922 when the Box list is closed which redraws Bill's PC, is the same address used when 0x1922 is called to draw Bill's PC when Bill's PC is selected from the previous menu. I think I can still include the OW palette change here because this code would be read two time:
When Bill's PC is selected and the OW palette is already correct. This will effectively do nothing, but that shouldn't be a problem.
And it would be read again when the Box list is closed to correct the OW palette when the current palette is the red health bar palette.
There isn't any real problem with this, I think.

Sawakita, do you think there is any way to accomplish this that isn't quite so messy or "hacky"?
I don't particularly like how redundant it is, but it may have to do.

Offline

#103 2012-11-13 22:07:45

Sawakita
Administrator
Registered: 2010-10-16
Post 337/365

Re: Pokemon Red: Palettes

Danny-E 33 wrote:
Sawakita wrote:
Danny-E 33 wrote:

Alright! So the call to 0x1922 that is for the Box list text box is at 1C:796C.
If I changed that call at 1C:796C to:

call $66EA

which is the only free space that remains in bank 1C for me

1c:66ea is not free space. Instead the typical bank ending's free space begins at 1c:7b9d.

1C:66EA used to be in the middle of the palette table. I moved that table to 0x73BA0 which is the free space you are reffering to and expanded it all the way to the end of the bank.

Ah, sorry, I didn't realize that.

Danny-E 33 wrote:

So currently, my very limited free space in bank 1C begins at 1C:66EA.
...

push bc
push hl
ld hl, $66F8
call $5FEB
pop hl
pop bc
call $1922
ret

Well done. Remember, considering there's not so much space in bank 0x1C, that you can replace a call+ret with a jp.

Danny-E 33 wrote:

EDIT: So after taking a look at the disassembly, I have no idea where the save routine is. There's a line in the disassembly that says:

call Predef ; save the game

and that call is to 0x3E6D. But that is certainly not the save routine.

Predef is a redirecting routine, you have to check the preceding instruction (`load a, xx`) to know the ID of the routine that will be called. There used to be a wiki in the disassembly repo, but after moving from hg to git it wasn't ported. Anyway at wiki.iimarck.us you can read my scripting notes under Scripting Reference (kindly ported and formatted by IIMarckus); at the end of it (under «APPENDIX ($3e6d)»), you can find a table of all the pointers, some of which are labeled and commented (I have to admit it's about time to update it :P). Also, in the disassembly repo, inside main.asm, look under «PredefPointers:»: it's the actual 3-byte pointers table of "redirectable" routines.

Danny-E 33 wrote:

I feel like the disassembly may be full of tons of information, but it is just impossible to navigate. I don't know, maybe I'm not doing it right. But any time I've trying looking into it, I've just gotten confused and frustrated cause there's no easy way to find anything I'm looking for. Is there supposed to be an easy way to take advantage of what's in the disassembly?

I usually use my text editor's search function, because the many labels and comments help finding information and location of several already disassembled routines and data. I understand that's not ideal; I can't think of an easy way to improve the "explorability" of the source code, though (well, we should go and add a wiki entry for each aspect and routine, but it would take time).


Danny-E 33 wrote:

Sawakita, do you think there is any way to accomplish this that isn't quite so messy or "hacky"?
I don't particularly like how redundant it is, but it may have to do.

An alternative would be to refactor the original code, used in the two situations, by extracting the specific code that displays the main PC menu. This way you could call it from two different routines (the original one, from which the code was extracted, and the one that runs after closing the Boxes menu), and (and this is the crucial point) have two return points, after which either sending the SGB packets or not.
That said, to me it's not worth it. Sending SGB packets once more than needed should not be a big problem; it just slow down the menu opening a bit (you would probably notice the delay, but it's still bearable).

Last edited by Sawakita (2012-11-13 22:11:23)

Offline

#104 2012-11-14 06:01:42

Danny-E 33
Administrator
Registered: 2012-06-09
Post 260/1,134

Re: Pokemon Red: Palettes

Sawakita wrote:
Danny-E 33 wrote:
Sawakita wrote:

1c:66ea is not free space. Instead the typical bank ending's free space begins at 1c:7b9d.

1C:66EA used to be in the middle of the palette table. I moved that table to 0x73BA0 which is the free space you are reffering to and expanded it all the way to the end of the bank.

Ah, sorry, I didn't realize that.

Not a problem :)

Sawakita wrote:
Danny-E 33 wrote:

So currently, my very limited free space in bank 1C begins at 1C:66EA.
...

push bc
push hl
ld hl, $66F8
call $5FEB
pop hl
pop bc
call $1922
ret

Well done. Remember, considering there's not so much space in bank 0x1C, that you can replace a call+ret with a jp.

Ah. You'd think I would remember this by now! ;)

So in this case, the call at 1C:796C which calls $66EA needs to stay a call so the next address (1C:796F) is in the SP, while $66EA is in the PC, yes?
But the call at the end of the short routine at 1C:66EA that calls $1922 should be changed to the jump so that at the end of the text box drawing routine at $1922, the ret command returns to 1C:796F, correct?

So the code at 1C:66EA should now look like:

push bc
push hl
ld hl, $66F7
call $5FEB
pop hl
pop bc
jp $1922
Sawakita wrote:
Danny-E 33 wrote:

Sawakita, do you think there is any way to accomplish this that isn't quite so messy or "hacky"?
I don't particularly like how redundant it is, but it may have to do.

An alternative would be to refactor the original code, used in the two situations, by extracting the specific code that displays the main PC menu. This way you could call it from two different routines (the original one, from which the code was extracted, and the one that runs after closing the Boxes menu), and (and this is the crucial point) have two return points, after which either sending the SGB packets or not.
That said, to me it's not worth it. Sending SGB packets once more than needed should not be a big problem; it just slow down the menu opening a bit (you would probably notice the delay, but it's still bearable).

Right. That kind of complexity wouldn't be worth it. I'm fine with it loading the OW palette every time Bill's PC menu is loaded.

Also, the call to the text box drawing routing for Bill's PC menu is at 8:5504.
However, when I inserted the code here to return to the OW palette, the Pokeballs in the Box list would flicker blue/green right before they dissapeared. I played around with this alot tonight and here's what I came up with.

So, I changed the call at 8:5561 from $3DD7 to $7F52 (the beginning of free space in bank $08) and at that location I added the code:

call $3DD7
ld b, $09
jp $3DEF

This worked great. The Pokeballs are red the entire time until they dissapear, and the OW palette is correctly loaded when you close the PC. There doesn't seem to be any unwanted side-effects.
Thanks alot for helping me understand SGB packets! :) I'm very pleased with the results.
Does it look good to you?

P.S. I remembered the jump this time ;)

EDIT: While we're trying to save space, I'm pretty sure there's absolutely no harm in changing the code at 1C:66EA to:

call $1922
ld hl, $66F3
jp $5FEB

I feel like this is much simpler and direct and it saves quite a bit of space. The way I was doing it before seems almost silly now. :P

Last edited by Danny-E 33 (2012-11-14 06:25:52)

Offline

#105 2012-11-16 05:34:26

Danny-E 33
Administrator
Registered: 2012-06-09
Post 263/1,134

Re: Pokemon Red: Palettes

So, if anyone cares, I fixed the palette of the Pokeballs in the Pokedex very easily.
I put a breakpoint at $5FEB and when the game broke, I went to the address in hl which was the SGB packet.
Then I just changed the palette ID in the packet from $10 to #21 and viola.
2CINKtd.png

I find it interesting that the Pokeballs in battle use the green health bar palette, the box list used the OW palette, and the Pokedex uses the Human palette.. :P
It feels good to know they are all using the same palette. :)

Also Sawakita, do you have any commentary for my previous post?

Last edited by Danny-E 33 (2013-06-08 11:36:17)

Offline

#106 2012-11-16 06:37:14

Miksy91
Member
Registered: 2010-10-16
Post 1,247/2,346

Re: Pokemon Red: Palettes

Danny-E 33 wrote:

So currently, my very limited free space in bank 1C begins at 1C:66EA.
...

push bc
push hl
ld hl, $66F8
call $5FEB
pop hl
pop bc
call $1922
ret

So in this case, the call at 1C:796C which calls $66EA needs to stay a call so the next address (1C:796F) is in the SP, while $66EA is in the PC, yes?
But the call at the end of the short routine at 1C:66EA that calls $1922 should be changed to the jump so that at the end of the text box drawing routine at $1922, the ret command returns to 1C:796F, correct?

So the code at 1C:66EA should now look like:

push bc
push hl
ld hl, $66F7
call $5FEB
pop hl
pop bc
jp $1922

Right but won't matter at all if you're not running out of free rom space. The processor executes one command in "micro seconds" (or faster). Unless the routine for that call+ret command is a subroutine of a subroutine of a subroutine... you can be sure the ram area reserved for stack is not exceeded.

I could pretty much reply to the whole post too but you never explained why you're decreasing hl in the code starting at 1C:66EA like that? Are you moving all the data after that code "ends" (with jp $1922) as much backwards as possible?
Also, what are $3DD7 and $3DEF for? Other than that, I can see the general idea behind the changes you've made.

Offline

#107 2012-11-16 20:15:57

Sawakita
Administrator
Registered: 2010-10-16
Post 338/365

Re: Pokemon Red: Palettes

Danny-E 33 wrote:

So in this case, the call at 1C:796C which calls $66EA needs to stay a call so the next address (1C:796F) is in the SP, while $66EA is in the PC, yes?
But the call at the end of the short routine at 1C:66EA that calls $1922 should be changed to the jump so that at the end of the text box drawing routine at $1922, the ret command returns to 1C:796F, correct?

So the code at 1C:66EA should now look like:

push bc
push hl
ld hl, $66F7
call $5FEB
pop hl
pop bc
jp $1922

Correct.

Danny-E 33 wrote:

Also, the call to the text box drawing routing for Bill's PC menu is at 8:5504.
However, when I inserted the code here to return to the OW palette, the Pokeballs in the Box list would flicker blue/green right before they dissapeared. I played around with this alot tonight and here's what I came up with.

So, I changed the call at 8:5561 from $3DD7 to $7F52 (the beginning of free space in bank $08) and at that location I added the code:

call $3DD7
ld b, $09
jp $3DEF

This worked great. The Pokeballs are red the entire time until they dissapear, and the OW palette is correctly loaded when you close the PC. There doesn't seem to be any unwanted side-effects.
Thanks alot for helping me understand SGB packets! :) I'm very pleased with the results.
Does it look good to you?

Well done. Did you find out that 0x3dd7 is the routine that refreshes the screen (thrice)? That makes it a good decision putting your new code right after that call.

Danny-E 33 wrote:

EDIT: While we're trying to save space, I'm pretty sure there's absolutely no harm in changing the code at 1C:66EA to:

call $1922
ld hl, $66F3
jp $5FEB

I feel like this is much simpler and direct and it saves quite a bit of space. The way I was doing it before seems almost silly now. :P

Much better.

Miksy91 wrote:

I could pretty much reply to the whole post too but you never explained why you're decreasing hl in the code starting at 1C:66EA like that? Are you moving all the data after that code "ends" (with jp $1922) as much backwards as possible?

Because he replaced the call+ret with a jp (which takes one byte less), it makes sense appending the rest of the data (in this case the SGB packet), right after the end of the code, without leaving empty bytes in the middle. Every byte counts ;)

Miksy91 wrote:

Also, what are $3DD7 and $3DEF for?

0x3dd7 waits three VBlank interrupts before returning. This allows the screen to be redrawn.
0x3def is a fast way to send predefined SGB packets (provided that the predefined routine's ID is passed via register b).

Offline

#108 2012-11-17 22:20:44

Danny-E 33
Administrator
Registered: 2012-06-09
Post 264/1,134

Re: Pokemon Red: Palettes

Miksy91 wrote:

Right but won't matter at all if you're not running out of free rom space. The processor executes one command in "micro seconds" (or faster). Unless the routine for that call+ret command is a subroutine of a subroutine of a subroutine... you can be sure the ram area reserved for stack is not exceeded.

Right, but I've become very limited on free space in bank 1C. It is the bank with the palette table, and I expanded that table from having 37 (0x25) palettes to 140 (0x8C) palettes. It took up every byte of free space in that bank, so now the only free space I have to work with is where the palette table used to be, which isn't very much. I had 296 (0x128) free bytes in the whole bank. And with all the editing I've done with Sawakita and stag019, I only have 133 (0x85) bytes left. So I'm trying my best to make each routine as short as possible. Like Sawakita said, every byte counts. :P

Sawakita wrote:

Well done. Did you find out that 0x3dd7 is the routine that refreshes the screen (thrice)? That makes it a good decision putting your new code right after that call.

Thank you! :)
Yeah, I caught on to that a bit, but it's not like I really knew anything for sure. I had a good idea, though. But what about the call immediately following the call to 0x3DD7, 0x3ABE? Is it also part of refreshing the screen? I didn't dive too deeply into it, but I'd be lost if I did anyway...

Sawakita wrote:
Miksy91 wrote:

I could pretty much reply to the whole post too but you never explained why you're decreasing hl in the code starting at 1C:66EA like that? Are you moving all the data after that code "ends" (with jp $1922) as much backwards as possible?

Because he replaced the call+ret with a jp (which takes one byte less), it makes sense appending the rest of the data (in this case the SGB packet), right after the end of the code, without leaving empty bytes in the middle. Every byte counts ;)

Right, at the location that's put into hl is the SBG packet that I created for this routine, so it's also put into free space that immediately follows my custom routine. You can see each time I revised the routine, I pushed back the SGB packet as much as I could.

Sawakita wrote:
Miksy91 wrote:

Also, what are $3DD7 and $3DEF for?

0x3dd7 waits three VBlank interrupts before returning. This allows the screen to be redrawn.
0x3def is a fast way to send predefined SGB packets (provided that the predefined routine's ID is passed via register b).

Yeah, 0x3DD7 is just a call I had to add back in since I overwrote the call to 0x3DD7 in order to point to free space. Then the free space I made it point to had to still have the original routine it was calling. That's all. I didn't actually know what the routine was for when I moved its call and added my custom code. I just found that it worked when I put my custom code there through lots and lots of trial and error, since it didn't work appropriately when I added my custom code where I initially thought it should go.
Although, could you properly define a VBlank for me, please?

And 0x3DEF is a routine that will automatically reevaluate the OW palette that's being used based on the map you're currectly in, as long as you put 0x09 in register b.
And Sawakita, what other things can this routine be responsible for with other values in b? Like, if b is 0x09, it evaluates the OW palette. Does it do anything else?

Also, IIMarckus and I talked a bit about this way earlier in this thread:

IIMarckus wrote:
Danny-E 33 wrote:

And now something that might be so much work that I might not be able to pull it off, even though I don't think there's any reason to say it would be impossible:
Currently, I would assume that when you walk onto a new map, it checks the map id to load the correct palette (pallet town, viridian city, route palette etc.)
Could this simple part of the engine be completely overhauled so that whenever you walk onto a map, instead of checking the map id, it checks the tileset number and from there loads an individual palette for each tile number of that specfic tileset from a pool of palettes determined by the tileset?

Seems feasible to me, but it would be a lot of work.

With the knowledge I have now about SGB features, I'm pretty sure this is actually immpossible, yes?

Offline

#109 2012-11-18 00:20:56

Sawakita
Administrator
Registered: 2010-10-16
Post 339/365

Re: Pokemon Red: Palettes

Danny-E 33 wrote:

Although, could you properly define a VBlank for me, please?

VBlank is short for Vertical Blanking. From "The Official Manual" (page 56):

LY indicates which line of data is currently being transferred to the LCD driver. LY takes a value of 0-153, with
144-153 representing the vertical blanking period.

VBlank is an interrupt that occurs each time the register mapped at 0xFF44, also called LY, reaches the value 0x90 (which is the first Y coordinate outside the actual LCD; by the way, this is the reason why you can access VRAM during the period LY is between 0x90-0x99). After reaching value 0x99, LY resets to zero in a constant loop.

Danny-E 33 wrote:

Also, IIMarckus and I talked a bit about this way earlier in this thread:

IIMarckus wrote:
Danny-E 33 wrote:

And now something that might be so much work that I might not be able to pull it off, even though I don't think there's any reason to say it would be impossible:
Currently, I would assume that when you walk onto a new map, it checks the map id to load the correct palette (pallet town, viridian city, route palette etc.)
Could this simple part of the engine be completely overhauled so that whenever you walk onto a map, instead of checking the map id, it checks the tileset number and from there loads an individual palette for each tile number of that specfic tileset from a pool of palettes determined by the tileset?

Seems feasible to me, but it would be a lot of work.

With the knowledge I have now about SGB features, I'm pretty sure this is actually immpossible, yes?

It's actually impossible indeed. Unlike CGB (Game Boy Color) that defines palettes for single tiles in VRAM, SGB can only define the colors for areas on the screen. This means you cannot colour maps on a SGB game (R/B) the way you colour a CGB game (GSC). In fact if you play Gold/Silver in SGB mode you'll notice that maps are coloured the same way as Red/Blue.

Offline

#110 2012-11-25 18:25:57

Danny-E 33
Administrator
Registered: 2012-06-09
Post 272/1,134

Re: Pokemon Red: Palettes

Well I have a couple problems again...

So, the SGB packet I modified at 1C:64A8 is the packet that the Pokedex uses, but that packet is also used by several other things like the Oak intro, and it acts like a universal Palette 0x10 packet.
So what I want to do is just change the value in hl when the Pokedex is being loaded to use the SGB packet I already made for the Box list. This would mean changing hl to $66F3.
The problem is, I don't know when $64A8 is put into hl and I can't seem to find it...
Do you think you can help me find when $64A8 is put into hl so I can change it to $66F3?

The other problem I'm having is, after the Elite Four when you're in the Hall of Fame, it shows the party that you beat the Elite Four with, and then it shows your player sprite.
But when it evaluates the palette to use for the player sprite, the player sprite doesn't have a trainer ID that gets put into $D031, so it uses the ID that was last put into $D031, which is $2B (the rival's ID, $F3, minus $C8).
So because of the routine that stag019 and I came up with that gives trainer sprites unique palettes causes the player sprite in the Hall of Fame to use your rivals's palette.
And I can't figure out a way to either:
change the value in $D031 when the player sprite is loaded
or hard code a palette number when the player sprite is loaded.

Any advice?

Offline

#111 2012-11-25 21:25:00

Sawakita
Administrator
Registered: 2010-10-16
Post 343/365

Re: Pokemon Red: Palettes

Danny-E 33 wrote:

Well I have a couple problems again...

So, the SGB packet I modified at 1C:64A8 is the packet that the Pokedex uses, but that packet is also used by several other things like the Oak intro, and it acts like a universal Palette 0x10 packet.
So what I want to do is just change the value in hl when the Pokedex is being loaded to use the SGB packet I already made for the Box list. This would mean changing hl to $66F3.
The problem is, I don't know when $64A8 is put into hl and I can't seem to find it...
Do you think you can help me find when $64A8 is put into hl so I can change it to $66F3?

Try using your hex editor's search function (search for the machine code for "ld hl,$64a8", which is 21 A8 64)

Danny-E 33 wrote:

The other problem I'm having is, after the Elite Four when you're in the Hall of Fame, it shows the party that you beat the Elite Four with, and then it shows your player sprite.
But when it evaluates the palette to use for the player sprite, the player sprite doesn't have a trainer ID that gets put into $D031, so it uses the ID that was last put into $D031, which is $2B (the rival's ID, $F3, minus $C8).
So because of the routine that stag019 and I came up with that gives trainer sprites unique palettes causes the player sprite in the Hall of Fame to use your rivals's palette.
And I can't figure out a way to either:
change the value in $D031 when the player sprite is loaded
or hard code a palette number when the player sprite is loaded.

Any advice?

Can't you just find the code that loads the player's backsprite during the "Hall of Fame" scene and add the ASM hack there?

Offline

#112 2012-11-26 02:52:25

Danny-E 33
Administrator
Registered: 2012-06-09
Post 275/1,134

Re: Pokemon Red: Palettes

Sawakita wrote:
Danny-E 33 wrote:

Well I have a couple problems again...

So, the SGB packet I modified at 1C:64A8 is the packet that the Pokedex uses, but that packet is also used by several other things like the Oak intro, and it acts like a universal Palette 0x10 packet.
So what I want to do is just change the value in hl when the Pokedex is being loaded to use the SGB packet I already made for the Box list. This would mean changing hl to $66F3.
The problem is, I don't know when $64A8 is put into hl and I can't seem to find it...
Do you think you can help me find when $64A8 is put into hl so I can change it to $66F3?

Try using your hex editor's search function (search for the machine code for "ld hl,$64a8", which is 21 A8 64)

Worked like a charm! It's at 0x71EAD.
I really should start being more creative with my problem solving and believe in myself more before giving up so quickly. I'm sorry for that....

EDIT: Ugh... It turns out the "ld hl, $64A8" command at 0x71EAD is still read for both the Oak intro and the Pokedex, so changing the value loaded into hl to my custom packet for the Pokedex still changes the packet used for the Oak into... So I guess now it's a matter of finding the different calls that call to the same place but editing the calls that are only read in the Pokedex and not editing those calls that are read during the Oak intro...

EDIT2: I should probably mention that I want to add in packets to change the palette for oak, then change the palette for the player, then change the palette for the rival, and then change the palette again for the player.
So it's probably best to insert the branches of code for palette changes inside the ASM for the Oak intro.
But I'd like to branch a palette change for the Pokedex still too, so I can leave the "ld hl, $64A8" command unchanged incase it's used for even more things, which is very likely.

Sawakita wrote:
Danny-E 33 wrote:

The other problem I'm having is, after the Elite Four when you're in the Hall of Fame, it shows the party that you beat the Elite Four with, and then it shows your player sprite.
But when it evaluates the palette to use for the player sprite, the player sprite doesn't have a trainer ID that gets put into $D031, so it uses the ID that was last put into $D031, which is $2B (the rival's ID, $F3, minus $C8).
So because of the routine that stag019 and I came up with that gives trainer sprites unique palettes causes the player sprite in the Hall of Fame to use your rivals's palette.
And I can't figure out a way to either:
change the value in $D031 when the player sprite is loaded
or hard code a palette number when the player sprite is loaded.

Any advice?

Can't you just find the code that loads the player's backsprite during the "Hall of Fame" scene and add the ASM hack there?

Right. Was I correct in thinking the back sprite loading routine for the "Hall of Fame" is at 1C:429B? I'm still not too sure about that one...

Last edited by Danny-E 33 (2012-11-26 04:42:13)

Offline

#113 2012-11-26 21:34:35

Sawakita
Administrator
Registered: 2010-10-16
Post 345/365

Re: Pokemon Red: Palettes

Danny-E 33 wrote:

Right. Was I correct in thinking the back sprite loading routine for the "Hall of Fame" is at 1C:429B? I'm still not too sure about that one...

No, I just noticed that what I said in my other post was badly worded, I'm sorry. When I said «go up one level in the stack of called routines» I did actually meant that you have to go to the caller of the currently executed code (the caller in BGB is reachable by looking at the currently highlighted 16-bit value in the stack area; I just realized that what I said seems to be meaning the 16-bit value *before* that, so please be patient with my english). So, long story short, the correct return pointer you have to go to is 1C:4365.

Backtracking a tiny bit, at 1C:4358 you can see that the pointer to the player's backsprite is loaded into register de, then routine 0x36eb (which decompresses a sprite, given a 2-byte pointer and a bank ID) is called.

Offline

#114 2012-11-27 16:49:54

Danny-E 33
Administrator
Registered: 2012-06-09
Post 277/1,134

Re: Pokemon Red: Palettes

Not a problem :) I sincerely appreciate all the guidance and knowledge you offer to me every day :)

Now I'm pretty confident I can fix the player backsprite palette in the Hall of Fame. I'll see if I have time to take a look at it tonight.

But do you think you can help me find a logical and efficient place to branch some code to give the Pokedex a different SGB packet than the Oak intro? I'm still having trouble coming up with an efficient way (or even an unefficient way, for that matter) of fixing this problem.

And while we're at it, I'd like to figure out solutions to branching several SGB packet changes for the different sprites in the Oak intro's script.
I would assume alot (if not all) of the Oak intro ASM script is right around 0x6155 (where the Red/Blue ROM Map notes several sprite pointers and text headers for the Oak intro).
So do you think it would be a good idea to call to free space a couple times in that script to insert some code to send the appropriate SGB packets?

Offline

#115 2012-11-27 21:35:44

Sawakita
Administrator
Registered: 2010-10-16
Post 347/365

Re: Pokemon Red: Palettes

Danny-E 33 wrote:

But do you think you can help me find a logical and efficient place to branch some code to give the Pokedex a different SGB packet than the Oak intro? I'm still having trouble coming up with an efficient way (or even an unefficient way, for that matter) of fixing this problem.

I don't have much time either, but in the next weekend I'll look into that, if you haven't found a solution before. Just a note (which you probably already know well about): there are some SGB packet sending routines that create a SGB packet dynamically in RAM (the one used in the battle screen is an example). I feel like it might be of some use for implementing the feature you want.

Danny-E 33 wrote:

And while we're at it, I'd like to figure out solutions to branching several SGB packet changes for the different sprites in the Oak intro's script.
I would assume alot (if not all) of the Oak intro ASM script is right around 0x6155 (where the Red/Blue ROM Map notes several sprite pointers and text headers for the Oak intro).
So do you think it would be a good idea to call to free space a couple times in that script to insert some code to send the appropriate SGB packets?

Sure, you could for example switch palette when the screen is "whited out"; by the way, if you want to look at the disassembled routine you can find it in pokered under:

OakSpeech: ; 6115

Last edited by Sawakita (2012-11-27 21:36:15)

Offline

#116 2012-11-28 02:34:52

Danny-E 33
Administrator
Registered: 2012-06-09
Post 281/1,134

Re: Pokemon Red: Palettes

Fixed the player sprite palette in the Hall of Fame!
I took the code I wrote from this post and changed it to:

call $6703
ld de, $9310
push de
jp $1670
nop

and added this code at 1C:6703:

ld hl, $D031
ld [hl], $14
ld a, $66
ret

Another thing checked off the list! :D

So I still want to fix the packet used for the Pokedex, and add SGB packets for each sprite during the Oak intro.
I tried out the Oak intro problem, but I'm a bit confused.
If I need to call $5FEB to send the SGB packets, and that routine is in bank 1C, then how do I control what value is in the program counter after I write $1C to $2000 and that bank is copied into RAM bank 01?
The problem is, that the "ld [$2000], $1C" command would be in ROM bank 01, so if bank 1C overwrites bank 01, a "call $5FEB" won't be read if that bank is no longer in RAM...
Does the next address to be executed after a $2000 bank switch come from the stack or something? I can't think of any other way to manipulate the pc after a bank switch if the bank switch command was in the bank that got replaced...

Last edited by Danny-E 33 (2012-11-28 02:36:25)

Offline

#117 2012-12-01 02:12:50

569/703

Re: Pokemon Red: Palettes

Danny-E 33 wrote:

Fixed the player sprite palette in the Hall of Fame!
I took the code I wrote from this post and changed it to:

call $6703
ld de, $9310
push de
jp $1670
nop

and added this code at 1C:6703:

ld hl, $D031
ld [hl], $14
ld a, $66
ret

Another thing checked off the list! :D

So I still want to fix the packet used for the Pokedex, and add SGB packets for each sprite during the Oak intro.
I tried out the Oak intro problem, but I'm a bit confused.
If I need to call $5FEB to send the SGB packets, and that routine is in bank 1C, then how do I control what value is in the program counter after I write $1C to $2000 and that bank is copied into RAM bank 01?
The problem is, that the "ld [$2000], $1C" command would be in ROM bank 01, so if bank 1C overwrites bank 01, a "call $5FEB" won't be read if that bank is no longer in RAM...
Does the next address to be executed after a $2000 bank switch come from the stack or something? I can't think of any other way to manipulate the pc after a bank switch if the bank switch command was in the bank that got replaced...

Changing banks should always be done in the home bank ($0000–3fff). But from anywhere you can use a function at $8 that handles this automatically, and will change banks back when you’re done.

ld hl,pointer
ld a,bank
rst $8

#118 2012-12-01 07:54:46

stag019
Idea Killer
Registered: 2011-01-05
Post 239/630

Re: Pokemon Red: Palettes

IIMarckus wrote:

But from anywhere you can use a function at $8 that handles this automatically, and will change banks back when you’re done.

ld hl,pointer
ld a,bank
rst $8

You're talking about Crystal and not Red, right?

; the rst vectors are unused
...
SECTION "rst08",HOME[8]
    db $FF

You can try to hide yourself in this world of pretend; when the paper's crumpled up, it can't be perfect again.

Offline

#119 2012-12-01 08:36:12

Miksy91
Member
Registered: 2010-10-16
Post 1,284/2,346

Re: Pokemon Red: Palettes

Couldn't that kind of codes be written to the rst vectors and make them useful that way?
Or would it require doing something about the rom header as well?

Last edited by Miksy91 (2012-12-01 08:36:31)

Offline

#120 2012-12-01 12:24:18

Sawakita
Administrator
Registered: 2010-10-16
Post 349/365

Re: Pokemon Red: Palettes

stag019 wrote:
IIMarckus wrote:

But from anywhere you can use a function at $8 that handles this automatically, and will change banks back when you’re done.

ld hl,pointer
ld a,bank
rst $8

You're talking about Crystal and not Red, right?

; the rst vectors are unused
...
SECTION "rst08",HOME[8]
    db $FF

Yeah, he just got confused. IIMarckus himself disassembled and named the routine that does that job in Red/blue: it's named Bankswitch and is located at 0x35d6. The usage is very similar:

ld hl,pointer
ld b,bank
call $35d6

Miksy91 wrote:

Couldn't that kind of codes be written to the rst vectors and make them useful that way?
Or would it require doing something about the rom header as well?

The RST vectors are used as shortcuts (calling them just takes one byte, while the call command requires 3 bytes): they're jumps (wrapped in pushes/pops to preserve registers) that redirect to another bank 0's routine which in turn takes care to do the job.

Last edited by Sawakita (2012-12-01 12:28:09)

Offline

#121 2012-12-01 12:32:22

Danny-E 33
Administrator
Registered: 2012-06-09
Post 285/1,134

Re: Pokemon Red: Palettes

Awesome! So hl will be what is in the pc and to be executed next, right?
And IIMarckus said something about the bank switching back when you're done, but that won't happen with this routine, right? To go back, you just have to add in another bank switch?
I'm pretty sure this was the only thing stopping me from accomplishing this, so I'll let you know how it turns out soon.
The only other thing is, I would like to use a single dynamic packet, rather than several static packets, but if you say this is kept in RAM, how do I know how to get it into RAM or where to put it?

Offline

#122 2012-12-01 12:45:04

Sawakita
Administrator
Registered: 2010-10-16
Post 351/365

Re: Pokemon Red: Palettes

Danny-E 33 wrote:

Awesome! So hl will be what is in the pc and to be executed next, right?
And IIMarckus said something about the bank switching back when you're done, but that won't happen with this routine, right? To go back, you just have to add in another bank switch?

You won't need to do anything else; when the "remote" routine ends (i.e. returns), the original caller's bank will be reloaded and the code flow wil continue from there.
Here's the source (from pokered) of Bankswitch routine:

Bankswitch: ; 0x35d6
; self-contained bankswitch, use this when not in the home bank
; switches to the bank in b
    ld a,[$FFB8]
    push af
    ld a,b
    ld [$FFB8],a
    ld [$2000],a
    ld bc,.Return
    push bc
    jp [hl]
.Return
    pop bc
    ld a,b
    ld [$FFB8],a
    ld [$2000],a
    ret
Danny-E 33 wrote:

I'm pretty sure this was the only thing stopping me from accomplishing this, so I'll let you know how it turns out soon.
The only other thing is, I would like to use a single dynamic packet, rather than several static packets, but if you say this is kept in RAM, how do I know how to get it into RAM or where to put it?

The routine that create dynamic SGB packets use RAM area 0xCF2D and following bytes (in a SGB palette packet, 0x51 is loaded in 0xCF2D, and palette IDs are loaded in the following RAM locations). Try putting access breakpoints in that RAM area to find out more.
I couldn't find info about this in my notes, but I'm pretty sure I wrote them down somewhere... I'll post more later on or tomorrow, if I find something.

Offline

#123 2012-12-01 12:56:06

Danny-E 33
Administrator
Registered: 2012-06-09
Post 287/1,134

Offline

#124 2012-12-01 14:29:06

Miksy91
Member
Registered: 2010-10-16
Post 1,286/2,346

Re: Pokemon Red: Palettes

Sawakita wrote:

The RST vectors are used as shortcuts (calling them just takes one byte, while the call command requires 3 bytes): they're jumps (wrapped in pushes/pops to preserve registers) that redirect to another bank 0's routine which in turn takes care to do the job.

Yeah, I know. If you debug your way though the routine used for a bankswitch in Gold/Silver (with rst 8), the code isn't that large though (or I have possibly been skipping parts of it with "F3" there too but I don't think it is).

Of course if the space in rom bank 0 is so limited that there is no point in adding such code, no particular reason in creating one either.

Last edited by Miksy91 (2012-12-01 14:29:28)

Offline

#125 2012-12-01 21:46:32

stag019
Idea Killer
Registered: 2011-01-05
Post 241/630

Re: Pokemon Red: Palettes

Sawakita wrote:

The RST vectors are used as shortcuts (calling them just takes one byte, while the call command requires 3 bytes): they're jumps (wrapped in pushes/pops to preserve registers) that redirect to another bank 0's routine which in turn takes care to do the job.

Which makes me wonder though. How much space does it save? How many calls are there to this function in Generation I? I'd like to know how much it would have benefitted to have used the RST vectors in Generation I, since it's been said that space was an issue during development.

Last edited by stag019 (2012-12-01 21:46:51)


You can try to hide yourself in this world of pretend; when the paper's crumpled up, it can't be perfect again.

Offline

Board footer

Powered by FluxBB