VIC-2020 MINIMON Cartridge

Hallo beisammen,

mein Monitor/Debugger/Freezer-Projekt habe ich hier im Forum64 verschiedentlich ja schon mal erwähnt und in Denial gibt's schon seit längerem einen ausführlichen Thread dazu.

Hier nun das vorläufige Ergebnis:

• Die Firmware, MINIMON, ist gerade mal 2 KB groß!
• Üblicherweise liegt MINIMON im Bereich $9800..$9FFF, der von der meisten 'üblichen' Software auf dem VC-20 nicht genutzt wird. Start mit SYS 38912.
• MINIMON hat alle Kommandos, die man von gängigen Monitoren kennt: Speicheranzeige und -änderung ("M" und ">"), Registeranzeige und -änderung ("R" und ";"), Maschinenprogramm ausführen ("G"), Direkt-Assembler und Disassembler mit allen dokumentierten Opcodes des NMOS 6502 ("A"/"." und "D"), Speicherbereiche kopieren ("T"), vergleichen ("C"), füllen ("F"), in Speicherbereichen suchen ("H"). Breakpoints gehen mit dem BRK-Befehl. Laden, speichern und überprüfen ("L", "S", "V") mit Floppy, Tape, etc.
• Besondere Aufmerksamkeit wurde darauf gelegt, daß MINIMON andere laufende Programme nicht beeinträchtigt. Der Betrieb von BASIC und KERNAL wird überhaupt nicht beeinflußt, Speicheradressen die häufig von anderen Maschinenprogrammen benutzt werden, wurden freigehalten - dies meint im besonderen die 'üblichen Verdächtigen' $FB..$FE in der Zero-Page, aber auch die sogenannten Program-Indirects ($02A1..$02FF) und der Tape-Buffer ($033C..$03FF) sind nach wie vor verfügbar für den Anwender.
• Die Ein- und Ausgabe von MINIMON kann umgelenkt werden. Hierdurch ist Stapel-Verarbeitung mit Dateien möglich, Ausdrucke auf einem Drucker, sogar Fernwartung über RS232 geht!

Die Cartridge enthält einen durchgeschleiften Expansionsport. Jede Standard-RAM-Erweiterung läuft in Kombination mit MINIMON. Wenn eine solche Cartridge ebenfalls den I/O-Bereich belegt, kann zwischen diesem I/O-Bereich ("CART") und MINIMON ("MON") mit einem Schiebeschalter umgeschaltet werden:

Der Reset-Button hat zwei Betriebsarten: eine kurze Betätigung erzeugt einen Reset-Puls, der sowohl auf den VC-20 (und Laufwerke, etc.) als auch auf die im durchgeschleiften Port eingesteckte Cartridge geht. Hält man den Button länger als 1 Sekunde, so leuchtet eine blaue LED auf um anzuzeigen, daß das jetzt ein "Freeze"-Reset wird: beim Loslassen geht dieser Reset *nur* auf den VC, nicht auf die Cartridge im durchgeschleiften Port und verhindert auch deren Autostart. Man landet also in der normalen Einschaltmeldung, kann (sofern nicht schon geschehen), den Schiebeschalter auf "MON" stellen und sich den Inhalt der hinzugesteckten Cartridge mit MINIMON genauer anschauen.

Um den Sockel des EPROMs herum ist genug Platz, daß da auch ein ZIF-Sockel paßt. Der Betrieb geht mit 2716 EPROMs, (z.B.) 28C64 EEPROMs mit Adaptersockel oder 2Kx8 6116 SRAMs. Ist ein 6116 gesteckt, oder soll das EEPROM programmiert werden, wird der Jumper in die Position "PGM" gesetzt. Ist ein 2716 gesteckt, oder soll das EEPROM sicher schreibgeschützt sein, so setzt man den Jumper in die Position "PCT".

...

So - damit hat der VC-20 jetzt endlich auch eine Freezer-Cartridge. Oder das, was am nächsten dran kommt.

Viele Grüße,

Michael

So zwischendrin habe ich dann auch eine Reihe von Tests (RAM-Check, etc.) mit der Mega-Cart gefahren:

