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 II Glitch Discussion

Powerful (but large!) memory editor for G/S - Page 1

Powerful (but large!) memory editor for G/S

Posted by: Couldntthinkofaname
Date: 2018-02-12 12:46:11
It's a lot larger than I was hoping/anticipating, but here it is anyway! It is, admittedly, a bit of a pain to setup if you are not on emulator.

f3 11 bc da af e0 26 4f 3c e0 d6 21 bb c3 d5 06
0b c5 7a cd 38 db 7b cd 38 db 3e 25 22 1a cd 38
db 13 01 0d 00 09 c1 05 20 e7 21 bf c3 79 a7 28
07 57 af c6 14 15 20 fb 16 00 5f 19 36 ed cd 4d
db d1 f0 a5 47 cb 47 c4 90 db 78 cb 77 28 08 79
a7 28 03 0d 18 01 1b 78 cb 7f 28 09 79 fe 0a 28
03 0c 18 01 13 78 cb 4f 28 05 af 3d e0 26 d9 78
cb 67 28 06 21 10 00 19 54 5d 78 cb 6f 28 06 21
f0 ff 19 54 5d 78 cb 57 28 0d af e0 d6 3d e0 26
fb 62 6b 06 00 09 e9 78 cb 5f c4 5a db c3 a3 da
c5 0e 02 47 cb 37 e6 0f c6 f6 30 02 c6 80 22 78
0d 20 f3 c1 c9 e5 c5 d5 cd bb 14 cd e6 08 d1 c1
e1 c9 c5 e5 3e 0e ea ab ce af e0 da fb 21 c0 7e
3e 38 cf f3 0e 01 21 34 d9 cd 88 db cb 37 47 cd
88 db b0 47 0d 20 03 50 18 ef 58 e1 c1 af 4f c9
2a d6 f6 30 02 d6 80 c9 d5 af 47 c5 3e ec 22 e5
62 6b 09 54 5d e1 1a 4f cd 4d db f0 a5 47 cb 6f
28 01 0d cb 67 28 01 0c cb 7f 28 04 79 d6 10 4f
78 cb 77 28 04 79 c6 10 4f 78 cb 4f 20 08 79 e5
cd 38 db e1 18 d2 79 12 c1 d1 c9


This is meant to be written to $DA98
Controls

A - Enter write mode
Up - Scroll cursor up
Down - Scroll cursor down
Select - Jump to address
Start - Address Lookup (more on that later)
B - Exit memory editor

Write Mode

Up - Increment upper nybble
Down - Decrement upper nybble
Left - Increment lower nybble
Right - Decrement lower nybble
B - Write byte, exit write mode

Address lookup is a feature I added that eliminates the need for scrolling through the memory editor. Simply press start, type in the address you want to go to, and the memory editor will place the cursor on the address.

Disadvantages & Notes:

- Using the Address Lookup feature writes to Box 14's name
- Unlike TheZZAZZglitch's R/B memory editor, this performs writes after the player presses "B" to exit out of write mode. Sorry.

I tried to pack as much power into this as I could (with the time I had), but if you feel you can shrink the byte size for more space, I've attached the RGBDS syntax ASM to this post. Feel free to try to optimize it! (To change where this is written, change "BaseAddress")

Enjoy!

Edit: Princess Torchic checked, and determined that this payload can fit into $DA98 without conflict. I have rebuilt the source with the new base address. Thanks!

Edit2: Shrank the payload by 8 bytes, and also fixed a bug that occurred when pressing "a" and L/R at the same time

ISSOtm shrank the payload by an impressive 32 bytes, however this optimization unfortunately does not work. If I can fix it, it would be a great byte shave though!

Re: Powerful (but large!) memory editor for G/S

Posted by: Torchickens
Date: 2018-02-12 13:01:48
Wow! This looks amazing. ^^

Thanks Epsilon.

Perhaps hopefully somebody will be able to shorten it for use on WRAM.

I'll try to showcase this in a YouTube video tomorrow.

Re: Powerful (but large!) memory editor for G/S

Posted by: Couldntthinkofaname
Date: 2018-02-12 13:08:12

Wow! This looks amazing. ^^


Thank you!

I forgot to mention that this is meant to be used with TM exec. Any box name code that unlocks SRAM, switches to bank 1, and jumps to $B002 will do.

Unfortunately i'm a bit busy at the moment and cannot write this box name code right now.

Re: Powerful (but large!) memory editor for G/S

Posted by: Torchickens
Date: 2018-02-12 13:34:47


Wow! This looks amazing. ^^


Thank you!

