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 - Epsilon

Pages: [1] 2 3 ... 21
Generation I Glitch Discussion / Re: Odd thing in Pokemon Yellow.
« on: February 08, 2019, 04:44:35 pm »
That just executes the script where the store owner gives you the potion. Nothing to see here.
General Discussion / Re: The Glitchy Thread of Topiclessness (#3)
« on: February 07, 2019, 03:38:35 pm »
Really? I just assumed all the activity was in Forum Games, which I had muted.
Forum Discussion / Re: How do you sticky a topic?
« on: February 01, 2019, 11:43:20 am »
Also why is this is in Gen 1 glitch discussion
General Discussion / Re: The Glitchy Thread of Topiclessness (#3)
« on: January 28, 2019, 06:20:10 pm »
Everyone was villifying a Discord server owner because the server disappeared. I said I didn't wanna villify him until I get the full story.

Turns out the server was TOS'd and his account was beaned. Luckily, his alt was not.


That's an oof.

Discord has done a lot of out-of-place TOSings recently. The events with Quackity HQ is one that comes to mind.

Still, not even remotely as bad as YouTube, who specifically targeted Mumkey Jones despite no clear evidence that rules were broken. His girlfriend even made a channel for him, but that was terminated before he even managed to crank out two videos.
Pokémon Discussion / Re: What is your favourite Pokémon game?
« on: January 28, 2019, 11:57:53 am »
Pokemon White.

First pokemon game I ever played, and wow, did my nine-ten year old self love it. Every aspect of it mesmerized me, especially the capture of legendary pokemon - Likely because it was the first major "game" i had ever played. The first legendary I encountered was Thundurus. Like a doof, I used my Master Ball on it, but it quickly became my favorite pokemon.

White would have much more of an impression because of a friend I had from 3rd through 5th grade, an student who was known as the class "walking calculator". Every now and then, we would go to the local Chinese restaurant (a friend of his had a family business), and played White on our DSs. It was a blast, so much so that we nearly got kicked out of the Chinese place on multiple occasions. At school, we would talk about the game nonstop. We came up with all kinds of wacky speculations - The one that was most popular between the two of us was that it was somehow possible to take a bus from Unova to Sinnoh. I was obsessed with this theory, because I really,really wanted to catch Giratina. The friend would later move to New York, but those experiences had a lasting impression on me.

Man, childhood was awesome.

I also played White 2, but that wouldn't be nearly as important to me, outside of the fact that my then ~12 year old mind would later replace thundurus with White Kyurem as my "new favorite pokemon", because of it's "sheer epicness" or whatever I determined signified it's superiority over the Zekrom-version and other pokemon.
Good morning,

I am beginning to learn ARM assembly, and there's one concept i'm not sure I quite grasp.

From ARM's docs, it would seem that if I `bx <reg>|<val>`, the value at <reg>  or <val> respectively needs to have bit 0 set if it is switching from ARM >>> Thumb, and reset if it's going from Thumb >>> ARM.

Would that entail an alignment of the subroutines, to ensure that the bits are set/reset respectively?

Example (GAS Assembler):
Code: [Select]
.align 2
EpsisAmazingSubroutine: @The alignment of this subroutine means that bit 0 is reset, so bx from a thumb subr will switch back to ARM
    stmdb sp!,{lr,fp}
    add fp,sp,#0
    sub sp,sp,#4

    @ var at fp-4 is EpsisAmaingInteger

    mov r3,#3
    str r3,[fp,#-4]

    @ EpsisAmazingInteger is now 3

    sub r0,fp,#4 @ Nab ptr to EpsisAmazingInteger
    bxl add3toInt @ Swap to thumb and call subr

    @ EpsisAmazingInteger should now be 6
    @ Close stack frame and leave

    add sp,fp,#0
    ldm sp!,{fp,lr} @ ARMv4 doesn't change state on pop {pc}
    bx lr

.align 2
.byte 0x69
add3toInt: @ The alignment, coupled by the byte, should set bit 0 of this address
    @ We don't need a stack frame here
    ldr r3,[r0]
    add r3,r3,#3
    str r3,[r0]
    bx lr @ (Hopefully) swap back to ARM and branch to link reg

Note: Assume CPU is ARM7TDMI
Multimedia Discussion / Re: What song are you listening to right now?
« on: January 20, 2019, 11:14:40 pm »
C418 - The End

Skip to 8:00.
Wiki Discussion / Re: 0x vs. $
« on: January 20, 2019, 10:06:27 pm »
If the reader does not know the meaning of one, they most likely will not know the meaning of the other. The contrary applies - if one knows and comprehends the meaning of one, the other should be under their belt as well.

I'm under the impression that if clarification is needed, it can be provided in brief. They both denote the same thing, so i'm sure it won't be an issue. Consistency between one or the other may even cause minor problems, as there as there as some familiar with 0x and others familiar with $.

That's my 0.02¢.
Video Games Discussion / Re: (!SPOILERS!) Deltarune Discussion Thread
« on: January 10, 2019, 06:52:24 pm »
Y'ever finish Jevil, ISSO?
I'm very unsure about how this works. The game should just reset, not do this.

It's resetting the game with Interrupts enabled. This means that interrupts are enabled while pretty much all RAM is being trashed. I didn't trace what exactly happens, but based on interrupts being enabled at that time there's a pretty big chance that's causing the effect.
Generation I Glitch Discussion / Re: ItemDexJP/B:000 theory
« on: December 19, 2018, 11:21:49 am »
Thank you for your lovely thorough reply Epsilon.

Yes, I had tested item 0x63 before and got the same results as you; item 0x63 was the only potential LOL glitch compatible item not executing a writable memory region.

If I recall correctly, there was one that, albeit jumping into memory, was able to jump back into the overworld loop. The memory it jumped into I believe was late HRAM, which may be somewhat predictable? I'll see if I can dig it back up to find out what exactly happened there.

About there being no need of a screen data saving glitch item (for 0x00/0x63 LG), this may not be true; as in the English games a copy of the screen without the Start menu being open is saved into memory once opening the menu. The purpose of the screen data saving glitch item (e.g. EN 9F) is to save what is on the menu into memory rather than from the overworld. However, I don't know for sure whether this also applies to the JP Blue Version.

I knew that. What I meant by "we need not an item that backups the screen data to buffer 2", is that we need not an item that does "exactly that"


The tile at X=2 Y=5 is at C406 in the main tilemap buffer and CDE2 in buffer2. Let's just say that, after the player opened the items menu, the values at both addresses were 0x38. We'll just say that 0x00's random name corrupted the value at C406 to C8. While there are no direct ways to write C406 to CDE2, we can force another backup to buffer 2 by using item 0x63 and reopening the items menu. After that, both values, C406 and CDE2 would be C8 in this hypothetical scenario.
Generation I Glitch Discussion / Re: ItemDexJP/B:000 theory
« on: December 18, 2018, 12:06:38 am »
Before I can answer this, lets do a brief recap of exactly how the LOL glitch works, that way we have context:

 - The player enters the overworld loop during batte, tricking the game into beleiving that the player is sill in battle
 - The player opens the items menu, causing the game to save it's current tilemap to wTileMapBackup2
 - The player presses "a" on an item that does not have a 0x50 in it's name within 20 bytes. This causes CopyData to write the unterminated string in a buffer neaby wTileMapBuffer, which CopyString will then read into. It will then write to it's own buffer, eventually overwriting wEnemyMonSpecies2, which determines which pokemon we get after throwing the master ball.

So by that logic, if we wanted to perform the LOL glitch by using a tile from B:000's name, we would need:
 - An item that jumps back to the overworld loop in battle
 - An item that jumps back to the overworld loop outside (in Eng-Red, both are satisfied by 9f)
 - A means of backing up the tilemap to buffer2 with B:000's name on screen (Recall that the last time the game normally does this is before the items menu opens!)

And thankfully, in Jp-Blue,we have all of theese!    ...except the first one.


0x63 is a glitch item in Jp-Blue that, through a miracle of code flow, jumps us back to the overworld loop!

So why can't we use it during battle? Well, part of the reason why it reaches the overworld loop in the first place is because, shortly after it's execution, it performs three pops, and then a ret. When not in battle, after the three pops, the ret instruction will take you to a part of the ROM that eventually leads to the overworld loop.But it seems that, during battle, the stack is not so in our favor. Once it reaches the ret instruction, it points to a location in ROM that eventually leads to an invalid opcode. Bummer.

Because if the abnormality with the stack, we can't use 63 to reach the overworld loop during battle. IIRC, I had luck with another glitch item that reached the overworld loop, but that I believe executed code from memory, so it's reliability may be called into question.

Backing up tile data to buffer 2

combined with a screen data saving glitch item?

No need!

In Jp-Blue, the tile that gets written into wEnemyMonSpecies2 is at X=2 Y=5. This is well out of the way of the Start menu, and it gets changed occasionally by B:000's name. Because of this, we able to trigger a backup of X=2 Y=5 to wTilemapBackup2 by jumping back to the overworld loop, and re-opening the items menu!

We're out of battle here, so 0x63 should work juuuust fine  8).

In conclusion, the setup would go as follows:

 - Get 0x00 and put in the first slot. Also grab 0x63 and some Master Balls.
 - Get into a battle
 - By some means, get into the overworld loop. (when testing, I used an item, breakpointed before the item was used, and then forced a jump to the overworld loop. Hopefuy a way can be found!)
 - Correct the graphics using a warp
 -  Open and close the items menu (with 0x00 in your first slot), until you are comfortable with the tile at X=2,Y=5 (sometimes 0x00's random name wont corrupt it,just be patient!)
 - Make sure there is an 0x50 subtile close to, but not before, X=2,Y=5
 - Use 0x60
 - Open the items menu (backs up X=2,Y=5 to buffer2)
 - Press "A" on 0x00 (not guaranteed to be unterminated) or another unterminated glitch item
 - Throw a Master Ball

Will look into how reaching the overworld loop in battle might be possible.
General Discussion / Re: The Glitchy Thread of Topiclessness (#3)
« on: December 15, 2018, 06:01:17 pm »
Genocide is designed to be frustrating to complete.
I like the idea behind that, but just don't have it in me to spend an entire day repeatedly failing an action-command-based boss (I generally get them down to about 1/3 health at best, and that's after resetting and making sure to pick up all the best items for it.) Maybe when the game's had more time to sit with me I'll feel more determined.

To save your own sanity, I recommend practicing the sans fight (Hell, it even works on mobile!)

As for UU, you're just going to have to tough that out. Best wishes to ya, though!
So what's happening is, what would be interpreted as NPC movement data is invalid beyond certain pointers, and therefore points to a glitch location to execute ACE?

Take a gander at this line pokered's home.asm.

As you can see, it takes the value at CC57, takes a pointer to a list of pointers to movement script pointer tables (phew!), and adds the two. It then grabs the pointer it finds there, puts it in hl, and makes a call to CallFunctionInTable.

So yeah, i'm assuming that's what's going on there.

Something else to note: The function I linked loads the value at CF10 (responsible for the function number in the pointer table) into the accumulator before making the call to CallFunctionInTable. I do wonder if that value may change the ability to do this trick.

EDIT: Some semi-important findings in this regard

The way this works is because the function I originally linked adds CC57 (which is DDh in the trick) to to the pointer to the pointer table which points to the other movement script pointer table. It gets 3193, which points to D5h and F5h. CallFunctionInTable reads these values and calls F5D5.

However, CF10 affects what pointer CallFunctionInTable calls when called with RunNPCMovementScript. This means CF10 must be zero or else this will not work!

Not sure what changes CF10, however.

Edit2: Something else to note:

While Torchic included setting CC58 to 0 in her instructions, this is actually unnecessary. 3193, which contains the "pointer" to FDF5, is in the "home" ROM bank - meaning it's irrelevant as to what the ROM bank is at the time of CallFunctionFromTable.

but I wonder if it works in battle?

No. NPC Movement scripts are not executed during battle.
Pages: [1] 2 3 ... 21