In der Mega-Cart ist eine Version vom TRON-Lichtradrennen aus meiner Feder drin, mit Sprachauswahl für die Anleitung. So ohne weiteres kommt man da ja nicht dran - das Spiel wird aus dem Mega-Cart-Menü gestartet und ist natürlich STOP- und STOP/RESTORE-fest und ein normaler Reset bringt einen auch nur ins Mega-Cart-Menü -, mit dem Freeze-Reset war das Spiel dann aber leicht herausgespeichert.

Die Debug-Fähigkeiten von MINIMON möchte ich hier mal anhand eines kleinen Beispiels zeigen. Tatsächlich arbeitet die betrachtete Routine wie gewünscht, aber ich wollte mir mal die Fließkomma-Zwischenergebnisse anschauen, welche die Routine produziert, wenn sie von BASIC aus aufgerufen wird.

Hier ist der kommentierte Quellcode der Routine:

Das ist eine Quadratwurzel-Routine auf Basis des Heron-Verfahrens und sie ist etwa 4x schneller als das Pendant im BASIC-ROM. Sie wird in die USR()-Funktion eingehängt. Die Idee ist nun, zu verfolgen was in Y (bzw. Sqrt_05) bei jeder Schleifeniteration drin steht.

Zunächst mal erfolgt die Batch-Assemblierung aus einer Datei. Ich hab das mal mitgefilmt, und weil die *.avi-Datei mit ca. 12 MB doch ein bischen groß ist, gibt's hier einen Link: heron.avi. Die Eingabe von MINIMON wird temporär auf eine SEQ-Datei umgelenkt:

Sobald die Batch-Assemblierung abgeschlossen ist, stellt eine kleine Hilfsroutine bei $0140 die Standard-Eingabe wieder her, schließt die Datei und kehrt nach BASIC zurück. Mit ">01 A1 02" wird zudem der USR()-Vektor (der liegt beim VC-20 an den Adressen 1 und 2!) auf die neue Routine gelegt.

Jetzt ein scharfer Blick auf den assemblierten Code, um die Stelle zu finden wo der Zwischenwert Y abgespeichert wird (also, die Zeile im Quellcode: "JSR $DBD4 ; FAC#1 nach Sqrt_05 (Y: Zwischenergebnis) speichern"):

... und wir werden bei $02CD fündig:

Das Zwischenergebnis wird in $02F1 gespeichert. Wir instrumentieren den Code jetzt, so daß wir uns den gespeicherten Fließkommawert bei jeder Iteration anschauen können. Dazu plazieren wir eine Kopie des Befehls JSR $DBD4 an geeigneter anderer Stelle als "Rucksack", den wir mit einer BRK/NOP/RTS-Befehlsabfolge abschließen. Diesen Rucksack rufen wir dann mit einem JSR auf, der an Stelle des originalen JSR $DBD4 bei $02CD steht:

Nach der Rückkehr zu BASIC führen wir PRINTUSR(2) aus, um die Quadratwurzel von 2 zu berechnen. Vor dem PRINT-Befehl steht eine Zeile aus Doppelpunkten: MINIMON nutzt ebenfalls den BASIC-Eingabepuffer für die eigene Kommandozeile und so wird vermieden, daß beim Abschluß ein ?SYNTAX ERROR angezeigt wird.

Während der Ausführung reduziert die Routine das Argument in den Bereich 0.5 (einschließlich) bis 2.0 (ausschließlich), sie berechnet intern also tatsächlich die Quadratwurzel von 0.5 und korrigiert den Exponenten des Ergebnisses zum Schluß:

Der BRK-Befehl im Rucksack ist jetzt das erste Mal ausgeführt worden und als Zwischenergebnis steht "$80 $40 $00 $00 $00" bei $02F1. Mit G und M lassen wir uns die nächsten Zwischenergebnisse ebenfalls anzeigen, bis die Routine ihre Berechnung abgeschlossen hat und die Kontrolle an den BASIC-Interpreter zurückgibt:

... wobei die PRINT-Ausgabe sauber ans letzte G-Kommando angehängt wird.

Die drei Zwischenergebnisse entsprechen den folgenden Dezimalbrüchen:

>02F1 80 40 00 00 00 ^= 0.75

>02F1 80 35 55 55 55 ^= 0.708333333

>02F1 80 35 05 05 05 ^= 0.707107843

