Game Boy core for Turbo Chameleon 64

Caution: Non registered users only see threads and messages in the currently selected language, which is determined by their browser. Please create an account and log in to see all content by default. This is a limitation of the forum software.


Also users that are not logged in can not create new threads. This is a, unfortunately needed, counter measure against spam. Please create an account and log in to start new threads.

Don't Panic. Please wash hands.
  • Cool stuff! Have to try this asap


    (There seems to be some copypaste error on the blog page...referring to the NES core :))


    Edit: awesome. i tried it with the one Gameboy Color title i was involved in that actually got published - works perfectly :)


    One thing that is a bit weird is, although my Monitor can display the image fine - the autodection will mess up the horizontal position so there is a considerably large black area on the left (something like a fifth of the screen or so).

  • Thanks for spotting the copy-paste errors - fixed now. (The wordpress text editor is a bit flaky sometimes, and when you delete a chunk of text it sometimes gets merged into the previous paragraph instead!)


    So which title was that? :D


    I shall look at improving the screen output at some point - it behaves a bit oddly here, too - it's somewhat narrow, and gets clipped slightly at the bottom of the screen. Also any time the game touches the video mode register the monitor ends up resyncing. So there's definite room for improvement there.

  • Quote

    Also any time the game touches the video mode register the monitor ends up resyncing. So there's definite room for improvement there.

    Yes, thats the most annoying thing.... i adjusted it, then pressed START and damn, its far to the right again =)


    check this :) (Is that 20 years old? damn!)

  • Yes, thats the most annoying thing.... i adjusted it, then pressed START and damn, its far to the right again =)


    check this :) (Is that 20 years old? damn!)

    Currently it just buffers two lines of video and seems to be pretty much at the "gameboy"'s mercy when it comes to generating sync. The SDRAM's not currently too congested, so it might be possible to move to a proper framebuffer in future.


    The game looks really cool!

  • so it might be possible to move to a proper framebuffer in future.

    You might get away without that: If you generate H/VSync on your own and only follow the Gameboy syncs in a corrective manner (like max. 2 lines difference between previous and current frame, similar figure for pixels on HSync), the picture will move heavily on every write to the video mode register, but the monitor won't blank the picture.


    Question is if this is really easier, or if you open another can of worms with this approach. After all, the limited number of colours shouldn't mean too-high requirements for a frame buffer. Also, is GBC a CLUT-based gfx thing? If so, a frame buffer before the lookup table will reduce framebuffer bandwidth requirements even more.

  • From my dusty memory: GBC has RGB565 palettes iirc, 4 palettes per tileset, 4 palettes for sprites, all of which can be combined and appear in a single line (and changed per line of course) - i really doubt storing a framebuffer as indices buys you anything.

  • Yeah, I'm noticing that when I pipe this through the OSSC, it keeps on blanking/refreshing and I'm presuming that is an effect of the issue you're talking about at the moment (I put my TC through the OSSC for ease of input into my setup as it's easier to move hdmi cables than VGA cables between my displays).