4 ms·

Very cool project! I'm surprised that it apparently works so well (most of the time, for many games) without knowing the state of inputs, just relying on condi

Very cool project! I'm surprised that it apparently works so well (most of the time, for many games) without knowing the state of inputs, just relying on conditional branching. I would have expected a lot of code to just manipulate registers based on inputs and use those to send different PPU commands. I wonder if you could achieve 100% parity (and audio) without modification of the console by doing all the emulation in the capture card. Send some pre-built ROM to the console which just reads inputs, sends them back to the "cartridge" and then reads back video output from the emulator. The same author already made https://there.oughta.be/a/wifi-game-boy-cartridge https://there.oughta.be/a/wifi-game-boy-cartridge and https://there.oughta.be/gta5-for-the-game-boy https://there.oughta.be/gta5-for-the-game-boy so it seems technically feasible :) Edit: Ah I see the video stream cartridge runs at 20fps, but gameboy games can run up to 60fps. I suppose that wouldn't work for the original purpose of streaming tournaments.

Salgat 4y ago
With a better chip this should be totally doable. It would achieve the desired result of being able to play on your hardware of choice (the original gameboy), but at the expense of it not being a "true" gameboy hardware ran game, but rather an entirely emulated game.
- progbits 4y ago
  Maybe I'm misreading the article but it sounds like even when just copying data from cartridge to vram there isn't enough time to get 60fps, no matter how fast your emulator hardware is. However, I guess that is a problem for arbitrary video where you have to be able to completely swap out the tile map on each frame (actually 2x/frame). For a GB game you could only swap the tiles/sprites that have actually updated and send over info what to redraw. So potentially possible I guess? Someone should do the instruction count / bus bandwidth math.
  - toast0 4y ago
    For games with really tight timing, it might be tricky, but worst case you could trigger on vsync, read the inputs, write them to the cartridge, the cartridge bank swaps to the real code, with the read inputs to load an immediate value without any further modifications. Then go back to the interception code when the original code is looking for vsync again. Maybe some games don't have time for that, but I'd guess most do. If you have execution bandwidth for that, you probably have execution bandwidth for straight line code that only does the PPU per frame work, because the emulator did all the cpu work and ran ahead (hopefully)... Of course, when PPU work happens midframe, timing gets real important and that may be tricky. Anyway, sounds pretty fun.
  - mod50ack 4y ago
    No, it's just that he used a codec that has much more bit depth than he needed on the output end to make it a regular webcam. He says himself that if he used a custom codec then it would be fine but would require software support on the receiving computer.
d_watt 4y ago
Regarding the chip just being a duplicate destination of the inputs, I wonder how many games are deterministic enough for this to be possible. I feel like a lot of effort put into modern multiplayer games is ensuring determinism where if you capture the set of user inputs, it's guaranteed to be replayed into the same game, but that perviously a lot of race conditions or randoms() would make that not true.
- djcannabiz 4y ago
  if i remember correctly, the rng on tetris on the gameboy is terrible, and is quite predictable. https://tetrisconcept.net/threads/randomizer-theory.512/page-9#post-51035 https://tetrisconcept.net/threads/randomizer-theory.512/page... has some more info about it. Im not familiar with with how some of the prng algorithms are seeded, but maybe on tetris, the hardware responsible is part of the cartridge and then can be intercepted. just a thought tho
  - anyfoo 4y ago
    I would be very surprised if the Gameboy, like practically any 8 bit CPU of that era, had any dedicated instructions or hardware for RNG. So it's a software RNG, and the user input is pretty much the only "random" thing coming in from outside. This is very common for games. It still is: Games like Civilization often let you specify the seed to initialize their software RNG with, so you or someone else can replay the exact same game.
- jf 4y ago
  The Game Boy is very deterministic. It had no internal source of randomness.
jf 4y ago
> I'm surprised that it apparently works so well (most of the time, for many games) I worked on a Game Boy related project recently and, similar to you, was surprised at how heavily the Game Boy uses the cartridge ROM. If I remember correctly, it makes on the order of thousands of requests to the ROM per frame.
- anyfoo 4y ago
  That's to be expected though: That's just the actual game code itself being executed! The code is not copied from the cartridge into RAM (that would just be a gigantic waste of RAM), the Gameboy directly executes it from the ROM in the cartridge. So every single instruction being executed, you will see on that bus. And every instruction hopefully serves to either build up the current frame, or do game logic for later on.
  - phire 4y ago
    Well... might be true 99% of the time, but it's not a safe assumption. Nothing stopping a developer temporally copying code out of ROM to minimise bank switches or because they want to implement an algorithm with self-modifying code. But that isn't actually a problem for this approach, because the CPU still puts the address on the cartridge bus even when it's accessing internal RAM, and you can still monitor which addresses it accesses to tell which way it's branching, even when executing from RAM.
    - dezgeg 4y ago
      On Gameboy copying some code to RAM is essentially required if you want to use sprites, because the fastest way to update the sprite attributes (so called OAM) is to use DMA. And during OAM DMA the CPU cannot access anything else than a internal 128 byte RAM, so the DMA trigger + delay loop procedure must be copied and executed there.
      - anyfoo 4y ago
        Likely true. You still do see every instruction executing on the bus if I’m not mistaken, and the overwhelming majority will still execute directly from the cartridge ROM I assume. (Happy to be proven wrong, but I imagine the code for addressing OAM is still a small fraction of what’s executing.)