Nach den drei Iterationen ist der nächste Wert in FAC#1 schon exakt innerhalb der darstellbaren Genauigkeit und nachdem der Exponent korrigiert wurde, wird das Ergebnis 1.41421356 ausgedruckt.

Quote from Jotta

Hast Du den Monitor/Assembler selbst geschrieben?

Ich hatte eine gute Vorlage, den TEDMON im C16/C116/+4.

Mir ging es speziell darum, einen möglichst kleinen Monitor (max. 2 KB) für den VC-20 zu bauen, der aber trotzdem einen Disassembler und Direkt-Assembler drin haben sollte. So paßt er in I/Ox rein und blockiert nicht andere Bereiche. Das ist gerade dann wichtig, wenn man sich z.B. Cartridge-Code in BLK5 anschauen will.

Davon ausgehend hatte ich TEDMON erst komplett reversed, relokatibel gemacht und auch dessen Nutzung der Zeropage an die Verhältnisse im VC-20 angepaßt. Direkt im Anschluß kamen dann Anpassungen an das Bildschirmlayout des VC-20: wegen der kleineren Zeilenlänge werden die Hex-Bytes im Disassembly nicht gedruckt und die Hex-Dump-Ausgabe des Memory-Befehls verkürzt auf 5 Byte ohne die Zeichen-Ausgabe hintendran. Die Möglichkeit mehr Code-Zeilen anzeigen zu können, hatte für mich höhere Priorität. Für die beiden jetzt fehlenden (Teil-)Ausgaben gibt es aber Abhilfen - die Hex-Bytes gehen ja immer noch anzuschauen über den korrespondierenden M-Befehl, und für die Text-Ausgabe gibt es ein transientes Tool, das immer eine ganze Speicherseite aus dem Monitor heraus ausdruckt, mit schnellem Vorwärts-Blättern.

Danach war die Anlegenheit aber noch nicht durch. In TEDMON und vielen anderen Monitoren aus der Zeit ist ein übler Stack-Overflow versteckt: bei fehlerhaften Eingaben im Assembler werden häufig zwei Bytes im Stack liegengelassen, und nach ca. 100 Fehleingaben stürzen die Teile einfach ab. Dieser Fehler, noch ein paar andere Fehler plus noch ein paar unnötige doppelte Routinen habe ich dann bereinigt. Zum Schluß war dann für einige vorsichtige Ergänzungen noch genug Platz über um knapp unter den 2 KB zu bleiben: der T-Befehl im originalen TEDMON konnte überlappend nur nach unten kopieren, das geht jetzt in beide Richtungen - und der F-Befehl kann jetzt nicht nur mit einem Byte füllen sondern mit einem bis zu 16 Byte langen Muster - dazu gab die Parser-Routine des H-Befehls dankenswerterweise ihren Code mit her.

In der Summe ist das jetzt also ein Monitor, der die meisten Funktionen von VICMON und HESMON statt in 4 KB in nur 2 KB unterbringt, aber im Gegensatz zu den beiden auch sauber mit BASIC und KERNAL zusammenarbeitet.

Quote from Jotta

Falls ja, ist der Sourcecode verfügbar? Ich gehe mal stark davon aus, dass Du die Software geschrieben hast, weil die Umleitung von Input/Output in glaube ich keinem der kleinen Monitoren eingebaut ist. [...] müsste sich Dein ROM [nicht] auch mit wenig Aufwand auf den C64 übertragen lassen?

Wie gesagt, es gab eine gute Vorlage, davon ausgehend hatte ich aber noch mal recht viel Arbeit reingesteckt, um den Monitor wetterfest zu machen. In der Summe habe ich mehr als 50% vom Originalcode umgebaut, korrigiert und verbessert. Daher habe ich bislang den Quellcode noch nicht herausgegeben und habe das in absehbarer Zeit auch nicht vor. Angucken in sich selbst geht natürlich ohnehin ohne Probleme.

Zumindest die Ausgabeumleitung geht mit dem CMD-Befehl auch in den anderen Monitoren ab Werk, also z.B. auf den Drucker so: OPEN4,4:CMD4:SYSxxxxx mit xxxxx als Monitor-Startadresse. Die Eingabeumlenkung mittels POKE781,x:SYS65478 können andere Monitore gegebenenfalls nur versaubeuteln, wenn ein zusätzliches Prompt erwartet wird, was in der umgelenkten Eingabe nicht vorkommt oder wenn der Monitor die Eingabe am KERNAL vorbei macht.

