letzter Beitrag von Mike am
TI$ ist eine Betriebssystemvariable, die wird beim Reset zurückgesetzt.
Ich rate mal: Mit BBRTC ist wohl gemeint, dass die Real Time Clocks in den beiden CIAs nachgezogen werden. Ist auch sinnvoller, die gehen genauer.
BBRTC ist eine ecterne RTC (laut VICE-Doku für Joy- oder Userport?), und ohne zusätzliche Software macht die mal grad gar nix.
OK, danke. Dann habe ich falsch geraten und hätte besser die Doku gelesen. 
Ich hätte die Idee ganz witzig gefunden, die CIA-TODs beim Reset im Emulator mit bestimmten Werten zu initialisieren. Gut, braucht wahrscheinlich wirklich (fast) niemand. 
Alles was RTC heisst, sollte eine externe Real Time Clock sein wie z.B. die hierzulande verkauften DCF77-Empfänger. Wie mc71 schon sagte braucht es Software, die damit was anzufangen weiss, sonst tut sich da nichts. Hat man die, ist es allerdings ganz spassig wenn meinetwegen GEOS mit entsprechendem Treiber schon beim Laden weiss was die Systemzeit ist. Theoretisch könnte man natürlich auch einfach eine (total unrealistische) Option in einen Emulator einbauen, nennen wir sie mal "Host system time passthrough on startup (y/n)", die wenn gewünscht die echte Uhrzeit tatsächlich direkt in TI$ schreibt. Wäre ja irgendwie ganz witzig.
Ja, wäre nett; als erste Fingerübung in BASIC seit etwa 20 Jahren versuche ich mich zur Zeit an einer großformatigen Digitaluhr (in meinem Avatarbild werden schon ein paar Zahlen auf den Bildschirm gemalt) mit Alarm, Zeitzonen und Countdown - als Killerfunktion inklusive Presets für Ziehzeiten meiner Lieblingsteesorten. 
Wäre halt fein, die Uhr im Emulator nicht immer neu stellen zu müssen.
Hier in diesem älteren Thread hat's Artverwandtes:
Vice V2.4 neue Funktionen
Wir hatten vor einiger Zeit auch mal einen Thread mit gesammelten grossen Bildschirmuhren-Programmen, finde ich dummerweise aber nicht wieder...
Wir hatten vor einiger Zeit auch mal einen Thread mit gesammelten grossen Bildschirmuhren-Programmen, finde ich dummerweise aber nicht wieder...
Vermutlich meinst Du diesen Thread: Wake Up Clock!!!!
Vermutlich meinst Du diesen Thread: Wake Up Clock!!!!
Genau den, danke.
ist es allerdings ganz spassig wenn meinetwegen GEOS mit entsprechendem Treiber schon beim Laden weiss was die Systemzeit ist.
Das geht doch schon .
Unter Geos arbeite mit einer CMD FD und benutze das Programm: CMD-Time. Die anderen Uhren-Programme von CMD (auch das für FD) funktionieren wohl nicht in VICE.
CP-Uhr habe ich auch mal probiert. Geht irgendwie nicht 
.
Bei MegaPatch 3 ist es noch einfacher: CMD-FD konfigurieren und im GeosxxEditor kannst Du das Uhren lesen auf Automatisch oder CMD-FD stellen. Nach dem Booten hat Geos/MP3 ist die Zeit des PC von Geos/MP3 übernommen.
Gruß
Werner
Abgesehen von den hier bereits vorgestellten Lösungen ist es vielleicht ganz gut so, daß VICE und andere Emulatoren die Anfrage im OP nicht so umsetzen wie gewünscht - es dürfte genügend Programme geben, welche die Zeropage-Adressen 160..162 (in welchen die Jiffy-Clock, vulgo: "TI$", sitzt) für andere Zwecke nutzen. Natürlich haben die dafür den IRQ auch woanders hin verbogen.
Jetzt ganz ironiefrei - was macht so ein Programm, wenn ein Emulator "von außen" diese Bytes verändert?
ZitatAbgesehen von den hier bereits vorgestellten Lösungen
Kurze Intervention: Zu meinem Ziel (Uhr mit Gedächtnis für BASIC im Emulator) sehe ich bisher keine Lösung. GEOS lässt mich völlig kalt.
Zitatvielleicht ganz gut so, daß VICE und andere Emulatoren die Anfrage im OP nicht so umsetzen wie gewünscht - es dürfte genügend Programme geben,
Wäre ja kein Problem als Option.
Abgesehen von den hier bereits vorgestellten Lösungen ist es vielleicht ganz gut so, daß VICE und andere Emulatoren die Anfrage im OP nicht so umsetzen wie gewünscht
Solange es optional bzw. das Verhalten an- und abschaltbar ist (was es sein sollte, sonst wäre es schlechtes Design), ist alles legitim.
(Exkurs: die Älteren (ahem...) werden sich erinnern, dass in der Frühzeit der Emulatorerei mal angedacht war, jeden Emulator im Gastsystem selbst mehr oder weniger zwingend identifizierbar zu machen, mit fix vergebenen ID-Bytes und Versionsnummern und Copyright Strings im Speicher und dergleichen. Das war dann nicht optional, und deswegen Müll. Wirklich mitgezogen hat da auch kaum jemand, und es hat sich zum Glück nicht durchgesetzt.)
Kurze Intervention: Zu meinem Ziel (Uhr mit Gedächtnis für BASIC im Emulator) sehe ich bisher keine Lösung.
Die Userport-RTC läßt sich mit einer kleinen Routine auslesen und nach TI$ übertragen. Dazu braucht's kein GEOS. Wenn sich partout kein Beispiel einer solchen Routine auftreiben läßt, dann ist das sicher ein guter Grund hier im Thread so eine Routine zu entwickeln.
Solange es optional bzw. das Verhalten an- und abschaltbar ist (was es sein sollte, sonst wäre es schlechtes Design), ist alles legitim.
Für mich ist da insofern eine Grenze überschritten, weil der Emulator - egal ob optional oder nicht - eine Funktion nachbildet, die in echter Hardware nicht realisiert ist und wo auch nicht absehbar ist, daß das mal einer macht. Wenn Du eine Erweiterung am C64 kennst, welche an der CPU vorbei Änderungen in die Zeropage-Adressen 160..162 reinschreibt, lasse ich mich da gerne eines besseren belehren.
Ansonsten stelle ich dann schon gerne die Frage, warum da anhalten? "Spinnen" wir uns doch einen VIC-II mit 256 oder noch mehr Farben, einen 5.1-Dolby-Surround-SID und noch anderes in Emulation zurecht. Wie, der echte C64 kann das nicht? So ein Pech.
Für mich ist da insofern eine Grenze überschritten, weil der Emulator - egal ob optional oder nicht - eine Funktion nachbildet, die in echter Hardware nicht realisiert ist
Genau das ist doch der Vorteil eines Emulators. Dass man da eben auch Sachen machen kann, die auf echter Hardware nicht gehen. Ich z.B. hab' noch nie einen C64 mit eingebauter "Warp" Funktion gesehen und nutze ALT+W in Vice in schöner Regelmässigkeit.
Wenn sich partout kein Beispiel einer solchen Routine auftreiben läßt, dann ist das sicher ein guter Grund hier im Thread so eine Routine zu entwickeln.
Siehe z.B. mein Link in Post 10. Ansonsten dürfte entsprechendes Material bei ungefähr jeder verkauften RTC-Hardware im Handbuch oder/und auf der beigelegten Diskette finden. Von Projekten in 64'er & Co ganz zu schweigen.
Ansonsten stelle ich dann schon gerne die Frage, warum da anhalten?
Ganz genau. Warum da anhalten? Die Frage ist lediglich, ob eine solche Option sinnvoll oder nützlich gefunden würde, oder ob sie eingebaut würde um dann unbeachtet rumzurosten weil sich niemand dafür interessiert.
Emulatoren können prinzipbedingt haufenweise Sachen, die die echte Hardware nicht können kann, auch nicht in aufgebohrter Form oder mit externen Erweiterungen. Eine vom Host optional reingeschriebene Uhrzeit wäre auch nicht viel anders als per Monitor im Speicher rumzuwerkeln. Deine Meinung in allen Ehren, aber ich sehe nicht so wirklich warum man da katholischer sein sollte als der Papst.
[...] Vorteil [...]
Die von dir angeführte Warp-Funktion ändert nichts grundsätzliches an der Funktionalität der emulierten Hardware, außer eben der (Rechen-)Geschwindigkeit. Daß das nicht ganz ohne Brüche ankommt, merkst Du schon daran, daß zwangsläufig die Soundausgabe abgeschaltet werden muß.
Für Batch-Prozesse oder Schachprogramme mag das in Ordnung sein. Kommt man aber in die Versuchung, ein selbstgeschriebenes Programm darauf auszulegen, daß es *nur* in Emulation und *nur* im Warp-Mode läuft - dann programmiert man an der Realität vorbei. Dann kann ich auch direkt auf dem Host-Rechner entwickeln.
Derweil gibt es mit der Super-CPU und dem Turbo-Chameleon ja durchaus echte Hardware, welche die Geschwindigkeit des C64 etwas aufpeppt, also zwar nicht eingebaut, aber schon verfügbar.
Eine vom Host optional reingeschriebene Uhrzeit wäre auch nicht viel anders als per Monitor im Speicher rumzuwerkeln.
Das geht mit einer geeigneten Freezer-Cartridge auch am C64. Da ist es aber der Benutzer selbst, der da Bytes im Speicher ändert - egal, ob jetzt in Emulation oder auf echter Hardware.
Letztenendes wandelt der Vorschlag des Eingangspostings drei Speicherzellen in der Zeropage in I/O-Register um, die sich damit nicht mehr wie RAM verhalten. Dann läuft es eben so: weil man es gerade mal für diese Nischenanwendung benötigt, wird "spaßeshalber" die "RTC-Inject"-Funktion eingeschaltet, dann vergessen und dann - Tage, Wochen oder Monate später - wundert sich der User, warum sich im VICE diese oder jene Anwendung, Spiel oder Demo völlig unvorhersehbar verhält. Macht einen Bug-Report und bis dann jemand auf die obskure Option "RTC-Inject" kommt, raufen sich 'ne Menge Leute die Haare aus. Oder so ähnlich.
