Power consumption of Game Boy flash cartridges | Hacker News Reader

Power consumption of Game Boy flash cartridges

gekkio.fi

281 pointszdw46 comments

If anyone is interested in making their own Game Boy game, I've been working on an open source game maker [0] that adds a UI around GBDK. I'm working on an updated replacement game engine [1] at the moment too that adds, among other things, support for flash cartridge saving (allows you to reflash cheap Pokémon carts), parallax backgrounds, large sprites and a stack based scripting language.

[0] https://www.gbstudio.dev/

[1] https://github.com/chrismaltby/gbvm

Thanks for your work. I've been messing about with GB studio for the last month. It's great

Wow! It's come a long way since I first heard about it and started messing around with it. I'll have to dig out the old source files I saved when I have some time. Good effort.

From what I recall, the original Game Boy uses a linear regulator so is wasting 20% of its power budget to heat as it converts 6V supplied by 4 AA’s to 5V used by the electronics. (Hand waiving the numbers here.)

Modern power regulators are much better 40 years later. A casual search reveals kits like this one https://handheldlegend.com/products/3-3v-voltage-regulator which could buck/boost a variety of voltages - even letting you run on 4x 3.6V lithium batteries in AA form factor: https://www.batteryjunction.com/plc-ls14500-ba.html

I’m not sure if the power savings by switching regulators are greater than switching carts but are in the same ballpark and are worth exploring if one is going to these lengths to begin with. Certainly combined with those lithium cells it would make cart selection irrelevant.

IIRC Game Boy Color (my favorite) used switching power regulators, but suffers from an audible humming, some units are pretty severe.

I'm genuinely surprised to see Tetris have the lowest power consumption, since unlike the other two games, it does not use the HALT instruction. The HALT instruction puts the CPU to sleep until an interrupt occurs, supposedly lowering power consumption during that time. Most games have it somewhere in their main loop, after they've done the work they needed to do for the current frame, they halt until a V-Blank occurs. Tetris on the other hand busy waits, going over the same 3 instruction loop until the next frame. Most games halt 80% of the time, so now I'm wondering if that instruction ever did anything at all.

But the post is about measuring the cartridge power consumption, no? So even if Tetris is running at 100% CPU usage all the time, it makes no difference to the power consumption of the cart itself, the game is small enough that it rarely reads from the cart.

The method described in the post indicates that it's measuring the full consumption of the whole gameboy+cartridge. You can also tell this because there's an example of the "without cartridge" power consumption, and it's not "flat zero" :-)

In his description of the test setup, he says that he powers the Game Boy with the DC jack input, so I assume he's measuring the power consumption of the entire machine, but I might be misunderstanding that. Either way I'd expect the Tetris cartridge on itself to consume more power as well, as during the busy loop the game is constantly reading the next instruction, whereas games which halt don't access the cartridge at all until an interrupt happens.

Tetris only had the lowest because the cartridge contains just a ROM chip and doesn't have RAM or memory bank controller chips as other cartridges have.

I'm sure the halt instruction does reduce CPU power but it isn't that significant compared to the overall power of the cartridge and other peripherals.

Just to add to what everyone else is saying. Quiescent current is the current the chips use doing nothing at all. It's a static power consumption. With this older hardware, my guess is it's shockingly high.

This test could have been a little better, if they measured current between the GB and the cartridge explicitly. Also, would want to check the voltage on the cartridge downstream of the shunt to make sure it's not browning out under the burden voltage of the current meter, and causing an artificially high current usage. (Though, going through the GB itself might address this...)

I initially considered measuring the cartridge +5V rail directly, but decided to go with total power consumption of the console for two main reasons:

1. Total power consumption is easier to relate to battery life, because e.g. doubling the total power consumption roughly halves battery life

2. Cartridge current draw on +5V rail doesn't fully capture the impact on total power consumption. Improper bus behaviour and leakage currents can increase current draw on the console itself. As an extreme example, shorting one of the cartridge I/O pins to ground might not pull any current from the cartridge +5V rail, but it might increase current draw and power dissipation in the main SoC significantly if it's driving the I/O line high.

