agg23 / fpga-tamagotchi

Tamagotchi P1 for Analogue Pocket and MiSTer
MIT License
110 stars 1 forks source link

RTC support? #5

Closed zenzoa closed 1 year ago

zenzoa commented 1 year ago

Ask a question

It would be awesome if the tamagotchi used the Analogue Pocket's real-time clock support to run at super-speed to catch up to whatever time the player starts it again, allowing it to more closely resemble running an actual tama 24/7.

Thanks so much for making this core!

agg23 commented 1 year ago

I agree, and that was the original idea, but there are a number of problems with that. Instead of rehashing a similar answer I gave, with the Pocket in particular for context, I'll just link to it here, and reproduce the answer for clarity: https://www.reddit.com/r/AnaloguePocket/comments/12mns4v/tamagochi_core_coming_soon/jgen8wz/


My original idea was to use the RTC on power on to restore the Tama to the state it would be had time passed since you last turned it off. A number of problems appeared with that:

  1. The Tamagotchi CPU never sleeps, screen never turns off, etc. It runs 24/7 from pulling the battery tab until it runs out of power. This means you can't do anything fancy to skip time; you must emulate every cycle

  2. With some convincing, the fastest I managed to run my design [on Pocket] at was 117.96 MHz (EDIT: Higher speeds may actually be harder on MiSTer, given that there's a large amount of framework code that also needs to run at that speed), which results in a 1,800x speedup. This means 1 second real time can be up to 30 minutes in Tama-land. Tamas can live for up to 14 days, so it seems like you would have to be able to "catch-up" that amount in a reasonable amount of time. 14 days = 20,160 minutes => 672 seconds to turbo from second 0 to 14 days. I could probably convince the design to run faster, but that means more power draw and getting closer to problems with the fabric with the entire core running so fast.

  3. I quickly realized after playing with it that most Tamas will die pretty quickly without interaction (namely feeding). Something like a few hours is enough in many cases for it to die. It doesn't make sense to build a feature that results in dead Tamas every time someone boots up the core

  4. # 3 then begs the question of whether or not you need to generate savestates so the user can go back to them if the Tama unexpectedly died/how would these savestates be accessed?

In other words, it just ended up being a big collection of problems that it didn't seem worth addressing yet. I'm open to user feedback on how I might improve this situation.

zenzoa commented 1 year ago

Thanks for such a thorough answer! I'm working on a game boy vpet of my own, hoping to take advantage of the Pocket's RTC once it gets support from the third-party gb core or the .pocket format, and I definitely need to slow down the pace significantly for those reasons (assuming the player checks in once or twice a day, instead of potentially multiple times an hour).

mhmetalheart commented 1 year ago

now I fully understand! thanks.