Ich habe MINIMON tatsächlich auch 'just for fun' mal auf den C64 gebracht. Das war weiter nicht schwierig. Für eine saubere "Rück"-Portierung zum C64 müßte man aber unter anderem die o.g. Anpassungen an die 22 Zeichen/Zeile wieder zurücknehmen. Mit dem dazu zusätzlichen Code reißt man aber sofort die 2-KB-Grenze - und in den 4 KB bei $C000..$CFFF sollte es eigentlich eine genügende Auswahl an Monitoren auf dem C64 geben, die ihre Sache (hoffentlich) richtig machen.

Quote from Jotta

Hast du den Code arg quetschen müssen, um von 4KB auf 2KB zu kommen? Ist das leicht zu erreichen?

Der Hauptteil der Vorlage, TEDMON, liegt im Speicher der 264er-ROMs von $F445 bis $FBB6. Das sind 1906 Bytes, also nicht ganz 2 KB. Im restlichen ROM kommen allerdings noch ein paar Support-Routinen dazu, die im VC-20-ROM so nicht vorhanden sind und ebenfalls mitkommen müssen. Mit denen ist man dann erstmal nur noch ganz knapp unter 2 KB.

Die von mir vorgenommenen Umbauten, Ergänzungen und Korrekturen bewegten sich anschließend weiterhin knapp unter 2 KB Gesamtgröße. Um die Ergänzungen von T und F ziemlich zum Schluß hinzufügen zu können, mußte ich vorher etwa 90 Bytes freischaufeln.

Mir war es dabei ganz recht, daß der originale TEDMON ziemlich genau den aus meiner Sicht minimalen und nicht weiter reduzierbaren Kommandosatz mitbrachte. Irgendwoher hat MINIMON nunmal seinen Namen her.

Was in VICMON und HESMON darüber hinaus 'nur' noch hinzukommt sind bidirektionales Scrolling, Singlestep-Tracing und ein Relokator. All diese drei Funktionen haben bei VICMON und HESMON so ihre ganz eigenen Macken, brauchen für das wenige was sie leisten unverhältnismäßig viel Platz und sind darum auch nicht mit an Bord. Mir war wichtiger, daß der verbleibende, aus TEDMON stammende Kernsatz an Kommandos 100%ig sauber funktioniert.

Beim Relokator hab' ich mich später insofern noch erbarmt, daß ich eine einfache Implementierung in 95 Bytes, ähnlich wie den pageweisen Zeichendump, als transientes Tool mitliefere. Da kann ich hier im Thread auch noch ein Nutzungsbeispiel zu anbringen.

Quote from Jotta

Und mal vielen Dank für die ausführliche Beschreibung, ich hatte schon lange mal vor, selbst einen einfachen Monitor zu schreiben. Ziel ist aber hauptsächlich die Verwendung in FPGA-Umbegungen, da muss dann aber der I/O-Teil komplett ohne KERNAL-Unterstützung auskommen. Werde mich also mal ausführlich lesend an Deinem Code austoben.

Für deinen Monitor wirst dann ohnehin noch einen anderen, adäquaten Satz an Kommandos definieren müssen - unabhängig davon, ob Du ihm 2 KB oder etwas mehr Speicher gönnst. Gerade wenn Du noch die I/O-Funktionen (Tastatureingabe, Bildschirmausgabe, Dateizugriff) selbst implementieren mußt, sind so schon schnell 2 KB weg.

Als Quelle empfehle ich derweil wie oben schon erwähnt, den Original-Code von TEDMON (z.B. im Commodore-Sachbuch C16 - s. F64-Wolke - zu finden). Noch zur Info: die Kernroutine des Disassemblers stammt von Steve Wozniak, ist auch in anderen Monitoren dutzendfach kopiert worden, und so ziemlich die einzige Routine, die ich nicht anfassen mußte - weil die einfach 100%ig funktioniert.

Quote from Mike

[...] Relokator [...] Zeichendump [...] Nutzungsbeispiel.

