Views: 6,703,205 Homepage | Main | Rules/FAQ | Memberlist | Active users | Last posts | Calendar | Stats | Online users | Search 03-29-24 12:32 PM
Guest:

0 users reading Need hel fixing the clock | 1 bot

Main - Development - Need hel fixing the clock Hide post layouts | New reply


TheMisteryousBoi
Posted on 01-28-19 01:59 AM Link | #862
Hello There guys! it turns out that I have been using melon ds for a long time. a few months ago I found a way to get event exclusive pokemon through downloading a distribution ROM, but it was necessary to edit the date of my PC. I edited it many times, and now my games inner clock isnt working properly: the berries wont grow, the swarms wont change, the Battleground gym leaders wont change... is there a way to fix this?

Arisotura
Posted on 01-28-19 12:22 PM Link | #863
the game might have detected that you're messing with the system time.

dunno.

____________________
Kuribo64

Ammako
Posted on 01-31-19 02:00 AM Link | #864
Guessing, melonDS is using the system clock as the in-game RTC, ignoring whichever offset value is in DS firmware, and using something else as the base internal RTC value, in such a way that changing the system clock allows games with anti time travel to detect that the clock has been tampered with. I don't actually know, but given that games are able to detect it, I imagine I can't be too far off.

If you would be interested in adding support for this in melonDS, I guess a better way of doing it would be to use system clock as internal RTC, using an RTC offset of 0 and ignoring whichever offset is saved in the firmware. Then you could have an option in melonDS config to enable the RTC offset, which would read the RTC offset from firmware to determine what the actual in-game time would be. People have been requesting the ability to change the DS clock independently of system clock through DS menu settings some time ago, so they'd probably be happy with that. As long as they don't mind that it would trip the anti time travel in games.

Arisotura
Posted on 04-08-19 11:12 PM Link | #961
technical note: the firmware doesn't actually store any offset or anything related to the current time. changing the date/time via the firmware interface directly changes the RTC parameters.

except in melonDS, changing the RTC parameters does nothing, because it always derives them from the host's current time.

I guess storing an offset would be the way to go for this to be possible.

another question would be: if melonDS runs below 60FPS, should the time stay true to host time (counting every second no matter what) or to guest time (so, to the emulated game, one second is one second, but then it'll drift away from host time)?

____________________
Kuribo64

Ammako
Posted on 04-09-19 10:27 PM (rev. 5 of 04-09-19 10:33 PM) Link | #971
Thought it did

https://problemkaputt.de/gbatek.htm#dsfirmwareusersettings

Addr Size Expl.
000h 2 Version (5) (Always 5, for all NDS/DSi Firmware versions)
002h 1 Favorite color (0..15) (0=Gray, 1=Brown, etc.)
003h 1 Birthday month (1..12) (Binary, non-BCD)
004h 1 Birthday day (1..31) (Binary, non-BCD)
005h 1 Not used (zero)
006h 20 Nickname string in UTF-16 format
01Ah 2 Nickname length in characters (0..10)
01Ch 52 Message string in UTF-16 format
050h 2 Message length in characters (0..26)
052h 1 Alarm hour (0..23) (Binary, non-BCD)
053h 1 Alarm minute (0..59) (Binary, non-BCD)
054h 2
056h 1 80h=enable alarm (huh?), bit 0..6=enable?
057h 1 Zero (1 byte)
058h 2x2 Touch-screen calibration point (adc.x1,y1) 12bit ADC-position
05Ch 2x1 Touch-screen calibration point (scr.x1,y1) 8bit pixel-position
05Eh 2x2 Touch-screen calibration point (adc.x2,y2) 12bit ADC-position
062h 2x1 Touch-screen calibration point (scr.x2,y2) 8bit pixel-position
064h 2 Language and Flags (see below)
066h 1 Year (2000..2255) (when having entered date in the boot menu)
067h 1 Unknown (usually 00h...08h or 78h..7Fh or so)
>>068h 4 RTC Offset (difference in seconds when RTC time/date was changed)
06Ch 4 Not used (FFh-filled, sometimes 00h-filled) (=MSBs of above?)

It has to be doing something like this, otherwise games wouldn't be able to detect when the RTC is changed to trigger their anti time cheat mechanism.

It's worth noting that this is how the 3DS works as well, and DS games follow 3DS RTC settings when played on a 3DS (and likewise, you can change raw RTC instead of changing the time in system settings, to time cheat in both DS and 3DS games.)

Arisotura
Posted on 04-09-19 11:08 PM Link | #974
oh, so it does.

I'd have to look into how that works. that's interesting.

____________________
Kuribo64

Ammako
Posted on 04-10-19 03:43 AM Link | #975
Also, regarding the framerate, imo it should stay true to host clock regardless of whether the emulator is running above or below 60 FPS. It's unlikely that games rely on RTC being "in sync" with the cpu timings/speed to function properly, although in all fairness I can't say this with certainty.

The option to de-limit the framerate is really nice for RPGs especially, as well, and it would be quite annoying if the in-game time were to move faster because of the game running at a framerate higher than normal.

It's probably not worth worrying about until a game shows up that does break because of the RTC, in any case.


Main - Development - Need hel fixing the clock Hide post layouts | New reply

Page rendered in 0.035 seconds. (2048KB of memory used)
MySQL - queries: 27, rows: 88/88, time: 0.014 seconds.
[powered by Acmlm] Acmlmboard 2.064 (2018-07-20)
© 2005-2008 Acmlm, Xkeeper, blackhole89 et al.