Exakt laufende Uhr im Rahmen


  • zrs1
  • 1377 Aufrufe 59 Antworten

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • 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: 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 :)
    Dateien
    • borderclock.prg

      (1,25 kB, 21 mal heruntergeladen, zuletzt: )

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von zrs1 ()

  • zrs1 schrieb:

    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.
    Fein, fein. Schade dass die Kommentarspalte faktisch leer ist, sonst wär' es wirklich ein schönes Lehrstück. ;)

    Das ist mir nur ad hoc eingefallen (ohne jetzt all zu viele Überlegungen der Realisierbarkeit gemacht zu haben):
    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. Auch wenn die RTC-Uhr selbst nicht synchron mit der Atomuhr ist, so reicht sie verschwindende IRQs auszugleichen. Z.B. mit einer Alarmzeit einen Interrupt auslesen und überprüfen, ob im entsprechenden Intervall auch die zu erwartende Anzahl von IRQs aufgetreten sind. Falls nicht, korrigiert man nach (dann springt die Uhr eventuell).
    Natürlich könnte man da gleich auf die Idee kommen, die RTC direkt zu verwenden ... spricht da etwas dagegen?
  • JeeK schrieb:

    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 :thumbup:

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

    edit:

    JeeK schrieb:

    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 :)
  • zrs1 schrieb:

    Dennoch bin ich mir fast sicher, dass der CPU-Takt im Zweifelsfall NOCH genauer ist
    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.
  • Gerrit schrieb:

    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.

    JeeK schrieb:

    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 :)
  • Gerrit schrieb:

    Nein, ist er nicht, denn die 50Hz im Netz werden nachgeregelt damit sie, über die Zeit betrachtet, wirklich 50Hz sind.
    IIRC braucht das aber einen Betrachtungszeitraum von ca. einem Tag oder so, kurzfristig ist der C64-Quarz genauer. Leider habe ich bisher keine ADEV-Diagramme für das Europäische Verbundnetz gefunden und mir fehlt die Technik um das mal selbst zu messen. Eine Messung aus den USA sieht aber ziemlich mies aus, schlechter als 10^-5 bei einer Mittelungszeit von einem Tag (etwas unter 10^5 Sekunden).

    Quellcode

    1. 10 x=rnd(-1963):fori=1to81:y=rnd(1):next
    2. 20 forj=1to5:printchr$(rnd(1)*16+70);:next
    3. 30 printint(rnd(1)*328)-217

    sd2iec Homepage
  • zrs1 schrieb:

    Gerrit schrieb:

    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 :)
    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).
    ' war Anfang 2000 schonmal unter dem Kennnamen 'c64fan' hier unterwegs.

    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von CommieSurfer ()

  • 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.
    ' war Anfang 2000 schonmal unter dem Kennnamen 'c64fan' hier unterwegs.
  • @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.
  • Neu

    zrs1 schrieb:

    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)
    Ich hab's auch schon seit gestern ca 21:30 laufen. Da war sie immer so eine halbe Sekunde hinter der NTP-synchronisierten Uhr des Hostsystems (Linux, Vice 2.4.28).
    Nach 21h läuft die Uhr im Emulator nun etwas vor (weniger als 1 s). Also der Drift ist bei mir in 21 h so ca. 1 bis 1,5 s.
  • Neu

    @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....
  • Benutzer online 1

    1 Besucher