Der Zeichendump sieht wie folgt aus ...

... und wird mit G 02A3 gestartet, wobei im Akku vorher die auszugebende Speicherseite (also das "xx" in $xx00..$xxFF) festgelegt wurde. Mit wiederholtem Drücken von [RETURN] wird der Speicher seitenweise ausgegeben. Im mit angezeigten Registerdump kann die nächste anzuzeigende Speicherseite schnell geändert werden, indem man den Eintrag für den Akku anpaßt und mit [RETURN] bestätigt.

In der Praxis sieht das dann so aus:

Hier wurde die Befehlsliste des "japanischen" Super-Expanders VIC-1211M gesucht. Das ROM beginnt bei $A000 und ist 4 KB groß. Bei $A1xx wurde ich da schon fündig. Die Untersuchung habe ich dann noch so fortgesetzt:

In $0308/$0309 steht der Token-Dispatch-Vektor, hier $A22B. Da dann noch ein scharfer Blick hinein:

Alle Tokens mit dem Wert kleiner als $CC oder größer-gleich $DB werden an das originale BASIC zurückverwiesen. Ansonsten führt die BASIC-Erweiterung ab $A23C ihre eigenen Befehle aus.

Das Beispiel zum Relokator folgt nach.

Als weiteres Nutzungsbeispiel nun der Relokator. Diese Routine ist nicht fester Bestandteil von MINIMON und wird stattdessen nachgeladen. Wie die ASCII-Dump-Routine im vorigen Beitrag geht sie in den Bereich $02A1..$02FF.

Eins noch vorweg: die Routine beinhaltet keine Verschiebe-Funktion. Dafür ist das T-Kommando da. Außerdem kann es auch notwendig sein, Adreß-Operanden anzupassen, ohne daß eine Verschiebung der betroffenen Routine vorliegt - etwa wenn ein anderer Bereich vorschoben wird und Adressen im anzupassenden Code eben in diesen Bereich zeigen!

Der Relokator sieht nun so aus:

Mit 'ptr/limit' wird der Bereich des anzupassenden Codes festgelegt, mit 'start/end' in gleicher Weise der Bereich der anzupassenden 16-Bit-Adreß-Operanden und mit 'offset' gibt man an, wie die Adressen angepaßt werden sollen (für negative Offsets gilt erwartungsgemäß das 2-Komplement). Die Parameter werden vor Aufruf mit ">" in die Zeropage geschrieben. $55..$60 nutzt der BASIC-Interpreter in der Formelauswertung - während wir mit dem Relokator dran sind, hat der BASIC-Interpreter gerade Pause.

Die Routine paßt gerade so in die 95 Bytes von $02A1..$02FF rein. Würde man an Stelle der BIT-Befehle ins BASIC-ROM eine Konstruktion aus TAY/AND #imm/TYA/... verwenden, dann müßte man zwischendrin mit LDY #$01 das Y-Register neu initialisieren und ist damit über's Platzbudget.

Genug der Vorrede, gehen wir in medias res.

Wir nehmen eine kleine Routine, die einen Interrupt installiert um $900F (Hintergrundfarbe und Rahmen) jede 60stel Sekunde zu ändern. Ursprünglich liegt sie bei $033C, aber aus irgendwelchen Gründen soll sie nun bei $1800 stehen ("example.prg" im Anhang). Mit LOAD"...",8,1 und SYS828 kann man sich kurz den Effekt anschauen. Nachdem wir MINIMON (oder irgendeinen anderen Monitor) gestartet haben, schauen wir uns das Beispiel mal an:

Wenn diese Routine jetzt bei $1800 liegen soll, muß offensichtlich was anderes in den Interrupt-Vektor bei $0314 rein ...

... davon abgesehen haben wir aber Glück: es sind keine Sprungbefehle anzupassen - aber was hat es mit dem BIT-Befehl in $034B auf sich?

Der absolute Operand des BIT-Befehls wird als Low- und High-Bytes des neuen Interrupt-Vektors von zwei LDA-Befehlen abgelesen!

