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.


Messages - TheZZAZZGlitch

Pages: [1] 2 3 ... 10
1
Generation I Glitch Discussion / Re: PP (not) Up
« on: September 30, 2019, 11:18:39 am »
That's because some glitch moves can have PP Ups already applied by default.

Let's look at a normal move first. It has a base PP value of 0x14, meaning it has 20 PP.
Now, what happens if we increase its PP with a PP Up? The game has to keep track of that somewhere. In order to save space, the highest two bits of the base PP value are used for this purpose, since normal moves would never have base PP above 64.
So after using a PP Up, the base PP byte corresponding to the modified move would change from 0x14, which looks like this in binary:

00010100
(red = number of PP Ups applied, blue = the move's base PP)

Into 0x54 (01010100), to represent that one PP Up was used on the move. Another PP Up would change that to 0x94 (10010100), then 0xD4 (11010100). After that, the game would not allow using more PP Ups.

Now, what happens with glitch moves? Their base PP information is taken from arbitrary data, so their base PP can have the highest bits (blue bits in the examples above) already set by default!
Let's look at TM04. It actually has 0xD2 base PP, which in binary, looks like this: 11010010. So this move has 18 base PP with 3 PP Ups already applied.
That's why no PP Ups can ever be applied to this move. The game thinks that 3 PP Ups were already applied, because the base PP value of a glitch move has the highest "PP Up" bits already set.

Another example: The glitch move TM11 has 0x49 base PP. Converting to binary, we have:
01001001
That means it has 9 PP, with 1 PP Up applied by default. So you can apply two additional PP Ups before the limit is reached.

***

Edit: This explanation is true, but does not really apply here. TM13 has 7 plain PP (0x07), so it should take 3 PP Ups normally. Did you obtain TM13 by leveling up 0xFA, or did you GameShark/edit the move in? How much PP does the move currently have when viewed in battle or in the stats screen?
2
0xEB's name is very interesting, because it features a lot of 0x4E and 0x4F control characters.

0x4E is the new line character. It moves the cursor two lines down. Why two lines? That's how textboxes are laid out!



0x4F is a similar control character, but this one puts the cursor always at specific coordinates x=1, y=16.

The name is really: <garbage tile 0x32><new line><another garbage tile 0x6D><new line>q<new line><yet another garbage tile 0x12><move cursor to x=1,y=16><yet yet another glitchy tile 0xD4><move cursor to x=1,y=16 again>.

An interesting thing is that tile 0xD4 is empty, so it's invisible under normal circumstances. But there are some places where it can be seen. For example, try selecting 0xEB in the party screen and choose "SWITCH". The text in the textbox below will change to "Move Pokémon where?". Now cancel out. The "W" in "where" will disappear for a split second! That's because it got overwritten by the invisible tile 0xD4. Now you can't unsee it.

Lastly, here's a small map to finish it off :p

3
General Discussion / Re: The Glitchy Thread of Topiclessness (#3)
« on: March 07, 2019, 10:08:03 am »
Oh, the classic "communicating through GitHub PRs". Remember the launch of fools2018?
Issue #1: commits not showing
4
Generation I Glitch Discussion / Re: Level 32 glitch trainers?
« on: March 07, 2019, 08:24:17 am »
Remind yourself that the LP you referenced (Let's horribly break Pokemon Blue) is 11 years old.
First, it was heavily Gamesharked, and if you're not using the same GS codes as the author, you'll probably get inconsistent results.
Second - at the time, a lot was still unknown about the game, and this was an era before disassemblers/debuggers/static code analysis became mainstream. Back then, people were just theorizing about how things work by observing the results (also known as "empirical glitching"). The point is, you probably shouldn't take that LP as a source of up-to-date, reliable Pokémon glitch knowledge.

Long answer to the question

In that LP the Gameshark code 01F4D8CF was probably used, to force an encounter with Lorelei. The thing is, this code not only changes the trainer to 0xF4 (Lorelei), but also changes all of her Pokémon to 0xF4 (the glitch Pokémon you wanted).
So her roster isn't anything that comes from the game directly. It's just a side effect of the Gameshark code that was used. There is no roster anywhere in the game that has six 0xF4 Pokémon, it's just Gameshark.

When using the Gameshark code and encountering the trainer in the grass (this also happens if you encounter a trainer through the Old Man trick, because shore tiles are really just grass tiles), you'll get rosters from a normally unexistent trainer class #256. Here are some details about it.

As you can see on the list, the roster number that has level 215 Pokémon is roster #03. You can use this GS code to change the current roster to roster 3, which will give you level 215 Pokémon: 01035DD0.

This way, if you encounter a trainer in the grass, you'll get the roster 3, which is:
TRAINER (hex CD) - level 215
Pidgeot (hex 97) - level 215
Ivysaur (hex 09) - level 215
TRAINER (hex CD) - level 215
Nidoking (hex 07) - level 215
Fearow (hex 23) - level 215

Of course, keep in mind that the GameShark code used to encounter Lorelei will change this roster into:
Glitch (hex F4) - level 215
Glitch (hex F4) - level 215
Glitch (hex F4) - level 215
Glitch (hex F4) - level 215
Glitch (hex F4) - level 215
Glitch (hex F4) - level 215

For curiosity, if you want to see her real Pokémon roster, just like it appears in the article, try activating the Gameshark code, going into grass, then once you're on the "LORELEI wants to fight" textbox, disable the code.

There's also a natural, no-cheating-devices method of changing the roster. The trainers encountered in grass via Gameshark/Old Man trick will use the last roster ID that was loaded in memory. So if you fight different trainers beforehand (real trainers, not Gamesharked trainers!), you can change the last loaded roster ID.
See: https://www.youtube.com/watch?v=3Zvl4YkeSJM (turn on subtitles, they contain the old YouTube annotations).

Short answer

Use these GS codes:
01035DD0
01F4D8CF
5
There is a Daycare cloning script, which is easy to set up. Store the Pokemon you want to clone into the Daycare, take it out, use 8F, take it out again, repeat to infinity.
6
Lovely Low Kick

7
I think we should isolate all of these questions into a nicely formatted Wiki page, and refer any newcomers there.
I might even help create such a short guide in my free time.

Also, giving this thread an official name and explicitly inviting newcomers here, while everything over here is still under construction, might not have been a very good idea.

Some common questions that will need to be addressed:
- What is ACE
- What is the most simple, up-to-date method of obtaining 8F
- What is bootstrapping, how to bootstrap 8F
- Will 8F work on all languages and game revisions? What are the alternatives?
- 8F just crashes the game, wat do
- 8F worked previously without any problems, but now it crashes...
- I tried this specific setup, and it didn't work! What happened?
- My game crashed and the save file got corrupted... is there any way to recover it?
- Are there any safety precautions I can take to make sure my save will never get corrupted by accident?
- Can I permanently modify the game using ACE?
- Is there anything that ACE can't do at all? Are there any limits?
- I've seen the "universal pseudo-Gameshark setup", but it needs a "memory address" and a "value". What are those things?
- How do I know which memory addresses do specific things I need? Is there any documentation on that?
- I have a memory address from English R/B - is there any way to find out the equivalent address in Yellow and other games?
- I've seen some complex setups that did incredible things, like making Mew appear under the truck. How do I do that?
- I want to write my own scripts. Where should I start? Are there any resources on this topic?
- How do I convert gbz80 assembly code to an item list and vice versa?
- I'm converting my code into an item list, but I keep getting glitch items, which are hard to obtain. Can I do anything about it?
- I looked into some setups, and some instructions in them did seemingly useless things...
- Having to write codes by using items is starting to drive me insane... Is there a better option for getting my code into the game?
- How do I know the address of a specific subroutine in the game, like GivePokemon?
- I've seen save files that automatically run some code. How does this work? How do I do that?
- Is there any way to have my code run continuously in the background, to have it persist between maps for example?

And potentially a lot more.
But most importantly:
- All I care about is getting a GameFreak Mew to transfer into Pokemon Bank. Show me the easiest way of accomplishing just that.
8
I analyzed how this works:
- The deathwarp and the two trainer battles advance the map script index to 0x06 (three trainer encounters in total, each one advances the index twice; Crystal_ once did a nice video explaining how trainer battles affect the script index values).
- Viridian Forest script 0x06 happens to point to $5180, bank 0x18.
- At this address we have some accidental code, created by interpreting the trainer encounter text (ViridianForestText4) as CPU instructions:
ViridianForestText4:
  ld ($5A21), sp
  ld d, c
  call TalkToTrainer
  jp TextScriptEnd

Which triggers a glitch textbox, but thankfully, does nothing harmful to the game.
- Then, we trigger another trainer battle in Viridian Forest, which advances the current map script to index 0x08.
- Viridian Forest script 0x08 happens to point to $24F4.
- Again some accidental code, but this time, it was sourced from the item pick up text (PickUpItemText):
PickUpItemText:
  ld ($5C3E), sp
  call Predef
  jp TextScriptEnd

This one however isn't so nice to the game, since it executes an invalid predefined function 0xF4 (calling Predef with A=0xF4).
- Predef 0xF4 happens to execute code from $F808. Which is the echo RAM equivalent of $D808
- Arbitrary code execution magic happens

Any trainer can be fought as the last one - I believe the only reason they chose the Bug Catcher closest to the entrance is because he would be the fastest to get to in a speedrun.

Adapting this exact method for general use is most likely impossible, since it requires insane levels of luck manipulation, and planning for it from the very beginning of the game. But a similar procedure can most likely be applied to any other map - so there should be a way to find a different route with different trainers, where the code execution happens from a more predictable location (like Pokemon boxes or inventory data).

Also, it's funny to look how a strategy originally meant for the A Button Challenge has inspired a new speedrun route, along with a new way of achieving arbitrary code execution.
9
Generation I Glitch Discussion / Re: J glitch item
« on: July 09, 2017, 04:12:07 pm »
'j.' is a glitch item with hex ID 00.
You get to see it a lot during item underflow, simply because 0 is a popular number and it occurs many times throughout the game's memory. Which is what item underflow really is - viewing the memory beyond inventory data as items.

This item happens to execute code from $01D1, which is in the middle of map header pointers. This garbage code (which isn't really game code, but the game has to interpret it somehow) eventually causes a jump to $BE42, in the middle of SRAM.
It could be potentially used for arbitrary code execution, although only theoretically, since there's no easy way to control data at $BE42 without cheating or resorting to another form of arbitrary code execution.

j.'s sell price of 414925 is completely accidental.
The game keeps a table of all item prices. This table only has 96 entries. Item 0 is actually interpreted as item 256, so the game tries to grab the 256th entry of this list, and ends up reading past the table.
Just so happens, item names are located there, and the game reads the last 3 bytes of "X ACCURACY(end marker)" (0x82, 0x98, 0x50) as an item price.

So, the item's buy price is 829850.
The sell price is dynamically calculated by the game to be the half of the buy price.
829850 divided by 2 is - you guessed it - 414925.
10
It is possible with arbitrary code execution - a subclass of glitches that allows the player to run any code they desire on the console, essentially making it possible to do anything with the game. The most popular and most human-friendly method of acquiring arbitrary code execution on Gen I games is through a glitch item called 8F.

Once it's possible to run any code within the game, one might construct a stub of code that will run constantly in the background and would keep overwriting the encounter tables - just like a Gameshark would do.

Note that this isn't exactly changing the encounter tables "permanently". It only creates an illusion of a permanent change, by constantly overwriting the encounter tables loaded in RAM. If the save file is deleted, everything will be back to normal. Even restarting the game and reloading the save file would reverse the process. We can get around the second restriction by adding some extra code, but the first problem cannot be avoided.

There's at least one thing that glitches cannot and will never be able to do - permanently change the ROM. It's impossible to permanently modify the cartridge by just pure glitching. With enough work it's possible to simulate the ROM changes, by loading code into RAM and running it there - but it's still your original cartridge on the inside. Wipe the save file and everything will be gone.
11
Arbitrary Code Execution Discussion / Re: Nothing seem to match
« on: June 21, 2017, 04:36:20 pm »
VBA sucks. But there are also VBA-RR and VBA-M, which suck less.
I sometimes use VBA-RR. Obviously not for first-time glitch research, because of rather bad emulation accuracy. But there are tiny features that make it worth using in some scenarios.

- Native video recording with little to no CPU load. It also doesn't need an external process for video encodes.
- Really fast turbo - with sound off and reduced resolution it can easily go up to 8000% on my computer, compared to 600% max on other emulators.
- Easily accessible and simplistic Lua scripting. Also, if you replace the DLL in VBA's working directory, it works with Lua version 5.3, which adds some really useful features (*cough* bitwise operators *cough*) - other emulators tend to have Lua compiled in and stuck at version 5.1.
- It can have multiple instances of memory viewer (aka hex editor) open at the same time. I can have multiple hex views, all centered on different addresses.
- The fact that the SRAM is never closed in the memory editor is sometimes useful, because it allows for direct save data editing without having to mess with the SAV file. Just change the SRAM and you're set.

I'd use VBA-M, but it doesn't have Lua scripting, so VBA-RR is the latest revision that has all of these features.

My preferences are:
- VBA-RR for video recording and "checking things out" in general
- BGB for more formal glitch research
- Bizhawk for TASing

I highly recommend to everyone using plain old VBA: Switch to VBA-RR.
It's really the same emulator, but it has Lua scripting and rudimentary TAS features.
And although VBA-RR's emulation accuracy is still bad, it's infinitely better than classic VBA - it properly handles wrong bank switches, VRAM accessiblity and echo RAM.
12
Yeah, save wipes with rst 38 crashes are really common on VC (I once erased my save by accident too).
This makes me think that the VC doesn't emulate SRAM locking at all.

People tend to corrupt their saves because they save right before trying out glitches, for safety. But this actually causes the game to switch to SRAM bank 1, which contains save data. So if some wrong code manages to later unlock SRAM (which might not be even necessary, since it always seems unlocked on VC) and overwrite its contents, the save data is gone.

It's a good idea to view any non-glitch Pokemon's stats before doing anything potentially game-crashing. This causes the game to switch to SRAM bank 0, which doesn't contain any important data. So even if something goes wrong and SRAM is overwritten, nothing bad will happen. The bad code would have needed to not only unlock the SRAM somehow, but also switch to bank 1/2, which is highly unlikely.
13
Pokémon Discussion / Re: Pokemon Direct - June 6th, 2017
« on: June 07, 2017, 01:57:32 am »
07:07, 6/6: Gold and Silver coming to the Virtual Console! Compatible with Pokemon Bank!

Can't wait for the Coin Case glitches flooding Pokemon Bank with completely legit Celebis!
14
Pokémon Discussion / Any text dumps of Japanese Gen I games?
« on: April 12, 2017, 07:17:45 am »
I really need to find a full text dump of any Japanese Gen I Pokemon game (don't ask why ;))

Any attempts of Googling it failed miserably, even when I entered the keywords in Japanese.
I also recall seeing such a text dump at least once in my life, so I'm sure it exists.

Normally I'd just attempt to make my own dump, but my knowledge of Japanese is really limited and I wouldn't really be able to separate the real ingame text from false-positives. If someone already made it, this would save me a lot of work.

The question is: are there any text dumps of Japanese Gen I Pokemon games? And where can I find them?
15
The problem here is something called VRAM inaccessibility.

When the LCD is on, VRAM can only be read (and written to) during short, specific periods of time.
The underlying reason for this is that most of the time during a frame, the graphics hardware is busy drawing graphics to the screen, and it doesn't allow anything to modify or access its data when it's working on it. There are only small periods each frame that the graphics controller takes a break and allows graphics data to be modified.

Being more exact, the time periods are called vBlank (short for 'vertical blanking interval') and hBlank ('horizontal blanking interval'). The first one occurs when the hardware finishes drawing the current frame, but hasn't yet started drawing the next frame. The second one happens if the hardware finishes drawing a single line of pixels on screen and goes to the next line. If graphics are actively displayed on the screen, these are the only periods when VRAM can ever be touched. Otherwise, the VRAM data sits there locked out from access.

Any write on "locked" VRAM won't do anything.
Any read on "locked" VRAM will return 0xFF, regardless of what the address really contains.

We really don't know when the code responsible for checking evolution data is going to run. It might, or might not run during vBlank. Or it might even run partially during an hBlank, and partially after hBlank has ended. It's impossible to predict - it comes down to microsecond-precise timing, which for a human player is essentially random.

So this bit of data:

10 10 10 10 10 10 08 00 00 00 10 10 10 15 12 1F 12 00 00 00

Will usually end up looking something like this when read by the game:

10 FF FF FF FF FF FF FF 00 00 10 FF FF FF FF FF FF FF 00 00

The 0xFF bytes are there because the subroutine tries to read VRAM data outside of vBlank/hBlank, and it ends up just reading 0xFF bytes.

The result of course comes down to timing, so it could be possible for this pattern to be shifted to a different position:

FF FF FF FF FF 10 08 00 FF FF FF FF FF FF FF 1F 12 00 FF FF

I haven't tested this in more detail, but it should be possible to have this pattern shifted in such a way that the Mew evolution data could still be read. It might just take a lot of time.

I think it would be more practical to not bother trying to put the appropriate data into VRAM, and focus on making the VRAM data slide through to SRAM and try to get the appropriate data into SRAM instead (maybe there's a Pokemon that has a "01 01 15" sequence in its decompressed sprite, and if not, we can just corrupt that with 'M/Missingno. until we get it).

Edit: Was too late :(
Pages: [1] 2 3 ... 10