In any case, optimally I'd have a setup for measuring both :) But right now I only have test automation infrastructure ready for HMC8043

If you use alkaline batteries, doubling the current more than halves the battery life; Ni based rechargeables don't show that effect though

This is because Tetris doesn't use an MBC unlike Pokemon and Wario

I never bothered to measure it but I suspect that for older CPUs dynamic consumption is not super high compared to the other elements. The main reason for that belief is that I know that some "retro" consoles didn't even feature any way to HALT the CPU and busy looping was the only possibility.

In particular the MIPS CPU used by the PlayStation didn't have any way to halt the CPU. AFAIK neither did the N64. Admittedly these weren't (usually) battery powered so power draw was less of an issue, but the fact that these ISAs didn't even bother with an HALT opcode at all tells me that it wasn't really considered a super valuable feature back then.

Admittedly the GameBoy CPU is CISC, so maybe it fared worse than MIPS in this case, but it was also running at a much lower clock rate, maybe a tight NOP loop didn't consume all that much.

When I was in school I remember a professor saying to "Never gate a clock." In the 90's I think people were worried about clock glitches.

My first few years in the industry in the late 90's we had customers that didn't care about power usage. They wanted the fastest performance and would put a heat sink or bigger fan on their chip.

It wasn't long after that when power usage became more important. We have had logic synthesis tools that automatically insert clock gate logic to save power using various glitchless clock cell designs.

Interesting fact: The TMS9900 had an IDLE instruction - I recall reading somewhere that it was implemented internally as an unconditional jump to itself.

IMHO I think for older classic CPUs in embedded situations, the expectation was that if halting the CPU was needed, external logic would do that.

- The video chip on the Commodore 64 halts the CPU during the frame to fetch memory every 8 lines IIRC (disabling video output increases CPU speed by a bit)

- The NES halts the CPU when it tells the PPU to DMA 256 bytes of memory to sprite descriptor memory before it renders the frame.

- Commodore 128 will halt the non-active CPU (Z80 or 8502). Not sure what hardware is responsible for this, probably that funky MMU chip.

