Weiß jemand, ob die Uhrzeit und Datum im C65 oder C65 vom System ausgelesen werden kann.
Ich habe im Handbuch auch nichts über das Stellen der Systemzeit gefunden.
Danke für die Rückinfo.
You are about to leave Forum64 to get redirected to the following address:
Please note, that the target website is not operated by us. We are not responsible for it's content nor does our privacy policy apply there.
Weiß jemand, ob die Uhrzeit und Datum im C65 oder C65 vom System ausgelesen werden kann.
Ich habe im Handbuch auch nichts über das Stellen der Systemzeit gefunden.
Danke für die Rückinfo.
Meinst Du TI$ ?
Setzen mit TI$ ="SS:MM:ss.ms" (Beispiel: TI$="19:25:30.7")
Ausgeben mit Print TI$
Der MEGA65 besitzt eine batteriegepufferte RTC, welche gesetzt werden kann.
Mir geht es um das Auslesen der batteriegepufferten RTC unter Basic 10.
Die Variable (TI) bzw. TI$ startet ja bei jedem anschalten neu, da der cevi keine batteriegepufferte Uhr hatte.
Der c65 hatte im Original (iirc) auch keine batteriegepufferte Uhr.
In der MEGA65 GEOS Version haben wir schon ein Tool eingebaut, mit welchem die RTC gesetzt werden kann und dann auch angezeigt wird.
Im letzten Ausgabe Mega64 user`s guide auf Seite 463 ist das Thema beschrieben. Sogar mit Basic Beispiel.
Jetzt ist noch offen, wo man die Zeit einstellen kann. Im Mega64 Geos, wie adtbm schreibt ist sicher eine Lösung.
Möglicherweise geht's noch anders. Mal sehen.
Also alles save.
Hallo,
ich habe es gerade für dich gemacht, dass man einfach im MEGA65 Configure Utility, den RTC liesen und aktualisieren kann. Sowieso:
Ist noch nicht perfekt, aber es geht.
LG
Paul.
Hi mega65 ,
Paul, i have a question: so the RTC is completely independant from the C64/C65s internal Timer
(TI$/TI) and keeps its settings saved in the RTCs own small battery powered NVRAM?
Since, iirc, some C64 programs were using the (unprecise) TI$ for certain operations.
So the new RTC is an usefull addition to the MEGA65, to be able to have precise time dependant operations working ?
Or in other words, we now have TI/TI$ & a RTC ?
Thanks Paul, for my programs the date plays a big role. I am very excited about the changed setup menu with date and time input. I can hardly wait to program a real mega65 computer.
Yes, we currently have TI$ and the RTC. I am thinking about how I can automatically inject the current time into a running C65, ideally automatically. This just needs a Hypevisor scheduled interrupt "hyperrupt" that gives the hypervisor the chance to inject the value after the C65 ROM has started up and initialised TI/TI$. Then it would just transparently be there. You are welcome to file a github issue, so that I don't forget to do it.
LG
Paul
Hi Paul,
thanks and this is indeed a great idea. i've created an issue in Github, here:
In Xemu (xc65 and xmega65) the actual time can be shown in BASIC 10 with PRINT TI$
I guess the emulator gets the time from the host system.
Yes, I believe so. We just need to implement a similar piece of magic for the MEGA65 to do this. I've got some ideas on this. It's just a matter of me having the time to attack it, along with everything else that needs to be done.
LG
Paul.
I hope you all realize, that TI / TI$ is only updated during the interrupts, and as soon as you load a program from disk (not even mentioning tape) this "clock" will be late?
I hope you all realize, that TI / TI$ is only updated during the interrupts, and as soon as you load a program from disk (not even mentioning tape) this "clock" will be late?
Yes, that's why i called it "unprecise". The RTC will be totally independant of it.
Like Paul said, our plan is to syncronise the TI$ with the RTC once at the bootup of the MEGA65 and then the user can do what he wants
with TI$ as usual.
If the User needs a precise clock, he can access the RTC ( MEGA65s GEOS is using the RTC i.e. already).
But thanks for the reminder anyway !
We could even periodically update it, but that is probably overkill.
But you are right that the C65's funny way of handling its internal drive causes a big problem for the TI/TI$ variables, as the CPU might be stopped for some time. That said, the DOS interface is so horribly innefficiently built, that apart from when seeking a new track or sector, the interruputs will be able to happen.
LG
Paul.
It's not just the internal drive - at least on C64 (standard Kernal) when loading from IEC device TI/TI$ counter misses about 1/6 ticks. Most turboloaders probably stop it completely. Commodore should have used TOD clock on one of the CIAs - but they didn't, they just reused VIC-20 code.
Periodical synchronisation from RTC might be disastrous for some C64 demos or games. They might disable original IRQ routines and reuse the $A0-$A2 for something else - this is a zero page after all. I could also imagine game setting the time to 0 and waiting for a certain value. IMHO such a feature should be user-selectable.
Yes, I quite agree that if we did it, it would be user-selectable.
I didn't realise that it was also a problem on the C64. I had figured that the IRQs would just be deferred, and get serviced after.
LG
Paul.
I was also surprised when I read about the delay here: https://www.c64-wiki.com/wiki/TIME - but after a quick test it was clear they are right.
The time setting inserted by Paul in the Chipset section of the Configuration menu should also be introduced like this in the manual.
I'm just fixing the documentation in the MEGA65 user guide material now.
There is also 45 pages of "introduction to BASIC" which is coming along nicely now.
LG
Paul.