I figured the reason why it was doing that is because the second timer is going from minute to minute is what checks the time and then checks whether to set the alarm, and it's true because if I hold down fast forward, the alarm will go off multiple times because of the internal timer reaching 60 or 0 or whatever.
I'm glad that it's working correctly now, Thank you so much for the wonderful script. I also edited it and got it to work with the registries in super mario bros!
We could try to make a zip of the cheats for each game I suppose
"desc": "Set clock to current time",
"run": "local lt = os.date('*t') local sec = lt.sec+1 if sec>=60 then sec=sec-60 end if sec >0 and sec<59 then cpu:write_u8(38,sec // 10) cpu:write_u8(39,sec % 10) end cpu:write_u8(37, lt.min % 10) cpu:write_u8(36, lt.min // 10) local hour = (lt.hour > 12) and (lt.hour - 12) or lt.hour if lt.hour == 0 then hour = 12 end cpu:write_u8(35, hour % 10) cpu:write_u8(34, (hour // 10+12) + (((lt.hour > 12) or (lt.hour == 12)) and -10 or 20))"
Edit: I made an edit to incorporate seconds to trigger the alarm. it syncs seconds besides the between 59 to 0 to activate the trigger for the alarm. Works pretty well.
I get what you mean by having the sync script just run on startup to minimize issues. I do think it could be fixable by having a variable that keeps track of a minute change and syncs each starting second back to 0 when the system clock starts at 0 seconds. If you think it would cause gameplay behavior to change I can test it out. Messing around with values in the registry suggest that a lot of timed events during gameplay have their own timers not correlated to the clock, and even if it was, it would probably be using the timer that counts seconds, not the seconds, minutes, or hours themselves. Maybe if these values influence pseudo random generation then maybe, otherwise maybe not.
By the way, What's a good way to read the hex registries in mame when running a game for debugging?