Da wollte wohl jemand dem Relokator helfen. Der BIT-Befehl ist tatsächlich nur ein Platzhalter für die Interrupt-Vektoradresse, und wenn der Relokator diesen Befehl antrifft, wird dessen Operand ebenfalls korrigiert! Wäre die Adresse des neuen Interrupt-Vektor stattdessen als zwei Immediate-Operanden der LDA-Befehle angegeben worden, hätte das jetzt nicht funktioniert.

Weiter geht's mit dem Relokator ("relocate.prg" im Anhang):

Mit dem T-Kommando T 033C 0353 1800 kopieren wir die Routine nach $1800. Disassemblieren wir die Routine bei $1800 mit dem D-Kommando, so stellen wir fest, daß die Befehle bei $1801, $1807 und $180F immer noch auf die ursprünglichen Adressen zeigen. 'ptr', der Zeiger auf den anzupassenden Code in $55/$56, wird auf $1800 gesetzt.

Auf gleiche Weise instruieren wir den Relokator, bei $1818 anzuhalten ('limit'-Adresse nach $57/$58). Alle 16-Bit-Operanden zwischen $033C ('start'-Adresse, geht nach $59/$5A) und strikt kleiner als $0354 ('end'-Adresse, geht nach $5B/$5C) sollen angepaßt werden - und zwar um $14C4 (= $1800 - $033C)! $14C4 geht als 'offset' nach $5D/$5E und dann starten wir den Relokator mit G 02A1 ...

... schauen uns die Kopie mit D 1800 1817 nochmal an und sehen, daß die Befehle bei $1801, $1807 und $180F nun angepaßt sind: bei beiden LDA-Befehle lesen die neue IRQ-Vektoradresse von dem Operanden des BIT-Befehls in $180F ab und der zeigt korrekterweise auf den INC $900F in $1812.

Der Form halber löschen wir den Original-Code mit F 033C 0353 00 und kehren dann mit X zu BASIC zurück.

SYS6144 läßt die verschobene IRQ-Routine ablaufen.

So, jetzt mal die Gretchenfrage an (Stand dieses Beitrags) Dierch-Jentz, emulaThor, aitsch, oobdoo, knusis, Freak, kinzi, -trb-, HouseOfPain, Goodwell, Paradroid und Parser, die anders als Jotta sich noch nicht weitergehend geäußert haben - bin ich mit dem Entwurf der Hardware überhaupt auf einer Linie mit welcher der informierte potentielle Benutzer überhaupt was anfangen kann bzw. möchte?

Ich habe hier ja nun einiges zur Historie erzählt, weiteren Hintergrund kann man auch aus dem Thread in Denial erschließen.

Mit wurde derweil schon von verschiedener Seite angetragen, ob man die Hardware denn nicht noch ändern könnte. Der derzeitige Hardwarestand ist in etwa so motiviert:

• Die bisher auf einer Cartridge vorhandenen Monitore (speziell VICMON und HESMON) sind im Zweifelsfall immer irgendwo im Weg und verhindern definitiv einen RAM-Vollausbau mit +35 KB - deshalb das Refugium im I/O-Bereich,
• Glück: Cartridge-RAM in I/O ist bislang kein Standard, Pech: Cartridge-RAM in I/O ist bislang kein Standard - heißt tendenziell muß man erstmal schon selbst hardware-technisch sicherstellen, daß MINIMON überhaupt erfolgreich dahin kommt, wo es ausgeführt werden soll,
• Es gibt durchaus einige Cartridges, die den I/O-Bereich zumindest zeitweise auch selbst brauchen (z.B. Mega-Cart, FE3) - also sollte man den I/O-Bereich ab- oder umschaltbar gestalten. Abschaltbar, wenn die neue Cartridge in einen Cartridge-Extender reingehen soll, umschaltbar, wenn sie zumindest einen durchgeschleiften Port mitbringt,
• Nicht jeder hat einen Cartridge-Extender - was die Einsatzmöglichkeiten einer MINIMON-Cartridge ohne durchgeschleiften Port und ohne weitere Extras (zusätzliches RAM, o.ä.) stark limitiert, auf den nicht-erweiterten VC nämlich. Dann hätte ich mir auch gar nicht den Aufwand machen brauchen, MINIMON in 2 KB unterzubringen ...,
• Umgekehrt, mit durchgeschleiftem Port kann jeder z.B. seine Lieblings-Cartridge(s) weitgehend problemlos (bis auf evtl. notwendiges Umschalten des I/O-Bereichs) mit MINIMON zusammen nutzen, d.h. MINIMON kann eingeblendet werden, wenn man ihn braucht, und muß nicht erst nachgeladen werden (dann ist es vielleicht schon zu spät, sozusagen),
• Die eigene Lieblings-Cartridge bringt wahrscheinlich ohnehin schon Zusatz-RAM mit, das muß also eigentlich nicht mit auf die MINIMON-Cartridge,
• Möchte man sich jetzt z.B. den Inhalt einer Spiel-Cartridge genauer ansehen, so muß es möglich sein, deren Autostart zu verhindern. Das ist in einer vorherigen Version der MINIMON-Cartridge umgesetzt mit einem Pull-Up auf BLK5 Richtung Extender und einem Jumper (Nutzung einigermaßen umständlich: Reset drücken und festhalten, BLK5-Jumper ziehen, Reset loslassen, BLK5-Jumper wieder stecken), und jetzt mit einer Timing-Schaltung, welche gerade genannte Aktionskette automatisch ausführt und zusätzlich auch noch die Reset-Leitung Richtung Zweit-Cartridge kurz auftrennt, so daß die vom Reset nichts mitbekommt und ihre internen Latches absehbar unverändert läßt.
• Als kleines Goodie: Der ZIF-Sockel ermöglicht es, anstelle von MINIMON zwischenzeitlich auch was anderes in den I/O-Bereich einzublenden.

