Glitch City Laboratories Archives

1. First and most important thing for me is, I would like to use the glitch in the german yellow version with w sm.
So I have seen that this link was posted a lot of times: https://glitchcity.info/biglist.htm
Has the german version the same list (sorry if this is a stupid question)?

2. When I check the list I cant find a difference between Red/Blue/Yellow.
So why we dont use the same item list for a glitch when using wsm in yellow (I mean the same item list like for red/blue with 8F?).

3. Sherkel answered in this topic (https://forums.glitchcity.info/index.php?topic=7995.0)
"$D158 in English Red corresponds to $D15D in European Red, and so forth." -> so from english red to german red would be +5 is that right?

4. I read often about BGB Debugger. Does this make the thing easier

or can we find the whole code of the game on a webpage?

5. Is there maybe a big thing i should know before starting for the german version? (I have read for the code +4 from english red/blue and +5 from english yellow).

2. When I check the list I cant find a difference between Red/Blue/Yellow.
So why we dont use the same item list for a glitch when using wsm in yellow (I mean the same item list like for red/blue with 8F?).

EU non-English (except French) games

I have read now a lot of pages and all was a little bit a mess. So i started to read every single post here in the ACE Section starting by last post.
So i came to six new questions^^.

1. Question:
ISSOtm posted this page: http://glitchcity.info/wiki/index.php/GB_Programming#A_new_world

So now im reading it and it makes a lot, really a lot clearer for me, its like i can see a little light at the end of the tunnel :).

I have a question there about a calculation in "Register pair and RAM" section. This is a calculation result from author:
sub a, b ; A = A - B = $06 - $DE = $06 + (-$DE) = $06 + ($21 + $01) = $28, C flag = 0

I calculated it i think in a really "noob" Version. I calculated $06 = 6 / $DE = 222
So 6 - 222 (and 0 is 256 / so 256 - 216) i come to 40 / $28 - okey its right.

But i would like to understand how the writer split -$DE into $21 and $01. I tried to understand and searched above in his post, but i really dont get it.

2.Question:
I have read and checked a video on youtube that a hex editor and a RAM Searcher is very good to use.
Im not very familiar with BGB Debugger atm. Is there such a thing implemented, like a all in one solution? Or do i need RAM Searcher and hex editor seperately?

3. to 5. Question:
Evie the Mother Hen has written in "Where to get started" this code:
ld a, 15
ld [$d059] ,a
ret

so atm im trying to find out by myself first which item and quantity i need and then i check with this page: https://eldred.fr/gbz80toitems3/
So im checking in big hex list the function for ld a,x  —> Lemonade
hex number 15 is for mew so dec is –> 21
Lemonade x21

ld (xxyy), a is TM34 -> yy is 59 to dec is 89
TM34 x89

