Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Topics - Ganix

Pages: [1]
Site Announcements / Clarification on Recent Events
« on: December 25, 2019, 10:37:30 pm »
Okay, so I haven't exactly been up-front or honest with everyone, and I want to explain the situation and clear up any confusion and ambiguity behind things. I'll only post the immediately relevant information to keep this post as concise as possible, and I'm open to talking about anything that requires additional explanation or clarification.


Back in March of 2018, an individual hacked into Nintendo's internal network, and Nintendo found out about the intrusion in May 2018. That individual goes by multiple names online, but the one relevant here is the name Wack0. This is the only name aside from my own that I will be specifically mentioning.

In May of 2018, Wack0 assumed the mantle of the anonymous figure known as "__" and uploaded a mysterious ROM to the PRET Discord server with only 20 available downloads. This ROM happened to be the Space World 1997 prototype of Pokemon Gold and Silver ("SW97"). Those who were known to have downloaded the ROM were quickly added to a private team called Team Spaceworld ("TSW"), which was the same team that was planning on making a translation of the SW97 ROM.

I was part of TSW too, as was Wack0 -- from this point forward, any further mention of "Wack0" will be referring to his anonymous persona known as "__".

There were many Pokemon-related things that Wack0 had come into possession of, including tools used to make the games, development versions of the games, and even source code for the games. He entrusted some of what he had with certain individuals, whether that be knowledge, tools, or data. Many believed that he wanted some of that to get out publicly at some point; I personally believe that he wanted a lot of it to get out, but certainly not _all_ of it, although nobody can really know for sure. I was one of those people he entrusted things with.


In February of 2019, a group named Helix Chamber, which is a group dedicated to preserving and analyzing Pokemon history and media, announced that the ROM that was played at Pokethon by RacieB was created using prototype assets left over from development of Pokemon Red and Green, which was given to them by an anonymous donor, and that only the backsprites of scrapped Pokemon were given to them without the accompanying front sprites.

The truth is that I was the one who gave them those prototype assets. I was careful not to include any actual data from the game or any game assets, but rather interpretations of those assets, such as including the backsprites as PNG files instead of the actual files that the game uses for backsprites.

Unfortunately, GAME FREAK developed a newer, more efficient method to store front sprites (it was probably just raw data instead of encoded data originally), so the front sprites for those Pokemon literally just did not exist after the front sprites underwent optimization. The only reason the backsprites survived was because they didn't undergo the same optimization. If anyone was hoping for the front sprites for those Pokemon, then the only viable option would be to ask GAME FREAK what they looked like.


In December of 2019, the early sprites for a lot of Gen IV Pokemon were leaked online. I was the anonymous source of the sprites, and again I only transmitted them in an interpreted form instead of any actual data from the game or any game assets. These sprites are from January 2006, approximately 8 months before Pokemon Diamond and Pearl released in Japan. The only reason I can guess as to why Shellos and Gastrodon weren't in the list is because they probably weren't in the game yet.


In summary, the Pokemon Red and Green assets are real, and the Pokemon Diamond and Pearl sprites are real as well. I have nothing else in my possession, and I've shown everything I did have.

I deeply apologize for letting this go on for as long as it has; I haven't felt right about this from the very beginning, and it's a burden I'm finally glad to rid myself of. I've withdrawn from the dev/proto scene entirely, and I've recused myself from the actively participating in the Pokemon Gen 1-7 glitching scene. Additionally, both Wack0 and myself will be stripped of any and all ranks on GCL following this announcement, although I still plan to remain active and participate however I can.

Again, I didn't plan for things to get this out of hand or cause negativity of any kind -- I wanted to give people a glimpse of "what could have been" and the amount of work and detail that went into some of these in any way that I could, but even acknowledging their existence may have been saying too much, and I sincerely apologize for all of this.
In addition to the two existing debug menus found on TCRF's Ruby/Sapphire Debug Menus article (Sound Test and Pokeblock Test), I've found a way to access three other debug menus in Pokemon Ruby and Sapphire. I've included the addresses where each debug menu can be found, as well as GameShark codes that can be used to access the menus on actual hardware.

Note: All addresses below are specific to Pokemon Ruby v1.0 (U).


Function Address: 0814A414

This one isn't that impressive, but it's a debug menu nonetheless. The options are as follows:

1. 1st round
2. 2nd round
3. 3rd round
4. 4th round
5. 5th round
6. 6th round
7. 7th round
8. 8th round

I'm not really sure what these do, but it might be associated with badge limitations or something.

GameShark Code
A6696B14 E11802B1
872FAA40 5896C524

Press RIGHT+SELECT while paused
to access the SOGABE menu.


Function Address: 08083F6C

This one's a bit more useful. The options are as follows:

