#159950 - zodiacdagreat - Tue Jul 08, 2008 8:16 pm
Hi, I'm a new learner to asm, and I did a routine, whicha actually works and changes palettes:
push {r0, r1, r2, lr}
ldr r1, .PaletteDestination
ldr r0, .PaletteSource
mov r2, #16 @lenght of palette change
swi 11
pop {r0, r1, r2, pc}
.align 2
.PaletteDestination:
.word 0x202F0C8 @ Sprite Pal begins here I think
.PaletteSource:
.word 0x8800100
But, the bad point is when the screen refreshes the palette change is, useless, as the colors turn back to normal. What I need to know, is how to perform a constant palette change routine, that keeps writing changes to the palette data, until, I cancel it.
#159954 - Dwedit - Tue Jul 08, 2008 9:02 pm
Is that even valid code?
The palette is at 0x05000000.
How do you know that your source address is 0x08800100? Are you reserving space there? I'd just use a label to point to the address of some data.
_________________
"We are merely sprites that dance at the beck and call of our button pressing overlord."
#159965 - Miked0801 - Tue Jul 08, 2008 9:50 pm
Why use assmebly at all?
| Code: |
u16 *palDest = (u16 *)0x202F0C8;
u16 *palSrc = (u16 *)0x8800100;
for(i=0;i<16;i++)
{
*palDest++ = *palSrc;
}
|
or even
| Code: |
typedef struct
{
u32 foo[8];
} COPY_32_BYTES;
foo()
{
COPY_32_BYTES*palDest = (COPY_32_BYTES*)0x202F0C8;
COPY_32_BYTES*palSrc = (COPY_32_BYTES*)0x8800100;
*palDest = *palSrc;
}
|
I bet you the compiler does a much better job than you in this case.
#159970 - gauauu - Tue Jul 08, 2008 10:07 pm
| zodiacdagreat wrote: |
| Hi, I'm a new learner to asm, and I did a routine, whicha actually works.... |
Not to disagree with you Mike (really I completely agree), but in this case, sounds like he's doing it as a learning exercise.
#159999 - zodiacdagreat - Wed Jul 09, 2008 5:02 am
| Quote: |
push {r0, r1, r2, lr}
ldr r1, .PaletteDestination
ldr r0, .PaletteSource
mov r2, #16 @lenght of palette change
swi 11
pop {r0, r1, r2, pc}
.align 2
.PaletteDestination:
.word 0x202F0C8 @ Sprite Pal begins here I think
.PaletteSource:
.word 0x8800100 |
Well, I'm a ROM Hacker, who's learning asm ... So the destination is 0202f0c8 , the game copies palette data from 0202f0c8 to 05000000, which is how I got it to work, while the PaletteSource is where, the palette data lies in the ROM.
I just need to know, how to make the palette change permanent.
@Miked0801 - I wished the game supports C/C++(What is it??) Thanks, for your help though. But, I wish I get the solution in ASM.
#160000 - sgeos - Wed Jul 09, 2008 5:08 am
Given your goals, why not write the code in C or C++, compile it and then inspect the results? Sure, it may not be the cleanest ASM, but it will be working ASM and you can learn how to improve it from there. You might even get somewhat good at C or C++ in the process.
-Brendan
#160001 - zodiacdagreat - Wed Jul 09, 2008 5:26 am
| Quote: |
Given your goals, why not write the code in C or C++, compile it and then inspect the results? Sure, it may not be the cleanest ASM, but it will be working ASM and you can learn how to improve it from there. You might even get somewhat good at C or C++ in the process.
-Brendan |
You got a point there, so what do I use to compile C or C++, and is the above code performing the permanent palette change ?
#160004 - eKid - Wed Jul 09, 2008 6:07 am
Maybe you're writing to a scratch buffer that the game is refilling every frame? :\
#160005 - sgeos - Wed Jul 09, 2008 6:13 am
| zodiacdagreat wrote: |
| You got a point there, so what do I use to compile C or C++, |
The Beginners FAQ covers the basics on getting started in homebrew. The documentation section of gbadev proper lists some tutorials. Some of them will take you through setting up the environment. To the extent you make it through a tutorial, you should have a grasp of all of the basic facilities of the GBA. I have no idea what the best up to date tutorials are at this point.
Keep in mind that you can have the compiler spit out assembler code. I could never make any sense out of GCC's ASM output, but someone else may be willing to share some insight on this.
If you are feeling motived to get a grasp of C, there is a tutorial listed in the FAQ. Also, I'm sure google will be able to churn out tutorials. Find a book on C should also be trivial, if you have any sort of a budget to work with.
| zodiacdagreat wrote: |
| and is the above code performing the permanent palette change ? |
Palettes are memory mapped. As far as hardware is concerned, writing new values to palette RAM is changing the palette. The palette will not change until the old value is overwritten. Different games manage palettes differently. I suspect a fair number of them refresh palettes every frame, and some of them will even modify them every scanline. There is always more than one way to get the job done.
-Brendan
#160007 - zodiacdagreat - Wed Jul 09, 2008 6:22 am
So is there any ways you know of to get the job done? Sorry to sound impolite.
| Quote: |
| Maybe you're writing to a scratch buffer that the game is refilling every frame? :\ |
Yeah, maybe, cause that same address, is used by all palettes to load the all. So I think a constant write to that address would do.
#160009 - eKid - Wed Jul 09, 2008 6:28 am
I think you'll have to find the function that writes data there and somehow work your routine into there.. :\
#160010 - sgeos - Wed Jul 09, 2008 6:49 am
| zodiacdagreat wrote: |
| So is there any ways you know of to get the job done? |
Generally, if you have arcane aspirations, achieving them will probably require a non-trivial upfront time investment to pick up the skills you need. The only way to properly get the job done is to begin at the beginning.
I know of plenty of ways to get things done when building a system from the ground up. If you are dealing with a system that is already in place, you will need to figure out what it is doing and either work with it or work around it. This will require a fair amount of time, and it will probably require a fair amount of trial and error, depending on what you are doing. It sounds like you are aiming to do something that is a taboo topic on this forum. If you ask questions about dealing with hardware, people will probably answer them.
In concrete terms:
Work through a simple C tutorial. You do not need to get very good at C, but you will need to be able to deal with it. The better you are at C, the easier your journey will be.
Work through at least one GBA tutorial. This should answer all of your basic questions.
Figure out what tools are available to get things done. The tutorials should introduce you to basic tools for GBA development. Typically people need other tools as well- level editors for people making games, etc. I'm sure you already have some of the special tools you need. You will certainly need documentation on the GBA no matter what you are doing, but it will not do you any good until you are familiar with the system.
At this point, if you are not up to speed on certain things, it may make sense to ask questions. Keep in mind though, that discussion of software reverse engineering on this forum generally stops at "how do I recreate this effect". Loading palettes are pretty simple. They are covered in the tutorials, but the basic patterns are either load once or update every tic. Plenty of variations are used though, because those generic solutions are very lacking depending on your goals.
-Brendan
#160013 - zodiacdagreat - Wed Jul 09, 2008 7:52 am
You know, I never came to this forum to ROM Hack, and to ROM Hack, I'm no beginner I came to learn ASM - to proceed further in ROM hacking xD.
So, until I find anything further - reverse the game engine (Like you suggested :) ) then I'll report back.
Thanks guys!
#160033 - Dwedit - Wed Jul 09, 2008 4:01 pm
Also, go buy no$gba, just for the debugger. No other GBA emulator author has bothered to make a decent debugger.
Romhacking without breakpoints is like skydiving without a parachute.
_________________
"We are merely sprites that dance at the beck and call of our button pressing overlord."
#160039 - silent_code - Wed Jul 09, 2008 5:07 pm
The only problem with that is, that Martin, no$gba's author, is currently missing, so licenses can not be purchased at the moment. :^(
_________________
July 5th 08: "Volumetric Shadow Demo" 1.6.0 (final) source released
June 5th 08: "Zombie NDS" WIP released!
It's all on my page, just click WWW below.