Super Game Boy Overclocked to 5.35 MHz

News
By
published

True turbo mode makes Game Boy games run faster.

Game Boy
(Image credit: Shutterstock)

Game Boy is one of the most iconic handheld gaming consoles of all time. Almost 35 years later, enthusiasts and gamers still find new mods and hacks for the retro device and its accompanying add-ons, such as the Super Game Boy.

The Super Game Boy is essentially a cartridge that bridges the gap between the Game Boy and the Super Nintendo Entertainment System (NES), allowing the latter to play cartridges from the handheld console. The Game Boy and Super NES are two different devices with little in common. As a result, the Super Game Boy leverages the same hardware as the Game Boy to emulate the latter's game on the Super NES.

The Game Boy features a custom Sharp LR35902 processor based on the Intel 8080 and Zilog Z80 chips. The 8-bit processor features a clock speed of 4.19 MHz. However, the Super Game Boy's clock speed is 4.295 MHz, resulting in the accessory running Game Boy games at a 2.4% faster pace. The audio is sped up, and there wasn't a link port on the Super Game Boy since the difference in clock speed would cause it and a normal Game Boy to desynchronize. It's why Nintendo exclusively launched the Super Game Boy 2 in Japan, an upgraded variant incorporating a custom crystal oscillator to mirror the Game Boy's clock speed alongside a link port for two-player gameplay.

As Nicole Express spotted, user nensondubois recently released a ROM hack for World Heroes 2 Jet to further overclock the Super Game Boy. The hack enables a "turbo mode" per se to run the device at 5.35 MHz. The website provided a few audio samples to show the overlock and a small video of the overclocked device. The biggest drawback is the graphical glitches, a product of the hardware limitation.

Obviously, Nintendo didn't want users to be fiddling with the Super Game Boy's turbo mode. According to Nicole Express, the code isn't available through the Super Game Boy BIOS on the Game Boy side. Instead, you can only access it through the Super NES end.

It's cool that the Game Boy scene is still alive after all these years, and we're still seeing new mods. Game Boy was part of many childhoods, so there's always a special place for the handheld gaming console in our hearts.

Zhiye Liu
Zhiye Liu
News Editor and Memory Reviewer

Zhiye Liu is a news editor and memory reviewer at Tom’s Hardware. Although he loves everything that’s hardware, he has a soft spot for CPUs, GPUs, and RAM.

