I've gotten that part taken care of! I moved all of the code bytes ahead one by one in each section since I didn't know what the jump code meant. I'm assuming since I changed their appearance flag code to FF I've also just freed up 7 flags I could use down the road if I want to make something new as well
Yeah, you can use flags freely that are unused now because you removed them.
Now I've been trying to add running shoes for the past two hours.
I can't post links yet I'll try and message them
I got this version to work easily enough: [Gold/Silver Running Shoes Pokecommunity]
But I'd like to use this version as it seems better: [Better running shoes Skeetando]
Now the one I want to use, I tried following what it said to do but it didn't work, realizing it was for crystal and not gold I tried to interpret the response assembly language for awhile. From what I could tell I changed the info as to the pointer of where the game says you're pushing b. I think I need to put the initial pointer code in a different offset though because it doesn't work. So I tried taking the pointer code from the first version (pokecommunity link) and then copying the other code after it but it doesn't seem to work either. I tried different variations. I believe my problem is I'm putting it in the wrong spot or the differing banks are messing with the pointers.
I feel fairly familiar with Hex editing/JohtoMap but I'm having a lot more trouble finding information for using an assembly program (and finding one)
I'm thinking this:
$101AE
call @next
37 scf
C9 ret
@next
FA 29 CF ld a,[$CF29]//let's game know, that you're pushing "B" ; D03E crystal
CB 57 bit 2,a
E6 02 and a,$02
20 06 jr z,@Walk
3E 02 ld a,$02//STEP_BIKE ; run
CD 5F 42 call $425F//DoStep
C9 ret
3E 01 ld a,$01//STEP_WALK
CD 5F 42 call $425F//DoStep
C9 ret
but there doesn't seem to be empty space in the same rom bank as $101AE so is it possible to call a different rom bank, all the calls seem to be 2 byte in this assembly language. In the Rom bank I see spurts of 00 or FF's but it doesn't seem empty
You can probably use the routine Chamber_ wrote unless you want to implement it on your own for some reason.
There is lots of room in that rom bank since it starts at 0x10000 and ends at 0x13FFF. In case you don't have enough room there / you want to fill in some other data as well, you can use a "3-byte call". There is an asm routine that can be accessed by filling register a with rom bank, hl with pointer value (for example, a = 10, hl = 405A would lead into address 10:405A = 0x10 * 0x4000 + 0x405A - 0x4000 = 0x4005A). This asm routine is written starting at rom address $8 (yep, it's at the start of the rom data and that's for a reason). You can access it directly with asm instruction
rst $8.
So in case you find some in-game asm routine doing the following;
ld a, $1b_value
ld hl, $2b_value
rst $8
That's basically a 3-byte call to address a:hl. For saving values of registers a and hl for later usage, you've got to
push them onto stack (instructions "push af" and "push hl").
Every asm instruction is 1-byte long but some of them have parameters that are either 1-byte or 2-byte long. For example ld a, $0F is a 1-byte instruction (ld) that was 1-byte parameter 0x0F. And "ld hl, 2b_value" has also 1-byte opcode with 2-byte parameter (= two 1-byte parameters!) that is attached as values to registers h and l.
There are no such things as "3-byte pointers" in Gameboy. Each pointer is 2-byte long. The reason why we don't have 3-byte pointers is because no asm instruction can even have a 3-byte parameter, the parameter can be only 1 or 2 bytes long.
Then again, by merging lots of asm instructions together in an efficient way, we can access code from other rom banks by either jumping there (= "3-byte jump) or by calling routines(= "3-byte call"). While "calls" in pksv language end with script code "end" or "return", Gameboy asm language, the instruction that tells the current subroutine ends is "ret" (or "reti").
Thanks Miksy
EDIT:
Found this for hex <=> assembly:
https://www.pastraiser.com/cpu/gameboy/gameboy_opcodes.html
https://marc.rawer.de/Gameboy/Docs/GBCPU_Instr.html
Kinda posting this stuff as I go along to try and help anyone else who might google this stuff
Are the hex numbers in specific banks (processor?) used for different numbers and thats say why 20 is a jump code there and not a give money? I'm looking again at the script for the guy who posted running shoes gold version and I'm unsure how the calls pointers and org pointers are arranged. It says call @extension...which isn't an offset...presumably its the org number above @extension later but the other @next has no such thing
The reason Chamber_ wrote offsets like that is because it doesn't really matter where you store that information (or routine) as long as it is called from somewhere. So @extension and @next are rom addresses there in his routine which you can choose freely (as long as they can be called with 2-byte pointer calls within the same bank). In his own code, he has probably decided to use address 04:7E03 as "@extension" but you can choose that address freely yourself.
Also, pksv script codes and gameboy asm code is no way related. To tell you the truth, those script codes are actually "manipulated" with asm routines that exist "beneath" them. It's kinda like this;
Let's say we have the following script;
#org 0x123456
6A - faceplayer
47 - loadfont
4C - 2writetext 0x7470 ' 0x123470 ' "Hello!"
53 - closetext
49 - loadmovesprites
90 - end
We have some asm routine beneath that controls the execution of this script. The routine first looks for, what byte is stored in rom address 0x123456, and loads that somewhere, for example to register a (a = 6A). Then from some "call table" (table consisting of pointers for each script code in order from 00 to A3), it checks the value of entry number 0x6A (= 6Bth entry in that table because 1st is 00, 2nd 01, 3rd 02 and so on). That "value" could be a "3-byte pointer" (that is handled somehow to access a routine from another bank!). Now it uses this 3-byte pointer and calls the routine behind it and finds an asm routine that is used to execute the asm code making this talked-to person face player. After all this is done, we step-by-step, return to "executing more script code" by looking for byte value at address 0x123457 (where we have byte 47 that resembles "loadfont" and "do stuff" with it).
And if you're wondering what happens when we eventually get to load value 4C ("2writetext"), it happens to check somehow (could be done in MANY different ways), "Should we load more data? (= Does value 4C have parameters? Yes. Two.)"
I don't think the game actually works like this, but it surely could and I would have implemented scripting system like this myself if I was the one to program these games. So there is probably an other kind of routine "beneath the script" but anyhow, we have some asm code that controls execution of the script. It's kinda like how computers are used execute Java programs with so called "Java Virtual Machine". Here we have a similar "virtual machine" too which is built as a huge program with gameboy asm instructions (and this controls the execution of script).
P.S
Google the following tools. They will definitely help out because you don't need to know each instruction - byte combination by heart.
Gameboy Assembler Plus, bgb (emulator with debugger), Gameboy Assembly Editor
