this post was submitted on 10 Jun 2026
84 points (98.8% liked)

Programmer Humor

31765 readers
1605 users here now

Welcome to Programmer Humor!

This is a place where you can post jokes, memes, humor, etc. related to programming!

For sharing awful code theres also Programming Horror.

Rules

founded 3 years ago
MODERATORS
 

I know it's not self-hosting, but I thought it deserved a shoutout.

And when you're done laughing:
https://tasvideos.org/5384S

you are viewing a single comment's thread
view the rest of the comments
[–] lokalhorst@feddit.org 19 points 19 hours ago (3 children)

I watched it but I need to admit that I have no idea what is going on. Okay so at first he exploits some glitches of Pokemon Yellow, but then, like what the fuck? Can anybody explain to me what's happening please

[–] Feyter@programming.dev 8 points 6 hours ago

I try to add something to the understand.

Especially in old games, the program code (what happens if you press a button, what happen if your health bar goes to zero...) is often handled in the same memory structure as the game data (sprites, your entered player name, you inventory...) If you glitch a function that should edit a memory block of game data (e.g. reduce the players money or rename a Pokémon) to do it's operation on a program code block instead, you can reprogram the game while you are playing it and even make it a different game.

A different famous example is Super Mario Land. If you glitch trough the level borders the game is displaying all kind of data (game data and program code) as level blocks that you can walk on. Some of those level blocks are distructable, which is setting this memory block to a different value. By carefully destructing the correct blocks, you can change things like how many life's you have. But if you hit a wrong block, the game will potentially crash because you changed the program code to something that doesn't make sense.

[–] towerful@programming.dev 16 points 17 hours ago (1 children)

The first play part is setting up arbitrary (in this case, player-entered) code execution.
The 2nd part is entering the arbitrary code to be executed.
The 3rd part is the arbitrary code being executed.

From the description:

This is a Tool-assisted run of Pokémon Yellow, playing around with arbitrary code execution and testing the limits of Gameboy hardware.

Tool-assisted meaning a program entering the data into the game. A lot of times tool-assisted is in the context of a speed run, a TAS (tool-assisted speedrun).
A TAS file can be shared and perfected by many people, and reflects the most optimised way to finish a game as fast as possible.
Sometimes TAS runs include techniques that are "TAS only", an extreme example being alternating between left & right every frame for 30 seconds. Sometimes these "TAS only" techniques end up being performed by actual speed runners. And some TAS runs are "Human viable" as in "no techniques used that can't be executed by a speed runner".

Some TAS systems can interface with an actual console, pretending to be a controller (called "TAS Bot" I believe). Generally, they run the game in an emulator or interface with an emulator.

So, this video is about a TAS (well, the tool-assisted part, not necessarily the speedrun part) setting up arbitrary code execution (ACE) that then executes a bunch of user-entered code, which is what happens in the rest of the video

[–] lokalhorst@feddit.org 2 points 6 hours ago (1 children)

Thanks for the explanation. Sounds interesting, I'll try to read up on the topic!

One thing I am still confused about:

Does that mean Super Mario and Zelda are somehow stored as legacy code in the Game Boy Game version of Pokemon Yellow, or is the code for these games injected by the TAS?

[–] ChaoticNeutralCzech@feddit.org 5 points 3 hours ago* (last edited 3 hours ago)

Everything is injected. Even most of Pokémon Gold, including the code enabling GBC features (the font is the same tho). This can't be done on the NES because the character (graphics) is in CPU-inaccessible memory (and therefore ROM on most cartridges). There are several stages of the payload that write and execute each other:

  1. name+item manipulation
    • a few bytes in several seconds
  2. copying existing button input buffer
    • 60 bytes per second
  3. polling buttons in a loop
    • only CPU-constrained, almost as fast as copying from the cartridge to RAM, literally fast enough to stream video