- The Atari 2600 has a WSYNC gregister which tells the TIA to halt the CPU until the next TV scanline starts (it otherwise doesn't use IRQs or NMIs which I found interesting).

Probably halting to save power didn't matter to manufacturers until CPUs required heatsinks or for portable devies. At that point saving power is also preventing heat buildup and enabling the hardware to last longer.

Couldn't find solid information on the original GameBoy CPU, but it's possible it didn't use CMOS style logic and had much higher static power consumption.

The reproduction cart is interesting: it consumes less power than the genuine cart in the startup measurement.

This is not surprising since it's newer. Someone looking to reduce costs as much as possible is going to reduce die area, i.e. using a smaller process with correspondingly smaller power consumption. The NOR flash on there has a datecode of 2007, almost a decade after the original.

Being a completely newbie of Game Boy architecture,I got surprised to see the cartridge had a battery.

It's for keeping save data =)

And losing it. I’m sure many people are surprised to come back to their GB, NES, and SNES games after a few decades to find that their save files are gone.

I've plugged in SNES cartridges that are 30 years old and the save data still persists. I'm guessing they got the same man who designed the everlasting Casio digital watch battery to design those.

I've heard about this for years, but I've never had it happen, and I don't know anyone else who's experienced it. I don't doubt it happens, but what could cause such a discrepancy in the time it takes to degrade?

Different battery manufacturers? Batteries stored in different conditions?

Anecdata

I was surprised last year to find my saves on Zelda 2 and others were still intact. Zelda 1 had been dead for years though.

My 33 year old final fantasy cart still holds saves; other newer ones have died. There's a huge variance there.

I recently got my old Game Boy games out so my son could play them. They've been in a box in storage for 20+ years. My saved games from the 90s are still there on all the ones I've checked.

Back them up on a old gameshark or something. I lost all my gamesaves and wish I still could revisit them.

Flash wasn't cost effective in the 90s, so most save games were stored in RAM with a battery so that it never lost power.

I've changed the battery on my copy of Pokemon Gold twice. I wonder if whoever designed those cartridges expected anyone to still be playing the game twenty years later.

I've seriously considered replacing the SRAM with MRAM so as to not require battery replacement. It would need level shifters though.

Meanwhile my Blue version is somehow still ticking along on its original battery nearly 23 years later.

Gen II (Silver/Gold/Crystal) had a time-of-day thing going, which I expect probably required more battery power due to also needing to maintain a clock along with the save data. Gen I only needed to hold the save data. That would be my guess for the difference in battery life.

My red and yellow carts still have original batteries too, and the saved games still work perfectly (as of two years ago when I last checked). The only thing I might say "oh well" about losing is the official Mew I got from some Pokemon event at a mall, but I don't even have the certificate that it came with so it doesn't really matter.

That whole site is a treasure trove for anyone looking to do ROM hacking or development on gameboy. I encourage other readers to poke around and see what’s there.

I haven't tested as sufficiently as the OP, but I discovered firsthand that the Everdrive GB x7 consumes more power than a standard cart. If I had to guess, I'd guess almost as much as the EZ-FLASH Junior.

My modded GB Pocket wasn't able to use either cart until I replaced the batteries with lithiums that boasted 1.5v output.

In a lot of embedded systems, there's no particular need for the software to participate in power saving, even when the system is ultimately battery powered. That's often true in automotive for example, where the device's power is often externally sequenced by an ignition or auxiliary signal. The quiescent draw is simply orders of magnitude lower than the average power draw of the electro-mechanical systems being controlled. It's also often true in aerospace. Additional power saving would have an intrinsic benefit, but adds complexity that is hard to justify most of the time.

It's too bad that there are so few options regardings carts for the NGPC (NeoGeo Pocket Color). There's the NeoPocket GameDrive but it's almost $100. Being a collector isn't a cheap hobby...

It is if you collect the right things. My garage has a small area with things that my kids thought were cool. She has a stick that she thought looked cool, some cicada shells, a dried up Luna moth, some rocks that she thought looked like things other than rocks and lord knows what else.

Her collection isn't much to most people, but she's pretty proud of it.

Nice writeup! It's always neat to see hardware stacking up. Good work on your design if efficiency wasn't explicitly a goal (even if it was, I guess).

The lower power consumption on newer hardware's probably down to raw power efficiency gain in the fabrication process itself. I'm not surprised there.

I actually am a little surprised that rando hardware seems to pattern that close to the original in general. I would've expected wider variation.

This is interesting. I wonder why some genuine carts have a quiescent current and tetris doesn't

Edit: I remember, Tetris is one of a few games that don't use MBCs. The quiescent current is probably that of the MBC

I hadn't looked into GB flash carts, but for GBA I was warned away from the EZ Flash Omega because apparently it used more power than the equivalent (more expensive) Everdrive. I'd be interested to see the numbers behind that.

Tetris just has a ROM chip. The other official carts have ROM, a bank switching chip, static RAM and a power switching chip (to switch the SRAM from the internal battery to Gameboy power). So there's just more stuff on the board that can drain power.

Edit: Dang, you remembered whilst I writing my reply...

Yeah, incidentally I've written a gameboy emulator and only remembered because I never implemented any MBCs and so it only played Tetris and Bubble Ghost

makho has a video on the power usage of the EZ Flash Omega DE versus some other flash carts.[1] He's also put together a spreadsheet with his results.[2] Essentially the EverDrive would result in a runtime about 90% of an original cart, with the EZ Flash Omega DE coming in at 80%. The original EZ Flash Omega would last about 70% of the time of an OEM game.

[1] https://youtu.be/HrGTzSrdCyA

[2] https://docs.google.com/spreadsheets/u/0/d/1baIDOZlUjERhOsmc...

Reply on news.ycombinator.com