Glitch City Laboratories Archives

Glitch City Laboratories closed on 1 September 2020 (announcement). This is an archived copy of a thread from Glitch City Laboratories Forums.

You can join Glitch City Research Institute to ask questions or discuss current developments.

You may also download the archive of this forum in .tar.gz, .sql.gz, or .sqlite.gz formats.

Generation I Glitch Discussion

Discovery about the root cause of the ZZAZZ glitch - Page 1

Discovery about the root cause of the ZZAZZ glitch

Posted by: bbbbbbbbba
Date: 2014-05-04 08:04:50
Well, I'm pretty sure I'm not the first one to discover it (see http://tasvideos.org/2945S.html), but since it is nowhere to be found on this site (to my best knowledge), here is it:

———-

When you defeat a trainer, the amount of money you win depends on the trainer class and the level of their party; namely, your winnings is the level of the last pokemon times a fixed amount depending on the trainer class. This fixed amount is always <= 99 for normal trainers, but is written in 2-byte (4-digit) BCD for the ease of computation. I will copy-paste some code from https://bitbucket.org/iimarckus/pokered: (I added some comments)

.FinishUp ; XXX this needs documenting
xor a      ; clear D079-D07B
ld de,$D079
ld [de],a
inc de
ld [de],a
inc de
ld [de],a ; de is now D07B
ld a,[W_CURENEMYLVL] ; the level of the last pokemon
ld b,a
.LastLoop
ld hl,$D047 ; the address of the trainer-class specific multiplicand
ld c,2 ; do 2-byte BCD arithmetic
push bc
ld a,$B
call Predef ; indirect jump to BCDAdd; reads operands from [de] and [hl], saves result in [de]
pop bc
inc de
inc de
dec b
jr nz,.LastLoop
ret

The intention of this loop is to add the multiplicand into address D07A-D07B for b times, where b is the level of the last pokemon. The two instructions in red is meant to restore the value of de, assuming that it is decreased exactly twice in the function BCDAdd. But is this the case?

Well, it is, as long as the BCD addition did not overflow. When it does overflow, the function sets the result to 9999 (in BCD; hex 99 = dec 153) (like how your money won't increase beyond 999999), and in this process also increase the value of de - the address to write to - by 3.

Does this pattern sound familiar?

Of course, the addition never overflows in normal play, because the multiplicand is <= 99 and the level is <= 100. Of course, glitch trainers abide by neither limitation. In fact, most ZZAZZ trainers takes the multiplicand from the names of real trainers, which is an ocean of uppercase letters, meaning that the multiplicand can easily be things like 8X8X, overflowing the content of any address in 1 or 2 additions. Seriously.

By the way, being ZZAZZ trainers doesn't mean they don't have stupidly long names. There is a good chance that some of the mysteries of the ZZAZZ glitch actually stem from the long name…

Re: Discovery about the root cause of the ZZAZZ glitch

Posted by: Torchickens
Date: 2014-05-04 09:49:56
TheZZAZZGlitch figured out the same kind of thing in this thread, but I think you're the first on these boards to show us this routine and copy the code (".FinishUp" starts at 0E:5D03). Thanks for the extra clarification.

Re: Discovery about the root cause of the ZZAZZ glitch

Posted by: bbbbbbbbba
Date: 2014-05-04 09:57:34
So I'm late, by less than one month… :)

Edit: I just realized that the function named BCDAdd by me is still undocumented in iimarkus's disassembly. I have my own copy on my mobile phone, where I documented it probably a month ago. Now I'm going on to document the "XXX this needs documenting" :)