11 Comments Comment from the forums
  • Alvar "Miles" Udell
    Sadly Nintendo didn't take the Game Boy emulator in Pokemon Stadium that could play in 2x and 3x speed and sell it as its own cartridge...
    Reply
  • bit_user
    I always thought Sony should've released a special edition of the PS3 that was overclocked and had a SSD. You know there must've been some good overclocking headroom, considering it started out on a 90 nm process node for the CPU & GPU and finally shipped on a 45 nm / 28 nm node.

    With the PS4, we finally got the Pro version. Basically the same idea, except it should've also come with a SSD.
    Reply
  • why_wolf
    For those that want the reverse qwertymodo over on Tindie sells a clock mode that brings the Super Gameboy down to the correct Gameboy speed. It's very simple to install.
    Reply
  • Vanderlindemedia
    bit_user said:
    I always thought Sony should've released a special edition of the PS3 that was overclocked and had a SSD. You know there must've been some good overclocking headroom, considering it started out on a 90 nm process node for the CPU & GPU and finally shipped on a 45 nm / 28 nm node.

    With the PS4, we finally got the Pro version. Basically the same idea, except it should've also come with a SSD.
    Sure there's tons of headroom in those things, but many games simply rely on the internal timers just as why the Turbo button existed in the first place. If you put the CPU clock faster the game, app and such will run faster (and quite unsuspected).
    Reply
  • bit_user
    Vanderlindemedia said:
    Sure there's tons of headroom in those things, but many games simply rely on the internal timers just as why the Turbo button existed in the first place. If you put the CPU clock faster the game, app and such will run faster (and quite unsuspected).
    According to the wikipedia page, Sony reduced the Rambus memory speed after the first version. So, it's not as if the hardware stayed completely fixed.

    I think, by the time we got to PS3 games, most game programmers were using the realtime clock to update the game state. You really couldn't use loop-based timing once the game engine gets beyond a certain level of complexity. I think that era pretty much ended with sprite-based graphics. By the time you get to multi-core and 3D graphics hardware, you pretty much have to use the RTC to avoid jarring slowdowns and such.
    Reply
  • jrharbort
    bit_user said:
    According to the wikipedia page, Sony reduced the Rambus memory speed after the first version. So, it's not as if the hardware stayed completely fixed.

    I think, by the time we got to PS3 games, most game programmers were using the realtime clock to update the game state. You really couldn't use loop-based timing once the game engine gets beyond a certain level of complexity. I think that era pretty much ended with sprite-based graphics. By the time you get to multi-core and 3D graphics hardware, you pretty much have to use the RTC to avoid jarring slowdowns and such.
    Pretty much. CPU clock based timing stopped being a thing after the first gen of 3D consoles.
    Reply
  • samopa
    Vanderlindemedia said:
    Sure there's tons of headroom in those things, but many games simply rely on the internal timers just as why the Turbo button existed in the first place. If you put the CPU clock faster the game, app and such will run faster (and quite unsuspected).
    King's Quest IV Perils of Rosella makes me upgrade from PC/XT (4.77 MHz without Turbo) to PC/AT (286 16 Mhz), becase without turbo you can't outrun the dog in the room ;)
    Reply
  • TerryLaze
    jrharbort said:
    Pretty much. CPU clock based timing stopped being a thing after the first gen of 3D consoles.
    There is more than one way to skin a cat...they still use the capability of each core as a limiting device, the games are balanced so that the main loop fills one core and so that all the rest completes the multithread part fast enough for the main loop.
    That's why so many games run so badly even on overpowered desktops and why changing the CPU speed on the consoles would mess up the timing there as well, if the single core part(main loop) runs way faster than the rest then you will get missing stuff or stuff popping in later than it should or you will get stutters if it waits for the multi part to come up with the data. Also why many devs push for a 30FPS limit it prevents them from having to recode the game to sync properly.
    http://www.redgamingtech.com/ps4-architecture-naughty-dog-sinfo-analysis-technical-breakdown-part-2/
    Reply
  • bit_user
    TerryLaze said:
    There is more than one way to skin a cat...they still use the capability of each core as a limiting device, the games are balanced so that the main loop fills one core and so that all the rest completes the multithread part fast enough for the main loop.
    I think that was meant to be a conceptual diagram, rather than literal. If your game is designed to generate frames sequentially, then the natural structure is to have the main loop queue up work for the other cores and then block on their completion, more or less. I'm sure it's allowed to have some of those jobs spawn other jobs, to the extent possible, but the main loop needs to be what's initiating the cascade of the work & waiting on its completion.

    The only way to beat that is to overlap production of sequential frames, but it comes at the cost of additional latency. I heard about one game (I forget which) that overlaps generation of up to 4 sequential frames, in order to achieve the best core utilization and the highest framerates. If it's something like a RTS game, then that would be an acceptable tradeoff. If it's a twitchy FPS, then no.
    Reply
  • TerryLaze
    bit_user said:
    I think that was meant to be a conceptual diagram, rather than literal. If your game is designed to generate frames sequentially, then the natural structure is to have the main loop queue up work for the other cores and then block on their completion, more or less. I'm sure it's allowed to have some of those jobs spawn other jobs, to the extent possible, but the main loop needs to be what's initiating the cascade of the work & waiting on its completion.
    Nope, that is very literal.
    The frames don't rely on the main loop, one of the jobs on the other cores is what sends the data to the gpu to make frames.
    That's why it loses sync if it is being run on a different CPU, it doesn't sync everything and then sends a frame to the GPU at the end of each main loop.
    Everything , main and rest, is running as fast as possible at the same time next to each other without any syncing between them in the form of actual code, the only thing that makes it work is that it is "optimized" to the core speed and amount of cores.
    (They put so much work in the main loop and in the rest that it balances out naturally)
    bit_user said:
    The only way to beat that is to overlap production of sequential frames, but it comes at the cost of additional latency. I heard about one game (I forget which) that overlaps generation of up to 4 sequential frames, in order to achieve the best core utilization and the highest framerates. If it's something like a RTS game, then that would be an acceptable tradeoff. If it's a twitchy FPS, then no.
    https://advances.realtimerendering.com/destiny/gdc_2015/Tatarchuk_GDC_2015__Destiny_Renderer_web.pdfPage 197 onwards.
    This reduces latency because they prepare the same frame multiple times and can pick the one closest to where the main loop is at the time the frame has to appear.
    Reply