This is how I learned about Portal in 2020
Programmer Humor
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
- Keep content in english
- No advertisements
- Posts must be related to programming or programmer topics
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
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.
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
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?
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:
- name+item manipulation
- a few bytes in several seconds
- copying existing button input buffer
- 60 bytes per second
- polling buttons in a loop
- only CPU-constrained, almost as fast as copying from the cartridge to RAM, literally fast enough to stream video
He is streaming data to the joypad faster than my internet connection
If he's on the actual hardware, the CPU frequencies are between 4.19 MHz~8.38 MHz. Not sure how that translates into joypad I/O speeds, but still cool.
On old consoles, inputs are usually directly memory-mapped, so you can use them as fast as the cpu can read them.
If inputs are crammed into bytes (which is also usual), you can probably create one custom byte per cpu operation via controller inputs, and copy it into ram for example.
If there are say 4 controllers, sitting next to each other, you can probably use an instruction that copies a 32 bit value, and copy 4 bytes to ram. If that copy takes 3 cycles (and the cpu has no fancy modern prediction), that would be 11 MB/s or 90mbit/s, modern lower-midrange internet speeds.
notyetEdit:
https://bgb.bircd.org/pandocs.htm#joypadinput
This info here seems to state we can only read 4 of the 8 buttons of gameboy controllers at a time, not 8. Also we might have to poll them and wait. Assuming the waiting is only for physical button debouncing reasons and not needed when you pump electric signals into a controller or mechanically operate it very rigidly, and assuming we can select one half and just keep reading, and taking the 4 controllers it mwntions in the text, that leaves 45mbit.
The data might have to be densified after writing, or there might be instructions that can do it in-flight without soowing the operation.
actualEdit:
Plain GB only has 1 controller, and the cpu only has 4.194304 (later fancier GBs had a mode to double that). Having only 1 controller doesn't really make it worse anyway, because the cpu is 8 bit with some limited 16 bit functionality. The insteuction to read from io memory and copy to ram, F2, takes 8 cycles. So I think that means we can do at most 2mbit/s, potentially less depending on how the assembly can be coded up. Definitely upper "the internet doesn't work" speed territory.
Thank you! The day I can give somebody an answer on this level will be the day that I am content with life.
...I was totally expecting DOOM.
Extremely entertaining and impressive
Yeah. If I could brag about doing this on my free time, I'd be a happy person.