C128 "Dead Test"

There are 177 replies in this Thread which has previously been viewed 27,834 times. The latest Post (September 6, 2025 at 6:36 PM) was by Nighti.

  • kinzi Ah, ok, das kann ich voll und ganz nachvollziehen! Da wäre ich genau so reingefallen...

    Früher waren 64k unglaublich viel, heute reicht es nicht mal mehr für "Hello, world!".

  • Wenn die C128-platine für 32KB ROMs konfiguriert ist, was empfehlt du für die unteren 16KB des ROM (normalerweise sind hier C64 BASIC und C64 KERNAL untergebracht)? Mit $ff auffüllen?

  • gibt's da auch irgendwo Resultate?

    Ich meine die wären alle nach dem Prinzip "grün ist gut" geschrieben, auf jeden Fall wird im Erfolgsfall 0 in $d7ff geschrieben weil die automatische Testbench darauf reagiert.

  • gibt's da auch irgendwo Resultate?

    Ich meine die wären alle nach dem Prinzip "grün ist gut" geschrieben, auf jeden Fall wird im Erfolgsfall 0 in $d7ff geschrieben weil die automatische Testbench darauf reagiert.

    Das gab ich schon verstanden und das mit D7FF auch gelesen.

    Aber heißt das, auf "echter" Hardware ist immer "alles grün"? Dieser Connex fehlt mir irgendwie.

    Wobei - je mehr ich darüber nachdenke ... was denn sonst ... :rolleyes:

  • Auf dem 128er Board das nur im 64er Modus Läuft funktionieren Dead Test V 0.10 und 0.20 so wie sie sollen,

    bei der V 0.7 fehlen die weißen Streifen die über den farbigen Rechtecken liegen. Siehe hier und hier.

    Auf einem funktionierenden Board sieht es so aus:

    Please login to see this attachment.

    Dort sind dann Weiße Linien zu sehen die sich quasi über die bunten Klötzchen legen.

    Module funktionieren mit dem defekten Board auch nur eingeschränkt, die Dead Test Cartridge Rev. 781220

    funktioniert garnicht (Bildschirm bleibt schwarz), bei meiner Ultimate II+ komme ich ins Menü kann aber keine

    Programme starten, dann kommt auch nur ein schwarzer Bildschirm.

  • Auf dem 128er Board das nur im 64er Modus Läuft funktionieren Dead Test V 0.10 und 0.20 so wie sie sollen,

    Ist zu erwarten. Sonst könnte der Z80 nicht den C64-Modus aktivieren.

    Module funktionieren mit dem defekten Board auch nur eingeschränkt, die Dead Test Cartridge Rev. 781220

    funktioniert garnicht (Bildschirm bleibt schwarz)

    Dann stimmt etwas mit den folgenden Leitungen nicht:

    • /GAME
    • /ROMH

    Vermutlich zweitere. /GAME wird erkannt und die Konfig für C64 Ultimax eingestellt, das ROM auf dem Modul kann,aber nicht aktiviert werden.

    Wenn beides nicht, möglicherweise MMU- oder PLA-Problem.

    P.S.: Ein Easyflash 3 funktioniert und ein Conrad Disk Booster Speedermodul auch.

    Das Conrad-Modul ist ziemlich sicher nur ein CBM80-Modul, würde zu obigem Verhalten passen.

    Beim EF3 bin ich im Moment au0en vor, wie das genau funktioniert. Ich wusste es mal, hab's aber vergessen. Ich schätze, das Menü ist ein normales CBM80-Modul. Dann passt das auch wieder zusammen.

  • Du schriebst

    Ach das... Frag lieber direkt Mac Bacon

    Damals(tm) hab ich mit einem speziellen Monitorprogramm, das beide CPUs unterstützt (den Namen müsste ich raussuchen...), testweise ein bisschen Speicher herumkopiert: Wenn man von den niedrigen Adressen von "Bank 0" kopiert, bekommt man Daten aus dem Z80-ROM. Wenn man von den niedrigen Adressen von "Bank 2" kopiert, bekommt man Daten aus RAM-Bank 0. Ich war dann stolz wie Bolle, damit quasi bewiesen zu haben, dass die MMU der 128ers intern tatsächlich zwischen vier Banks unterscheiden kann und nicht nur zwischen den zwei Banks, deren Select-Leitungen nach außen geführt sind.

    Mehr hab ich mit dem Z80 aber eigentlich nicht getestet, deshalb hab ich auch keinen Schimmer, was im vorliegenden Fall das Problem sein könnte.

    wilde Idee: werden evtl. Interrupts ausgelöst? aber ein unvorhergesehener Sprung ins Z80-ROM sollte eigentlich genauso zum Absturz führen wie ein unvorhergesehener Sprung in nicht initialisiertes RAM...

  • Wenn man von den niedrigen Adressen von "Bank 0" kopiert, bekommt man Daten aus dem Z80-ROM. Wenn man von den niedrigen Adressen von "Bank 2" kopiert, bekommt man Daten aus RAM-Bank 0

    Hmmm ... ich raffe jetzt noch nicht ganz, wie das bestätigt, dass mehr als zwei RAM-Bänke adressiert werden, wenn in "BANK2" Daten auis "BANK0" gelesen werden. Aber egal.

    wilde Idee: werden evtl. Interrupts ausgelöst? aber ein unvorhergesehener Sprung ins Z80-ROM sollte eigentlich genauso zum Absturz führen wie ein unvorhergesehener Sprung in nicht initialisiertes RAM...

    Glaub ich nicht. Kann ich aber versuchen, IRQs sperren ist vermutlich sowieso eine gute Idee.

    Wie gesagt, ob ich nun im Z80-BIOS-ROM oder im Kernalbereich umschalte, das Verhalten ist genau gleich. Und im Z80-Bereich hätte ich mir augenblicklich einen Crash erwartet, wenn das ROM ausgebelendet wird.

    Vielleicht ist das alles auch nicht so wichtig. Für meine Zwecke ist schon mal gut. dass man sieht, ob die Kiste auf dem Z80 anspringt; bisher stochert man da ja eher im Dunkeln.Ich bau da vielleicht noch eine testweise Umschaltung auf 8502 und wieder zurück ein; das müsste auch schon wieder mehr Aufschluss geben, denn dann muss ja der normale Dead Test eigentlich anspringen.

    Vielleicht baue ich auch ein Menü ein, wo man C128 und C64 per Tastendruck starten kann.

    Den RAM-Test verschiebe ich glaube ich erstmal.

    Danke jedenfalls für deinen ganzen Input!


    [edit]

    Interrupts abschalten ändert nichts. Egal, wo der "Umschaltcode" steht.

    Und ob Mode auf 64 oder 128 steht, ist auch egal.

    :nixwiss:


    [/edit]

  • Wenn man von den niedrigen Adressen von "Bank 0" kopiert, bekommt man Daten aus dem Z80-ROM. Wenn man von den niedrigen Adressen von "Bank 2" kopiert, bekommt man Daten aus RAM-Bank 0

    Hmmm ... ich raffe jetzt noch nicht ganz, wie das bestätigt, dass mehr als zwei RAM-Bänke adressiert werden, wenn in "BANK2" Daten auis "BANK0" gelesen werden. Aber egal.

    Glaub ich nicht. Kann ich aber versuchen, IRQs sperren ist vermutlich sowieso eine gute Idee.

    Für Verwirrung hat Commo selbst gesorgt indem sie MMU Configs als 'Bank 0- 15' bezeichnet haben.

    Der MMU, so wie er ist, kann meines wissens 4 echte RAM-Bänke à 64k verwalten. Es sind aber bekanntlich nur Bank 0 und Bank 1 bestückt.

    Irgendwo hatte ich Anno Dazumal gelesen, daß MMU-Zugriffe auf (echte) Bank 2 automatisch aus Bank 0 gemappt wurden, und dementsprechend Zugriffe auf (echte) Bank 3 auf Bank 1 gemappt werden.

    (alle Angaben ohne Gewehr).

    [Edith]

    h=g

    :biggrin:

    [/Edith]

  • Der MMU, so wie er ist, kann meines wissens 4 echte RAM-Bänke à 64k verwalten. Es sind aber bekanntlich nur Bank 0 und Bank 1 bestückt.

    Erstens das, und zweitens sind schlicht keine /CAS-Ausgänge für RAMBANK2 und RAMBANK3 vorhanden - es waren offenbar keine Pins mehr frei.

    Irgendwo hatte ich Anno Dazumal gelesen, daß MMU-Zuhriffe auf (echte) Bank 2 automatisch aus Bank 0 gemappt wurden, und dementsprechend Zugriffe auf (echte) Bank 3 auf Bank 1 gemappt werden.

    (alle Angaben ohne Gewehr).

    Das habe ich jetzt noch nirgends gefunden. Könnte aber natürlich sein, ja.

  • Zieh Tat:

    Obwohl der C128 theoretisch 256k RAM in vier Blöcken unterstützen kann, hat die Platine keine Vorkehrungen, um diesen zusätzlichen RAM hinzuzufügen, noch kann die MMU tatsächlich auf mehr als 128k zugreifen. Wenn die MMU für den Zugriff auf die Blöcke 2 oder 3 programmiert ist, ergibt sich daher nur eine Spiegelung des RAM in den Blöcken 0 und 1.

    Siehe : https://de.abcdef.wiki/wiki/Commodore_128#RAM_setup

    [Edith]

    Was passiert eigentlich, wenn man per MMU Bank 2 oder 3 'einblendet' und dort Daten hineinschreibt?

    Könnte man so z.B. ein Programm in Bank 0 überschreiben, bzw. Variablen aus Bank 1 und somit ein Programm zum Absturz führen?

    Oder gillt das Spiegeln nur für Lesezugriffe und nicht für Schreibzugriffe?

    Würde mich echt interessieren.

    [/Edith]

  • Irgendwo hatte ich Anno Dazumal gelesen, daß MMU-Zuhriffe auf (echte) Bank 2 automatisch aus Bank 0 gemappt wurden, und dementsprechend Zugriffe auf (echte) Bank 3 auf Bank 1 gemappt werden.

    (alle Angaben ohne Gewehr).

    Das habe ich jetzt noch nirgends gefunden. Könnte aber natürlich sein, ja.

    Das ist deswegen so, weil in $D500 von Bit 6 und 7 nur das Bit 6 Relevanz hat und Bit 7 ignoriert wird. Also 01 und 11 bzw. 00 und 10 jeweils gleich als 01 bzw. 00 behandelt werden.

    Please login to see this attachment.

    (Quelle)

  • "Fotomontage" oder funktioniert das? :P

    Also bitte!

    Jetzt bin ich fast beleidigt ...

    Es dreht gerade noch einige Runden auf echter Hardware - das liefert immer wieder den einen oder anderen "Bug".

    In Kürze in diesem Theater ...

  • Hier ist also das "Release". ... :smile:

    Getestet auch auf echter Hardware ...auf einem C128DCR habe ich es nicht probiert.

    Leider ist der Test vom Zero Page und Stack Page nicht dabei. Sollte ich eine stabile Möglichkeit finden, auf die untersten 4 kB im Z80-Mode zugreifen zu können, hole ich das vielleicht noch nach. Aber ein Dreiviertel-RAM-Test ist besser als gar keiner. :tong:

    Eine kleine Anleitung und der Source Code sind auch dabei. Da gleich eine WARNUNG: Ich bin kein Programmierer, und schon gar keiner für den Z80. Das sind meine ersten Z80-Gehversuche. (Vermutlich auch die letzten ... :biggrin: ). Wenn jemand Augenkrebs von Source Code bekommt - ich habe gewarnt.

    Da im Code keinerlei RAM verwendet werden kann, bis zumindest ein Teil für gut befunden wurde, ist auch kein Stack vorhanden. Daher können nur Register und Sprünge, aber keine Unterprogramme verwendet werden. Ein Z80-Profi würde das wohl doppelt so schnell, halb so hässlich und nur ein Zehntel in der Größe gebacken bekommen. Mir egal, ich hab das für mich geschrieben und meine Zwecke erfüllt es. :tong:

    Wer's außerdem brauchen kann - gerne.

    Frei für nichtkommerzielle Nutzung.

    Bitte immer das ganze ZIP weitergeben, nicht nur einzelne Dateien.