So then the next item describes the xx (3. Question -> is this all the time when we have a function with xxyy, that next item describes xx?) and its TM08. If i understood it right yy is read first coz of that-> part from (http://glitchcity.info/wiki/index.php/GB_Programming#A_new_world)

((Let's say the following instruction is ld ($2315), hl. Applying the same logic would mean H's value would be stored at ($2315), and L's would be at ($2316). However, you just lost THE GAME; because the z80 is a "little-endian" processor, L's value (the "little-end") is stored first, at ($2315). So ($2315) is $61, and ($2316) is $D3.)) 
(I think nearly the same question like 3. Question->) If we had a function like this: ld hl, (xxyy) xx would be first or not?

ret (4. Question - > i dont get it what ret is. I have never found this function on all the explanations pages i was looking^^. Does this finish the code we are writing?) but i understand with the itemgenerator page that it must be x201 for "ret".

https://eldred.fr/gbz80toitems3/ –> shows me this:
Lemonade x15 (hex:0F)
TM34 x89 (hex:59)
TM08 x201 (hex:C9)

But im confused. 5. Question -> Why we have 15 lemonade? I come to 21… ouh man…^^

(There is a short paper way to convert the number systems, like as described on this webpage:

1. Divide the decimal number by 16. Treat the division as an integer division.
2. Write down the remainder (in hexadecimal).
3. Divide the result again by 16. Treat the division as an integer division.
4. Repeat step 2 and 3 until result is 0.
5. The hex value is the digit sequence of the remainders from the last to first.

However, I've usually used either a search engine for an online conversion or Windows Calculator. Setting it to programmer mode, typing a hex value then clicking dec will convert it, vice versa.

I'm unsure how he got $21 + 01 either sorry. To spread some insight, because only one byte is used, after $FF you get $00 but we can suppose this is $100. $100-$DE is $22; and $06 + $22 gives the answer but not where the $01 came from. From another approach (not sure if this is a valid proof), I also tried inversing the bits (binary representation). Type $DE into Windows Calculator on Programmer, you get 1101 1110. So 0010 0001 converted is $21. (This is the "Not" operation in electronics).

2. Sure can answer this. :) Yes with pen and paper, however BGB's debugger uses ROM banks. But in short BGB, a separate hex editor, and knowledge (or calculator) for swapping between offsets/pointers makes identifying parts of the ROM easier (sometimes the disassembly only gives pointers, other times offsets are available).

The bankless(?) or bank 0 ROM section only goes from 0000-3FFF. 4000-7FFF conversely in Pokémon is for banked ROM. These are called pointers (see also here for how the pointers map out). Pointers and offsets (the latter you'd find in many hex editors) however may not have the same definition; an offset for instance might be hex:012345 (this as a pointer is 04:6345 where 04 means the bank. As there are three byte pairs it is called a "three byte pointer"). To convert from three byte pointer to offset, you do: (Bank value)x4000 + ((Bytes after bank value) - 0x4000), which gives 012345 as expected. (Workings are 4x4000 + 6345-4000 10000 + 2345 = 12345).

For converting offset to three byte pointer, DataCrystal offers this explanation:

Take the offset that you wish to point to.
Take the last four digits of the offset, and cut off the rest.
If the offset is outside the range 4000-7FFF, it must be converted like this: (offset mod 4000) + 4000. In other words:
If the offset is from 0000-3FFF, add 4000 to the offset.
If the offset is from 4000-7FFF, do not add anything to the offset.
If the offset is from 8000-BFFF, subtract 4000 from the offset.
If the offset is from C000-FFFF, subtract 8000 from the offset.
Because Game Boy is little endian, switch the first two digits with the last two.
Note: In rare cases, some games, such as Donkey Kong Land 2 and Donkey Kong Land III, may store pointers in big endian, in which case this step is not necessary.
Example: $1201FA is the offset you wish to point to in a game that uses little endian pointers.
Take the offset $1201FA
Take the last four digits: $01FA
Since $01FA is between 0000-3FFF, you add 4000, so you get $41FA
Because Game Boy is little endian, you take the 41FA, switch the 41 and FA around to get FA41

May also have an alternative method?:

To convert 12345 back into 04:6345, first the last two digit pair will always be the same (for big endian); so ??:??45. Do 12345/4000 (in hexadecimal) and throw away the remainder to get 4; so 04:??45. Finally, the 63 for some reason is the "23" + 40.

Sometimes using both the debugger (which is very useful for things like breakpoints in addition to general memory viewing) and a separate hex editor is convenient. My favourite is an open source one (I believe, as of memory in writing) called "HxD", which will give you offsets for any (well maybe not strictly any but any normal allocated/on a harddrive, memory stick etc.) file. Remember too make sure read only settings are off (properties, settings, etc.). There are conveniently too calculators to switch between pointers and offsets, such as here

3 to 5.

Yes, the items and opcodes convert :). It depends really where the code is in RAM. If it's executing say D327 (item 3 in German/French/Italian/Spanish Red) then the ld a,  part (for this opcode) is Lemonade but as D328 is item 3 quantity, the $15 is the x21. The reason why it's x21 is because the item quantities appear in decimal in the game, and the hexadecimal $15 becomes 21 in decimal (or 16*1 [left most digit]+5 [right most]). For the ld (yyxx), a (for this opcode TM34) after, we're at D329 (item 4), then D32A (item 4 quantity is $59 - in game; this is decimal:89) and this pattern continues.

Note you can use normally unnecessary padding to switch between whether it becomes an item or quantity. So, for instance using Poké Ball (inc b) straight after the ld a,$15 in the above would mean Poké Ball x 234 (EA in decimal is 234) instead of a TM34 stack.

Additionally I may have forgotten to consider the D059 in German version would be D05E (+5 of original) instead, so a quantity of 94, sorry. :(
yyxx instead of xxyy means what is called little endian; so 5ED0 (for yyxx) instead of D05E (xxyy) etc.

For your following similar question, if the documentation said something like ld hl, (xxyy) then it may be 21 D0 5E or either: Thunderstone x 208 and  9F, or (item) x 33 [21 in dec] and TM08 x 94, however the available opcode in this case is ld hl, (yyxx) so it would be 21 5E D0: Thunderstone x 94 and TM08 or (item) x 33 [21 in dec] 9F x 208.

Finally, ret is normally needed to end the code without a freeze. Basically (shorter answer) it can be understood like 'make the game return to what it should be doing after the arbitrary code execution finishes' (so return to item menu processing, music processing, etc.), with the absence of it causing the game to execute code in the next memory addresses indefinitely (often with this the game runs rst $38 [opcode $FF at some point] which in Pokémon Gen I runs a 0038 containing another $FF, which is an endless loop and responsible for the 00 39 corruption freezes). The longer answer is "Pop two bytes from stack & jump to that address." where the stack pointer (imagine like a stack of papers with each one a command) and pop, push instructions are involved. I've forgotten or never fully registered which of these (pop and push) do what, but this can likely be found with BGB debugger experimentation. Ret will not work if the ACE method (or part of the code) corrupts the stack without fixing it. Some methods (like Coin Case glitch in Generation II) do break the stack so have workarounds included in the codes, but usually you can use ret (TM01 or quantity 201) at the end of your code and don't have to worry about how to use it.

Hope this helps. ^^

Just interested in the ret function. Is there a difference between the rets like "ret nz" "ret z"… I think that it has a difference, but do i only need "ret" (TM01/ or x201) and the others i can forget :)?


Yep, it helped a lot :).
Thanks again a lot for your good answers and explanations :).

Have a nice day

"ret" is a opcode that pops the value of the top of the stack and jumps to it,and it's responsible for returning from functions.

The Zero Flag (Z) is a CPU flag that is "set" by any operation (with the exception of loading) that causes the value that the opcode was working with to be zero

For Example:

ld a,$03; the accumulator is now 3
sub $03 ; the accumulator is now 0 and the Zero flag is set.


Loading does not set the zero flag

ld a,0 ; zero flag not set
and a ; ...now it is!


Opcodes that use "nz" and "z" check the zero if is it set, and perform operations depending on whether or not it is

Example:

start:
ld a,$03
sub $03
jr z, .skip
call doSomething ; THIS IS NEVER CALLED!
.skip:
call doOtherStuff



start:
ld a,$03
sub $03
jr nz, .skip
call doSomething ; this is called
.skip:
call doOtherStuff



Similarly, "ret nz" returns if the zero flag is not set, and "ret z" returns if it is. "ret" returns regardless