Few question about design

[tuantdang]

Thank you for your awesome work! I'm really interested in this project!
I'm also building a battery-free device for my application that is related to your work, so I have some questions that need to be clarified:

1. Your design harvest energy from solar and button action, then store in a capacitor to power the device. As I know a capacitor looks like a battery but it stores less energy than a battery. What if you do not play the games and the capacitor is fully charged? Is it a waste of energy while the device is idle?
2. As far I know, the implementation of MPatch run-time is consuming power. I want to know the level of play game versus the level of running MPatch lib. If the cost of running this run-time lib is large, it could contribute to the frequent failure in power.
3. Could we use a bigger capacitor or multiple capacitors to store energy to avoid frequent power failure?

Thank you!
I'm looking forward to hearing your response!
Or you can drop me a message at: ttd9645@mavs.uta.edu
Best regards,
Tuan Dang

[przemyslaw-pawelczak]

Dear @tuantdang thank you for your interest in this project. We're really interested to hear about your own battery-less device.

Here are our quick answers to your questions:

• Regarding 1. Indeed, a capacitor (just like battery) has finite volume and cannot store infinite amount of energy. So from this perspective as you rightly point out we waste the opportunity of storing more energy for the future.
• Regarding 2. Yes, as you correctly observe, MPatch (as any other runtime) will introduce overhead (however in case of MPatch that memory overhead is small - each patch takes 29 B of memory, see Patch Allocation section of the ENGAGE paper. But I guess your question implies that if MPatch would have almost zero overhead, the game play would significantly improve. The answer is "Yes"... however the biggest performance killer of all the software running in ENGAGE is the game emulator - running games natively would in our opinion improve game play much more than making `MPatch' more efficient
• Regarding 3. Yes, both are possible. However, bigger capacitor results in longer startup time after every power failure. In my humble opinion capacitor bank would be an interesting solution to consider (which was already proposed by other research groups working in intermittently-powered systems).

Hope I was able to answer your questions. Feel free to send a follow-up questions!

[tuantdang]

Dear @przemyslaw-pawelczak,
Thank you for your quick reply.

Another point that I concerned about is when to do the checkpoint.
When reading the paper, I think there are some ways to predict power failure before doing checkpoints.
I tried to find it in the source code, but I could not.

Below is the code that I found. As source code: Checkpoint is done every 5 times after gameboy_single_step, whose source is not available in the repository, could you explain it?

void emulatorRun() {
  while (true) {
    gameboy_single_step();
#ifdef CHECKPOINT
    if (jit_checkpoint) {
      if (jitCheckpointcount == 0) {
        jitCheckpointcount = 5;
        checkpoint();
      } else {
        jitCheckpointcount--;
      }

      jit_checkpoint = 0;
    }
#endif
  }
}

[iiKoe]

Hi @tuantdang

That piece of code (software/libs/emulator/emulator.c) performs a checkpoint (of the changed memory) if the jit_checkpoint variable is not zero for 5 emulation steps. This jit_checkpoint variable is set in an interrupt defined in software/libs/jit/jit_checkpoint.c. This interrupt is an ADC interrupt that is connected to the voltage level of the buffer/storage capacitor.

As for gameboy_single_step(), it's in the external emulator code as described in the README #note-on-the-game-boy-emulator

I hope this clears things up :)

[tuantdang]

Dear @iiKoe,

As far I understand that when the interrupt on ADC (specifically, Window comparator voltage excursion interrupt) occurs the flag jit_checkpoint will be raised up. After 5 emulation steps with the raised flag, the checkpoint will be executed.

My question is how long is gameboy_single_step() 's execution time?
Have the Gamboy could missed some checkpoints because of 5 times execution of gameboy_single_step?

How about if checkpoint should be placed in the ADC interrupt service routine to response immmediately to power failure?

I think there are some reasons behind it.
I'm very happy if you share more about it.

P/S: I'm very interesting on this project and I'd like to learn more about it.
I'm sorry if these questions bother you guys. ^^

Thank you!

[iiKoe]

No problem @tuantdang, we will be happy to answer your questions 😃

I don't know the exact time gameboy_single_step() takes to execute, and it will vary somewhat, I think, due to the graphics emulation (not 100% sure). But in any case, the execution time is very short in the grand scheme of things (it's one assembly instruction of the z80 + some graphics). Placing the checkpoint in the interrupt might lead to some hard to debug situations compared to placing it at the start of the emulation loop, and it will not lead to any real benefits.

The magic number 5 is empirically chosen. It limits the number of checkpoints so that the system can also emulate some Game Boy code between checkpoints if the system reaches the "low energy" state (i.e., jit_checkpoint==1). This is just a very simple way to space out the checkpoints. Because the variable jitCheckpointcount has the keyword CHECKPOINT_EXCLUDE_BSS before it, it will be set to zero at every boot, so after a boot, the first checkpoint will always execute immediately (no 5 wait steps).
As you might observe, if the system gets out of the low energy state without rebooting, the variable does not reset to zero, but this is an edge case and not worth optimizing for.

[tuantdang]

Thank you for your answer!

[przemyslaw-pawelczak]

@tuantdang Apologies (I should have informed you before shifting your issue into Discussion) I have moved our discussion from Issues into Discussion section, as I feel it fits better here. Nonetheless, if you feel this fits better in Issues, I will revert our discussion here back into Issues.

Thanks again for being so active and we look forward to continued discussion with you! 💪

[tuantdang]

@przemyslaw-pawelczak
Thank you for your re-arrangement!

[przemyslaw-pawelczak]

My pleasure! Feel free to ask us any question you may have.