Frequency tones and time drift

[shurillu]

Hello Jean-Christophe,

I found your library and I'm very happy with it. I'm doing some experiments with it and an ESP32 board (actually an M5Stack Core). During my experiments, I noticed that the frequency reported in the callback static void hal_set_frequency(u32_t freq) is ten times the real value. For example, the initial beep (when the emulator boots) is reported as 23406 Hz, far beyond the real tone frequency. Dividing it by 10, it have the correct tone/frequency. Is that correct? Using the static void hal_sleep_until(timestamp_t ts) callback I can manage correctly the synchronization between the emulated MCU and the ESP32, but I noticed a little time drifting (around a second over ten minutes, the emulated machine go faster). I checked the tamatool WIN32 application and there is a similar time drift. There is a way for setting the time in the emulated machine, without doing it manually? Thank you for your excellent work, it bring me back to the '90 heheh

Cheers,

Stefano

[jcrona]

Hi @shurillu,

You are correct for the frequency, it is in decihertz, I made it clear in hal.h now. Regarding the drift, I noticed it too. It probably comes from how instruction durations are cast to integer in cpu.c, it is on my TODO list ;-). As for setting the time, I actually looked at the disassembled code some time ago to see if it would be possible to inject the time, and it is. However, I did not write the code to do it as it becomes very dependent on the ROM emulated (even if there is only one out there). But I could if you are interested in it. It is basically a matter of memory patching, with an optional JUMP if you want to start from an uninitialized Tamagotchi (the code handling that state is actually a separate loop from the regular "mainloop").

[shurillu]

Hello @jcrona, thank you for the reply! Diving in the sources, I found that the frequncy is in decihertz, thanks. Regarding the ability/possibility to correct the drift by synchronizing the time in the emulated CPU with the time of the host, it could be a workaround. If you want I can do some test, as long as you found a way to solve the "root of the drifting issue" ;-)

Regards,

Stefano

[BenjaminSoelberg]

See my code on how to patch the time in a running emulator:

https://github.com/BenjaminSoelberg/game-and-watch-retro-go/commit/a9191bc84437ce4b1b546525ea3723a2e4cf8351

[shurillu]

Hello Benjamin, thank you so much for reviving this thread! I saw your suggestion and it solved my problem, thank you so much. Have you decoded other memory location? For example, the joy/hungry level.. Regards,

Stefano

[BenjaminSoelberg]

Stefano, im glad you could use the information. I haven't really looked too much into the memory. So unfortunately no. I found the locations for the clock by hex dumping the memory each frame to watch the difference on a running emulator. You could do the same ?

[shurillu]

Hello Benjamin, thanks for the quick response. Before doing a memory dump & compare, I asked: maybe you already have found other infos ;-) Again, thanks a lot! Regards,

Stefano

[BenjaminSoelberg]

Nope, haven't found anything else but wasn't looking either.