7 ms·

Looks like they used an existing emulator and this was mostly a hardware and memory integrity experiment. I’d love to see this approached from the perspective o

Looks like they used an existing emulator and this was mostly a hardware and memory integrity experiment. I’d love to see this approached from the perspective of “how clever can we get with the emulator itself to save power?” When I wrote mine, something I ran into was realizing that often the CPU and PPU are just doing the same thing over and over and over. If only I could cache all that work. For example, you don’t modify the previous frame. You have to draw the entire frame every time, writing sprites from OAM memory every time. Sometimes games do clever stuff here for effects, but a lot of the time you’re just drawing the same stuff. Like Tetris is almost completely a routine of drawing almost entirely the same graphics every time. Most of the cycles and OAM writes are just juggling sprites to draw the same layout every time. I documented the heck out of the PPU because it gave me the second most grief (sound being the worst by far) if you are curious: https://github.com/ablakey/gameboy/blob/master/src/guest/systems/ppu.rs https://github.com/ablakey/gameboy/blob/master/src/guest/sys... (goodness I’m proud of this project. Don’t tell my boss. He’ll want this level of documentation at work ;) )

rapind 4y ago
That was a pleasure to read through. Made me think of literate code.
- IshKebab 4y ago
  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!"
  - hackernewds 4y ago
    you must also have really good commenting habits. I've rarely seen this at work, let alone for a passion project
  - actionfromafar 4y ago
    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.)
  - ddevault 4y ago
    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() {
    - dizhn 4y ago
      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.
      - ddevault 4y ago
        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.
  - Cthulhu_ 4y ago
    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.
zrobotics 4y ago
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.
hackernewds 4y ago
Great contribution to the space, my friend
Cthulhu_ 4y ago
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.
- Shish2k 4y ago
  > 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 ;)
  - bobajeff 4y ago
    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.
    - datpiff 4y ago
      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/Product-information/Technical-data/Technical-data-619585.html https://www.nintendo.co.uk/Support/Game-Boy-Pocket-Color/Pro...
  - anthk 4y ago
    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.
joshspankit 4y ago
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?

rapind 4y ago

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

IshKebab 4y ago
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!"
- hackernewds 4y ago
  you must also have really good commenting habits. I've rarely seen this at work, let alone for a passion project
- actionfromafar 4y ago
  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.)
- ddevault 4y ago
  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() {
  - dizhn 4y ago
    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.
    - ddevault 4y ago
      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.
- Cthulhu_ 4y ago
  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.

zrobotics 4y ago

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.

hackernewds 4y ago

Great contribution to the space, my friend

Cthulhu_ 4y ago

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.

Shish2k 4y ago
> 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 ;)
- bobajeff 4y ago
  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.
  - datpiff 4y ago
    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/Product-information/Technical-data/Technical-data-619585.html https://www.nintendo.co.uk/Support/Game-Boy-Pocket-Color/Pro...
- anthk 4y ago
  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.

joshspankit 4y ago

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?