• lokalhorst@feddit.org
    link
    fedilink
    arrow-up
    25
    ·
    20 hours ago

    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
      cake
      M
      link
      fedilink
      arrow-up
      12
      ·
      8 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
      link
      fedilink
      arrow-up
      24
      ·
      19 hours ago

      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
        link
        fedilink
        arrow-up
        5
        ·
        8 hours ago

        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
          link
          fedilink
          English
          arrow-up
          7
          ·
          edit-2
          4 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

          The Ocarina of Time “Triforce%” TAS speedrun activates some debug code such as the F-Zero spaceship model

          • printf("%s", name);@piefed.blahaj.zoneOP
            link
            fedilink
            English
            arrow-up
            1
            ·
            edit-2
            31 minutes ago

            What have you done. I saw your comment the moment I entered my flat. I shouldn’t have pressed the link (pun intended). But I did.

            I didn’t change, shower, eat or any other of my coming home on a workday routines. I just watched. And cried at the end.

            My childhood is now complete. Thank you 🫶

      • Redjard@reddthat.com
        link
        fedilink
        arrow-up
        11
        ·
        edit-2
        17 hours ago

        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.

  • civA
    link
    fedilink
    English
    arrow-up
    12
    ·
    22 hours ago

    Extremely entertaining and impressive