letzter Beitrag von pi64 am
Bei uns in Österreich hieß es "Es wird mit dem Summerton ......."
Interessant. Ich wusste nicht, dass das für Österreich extra aufgenommen wurde. Steht im Wiki Artikel aber drin 
.
Auf der Wikipedia-Seite kann man oben rechts ein Beispiel der deutschen Ansage anhören.
https://de.wikipedia.org/wiki/Zeitansage
Witzigerweise geht auch 25 Uhr
Witzigerweise geht auch 25 Uhr
Eine "Tag" dauert auf Merkur etwa 58 Tage. Also müsste dort die Uhr 1.392 Stunden anzeigen 
input validation ist luxus, den sich der c64 coder nicht leisten mag ... ihr sollt mir nicht böswillig mein Programm zerschießen !!!1
Nach diesen Erkenntnissen würde ich TOD auch nicht zur Messung des lokalen Drifts einsetzen. Genauer als meine Uhr hier dürfte (ohne zusätzliche Hardware wie DCF-77 Empfänger oder Netzwerkkarte) einfach nicht möglich sein.
Das spielt ja keine Rolle, es geht ja nur darum verlorene Interrupt (laos wenn das meinen Vorschlag angeht) auszugleichen, da ist es m.E. egal, wie die Langzeitgenauigkeit der TOD ist. Wichtig ist, dass diese keine Aussetzer hat. Davon kann man ja ausgehen.
Aber man muss auch nicht die TOD nehmen, sondern könnte einen weiteren CIA-TImer nehmen, der mit automatischen Timer-Reload vor sich hinläuft. Die Interrupt-Routine kann dann vergleichen, ob die dort verstrichene Zeit mit den Interrupt noch passt und gegebenenfalls korrigieren.
Oder gleich einen anderen Ansatz. Einen Referenz-Timer (vielleicht A+B gekoppelt) laufen lassen mit automatischem Reload.
Das aktualisieren der Uhr passiert z.B. dann in einem beliebigen Interrupt (Raster, noch ein anderer Timer) und dort wird nur das verstrichene Intervall gemäß Referenztimer aufaddiert und dargestellt. Wie wär das? 
So, bin noch ein paar Bytes losgeworden durch eine etwas sinnvollere Speicheraufteilung ....
UND -- wofür gibt's conditional assembly 
Mit make DEFFONT=1 lässt sich jetzt eine Version bauen, die sehr unauffällig läuft und den Systemzeichensatz verwendet. Hat definitiv auch was für sich -- den Build hänge ich mal an
Cooles Programm,
hab nochmal was ausprobiert.
Wenn man die Uhr auf z.B. 4:59:58 setzt dann dauert der Refresh auf 5:00:00 ca. 2 Sekunden ansonsten.
Also man sieht 5:00:00 gat nicht erst sondern direkt 5:00:01
Zumindest in Vice.
Schande, das ist ein Bug! Passiert immer, wenn die Stunde wechselt, ist mir noch gar nicht aufgefallen. Immerhin, die Uhr läuft trotzdem korrekt Jetzt sehe ich natürlich direkt den Fehler, muss noch überlegen, wie ich den am elegantesten fixe...
edit: Bugfix eingecheckt.
Neue Builds im Anhang
UND -- wofür gibt's conditional assembly Mit make DEFFONT=1 lässt sich jetzt eine Version bauen, die sehr unauffällig läuft und den Systemzeichensatz verwendet. Hat definitiv auch was für sich -- den Build hänge ich mal an
Ja, super! Ich wollte bei der Originaloptik nicht herummäkeln, aber die Systemfont-Variante ist jetzt wirklich augenschonend. Weniger ist dann doch auch mal mehr.
@JeeK dachte halt wenn ich schon sprites brauche kann ich "was draus machen" war ja eh ein Spaßprojekt, und der Effekt jede Sekunde war bewusst "annoying" ... aber Grafik hab ich auch einfach nicht drauf!
Was TOD angeht, habe nicht deinen Vorschlag gemeint -- zum erkennen "verpasster" ticks taugt TOD sicher! Ging um die Idee, anhand der TOD vielleicht den Drift zu korrigieren, die ist nach den Messergebnissen im Web verworfen
Ist es Absicht dass eine schwarze Linie angezeigt wird oberhalb der Uhrzeit? Oder liegt das am Emulator den ich gerade nutze (Frodo auf dem Android-Handy)
@ZeHa ich krieg es gerade auf meinem handy weder in anvice noch in frodo geladen 
da soll natürlich KEINE schwarze linie sein und im x64sc (vice 3.2, auf windows und freebsd) ist da auch keine, aber ich muss zugeben, dass ich gerade nicht auf echter hardware testen kann, wegen diverser hardware-schäden
Edit: konnte es jetzt in frodo nachstellen -- PLUS müll in der obersten Bildschirmzeile. Hoffe mal sehr das liegt an Frodo
Edit2: AnVICE 3.1 (x64sc, armeabi8) lädt es korrekt und zeigt auch korrekt an (keine schwarze linie, kein bildschirmmüll). Ich denke/hoffe frodo vermurkst da das timing mit meinem "fake" rahmen
Kann man das "resident" machen (im REU o.ä.), so dass das auch z.B. in Spielen überlebt?
vermutlich möglich, aber sinnlos im aktuellen design läuft die uhr nur, wenn sie regelmäßig (z.b. eben im raster-IRQ, so ist das jedenfalls gedacht) "gepollt" wird. Man kann sie natürlich auch per NMI treiben (mit dem Nachteil, dass das ins eventuell cycle-exakte timing von raster-IRQs pfuschen würde) oder @JeeKs Idee aufgreifen und die TOD zur Kontrolle mitlaufen lassen -- aber niemand garantiert, dass das Spiel nicht einfach selbst an den Timern der CIA#2 fummelt, und damit hat man dann spätestens verloren. So ist das eben auf alten Systemen ohne Speicherschutz und mit vollem Hardwarezugriff für jedes Programm
"Fehlerteufel" zu meinem letzten Post: meinte natürlich arm64-v8a armeabi heißen ja nur die 32-bitter...
vermutlich möglich, aber sinnlos
Als Uhr vielleicht. Aber als Systemmonitor (ähnlich Conky) könnte man ja auch sinnvolle Dinge darstellen, wie Visualisierung des SID, Ableiten der CPU Auslastung, Taktgeber, Bitflags, IRQs, Diagnosegeschichten oder ein buntes Patchfeld., dass relevante Speicherzellen farbig repräsentiert. Keine Ahnung, was man da raus holen könnte. Ein permanentes Overlay, das Systeminformationen in Echtzeit anzeigt finde ich durchaus spannend.
Ich glaube mich erinnern zu können, dass es mal auf einer 64'er Heftdiskette ne Uhr im Rahmen gab. Wie genau die war hab ich nie getestet.
Ein permanentes Overlay, das Systeminformationen in Echtzeit anzeigt finde ich durchaus spannend.
Das interessante hier war meiner Meinung nach die Uhr, der Rest ist "nur" (auch im Code völlig unabhängig) Präsentation. Wenn man das per Software "permanent" haben will muss es auch immer im RAM sein, schon dafür bietet die Architektur des C64 keine Möglichkeit -- jedes Programm kann "alles" tun, also auch jedes andere überschreiben. Außerdem braucht eine Darstellung im Rahmen raster-IRQs an den richtigen Stellen. Dazu kommt dann, dass sich viele von dir vorgeschlagene Dinge in Software überhaupt nicht zuverlässig monitorn lassen. Der SID zum Beispiel hat fast nur write-only register. Interrupt-Vektoren kann jedes programm beliebig ändern (was auch ständig genutzt wird), auf der basis kann man also niemals zuverlässig Interrupts zählen -- usw.
Was du dir hier vorstellst müsste auf dem C64 in Hardware realisiert werden.
Ich glaube mich erinnern zu können, dass es mal auf einer 64'er Heftdiskette ne Uhr im Rahmen gab. Wie genau die war hab ich nie getestet.
Die würde ich gerne mal sehen, vor allem um mal zu schauen, wie die Anzeige realisiert wurde Ich bin ja "verschwenderisch" mit den Sprites und nutze alle 8, brauche dadurch aber auch sehr wenig Rechenzeit. Mit dem System-Font würden prinzipiell 3 Sprites genügen...
Kann man das "resident" machen (im REU o.ä.), so dass das auch z.B. in Spielen überlebt?
In der REU könnte der Code überleben, aber die Uhr würde dort nicht laufen.
Ein permanentes Overlay, das Systeminformationen in Echtzeit anzeigt finde ich durchaus spannend.
In Emulatoren sind solche Debug-Features sicher kein großes Ding, aber so als C64-Software wohl eher nicht. Da geht eigentlich gar nichts, ohne andere Programme zu stören. Ein C64 ist eben keine Multitasking-Platform. Deswegen sind auch Viren auf dem C64 eine sehr seltene Spezies.
Mich auch, ich kann's nur grad ums verrecken nicht finden. Hab bisher nur in Sonderheft 93 ne BASIC Erweiterung entdeckt für die Nutzung des Rahmens.
Die würde ich gerne mal sehen, vor allem um mal zu schauen, wie die Anzeige realisiert wurde