1. Search a child
2. Egg
3. Egg (male)
4. 1000 steps
5. 10000 steps
7. Breed an egg
8. Long name
9. Pokeblock Case

Most are intuitive as to what they do, but #1, #8, and #9 might be confusing. "Search a child" shows the contents of an egg if it's at the front of your party, while "Long name" replaces the name of the first Pokemon in your party with a long, generic name (ながいなまえぽけもん, or "Long Pokemon name"). "Pokeblock Case" deletes all of the Pokeblocks in your Pokeblock Case.

GameShark Code
4734D246 90FE8764
CC42BB92 3A9D71F0

Press SELECT while paused
to access the MORI menu.


Function Address: 080A9B28

Lastly, there's the MATSUDA menu, which mostly deals with Contests. The options are as follows:

1. Contest
2. Contest results
3. Contest (comm.)
4. Init comm. data
5. Set highest score
6. Reset highest score
7. Set all art museum items

If you select the "Contest" or "Contest (comm.)" options, you'll be brought to an interesting interface. Here, you can set all of the parameters for a Contest (trainers, Pokemon, stats, rank, moves, etc.) and initiate the Contest by pressing the START button. The bottom-right option exits the interface.

GameShark Code
E7F53B53 68B223B0
4C529E3E 7EB9CBA6

Press LEFT+SELECT while paused
to access the MATSUDA menu.
Generation IV Glitch Discussion / Submissions for Gen IV Void Glitch FAQ
« on: February 17, 2017, 09:48:01 am »
Hey guys, I'm going to start working on a commentary-like video (similar to Stryder7x's videos, but a bit more user-friendly) this weekend explaining many aspects of the void in Pokemon Diamond and Pearl (what it is / how it works / what influences it / safety / etc.), but I've been out of the loop for 5+ years now and I'm not entirely sure what's been made common knowledge and what isn't yet known.

It'd help a ton to get some help from the GCL community by hearing what you're unfamiliar with, what you'd like to see more explanation or detail on, things that aren't entirely clear, and other stuff like that.

That being said, what questions do you have about the void, or what would you want explained better?

NOTE: I won't really respond to questions on this thread, but any questions/requests have a good chance of making it into the video.
By utilizing the L-shaped tweaking pattern in Pokemon Platinum, you're able to cause a bunch of weird stuff to happen, such as slowing everything in Jubilife City to a crawl or modifying the map right under your feet

The fact that the L-shaped tweaking pattern causes really weird effects has been known for a while now and was previously known as the "????? Glitch", but after analyzing the effects of the tweak, I decided to give it a more descriptive name that mirrors its effects—the "Cascade Glitch".


In order to trigger the glitch, all you need to do is tweak using any L-shaped pattern in the fastest gear of your bike.

No really, that's it.


The reason it's called the Cascade Glitch is because of the one constant that always occurs each time this glitch is triggered—starting from the map data ID (0 - 665) that you refreshed the screen in, the map tile data, 3D model data, building data, et al. for each successive map data ID is written to RAM immediately after the tweak. The chaotic nature of such an effect means that freezes will occur a lot of the time.

However, because the data written to RAM depends on the map data ID that you refreshed the screen in, you're able to influence the data that gets written and, to a loose extent, where that data gets written. This means that altering progression flags is completely possible using this method.


So what exactly happened here?

As a little background information, the tile data for each map should be at least somewhat legible, such as the map tile data for lower Jubilife City below.

Code: [Select]

Okay, so that's not the actual map tile data for lower Jubilife City, but it gets the point across that it should at least be somewhat legible and able to be discerned just from looking at the layout.

First, to pull off this tweak, you'll want to refresh your screen anywhere in the area below. You can do this by opening the Bag or performing any action that forces the graphics to be redrawn.

Next, perform the tweak as shown in the previous GIF. If you need help locating the loadlines in order to do this, you can find them here.

After performing the tweak, the map tile data for Route 202 will be replaced with the data below.

Code: [Select]

Definitely not what it should be.

If you were to load the graphics for this area, it would look a little something like this:

(just a rough sketch; the actual visual data would probably look a lot cooler)


The section containing pointers to the currently-loaded map data (as well as the data that will be imminently loaded) can be found at Base + 0x8BAD0. This section has enough space for 3 areas, which is all that should ever need to be reserved within normal gameplay, since it's not possible to load 4 different areas in such quick succession. I'm guessing that's what the devs though, anyway.

I've created a visual representation of the pointer storage location as well as the pointers to the current map data for additional detail, found below.

The 4 pointers are arranged in the following order:
  • Top-Left
  • Top-Right
  • Bottom-Left
  • Bottom-Right

In this case, the 3rd pointer is the address of the garbled data. This means that the area we're currently in (Route 202) should be located in the bottom-left of the 4 currently loaded areas, which it is.


