News Super Game Boy Overclocked to 5.35 MHz

[Admin]

Nicole Express explains the Super Game Boy hack that makes the device run faster.

Super Game Boy Overclocked to 5.35 MHz : Read more

 

[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...

 

[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.

 

[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.

 

[Vanderlindemedia]

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).

 

[bit_user]

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.

 

[jrharbort]

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.

 

[samopa]

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

 

[TerryLaze]

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.

PS4 Architecture Naughty Dog SINFO Analysis & Technical Breakdown Part 2

Part 1 The Playstation 4's Job System is very similar to design of the PS3 (hence the reason we've just taken a look at it). Each of the six cores from the

www.redgamingtech.com

 

[bit_user]

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.

 

[TerryLaze]

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)

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.pdf

Page 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.

 

[bit_user]

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)

I didn't see that level of detail in the article you linked.