Die im Start-Thread gezeigte Cartridge bekommt noch ein kleines Hardware-Update und was danach kommt hängt davon ab, wie die Interessenlage hier ist. Da ich absehbar nicht dazu kommen werde, die Cartridge in Sonn- und Feierabendsarbeit in Kleinserie aufzubauen, bin ich diesbezüglich auch für Vorschläge dankbar.

Quote from kinzi

Wenn ich das richtig gelesen habe, ist die Software relozierbar?

Ja, das geht. Zwar nicht mit dem hier im Thread angebrachten Relokator, dazu ist der Code nicht entsprechend vorbereitet, es existiert aber eine (ebenfalls nachzuladende) Support-Routine, die MINIMON pageweise verschieben kann.

Erst wird mit dem T-Kommando eine Kopie an der neuen Stelle erzeugt, und dann wird beim Aufruf in X die alte Start-Page (üblicherweise $98) und in Y die neue Start-Page (hier als Beispiel: $A0) übergeben. Das sieht dann so aus:

"==" bedeutet, daß man den angezeigten Wert so lassen soll, bevor man mit [RETURN] das ";"-Kommando aus dem Register-Dump bestätigt. Das erste G-Kommando startet dann die Anpassung bei $033C und G A000 startet den verschobenen MINIMON.

Quote from kinzi

Das würde geradezu danach schreien, mehrere Bereiche (BLK*, RAM*, ...) auswählbar zu machen.

Das geht so wie gerade beschrieben schon mit einer einfachen RAM-Erweiterung ab Werk.

Wenn das aber als automatische Funktion auf der Karte so mit drauf sein soll, daß sie akkurat in jedem denkbaren Bereich 2 KB mit MINIMON überlagern kann, dann reichen die bisher benutzten drei TTL-ICs sicher nicht mehr.

Quote from kinzi

Automatisch nicht, sondern mit Jumper/DIP-Switches wählbar.

So hatte ich deine Idee auch aufgefaßt, daß man z.B. die gewünschte Start-Page (sofern realisierbar!) per 8-stelligem DIP-Switch einstellen kann. Das braucht dann folgendes:

• Eine Rekonstruktion des CPU-High-Bytes am Adreßbus aus allen vorhandenen Select-Signalen plus CA8..CA11,
• Einen Bereichscheck "Start-Page <= CPU-High-Byte < Start-Page+8" und
• Eine on-the-fly Anpassung des Monitor-Codes an die gewählte Startadresse.

Zumindest der letzte Punkt ließe sich mit einem 4-MBit-Flash (organisiert als 512Kx8) erschlagen, wobei man dessen obere 8 Adreßleitungen direkt mit dem DIP-Switch verbindet und ihn mit allen seitenweise verschobenen Kopien von MINIMON vollschreibt.