Hacker News Reader

Comment by Salgat | Hacker News Reader

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.

View on HN

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.

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.

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.

Reply on news.ycombinator.com