Salgat 4y ago

With a better chip this should be totally doable. It would achieve the desired result of being able to play on your hardware of choice (the original gameboy), but at the expense of it not being a "true" gameboy hardware ran game, but rather an entirely emulated game.

progbits 4y ago
Maybe I'm misreading the article but it sounds like even when just copying data from cartridge to vram there isn't enough time to get 60fps, no matter how fast your emulator hardware is. However, I guess that is a problem for arbitrary video where you have to be able to completely swap out the tile map on each frame (actually 2x/frame). For a GB game you could only swap the tiles/sprites that have actually updated and send over info what to redraw. So potentially possible I guess? Someone should do the instruction count / bus bandwidth math.
- toast0 4y ago
  For games with really tight timing, it might be tricky, but worst case you could trigger on vsync, read the inputs, write them to the cartridge, the cartridge bank swaps to the real code, with the read inputs to load an immediate value without any further modifications. Then go back to the interception code when the original code is looking for vsync again. Maybe some games don't have time for that, but I'd guess most do. If you have execution bandwidth for that, you probably have execution bandwidth for straight line code that only does the PPU per frame work, because the emulator did all the cpu work and ran ahead (hopefully)... Of course, when PPU work happens midframe, timing gets real important and that may be tricky. Anyway, sounds pretty fun.
- mod50ack 4y ago
  No, it's just that he used a codec that has much more bit depth than he needed on the output end to make it a regular webcam. He says himself that if he used a custom codec then it would be fine but would require software support on the receiving computer.

d_watt 4y ago

Regarding the chip just being a duplicate destination of the inputs, I wonder how many games are deterministic enough for this to be possible. I feel like a lot of effort put into modern multiplayer games is ensuring determinism where if you capture the set of user inputs, it's guaranteed to be replayed into the same game, but that perviously a lot of race conditions or randoms() would make that not true.

djcannabiz 4y ago
if i remember correctly, the rng on tetris on the gameboy is terrible, and is quite predictable. https://tetrisconcept.net/threads/randomizer-theory.512/page-9#post-51035 https://tetrisconcept.net/threads/randomizer-theory.512/page... has some more info about it. Im not familiar with with how some of the prng algorithms are seeded, but maybe on tetris, the hardware responsible is part of the cartridge and then can be intercepted. just a thought tho
- anyfoo 4y ago
  I would be very surprised if the Gameboy, like practically any 8 bit CPU of that era, had any dedicated instructions or hardware for RNG. So it's a software RNG, and the user input is pretty much the only "random" thing coming in from outside. This is very common for games. It still is: Games like Civilization often let you specify the seed to initialize their software RNG with, so you or someone else can replay the exact same game.
jf 4y ago
The Game Boy is very deterministic. It had no internal source of randomness.

jf 4y ago

> I'm surprised that it apparently works so well (most of the time, for many games) I worked on a Game Boy related project recently and, similar to you, was surprised at how heavily the Game Boy uses the cartridge ROM. If I remember correctly, it makes on the order of thousands of requests to the ROM per frame.

anyfoo 4y ago
That's to be expected though: That's just the actual game code itself being executed! The code is not copied from the cartridge into RAM (that would just be a gigantic waste of RAM), the Gameboy directly executes it from the ROM in the cartridge. So every single instruction being executed, you will see on that bus. And every instruction hopefully serves to either build up the current frame, or do game logic for later on.
- phire 4y ago
  Well... might be true 99% of the time, but it's not a safe assumption. Nothing stopping a developer temporally copying code out of ROM to minimise bank switches or because they want to implement an algorithm with self-modifying code. But that isn't actually a problem for this approach, because the CPU still puts the address on the cartridge bus even when it's accessing internal RAM, and you can still monitor which addresses it accesses to tell which way it's branching, even when executing from RAM.
  - dezgeg 4y ago
    On Gameboy copying some code to RAM is essentially required if you want to use sprites, because the fastest way to update the sprite attributes (so called OAM) is to use DMA. And during OAM DMA the CPU cannot access anything else than a internal 128 byte RAM, so the DMA trigger + delay loop procedure must be copied and executed there.
    - anyfoo 4y ago
      Likely true. You still do see every instruction executing on the bus if I’m not mistaken, and the overwhelming majority will still execute directly from the cartridge ROM I assume. (Happy to be proven wrong, but I imagine the code for addressing OAM is still a small fraction of what’s executing.)