Doing this in Valor Lakefront yields some pretty amazing results. Instead of simply writing the data for each successive map data ID, it completely annihilates your base pointers. The base pointers located at 0x02101D20 just get overwritten with zeroes.

The result?

Since there aren't any base pointers, the game just kind of gives up and crashes. It also messed up my ASLR calculations in the VET script and caused all of my values to return 0.

If that kind of thing is possible just by tweaking, then I think that this may very well be our best chance at ACE in Gen IV.


I should be receiving an IS-NITRO-DEBUGGER development kit through the mail within the next few days, and I highly plan to analyze this glitch further on actual hardware. It's hard to tell whether some of these results are due to emulation errors or whether these would actually happen on a console.
Well, kind of. It's not a TAS or even eligible to be one, since it doesn't start from an SRAM reset.

After a crazy amount of effort and debugging, I've finally nailed down a method to beat Pokemon R/B/Y in as little(-ish) time as possible, starting from the point Professor Oak ends his speech. I know I could've just immediately triggered the Hall of Fame entry part (after the whole champion speech), but I wanted to at least make it a little showy.


Nothing really new here, just wanted to show that it was a thing.

It was also a great learning experience for me, especially since the only way I could get it to fully work on a physical console after cart swapping (without freezing) was to wait until it was in V-Blank. ( ̄▽ ̄*)ゞ
Generation IV Glitch Discussion / Obtaining Arceus via the Void Glitch
« on: January 10, 2017, 11:20:21 pm »
By using the RETIRE trick, it is possible to obtain Arceus via the Void glitch.

The steps below must be followed exactly. The RAM values being manipulated are loaded map data, and entering any map different than the ones you'd encounter by following the steps below may overwrite the data we need.

STEPS: (from the Poketch Co. door)

Step 1
1 S
17 W
14 N
2015 W
512 S
Save & Reset

Step 2
32 E
384 S
32 W
1792 S
128 W
32 S
192 W
64 S
160 W

