Exakt laufende Uhr im Rahmen

In einem Thread auf lemon hatte jemand Bedarf an einer exakten Uhr für den C64. Im Lauf des Threads habe ich passenden Code entwickelt, der mit Hilfe der Timer von CIA#2 exakt Sekunden zählt (1022727 Cycles auf NTSC, 985248 Cycles auf PAL). Daraus ist einfach zum Spaß ein kleines Spielzeug entstanden, eine Uhr im Rahmen:

Source: https://github.com/Zirias/c64_borderclock
PRG hängt an.

Die Funktionalität der Uhr an sich ist im File src/clock.s zu finden, falls sich jemand dafür interessiert. Sie funktioniert ohne Interrupts (damit VIC Effekte nicht gestört werden), es muss mit clock_run "gepollt" werden (z.B. einmal pro Frame aus einem Raster IRQ), das Carry Flag sagt danach, ob die Uhr eine Sekunde weitergezählt hat.

Natürlich kommt auch diese Uhr aus dem Tritt, wenn IRQs länger deaktiviert werden -- ansonsten läuft sie aber so exakt wie auf dem C64 möglich

Mit Contiki dürfte der Code hier eher nicht kompatibel sein. Aber es wäre sicher möglich, per Abfrage eines NTP Servers bei entsprechender Netzwerkhardware z.B. einmal pro Tag diese Uhr zu korrigieren. Die Sinnhaftigkeit sehe ich aber nochmal ein Stück geringer als bei der Uhr an sich (die schon recht sinnlos ist)

Zitat von JeeK

Um die Laufstabilität auch bei IRQ-Blockierungen zu gewährleisten, könnte man ja die die CIA Realtime-Clock laufen lassen und als Gleichlaufreferenz verwenden.

Das ist eine hervorragende Idee :o Die TOD Clock wollte ich nicht verwenden, weil ich mich nicht auf eine exakte Frequenz des Wechselstroms verlassen wollte -- aber als Hilfe zur Korrektur bei verpassten Ticks scheint sie wirklich geeignet

Vielleicht kommt dann ja bald "V2" der unnützen Uhr

edit:

Zitat von JeeK

Schade dass die Kommentarspalte faktisch leer ist, sonst wär' es wirklich ein schönes Lehrstück.

Och, wer braucht schon Kommentare, der Source spricht doch für sich (oder etwa nicht)?

Aber ernsthaft, falls jemand etwas davon lernen will könnte das nützlich sein, im Thread drübern auf Lemon hatte ich den Code auch zunächst mit Kommentaren entwickelt. Ich denke die werde ich nachreichen

Zitat von Gerrit

Die ist sehr genau, zumindest auf die Zeiträume betrachtet die dein C64 damit am Stück laufen wird.

Dennoch bin ich mir fast sicher, dass der CPU-Takt im Zweifelsfall NOCH genauer ist

Zitat von Gerrit

Nein, ist er nicht, denn die 50Hz im Netz werden nachgeregelt damit sie, über die Zeit betrachtet, wirklich 50Hz sind.

Wir hatten letzten Winter ein Problem im europäischen Verbundnetz, aber ansonsten laufen netzsynchrone Uhren genauer als Quarzuhren.

"Nachgeregelt" bedeutet, dass es Schwankungen gibt. Man will ja nicht nur, dass die Uhr im Mittel, also "irgendwann wieder", korrekt läuft, sondern möglichst immer. Zudem bin ich sehr skeptisch, was solche Garantien angeht, wenn man etwas mehr als nur das europäische Stromnetz betrachtet.

Zitat von JeeK

Schade dass die Kommentarspalte faktisch leer ist, sonst wär' es wirklich ein schönes Lehrstück.

Ist nun nachgereicht, src/clock.s ist ausführlich kommentiert, so dass hoffentlich jeder nachvollziehen kann, wie es funktioniert

Hehe, eigentlich ist es eh recht sinnlos, darüber zu diskutieren, bei einem Tool, das eher als Spielerei / Techdemo gedacht ist, quasi als POC, dass man mit dem C64 (und eben OHNE externe Hilfe) eine genaue Uhr hinbekommt Ich hoffe mal, der mittlerweile kommentierte Code interessiert einfach manche "rein technisch"

Zitat von zrs1

Dennoch bin ich mir fast sicher, dass der CPU-Takt im Zweifelsfall NOCH genauer ist

Der CPU Takt läuft einen Mist genauer als z.B. die 50Hz aus dem Netz. Ganz allein weil fast jeder C64 Quarz nicht exakt gleich schnell und auf "Norm" läuft.
Ich hatte da ja bei Audio Rec.-Tests pro 4:47 Min., so lang lief das SID Stück zufällig, bis zu 25ms* Abweichung allein wegen eines leicht gedrifteten Quarzes, aber noch kein Farbaussetzer im / für's Bild bei dem (nur ganz leicht ein anderes Gelb) - bei anderen Quarzen kann das also gar noch krasser ausfallen.. :). 14 x 4:47 Min. den C64 mit einer solchen Uhr laufen lassen und schon hat man = eine ganze Sekunde Abweichung ! Exakt ist anders.. .

