[HN Gopher] There oughta be a Game Boy capture cartridge
___________________________________________________________________
There oughta be a Game Boy capture cartridge
Author : Amorymeltzer
Score : 244 points
Date : 2022-12-20 17:40 UTC (5 hours ago)
(HTM) web link (there.oughta.be)
(TXT) w3m dump (there.oughta.be)
| philistine wrote:
| Speaking as a connoisseur of Game Boy (I write
| gameboyessentials.com) I have to say this is a very interesting
| project, since it allows video out, sort of, without modifying
| the device. Congratulations.
|
| Would your device work with a Game Boy Camera?
| jonhohle wrote:
| As long as the image data is coming from the cartridge and the
| instructions are obviously moving data that originated from the
| cart to video RAM or registers (I don't know anything about the
| game boy). M with something like the GB camera, latency is less
| of a concern though, so the cartridge could probably interrupt
| the camera periodically to read video memory.
| iak8god wrote:
| The youtube video embedded in the page shows it working with a
| GBC: https://www.youtube.com/watch?v=6mOJtrFnawk&t=392s
| mungoman2 wrote:
| What a wonderful piece of work! From the description it's
| possible to imagine a series of showstoppers, each followed by an
| epiphany that allowed the work to continue one more step. And I'm
| sure there are more stories not shared. Truly inspiring!
| endisneigh wrote:
| curious if it's possible to make a generic version of this that
| somehow interprets the voltage of the LCD and can stream anything
| without actually _seeing_ , so to speak.
| vikingerik wrote:
| It's possible but requires more hardware hacking. The only
| accessible port on an unmodified Game Boy is the cartridge
| slot, which doesn't carry the video signal. The point of this
| article is to use an unmodified console, which means you can
| only access what can be seen from the cartridge slot, which is
| activity on the memory/IO bus, and so this project recreates
| the video from that.
|
| To do what you propose, you'd have to open it up and add
| hardware hooked in to the connection that goes to the LCD.
| Someone's probably done that somewhere; it's a different scope
| than the project here.
| thehours wrote:
| > Switching them for an unfamiliar modern device or an emulator
| will significantly impede their ability to play competitively
|
| Was this used in a tournament? How was it received by the
| competitors?
| maccard wrote:
| Once or twice a year on HN, I find myself reading a post and
| thinking "this is a complete and utter waste of time, this person
| has spent so much time and effort on something so meaningless
| that they could have spent on something else", and yet despite
| that thought, absolutely loving it.
|
| This is probably my favourite link this year.
| a_t48 wrote:
| > Have a look at the first vsync interrupt of "The Legend of
| Zelda - A Link to the Past" on the original Game Boy:
|
| I think this should be "Links Awakening".
|
| Side note, something like this could _almost_ be used to
| implement multiplayer gaming for things like multi-world
| randomizers (see https://www.youtube.com/watch?v=2VJ21rQ4L2U for
| an example on SNES).
| progbits wrote:
| 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 and 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| rsync wrote:
| I've always wanted a debug cartridge with modern design and
| features ... I imagined something _very much like this_ but with
| additional serial and video outputs:
|
| - video passthrough (like this one, obviously)
|
| - serial console debug output (framerate ? CPU ? sprite count ?)
|
| - secondary video output of sprites - perhaps with a palette of
| all sprites and an array of sprites actually on-screen ?
|
| - tertiary video output ???
|
| I make no claim that _any of the above_ would actually be useful.
|
| I'm thinking about this as a development tool from an alternative
| timeline that never existed here ... and specifically, a
| _standalone_ development tool that doesn 't require a PC tied to
| it with a SCSI cable like the SN Systems and (other carts) did.
| goosedragons wrote:
| I wonder if it would have been eaiser to make a cartridge that
| lets you use the gameboy controls as a controller instead? This
| is still really neat of course but maybe that would have saved
| the emulator step.
___________________________________________________________________
(page generated 2022-12-20 23:00 UTC)