I forgot to mention that this is meant to be used with TM exec. Any box name code that unlocks SRAM, switches to bank 1, and jumps to $B002 will do.

Unfortunately i'm a bit busy at the moment and cannot write this box name code right now.


You're welcome.

That's OK.

Remember the TM/HM method where you fill the TM/HM pocket first and then use a Lucky Egg Attract Quagsire? It seems like we can write the code there without the need of any padding. I think this is ideal for writing to SRAM byte by byte as well as you could theoretically adjust one-two quantities each write (start with later addresses and then toss to write to earlier addresses, or something similar).

I forgot exactly how enabling SRAM works, but in the past I used this method to enable SRAM bank 1 for obtaining the GS Ball for Celebi in Crystal (which looking back is now not very useful for Virtual Console users as the same address is enabled after beating the Elite Four). The specific addresses below may not matter, but it still works on Gold/Silver thankfully.

ld a,01  ; 3e 01
ld (4e01),a  ; ea 01 4e change to SRAM bank 1
ld a, 0a ; 3e 01
ld (0d01),a  ; ea 01 0d ;this enables writing to SRAM
ld a, 0b ; 3e 0b
ld (be3c),a  ;enable Celebi GS Ball event

We can ignore the GS Ball Celebi part and instead have a jp B002 (c3 02 b0) there.