*Bzw. gar 30 bis 40ms (verglichen ersteres mit meinem schnellsten Cevi und zweiteres mit dem nochmal 10ms fixeren Reloaded MKI C64).., die 25ms waren nur die Abweichung von einem Normalwert den der Durchnitt aller Cevis so hatte.
Die widerum schwanken dann nur so um 4-5ms pro 4:47 Min., da dauert's dann zugegeben etwas (nochmal 4x) länger als im obigen Bsp., bis eine Sekunde Abweichung erreicht wäre.

Kennt man ja auch von Quarz Digitaluhren seit den 80ern. Ich hatte selten eine, die nicht nach ein paar Wochen schon um ein paar wenige Minuten falsch lief.
Selbes mit der Uhr an meinem Whg. Thermostat: Die Quarz Uhr darin geht nach einigen Wochen schonmal und regelmäßig um die 10 Min. vor (und aktuell schon wieder um 7 Min. vor, gerade nachgesehen), das ist das krasseste Bsp. welches ich kenne.
Gefolgt von der Uhr in meinem 2001er PIII Rechner.. . Die lief u. läuft etwas zu langsam, muss ich dann und wann immer wieder um einige Minuten vor stellen (heutzutage geschieht sowas ja syncronisierend mit dem I-Net, da braucht man das nicht mehr).

Wie geschieht das eigentlich in heutiger PC Software ? Im Simracing z.B. werden von den Programmen nur die lap Zeitnahmen des eigenen PCs beim z.B. hotlappen etc. an den Server übermittelt.
Wenn jetzt also einer einen PC hat, der zufällig oder gewollt (gehakt) intern etwas langsamer bei 'der Uhr' abläuft (der Rest aber gleich schnell, das Bild) hätte derjenige logischerweise einen Vorteil (Rundenzeiten die übermittelt werden sind niedriger). Wenn auch meistens vernachlässigbar, denn die paar ms pro Runde kann man sich meinetwegen noch schenken.

Da müsste ich eher beim Entwickler 'mal nachfragen, hier im Forum weiß das ggf. keiner ganz genau. Interessiert mich aber schon länger, bzw. treibt mich die Frage etwas 'rum.

@CommieSurfer, du dürftest dich ruhig ein bisschen klarer ausdrücken. Die qualitative Aussage (der C64 Takt läuft nicht ganz exakt) wird zwar klar, überrascht mich auch nicht wirklich -- aber was du an Werten angibst ist verwirrend bis widersprüchlich. Ich entnehme dem mal, dass dieses MK1 Board einfach "zu schnell" läuft, und damit für eine Uhr dieser Art hier unbrauchbar wäre. Ansonsten --- was soll das jetzt bedeuten? Wenn ich es so interpretiere, dass die 5ms pro 5min etwa die "Standardabweichung" deiner Stichprobe sind würde das heißen, auf einem originalen Gerät wäre die zu erwartende Ungenauigkeit 1 Sekunde pro 200* 5 Minunten, also eine Sekunde in 16 Stunden und 40 Minuten. Das finde ich für eine C64 Uhr aber völlig akzeptabel, es überbietet die "Genauigkeit" von TI$ jedenfalls bei weitem. Und der Vorteil des Systemtakts ist, dass er absolut gleichmäßig läuft -- ein Drift stellt sich also erst nach längerer Zeit ein.

Wenn man jetzt tatsächlich mal über sowas wie "praktischen Nutzen" nachdenkt könnte man z.B. bei BBS Servern landen, die dann wirklich lange Zeit durchlaufen. Dort könnte man, unter der Annahme, dass die Wechselstromfrequenz zumindest im 24-Stunden Mittel sehr exakt ist, etwas ähnliches implementieren wie NTP: Mit Referenz über die TOD den Drift des eigenen Takts immer genauer berechnen und mit diesen Erkenntnissen die Geschwindigkeit der Uhr feinjustieren Das wäre dann sicher DIE PERFEKTE C64-Uhr (als reine Softwarelösung) -- ist allerdings nicht ganz einfach zu implementieren.

Ich wollte mal wissen, wie genau das eigentlich in VICE läuft Also heute morgen um 8:48 die Uhr passend gestartet (VICE 3.2 auf Windows 10)

Inzwischen geht die Uhr ziemlich genau 3 Sekunden nach. Würde mal sagen ziemlich gut für einen Emulator

@JeeK cool! Das beweist, dass VICE die originale Geschwindigkeit sehr gut trifft. Und ich vermute auf Linux/BSD/.. (vermutlich allen Systemen mit X11) sogar noch ein bisschen genauer als auf Windows, denn auf Windows ist mir aufgefallen, dass der emulierte Rechner z.B. beim Fenster verschieben stehenbleibt. Vermutlich kann VICE da nichts dafür...

Viel interessanter fände ich natürlich Testergebnisse auf realer Hardware. Die Uhr ist "nach Specs" absolut genau, so könnte man schauen, wie exakt denn die Oszillatoren so sind Wenn nicht gerade die 1571 im 128D den Geist aufgegeben und der 64 (wohl wegen defektem CIA) nicht mehr mit der 1541 sprechen würde, hätte ich schon längst selbst Tests gestartet....