Hacker News Reader

That code was a joy to read, that is an example of comments done right. Such a pleasure to see comments that actually describe the intent of a function rather than stepping through the code, although doing it well is definitely much harder work.

Instead of software emulation, why not hardware emulation? The original Gameboy ran on two AA batteries for 12-20 hours (depending on whether the light was on); I'd argue that rebuilding the original hardware with modern-day technologies could reduce that energy consumption by 90% or more.

> The original Gameboy ran on two AA batteries for 12-20 hours (depending on whether the light was on)

I wonder if you googled for this? Googling for “original gameboy battery life” gives nearly this exact quote, but then reading the wikipedia article that it came from reveals that this is talking about the Gameboy Light (1998 - arguably “the original hardware with modern technology to reduce energy consumption”). I went and fact-checked because I remembered that the original original gameboy (1989) had 4 AA batteries and no light ;)

It's worth noting that back then AA batteries were less efficient. Which is why later when AA's got better Nintendo was able to release the Gameboy pocket and Gameboy color using only 2 batteries.

The new hardware used less power, the batteries didn't change very much.

edit. also Nintendo's figures show a lower battery time for the Pocket and Color, so they probably just decided to trade for space/weight.

https://www.nintendo.co.uk/Support/Game-Boy-Pocket-Color/Pro...

No one but Japan got the GB light.

Everyone had either the GB and many more people had the GB Pocket because of Pokémon.

The gameboy color also ran on two AAs and had long battery life and slightly better specs

I know, I had one with Pokémon Crystal, Cannon Fodder and some N in 1 multicart.

Still no backlight.

While true, my prized possession as a kid was my GameBoy Light that was imported from Japan. Other people had regular GameBoy pockets or even colors, but I'd rather have that awesome backlight. My kids still use it to this day to play Zelda.

Ah, you just triggered fond nostalgia for me, of pillaging my dad's stash of batteries for my ever hungry Gameboy Pocket. It ran on two AAAs and my parents must have lost a few sanity points from my constant requests to stop at a gas station for batteries on long road trips (which were almost always denied, gas station batteries ain't cheap).

I got much better battery life out of my Gameboy pocket with the help of electrical tape, some bits of wire and a pair of D cell batteries.

9 year old me was particularly proud of the self made spring that fit between the batteries.

Adult me would probably put the batteries side by side though.

I agree, but since it was designed as a demo, it was a lot quicker to find an existing emulator: https://mikrocontroller.bplaced.net/wordpress/?page_id=1290 and rewrite it for a related Cortex M4 processor.

FYI, I contacted the group to express interest over 2 years ago and never got a response. They are working on a new project with more advanced graphics https://www.techradar.com/features/the-quest-for-the-solar-p...

That was a pleasure to read through. Made me think of literate code.

Am I the only one that thinks this is a normal level of comments? Ok maybe slightly more than I would normally do... But if I was reading it my thought would be "thank god they wrote comments" not "they commented the heck out of this!"

you must also have really good commenting habits. I've rarely seen this at work, let alone for a passion project

It sticks out to me. The regular mode for me when reading code is guessing. Even more rare are comprehensive comments which are actually up to date. Documenting something which never changes (like a gameboy) lends itself more to such. (Even though the code can still change, the device it emulates at least never does.)

From the perspective of someone who generally writes far fewer comments than this, I find that this code has a number of comments which is well-justified due to the complexity of the subject, poor availability of external documentation describing the interface it implements, and the nature of the code. However, the code can be written in a manner which is still readable with fewer comments.

Here's a sample from the file:

    // For sprites, color 0 is transparency so don't draw anything.
    if color == 0 {
        continue;
    }

This comment is probably not necessary: it would be equally clear if it were written as something like the following:

    if color == SPRITE_COLOR_TRANSPARENT {
        continue;
    }

A few lines up is another comment:

    // Is this specific pixel not on the screen? We already check that x_pos is not off
    // the left side earlier, so only need to check that it's not off the right side.
    if x_pos + p >= 160 {
        continue;
    }

If the code were written with a constant, then it would only need to clarify why we don't check the left side here (the only non-obvious thing about the code), so:

    // Note: bounds testing on the left side is handled earlier
    if x_pos + p >= SCREEN_WIDTH {
        continue;
    }

One last example:

    // We want to iterate through 160 pixels to draw one scanline.
    for col in 0..160u8 {

No comment, similar level of readability:

    for col in ppu.iterscanlines() {

I like the changes but I think the original has merit too. Along with the comments it is documenting the parameters/bounds that apply to this device where they are actually being used, making the code a kind of documentation for others who want to implement similar things. Having these defined in constants elsewhere would require some back and forth if this "document" is used as a reference.

Well, I said upfront that the level of comments here is fine. Just offering a perspective on how it could still be good code with less. In general I think it's fine to expect a reading of the code to be paired with a reading of the documentation/specification; in the absence of such a resource for the GameBoy the comments here are well-justified. I would definitely add more constants, though, and I would anticipate that a second implementation which references this would start by re-defining all of the constants in its own code.

Most people will argue that this is nitpicking, however, I've learned something new today. Thank you.

Quite a difference in code readability to the point where the code becomes self-evident. Few people are able to reach a more verbose level of documentation, let alone make sure the code remains understandeable in the future.

It depends on the application, I wouldn't want this in the average webapp I build but most of that is nonspecific and low value code that will be replaced every five years or so.

I operate at higher levels of abstraction, so forgive if this is a wild suggestion, but would a FPGA work here to enable creating a low-power “hardware” emulator?

Great contribution to the space, my friend