I inserted your memory editor and it was a success (I don't know if the ret at the end was needed, but I added it just to be safe).

[img]https://i.imgur.com/VJ8CidG.png[/img]

You have a name for this memory editor or are you all right with me just calling it Epsilon's Generation II memory editor?

Re: Powerful (but large!) memory editor for G/S

Posted by: Couldntthinkofaname
Date: 2018-02-12 13:46:29

You have a name for this memory editor or are you all right with me just calling it Epsilon's Generation II memory editor?


Lol, that's fine :)


[img]https://i.imgur.com/VJ8CidG.png[/img]


Hmm, wonder why some characters appear normally wheras some characters appear red? Oh well, I suppose it's a minor problem, and fixing it would be a waste of bytes :P

I did all of my tests on DMG mode. Since you're on CGB mode, would you mind testing the Address lookup feature? I'm sure it will still work, but I just want to make sure.

Re: Powerful (but large!) memory editor for G/S

Posted by: Torchickens
Date: 2018-02-12 14:02:46


You have a name for this memory editor or are you all right with me just calling it Epsilon's Generation II memory editor?


Lol, that's fine :)


OK cool. ^^


Hmm, wonder why some characters appear normally wheras some characters appear red? Oh well, I suppose it's a minor problem, and fixing it would be a waste of bytes :P


Hmm that's interesting. Wonder if it's related to the red border around the text "Balls". Seems that's true though, so far the memory editor is working perfectly on my side.


I did all of my tests on DMG mode. Since you're on CGB mode, would you mind testing the Address lookup feature? I'm sure it will still work, but I just want to make sure.


It works perfectly so far. Entered the addresses in their normal big endian form and jumped back to the TM/HM pocket. I also tried jumping to phone numbers and decorations. Had a lot of fun with it and did some OAM DMA hijacking with the memory editor to get Celebi later. :) Not sure what's meant to happen with strings that aren't addresses (like "&123") but I tried it once and the memory editor sent me somewhere to VRAM (or possibly ROM, SRAM, I can't remember the details sorry) to modify.

Re: Powerful (but large!) memory editor for G/S

Posted by: Torchickens
Date: 2018-02-12 14:40:49
I have an idea. Your memory editor seems to be 322 bytes.

Before (according to ISSOtm) the unused memory addresses at DF00-DF80 are multiple structures, but the first two don't seem to be that important.


wOTPartyMons::
wOTPartyMon1:: party_struct wOTPartyMon1 ; dd5d
wOTPartyMon2:: party_struct wOTPartyMon2 ; dd8d
wOTPartyMon3:: party_struct wOTPartyMon3 ; ddbd
wOTPartyMon4:: party_struct wOTPartyMon4 ; dded
wOTPartyMon5:: party_struct wOTPartyMon5 ; de1d
wOTPartyMon6:: party_struct wOTPartyMon6 ; de4d

wOTPartyMonOT::
wOTPartyMon1OT:: ds NAME_LENGTH ; de7d
wOTPartyMon2OT:: ds NAME_LENGTH ; de88
wOTPartyMon3OT:: ds NAME_LENGTH ; de93
wOTPartyMon4OT:: ds NAME_LENGTH ; de9e
wOTPartyMon5OT:: ds NAME_LENGTH ; dea9
wOTPartyMon6OT:: ds NAME_LENGTH ; deb4

wOTPartyMonNicknames::
wOTPartyMon1Nickname:: ds PKMN_NAME_LENGTH ; debf
wOTPartyMon2Nickname:: ds PKMN_NAME_LENGTH ; deca
wOTPartyMon3Nickname:: ds PKMN_NAME_LENGTH ; ded5
wOTPartyMon4Nickname:: ds PKMN_NAME_LENGTH ; dee0
wOTPartyMon5Nickname:: ds PKMN_NAME_LENGTH ; deeb
wOTPartyMon6Nickname:: ds PKMN_NAME_LENGTH ; def6
ENDU


If the code begins at DD5D it should finish at DE95. If the labels are accurate it seems only the OT data is overwritten, which is not a problem if you keep your party the same (ideally with 6 Pokémon) and don't mind about those Pokémon.

Edit: Sorry, this is enemy Trainer related and is overwritten after facing a Trainer. Though food for thought maybe you could link with another game with a corrupted party to set this up. Will edit this post with more ideas.

Edit 2: The only other idea I have is perhaps you can use the party data. It's not very friendly and breaks the gameplay but is large enough. To avoid freezes it would probably be best to also set DA22 to 0 and not use that address as part of the code, which means all battles will be won and the Pokémon menu will have no effect. There's the fact you would need another wrong pocket TM, but we could probably write to another address to get it to work. Pokémon Crystal has a useful wrong pocket TM that points somewhere in the expanded Balls pocket (where the address does not change), so maybe there could be something like that in Gold/Silver too.

Re: Powerful (but large!) memory editor for G/S

Posted by: Torchickens
Date: 2018-02-12 17:26:03
OK. Using rgbasm and rgblink to generate a code for use at DA8D (Pokémon 3 move 2) works fine.

My setup for TM25 now has the same Quagsire in slot 3 with Attract as move 1 holding a Lucky Egg. At D57E (TMs/HMs) is a jp DA8D, and at DA8D is the following code:

11 80 FF 0E 00 AF E0 26 3C E0 D6 F3 21 BB C3 D5 06 0B C5 7A CD 32 DB 7B CD 32 DB 3E 25 22 1A CD 32 DB 13 01 0D 00 09 C1 05 20 E7 21 BF C3 79 A7 28 07 57 AF C6 14 15 20 FB 16 00 5F 19 36 ED CD 47 DB D1 F0 A5 47 CB 77 28 08 79 A7 28 03 0D 18 01 1B 78 CB 7F 28 09 79 FE 0A 28 03 0C 18 01 13 78 CB 4F 28 05 AF 3D E0 26 D9 78 CB 67 28 06 21 10 00 19 54 5D 78 CB 6F 28 06 21 F0 FF 19 54 5D 78 CB 57 28 0D AF E0 D6 3D E0 26 FB 62 6B 06 00 09 E9 78 CB 5F 28 03 CD 56 DB 78 CB 47 28 03 CD 8C DB C3 99 DA C5 0E 02 47 CB 37 E6 0F C6 F6 30 02 C6 80 22 78 0D 20 F3 C1 C9 E5 C5 D5 F5 CD BB 14 CD E6 08 F1 D1 C1 E1 C9 C5 E5 3E 0E EA AB CE AF E0 DA FB 21 C0 7E 3E 38 CF F3 0E 01 21 34 D9 CD 84 DB CB 37 47 CD 84 DB B0 47 0D 20 03 50 18 EF 58 E1 C1 AF 4F C9 2A D6 F6 30 02 D6 80 C9 D5 AF 47 C5 3E EC 22 E5 62 6B 09 54 5D E1 1A 4F CD 47 DB F0 A5 47 CB 6F 28 01 0D CB 67 28 01 0C CB 7F 28 04 79 D6 10 4F 78 CB 77 28 04 79 C6 10 4F 78 CB 4F 20 08 79 E5 CD 32 DB E1 18 D2 79 12 C1 D1 C9

I decided to set de as FF80 with OAM DMA hijacking being one of the most powerful glitches.

Before using TMs/HM quantities to write the jump to DA8D at D57E, you could set up a code injection program beginning in the TM/HM quantities. If you set DA22 (number of Pokémon counter) to 01, DA34 (second Pokémon) to FF you won't ever be touching Pokémon 3+'s happiness and healing Pokémon is safe. It may be wise too to give your first Pokémon HM moves by modifying DA2C-DA2F.

The 0x00 bytes and address values may be problematic for creating a reusable memory editor, but there must be a convenient way.

After finishing writing to DA8D would go the jp DA8D, and fortunately that's all there is to it, though the logistics of writing all the data may be long and prove interesting.

[img]https://i.imgur.com/xOTPMPz.png[/img][img]https://i.imgur.com/Cpn7Xhx.png[/img][img]https://i.imgur.com/oV4Io66.png[/img]

Re: Powerful (but large!) memory editor for G/S

Posted by: Couldntthinkofaname
Date: 2018-02-12 17:53:22
Ah, I see. I will rebuild my code with the new base address and update the source.

Thank you for trying that address!


Not sure what's meant to happen with strings that aren't addresses (like "&123") but I tried it once and the memory editor sent me somewhere to VRAM (or possibly ROM, SRAM, I can't remember the details sorry) to modify.


The memory editor simply takes the character hex and subtracts 246. If that set the carry flag, the editor then subtracts 128. It then swaps the result and loads it into "b". This process is then repeated for the next nybble, but then rather than swap the nybbles it bitwise OR's the result and "b". It does this twice to get the least significant byte (big-endian)

So "&123" would be $3723

Re: Powerful (but large!) memory editor for G/S

Posted by: Torchickens
Date: 2018-02-12 18:05:13

Ah, I see. I will rebuild my code with the new base address and update the source.

Thank you for trying that address!


You're welcome. :) Happy to have helped.

The only downside with this method is you're stuck with one party Pokémon. Catching a new one will break the code. Going to try this on Virtual Console shortly. Do you know if you can still edit stored Pokémon in the box on those versions with no issues? That could make it useful for Pokémon farming.


The memory editor simply takes the character hex and subtracts 246. If that set the carry flag, the editor then subtracts 128. It then swaps the result and loads it into "b". This process is then repeated for the next nybble, but then rather than swap the nybbles it bitwise OR's the result and "b". It does this twice to get the least significant byte (big-endian)

So "&123" would be $3723


Ah OK, that makes sense. Thanks. ^^

Re: Powerful (but large!) memory editor for G/S

Posted by: Couldntthinkofaname
Date: 2018-02-12 18:14:17

The only downside with this method is you're stuck with one party Pokémon. Catching a new one will break the code. Going to try this on Virtual Console shortly. Do you know if you can still edit stored Pokémon in the box on those versions with no issues? That could make it useful for Pokémon farming.


Unfortunately, I lack a functional 3ds, and as such I am unable to use 3dsVC

Re: Powerful (but large!) memory editor for G/S

Posted by: Torchickens
Date: 2018-02-12 18:23:17


The only downside with this method is you're stuck with one party Pokémon. Catching a new one will break the code. Going to try this on Virtual Console shortly. Do you know if you can still edit stored Pokémon in the box on those versions with no issues? That could make it useful for Pokémon farming.


Unfortunately, I lack a functional 3ds, and as such I am unable to use 3dsVC


OK, thanks anyway Epsilon. I'm signing off now to get some sleep after testing so will (if possible) report back tomorrow.

Re: Powerful (but large!) memory editor for G/S

Posted by: Torchickens
Date: 2018-02-12 20:52:19
Back to report both the memory editor (party setup) and editing SRAM bank 1 to change the stored Pokémon worked on Virtual Console :)

[img]https://i.imgur.com/utNznJK.png[/img]

Also edited the Trainer House (SRAM bank 0) to fight a Mewtwo over Level 100. I didn't have many items so I got owned.

Re: Powerful (but large!) memory editor for G/S

Posted by: Couldntthinkofaname
Date: 2018-02-12 20:57:29

Back to report both the memory editor (party setup) and editing SRAM bank 1 to change the stored Pokémon worked on Virtual Console :)

[img]https://i.imgur.com/utNznJK.png[/img]

Also edited the Trainer House (SRAM bank 0) to fight a Mewtwo over Level 100. I didn't have many items so I got owned.


Good to hear, and thank you for testing!

Re: Powerful (but large!) memory editor for G/S

Posted by: SgvSth
Date: 2018-02-13 23:59:03



Hmm, wonder why some characters appear normally wheras some characters appear red? Oh well, I suppose it's a minor problem, and fixing it would be a waste of bytes :P


Hmm that's interesting. Wonder if it's related to the red border around the text "Balls". Seems that's true though, so far the memory editor is working perfectly on my side.


Thanks to this topic, and more importantly the footage at 5:50 in the video, it can be safely assumed to actually be the standard cursor in the menus for items.  If the letters could be adjusted to the right one space, then the effect would disappear.  (Of course, I doubt that it is actually causing any issues.)