Step 3
96 S
96 E
32 S
63 E
1 N
63 E (or 64 E if you've already been to Pal Park before)
191 N
1 N

Step 4
192 E
66 S
1 N

Step 5
192 W
64 N
64 W
32 N
128 W
64 N
64 W
96 N
226 E
Start -> RETIRE

Step 6
34 S
33 W
128 S
160 W
160 S
160 E
31 S
1 S
64 E
166 N
1 N
Start -> RETIRE



Each of the steps listed above loads a desired map property into memory, which we then travel to in order to encounter that property as our current map ID (in turn loading different map properties). Below are the target maps that get loaded—as well as the map property that determines the next map ID—in order to activate the RETIRE trick.

(2) Underground
    Sprite 1:
         X Coordinate: 392 (Route 221)

(392) Route 221
    Warp 1:
        Map ID: 393 (Pal Park entrance)

(393) Route 221 R1-01
    Warp 1:
        Map ID: 251 (Pal Park)

The maps and properties below lead to the Hall of Origin.

(45) Oreburgh City
    Sprite 13:
        X Coordinate: 316 (Lake Valor cavern)

(316) Lake Valor R1-03
    Sprite 0:
        Flag: 510 (Hall of Origin)

Once Arceus is captured, the only thing left to do is to disable Pal Park mode and exit the void, which is done by using RETIRE in the Pal Park map. This is the only way to initiate the StopGreatMarsh 1 function.

Note: Encountering maps with IDs greater than 558 will overwrite almost all of the map data, so RAM values 0x022F - 0xFFFF should be avoided.

Using the RETIRE option in Pal Park works as expected—asking if you'd like to leave, then either warping you out or doing nothing. However, when used anywhere else, the RETIRE option will immediately run the 4th script loaded in a given map.

An important distinction to make is that this does not refer to the script at index 3 of the map data. Instead, it refers to the order that the scripts are run. For example, the Hall of Origin has only 3 scripts, but the order that the scripts are run is as follows:

  • Script 2
  • Script 3
  • Script 1
  • Script 3

Since the 3rd script is loaded twice, using the RETIRE option runs Script 3, which happens to be the encounter script for Arceus.

EDIT: After doing research into a few rare cases of the game crashing after Arceus is caught, I noticed that the cause of the freeze was caused by users hacking the Shaymin event into their game. Specifically, the data at [Base + 0x23998] is permanently changed from 0x76 to 0x7A after using the Oak's Letter key item and opening up Seabreak Path.

This can be fixed by doing these steps in place of the 1792 S:

1152 S
32 E
64 S
32 W
576 S
Whew, it definitely took a few days, and the code may not look all that great, but I've finally come up with a method of using the GameBoy's joypad to write arbitrary bytes to RAM in as little time as possible with as few buttons as possible.

When 8F is used, the screen and sound will function as normal, but the controls will lock up and you will now be in INPUT mode. During this mode, any button you press will add that button's value to the specified byte in memory, with two exceptions: If you press the same button twice in a row, it will move on to the next byte; and if you hold (or press) the START and SELECT buttons together at the same time, the program will jump to the specified offset and start executing your code.

This allows for a 1-to-1 mapping of buttons to values for optimal speed while still providing all necessary functionality.

NOTE: Due to space limitations, you must press A once before you enter anything on the joypad. When you press A to select the USE option on 8F, the game registers that as the initial value to be executed. Pressing A before you enter your own code skips this junk byte, and it's also why HL is initially set to $D3FE instead of $D400 in the code below.

Item            Quantity
8F              x1
[Any Item]      xAny
X Accuracy      x254
Escape Rope     x84
Potion          x213
HP Up           x205
TM50            x63
Soda Pop        x240
TM48            x254
Burn Heal       x200
TM40            x178
Guard Spec.     x183
Rare Candy      x241
X Speed         x185
X Defense       x40
TM35            x79
X Attack        x134
Ether           x119
X Special       x24
TM28            xAny

Code: [Select]
    ld l,$FE            ; Destination = $D3FE
    dec e               ; Zero out E
    ld d,h              ; DE = $D300
    inc d               ; DE = $D400 (Code Start)
    push de             ; Push onto the stack for later RET

    inc hl              ; Go to the next byte

    call $3FFA          ; Joypad polling subroutine
    dec a               ; - Padding -
    ldh a,($F8)         ; Get the current held button
    cp $0C              ; START + SELECT = exit
    ret z               ; Jump to arbitrary code ($D400)

    ldh a,($B2)         ; Get the most recently released button
    scf                 ; - Padding -
    or a                ; Check whether a button was released
    jr z,Check_Input    ; If not, keep looping until one is

    ld b,e              ; - Padding -
    cp c                ; Check if the button was pressed twice
    ld b,d              ; - Padding -
    jr z,Next_Byte      ; Move to the next byte if so

    ld c,a              ; Backup the previous button
    ld b,c              ; - Padding -
    add a,(hl)          ; Add button value to current value
    ld d,b              ; - Padding -
    ld (hl),a           ; Save new value in memory
    ld b,h              ; - Padding -
    jr Check_Input      ; Loop until manually RET

One of the things that I use this method for the most has to do with cartridge swapping capabilities. The setup below simply puts P14 to low and enters STOP mode, followed by a RET instruction to continue normal execution. This means that you can enter STOP mode, swap cartridges, then press any button on the D-Pad to return execution.

Code: [Select]
ld a,$EF
ldh ($00),a

To execute the code above, simply use the 8F item, then press the buttons below in sequence. Each line represents a byte written to memory, with the first line skipping the junk byte and the last line jumping to the written program.


NOTE: If you pop the cartridge out, put the same cartridge back in, then exit STOP mode, then the game will continue executing as normally. However, the values written to RAM remain there, so in order to re-run the stop routine above, the only buttons you'd have to press are START + SELECT.

Putting in the same combination twice without resetting will effectively double the existing program's bytes in RAM, since this is an additive approach. One pretty rad workaround is the polymorphic aspect of the setup—you can alter the items in your bag (to remove padding, etc.) and save the game with your new RAM writing bulldozer. ;D

PS: This method was successfully tested on Pokemon Red and Pokemon Blue hardware; I'm not sure about Pokemon Yellow yet, but it should work just fine.
Heya guys,

After a good bit of going back-and-forth to the Wiki (and later back-and-forth to a text file) in order to look up values for the 8F glitch, I decided to write a program in C using lookup tables that could directly parse gbz80 assembly and machine code, then output the results to the console pretty quickly (~12 milliseconds) in a variety of outputs.

You can check it out over at its Github page, 8F Helper.

As an example of its output, I took the assembly instructions for the perpetually resetting save file by Wacko and converted them to 8F items with the utility.

Code: [Select]
ld l,$6E
ld (hl),$36
ld a,$D3
ld ($D36F),a
inc b
ld c,$1c
ld h,$78
ld l,$48 ; 1c:7848: SaveSAVtoSRAM
ld b,c
call $35d6 ; BankSwitch
jp nc,$1f49 ; SoftReset

Command and output:
Code: [Select]
root@gbdev:~# gbz80aid -o gen1 -f test_code.asm

Item            Quantity
X Accuracy      x110
Max Revive      x54
Lemonade        x211
TM34            x111
TM11            x4
Awakening       x28
Carbos          x120
X Accuracy      x72
X Attack        x205
TM14            x53
TM10            x73
Old Amber       xAny

Hope it can be of use! ;D
Pages: [1]