Wie erkennen ob C64 ohne Monitor noch läuft?

Es gibt 46 Antworten in diesem Thema, welches 7.397 mal aufgerufen wurde. Der letzte Beitrag (21. Juni 2014 um 17:28) ist von Gerrit.

  • Moin,

    ich bin auf der Suche nach einer Lösung für mein Problem:

    Ich habe einen C64 der 24/7 laufen soll, allerdings ohne Monitor um Strom zu sparen.
    Nun möchte ich allerdings gerne irgendwie optisch sehen,ob der C64 noch läuft.

    Gibt es nun irgendwie eine Möglichkeit zu erkennen ob der C64 noch läuft?
    Kann ich vielleicht irgendwie die aktuelle C64-Uhrzeit auf einem LCD Display anzeigen lassen?
    Das wäre optimal :smile:

    Ich sage mal so, Geld spielt erstmal keine Rolle ...

    - pcollins

    --------------------------------------------------------------------------------------------------------
    RapidFire BBS: rapidfire.hopto.org:64128

  • prinzipiell muesste das ueber den userport realisierbar sein - ein paar genauere infos waehren nich schlecht!

    Was meinst du? Was an Informationen brauchst du?

    --------------------------------------------------------------------------------------------------------
    RapidFire BBS: rapidfire.hopto.org:64128

  • Na, z.B. was auf dem C64 für eine Software laufen soll. Ob der Rechner läuft oder nicht, sieht man an der Power-LED. Es geht Dir also offensichtlich darum, sehen zu können, ob die Software noch läuft. Da würde eine zusätzliche LED am Userport reichen, die man in der Hauptschleife der Software blinken lässt. Stürzt das Programm ab, hört das Blinken auf.
    Wie schwierig das umzusetzen ist, hängt davon ab, welche Software laufen soll.

    Yes, I'm the guy responsible for the Bitte melde dich an, um diesen Link zu sehen. cross assembler. And some Bitte melde dich an, um diesen Link zu sehen..

  • mhm - eigentlich braucht dein laufendes programm nur eine led am userport in abhaengigkeit von einem cia-timer anzusteuern, dann
    hast du eigentlich schon die "anzeige", dass der rechner laeuft

  • Ah, ok....

    Also in die Software kann ich nicht so ohne weiteres eingreifen :-/
    Ich habe zwar den Sourcecode, aber da fehlt mir leider das nötige KnowHow um da was anzupassen.

    Ich meine mich irgendwie schwach zu erinnern, das es mal ein MOD gab, der immer die XY und A Register angezeigt hat.
    Könnte man darauf nicht aufbauen? Wenn C64 hängt, würden die doch auch nicht mehr gefüllt werden, oder?

    --------------------------------------------------------------------------------------------------------
    RapidFire BBS: rapidfire.hopto.org:64128

  • Also die Zeit auf einem LCD anzeigen zu lassen ist prinzipiell kein Problem. Du nimmst ein Textdisplay mit z.B. 2x16 Zeichen (Standard, vielleicht findest du auch ein kleineres Display) mit HD44780-Controller und initialisierst den Controller im 4-Bit-Mode. Dann reichen 7 der 9 frei programmierbaren Pins des Userports aus, weitere aktive Elektronik ist dann nicht notwendig. Programmieren muß man das dann natürlich selbst.

    EDIT: wenn ein Eingriff in die Software nicht in Frage kommt, geht das natürlich nicht. Und das Ganze in den Interrupt verlagern wäre auch keine Lösung, weil der u.U. noch läuft, während das Hauptprogramm längst abgestürzt ist.

  • Ich meine mich irgendwie schwach zu erinnern, das es mal ein MOD gab, der immer die XY und A Register angezeigt hat.
    Könnte man darauf nicht aufbauen? Wenn C64 hängt, würden die doch auch nicht mehr gefüllt werden, oder?

    Beim "normalen" Absturz über einen der halt-and-catch-fire-Opcodes ist das so, ja. Es ist aber auch denkbar, dass die Software durch einen Fehler in eine Endlosschleife geht, in der auch die Register verändert werden. Dieser Fall würde von einem Hardware-Mod nicht als Absturz erkannt werden, daher ist eine softwaregesteuerte "Heartbeat"-LED eigentlich das Naheliegendste.

    Yes, I'm the guy responsible for the Bitte melde dich an, um diesen Link zu sehen. cross assembler. And some Bitte melde dich an, um diesen Link zu sehen..

  • Meine dumme Idee dazu: Am Expansionport liegen ja auch die Adressleitungen der CPU an. Ich würde erwarten, dass das niederwertigste Bit da halbwegs gleichverteilt logisch 0 oder logisch 1 ist. Würde man damit eine LED ansteuern, so wäre meine naive Erwartung, dass sie mit ca. "halber Helligkeit" brennen würde (ein Flackern wäre da unmöglich zu sehen) im Vergleich zu einer gleichartigen LED, die immer auf "1" gezogen ist.

    Wenn sich nun die CPU komplett aufhängt, so würde die LED hingegen entweder mit voller Helligkeit leuchten (Adresse hängt mit niederwertigstem Bit auf 1) oder dauerhaft aus sein (hängt zufällig mit 0).

    Damit wäre allerdings nur sichtbar, ob die CPU noch "lebt" - es gibt sicherlich auch Fehlersituationen, in denen die CPU noch lebt, aber nach einem Programmabsturz noch Blödsinn berechnet.

    edit: Oh, und ich würde nicht davon ausgehen, dass der Adressbus direkt eine LED antreiben kann.

  • Und man müsste die LED so ansteuern, dass sie die VIC-Buszugriffe ignoriert, denn der VIC macht ja nach einem CPU-Absturz unbeirrt weiter.

    Yes, I'm the guy responsible for the Bitte melde dich an, um diesen Link zu sehen. cross assembler. And some Bitte melde dich an, um diesen Link zu sehen..

  • Und welchen Grund - außer daß der Takt ausfällt - soll es geben, daß die CPU auf einer Adresse stehen bleibt? Auch wenn die CPU abgestürzt ist, wird sie vermutlich noch (sinnlose) Maschinenbefehle ausführen und den PC incrementieren.

  • Ein Frequenzteiler in der IRQ Leitung kann eine LED schön Blinken lassen. Für eine Endlosschleife ist eine LED am NMI Port aber besser, man braucht nur die Restore zu Drücken und sieht ob sich die LED Verändert.

    Wem es beim Bit zählen schwindelig wird, der hat zuviel davon.

    Alt werden ist schön, das Altern nicht.

  • Und welchen Grund - außer daß der Takt ausfällt - soll es geben, daß die CPU auf einer Adresse stehen bleibt? Auch wenn die CPU abgestürzt ist, wird sie vermutlich noch (sinnlose) Maschinenbefehle ausführen und den PC incrementieren.

    Unter den undokumentierten ("illegalen") Opcodes sind zwölf, die die CPU komplett anhalten: $02, $12, $22, $32, $42, $52, $62, $72, $92, $b2, $d2 und $f2.

    Yes, I'm the guy responsible for the Bitte melde dich an, um diesen Link zu sehen. cross assembler. And some Bitte melde dich an, um diesen Link zu sehen..

  • Und man müsste die LED so ansteuern, dass sie die VIC-Buszugriffe ignoriert, denn der VIC macht ja nach einem CPU-Absturz unbeirrt weiter.

    Oops :rotwerd:


    Und welchen Grund - außer daß der Takt ausfällt - soll es geben, daß die CPU auf einer Adresse stehen bleibt? Auch wenn die CPU abgestürzt ist, wird sie vermutlich noch (sinnlose) Maschinenbefehle ausführen und den PC incrementieren.

    Nun, wenn sich die CPU erstmal auf Abwegen befindet, dann wird in der Regel irgendwann auch einer der illegalen Opcodes auftauchen, die so nett mit "KIL" bezeichnet werden. Verklemmt sich da nicht die Zustandsmaschine des 6510 - und der PC wird nicht inkrementiert?

  • Spannendes Thema.

    Hat jemand Erfahrungen, ob das geht, sprich, wie stabil ist eine C-64 Platine im Dauerbetrieb unter thermisch vertretbaren
    Bedingungen?

    Klar das man ökonomisch sinnvoll für solch profanen Steuerzwecke vielleicht eher einen Duinomite/Atmel etc nehmen würde, aber das soll ja hier nicht das Thema sein :)

  • Hast du denn ein Diskettenlaufwerk?

    Wenn nach Blindeingabe irgendeines Diskettenbefehls wie

    Code
    LOAD"$",8 [RETURN]


    das Drive anläuft (LED, Motor), dann geht höchstwahrscheinlich schon mal ziemlich viel.

    Aber ob der C64 wirklich einwandfrei arbeitet, lässt sich ohne Monitor nicht herausfinden :)

  • Geht doch (wohl) darum, dass der C64 rund um die uhr etwas machen soll. Diskettenzugriff hatte ich auch schon als Billiglösung gedacht (scratch/save), aber das wird wohl keine Disk und auch kein Laufwerk 24/7 mitmachen... ;)