Hello, Guest the thread was called2k times and contains 28 replays

last post from Mike at the

VIC-2020 MINIMON Cartridge

  • Läuft der Minimon ohne ROMs? Vermutlich nicht, weil der Hardware-Init fehlt (VIC z. B.)?

    Ins BASIC durchstarten sollte der VC-20 schon noch. MINIMON nutzt allerdings auch nur KERNAL-Routinen, und keine aus dem BASIC-Interpreter.

    Und die Abfrage der Vektoren?

    Da ist mir nicht ganz klar was Du genau meinst. Beim Start durch SYS ändert MINIMON den BRK-Vektor in $0316/$0317 auf seinen Break-Eintritt (PC, Status, Register, Stackpointer wegschreiben) und den NMI-Vektor in $0318/$0319. Letzterer hält sich selbst und den BRK-Vektor bei einem BASIC-Warmstart durch STOP/RESTORE aktiv.


    Sonst müsste da noch eine Version für den Kernal-Sockel her. ^^

    Die 2 KB kriegst Du aber nur freigeschaufelt, wenn Du sowohl die Tape- als auch die RS232-Routinen entfernst. Durch letzteres ist's aber auch Essig mit Remote-Debugging.


    Die Frage ist aber auch, was Du mit MINIMON in einem halbtoten Rechner machen willst, was mit einem dedizierten Deadtest-KERNAL nicht geht.



    Da macht schon eher eine Version von MINIMON Sinn, die sich bei $8800..$8FFF im Character-ROM versteckt, und zwar so, daß nur die CPU den Code sieht, der VIC aber immer noch auf den Klein-/Großschrift-Zeichensatz zugreifen kann. :D

  • Ich meinte MINIMON alleine, ohne alle ROMs. Da muss er dann bei FFFC/FFFD den Startvektor hinterlegt haben. Aber ja, wozu. Stimmt eigentlich.

    Da macht schon eher eine Version von MINIMON Sinn, die sich bei $8800..$8FFF im Character-ROM versteckt, und zwar so, daß nur die CPU den Code sieht, der VIC aber immer noch auf den Klein-/Großschrift-Zeichensatz zugreifen kann. :D

    Auch eine schöne Idee. ^^

    "Wenn du überredet, ermahnt, unter Druck gesetzt, belogen, durch Anreize gelockt, gezwungen, gemobbt, bloßgestellt, beschuldigt, bedroht, bestraft und kriminalisiert werden musst. Wenn all dies als notwendig erachtet wird, um deine Zustimmung zu erlangen, dann kannst du absolut sicher sein, dass das, was angepriesen wird, nicht zu deinem Besten ist." - Quelle unbekannt.


    "Steve Jobs hat User hervorgebracht, Jack Tramiel Experten." - Quelle unbekannt.

    "Mein Herr, ich teile Ihre Meinung nicht, aber ich würde mein Leben dafür einsetzen, dass Sie sie äußern dürfen." - Voltaire.

    "Diskutiere nie mit einem Idioten - er zieht dich auf sein Niveau hinunter und schlägt dich dort mit seiner Erfahrung!" - Volksweisheit.


  • [... MINIMON im Character-ROM ...] Auch eine schöne Idee. ^^

    Das braucht nur einen schnellen 2764 im Adaptersockel, mit VA12 und VA13 auf /CS und /OE - sowie SPhi2 von geeigneter Stelle des Mainboards auf A12 des EPROMs. Das EPROM wird mit folgendem Inhalt belegt:


    $0000..$07FF: Großbuchstaben/Grafik (SPhi2 = 0, d.h. VIC dran)

    $0800..$0FFF: Klein-/Großbuchstaben (SPhi2 = 0)

    $1000..$17FF: Großbuchstaben/Grafik (SPhi2 = 1, d.h. CPU dran)

    $1800..$1FFF: MINIMON (SPhi2 = 1)

  • 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 diesen Beitrag als 'Projektvorstellung' verstanden und fleißig mitgelesen. Da ich technisch nicht so fit bin wie viele andere hier kam auch keine Antwort meinerseits sondern 'nur' ein Like. Das Projekt gefällt mit gut und ich wäre auch ein potentieller Nutzer aber du hast noch keine Bezugsquelle genannt. So eine Karte selbst herstellen und mit einem EPROM bestücken könnte ich nicht.

  • Ich würde ja sagen: "Beware of feature creep" und "diminishing returns". Für mich wäre die Minimon-Cartridge das ideale Ergänzungs-Modul zu bestehenden Erweiterungen wie MegaCart, Penultimare, FE3 usw. Der Speicherbereich $9800-$9fff ist perfekt gewählt, da es nur kaum eine Handvoll anderer Software gibt, die diesen Bereich nutzt. Den Minimon an eine andere Stelle im Speicher verschieben zu können, ist dann auch praktisch nie nötig und dafür hardware-technisch Aufwand zu betreiben meiner Meinung nach Overkill. Der Freeze-Reset zur Umgehung des Modulstarts ist in Verbindung mit dem Monitor meiner Meinung nach das Killer-Feature :-) Schön ist auch die Möglichkeit, in den $9800-$9fff-Bereich eigene Software zu flashen, wie z. B. einen Fastloader. Alles in allem, wüsste ich nicht, was man noch sinnvoll an der Cart ergänzen könnte ohne dass die Komplexität/Preis unnötig erhöht wird.

  • Ich habe diesen Beitrag als 'Projektvorstellung' verstanden und fleißig mitgelesen.

    Über den Schritt Projektvorstellung im Sinne von "Anfrage zur Ideensammlung" bin ich schon lange hinaus.


    Wenn ich einen frühesten Zeitpunkt benennen sollte, wo mir die Idee kam, einen Monitor für den VC-20 in den I/O-Bereich zu stecken, dann könnte ich ein Posting im Denial-Forum von 2014 angeben.


    2 KB Platz um neben Hex-Dump-Anzeige und -Änderung, Register-Anzeige und -Änderung, Programmstart und BRK-Handler und Laden/Speichern (das ist in etwa der Funktionsumfang von TinyMon) auch noch den Direkt-Assembler und Disassembler plus noch Verschieben/Vergleichen/Suchen/Füllen unterzubringen, das ist schon eine Herausforderung.


    Ende 2017 hatte ich dann den Software-Teil des Projekts gestartet und Mitte 2018 war die Firmware dann fertig. Neben dem eigentlichen Quellcode umfaßt das Projektverzeichnis noch dutzende Textdateien mit Seitendokumentation, in denen die Funktionsweise aller Routinen noch mal detailliert ausgeführt ist, plus ein Journal in dem sorgfältig alle Änderungsgründe für alle Builds (35 Stück in der Zahl) aufgeführt sind. In der Summe stecken da ca. 100 Stunden drin.


    Anfang 2019 gab es dann den ersten Hardware-Prototypen auf Basis einer +3K-RAM-Erweiterung. Der sollte testen, daß die Logik zur Ansteuerung eines EPROMs im I/O-Bereich richtig funktioniert. Diese Cartridge war dann auch im harten Einsatz bei der Revision 2019. :)


    Zeitgleich hatte ich in Denial das erste Posting dazu geschrieben. Da kam recht zeitnah das Angebot von einem Foren-Mitglied, das ganze in eine eigene Cartridge zu bringen und das brachten wir dann Anfang 2020 auf den Weg. Leider hatte derjenige so seine ganz eigene Agenda, die mir erst klar wurde, als das Teil-Projekt schon recht weit fortgeschritten war, und die mir nicht paßte (das ist noch nett ausgedrückt) und ich mußte da die Notbremse ziehen. Einen Zwischenentwurf aus dieser Zusammenarbeit konnte ich aber als zweiten Prototyp fertigen und damit zumindest schon mal die I/O-Umschaltung zwischen Monitor und Cartridge im durchgeschleiften Cartridge-Port testen.


    Der jetzige Stand ist also bereits das Ergebnis eines längeren Entwicklungsprozesses und es sind einige Erfahrungswerte aus aktueller Nutzung eingeflossen.


    Ich würde ja sagen: "Beware of feature creep" und "diminishing returns".

    Keine Sorge. Firmware und Hardware stehen auf solider Basis. Ohne zureichenden Grund ändere ich da absehbar nichts mehr. :)


    Die zuvor angebrachte Anfrage zur Relozierbarkeit ist ja bereits geklärt - eine RAM-Erweiterung plus ein kleines Support-Tool reichen ja schon. Es gab auch noch in PN die Nachfrage nach einer integrierten Dezimal/Hex-Umrechnung. In MINIMON selbst ist für sowas kein Platz mehr, wenn es bei 2 KB Größe bleiben soll, aber als transientes Utility geht (fast) alles.


    [...] ich wäre auch ein potentieller Nutzer aber du hast noch keine Bezugsquelle genannt.

    In einem vorigen Beitrag hatte ich ja bereits erwähnt, daß ich absehbar nicht dazu kommen werde, in eigener Regie eine Kleinserie in Sonn- und Feierabendstätigkeit zusammenzubauen und zu verkaufen. Wenn jemand hier dazu einen Vorschlag hat, immer her damit!

  • Anfang Juni hatte ich MINIMON hergenommen, um das Spiel "Get More Diamonds" dahingehend zu verbessern, daß man jetzt unendlich viele Leben hat, statt am Anfang nur 3. Es gibt zwar Extraleben in den Levels (dargestellt als Herzen), aber die Schlüssel-Tor-Rätsel sind auch so schon knifflig genug.


    Tools die vergleichbares auf anderen Systemen/Konsolen leisten, benutzen häufig folgende Methode um die Speicherstelle herauszufinden, wo die Anzahl der Leben gespeichert ist - entweder um diese Anzahl direkt zu erhöhen oder um die Befehle auszuschalten, welche die Anzahl der Leben auf Null runterzählen: direkt am Anfang wird das Spiel ge-freeze-d, die Anzahl eingegeben und daraus eine Liste von Kandidaten-Adressen generiert. Nach Wiederanlauf wird ein Leben verloren und nach erneutem Freeze die Liste abgeprüft, wo da jetzt die Anzahl minus 1 drinsteht. Dieses Vorgehen wird solange wiederholt, bis das Ergebnis eindeutig ist. Auf einem Rechner mit limitiertem Speicher ist diese Methode aber nicht sinnvoll einsetzbar.


    Wenn man GMD spielt, fällt einem recht schnell die reduzierte Bildschirmgröße von nur 16x16 Zeichen auf. Die erste Textzeile zeigt die Punkte, die Anzahl der Leben und noch andere Sachen an. Wir können annehmen, daß die Anzahl der Leben als Bytewert gespeichert ist, möglicherweise in der Zeropage. Jetzt den Code danach händisch zu durchkämmen ist einigermaßen umständlich - aber es schadet sicher nichts, wenn wir uns erstmal in ASCII-Ansicht einen Überblick verschaffen:



    Hier wurde zunächst das Spiel geladen, dann MINIMON gestartet und dann das transiente ASCII-Dump-Tool aus Beitrag #8 hier im Thread geladen.


    Mit +24K RAM oder mehr geht der BASIC-Speicher von $1201 bis $7FFF, und GMD will sogar eine +35K-Erweiterung! Den erneut angezeigten Registerdump ändern wir um, so daß PC=$02A3 (Startadresse des Tools) und $AC=12 ist ...



    ... womit nach G die Speicherseite $12xx angezeigt wird:



    Das liefert uns gleich den ersten Hinweis - die Adressen $1221 bis $1230 enthalten die "Blaupause" für die Punkteanzeige!


    Jetzt ist es schon recht wahrscheinlich, daß auf diese Blaupause mit einem register-indizierten Befehl zugegriffen wird, mit entweder $1221 oder $1220 als Basis-Adresse. Mit dem Befehl H 1200 7FFF 21 12 bekommen wir 3 Treffer und wir disassemblieren bei diesen Adressen, minus 1 um den Opcode des Befehls mit drin zu haben:



    Gleich der erste Treffer bei $3254 bringt uns schon weiter: das ist die Schleife, welche die Statuszeile beim Start des Spiels in die erste Bildschirmzeile kopiert. Wir halten fest, daß die Anzahl der Leben im Bildschirmspeicher an der Adresse $1008 zu liegen kommt. Als nächsten Schritt suchen wir darum nach einem Speicherbefehl auf $1008 - etwa STA $1008.


    MINIMON zeigt aus Platzgründen in einem Disassembly die (bis zu 3) Hex-Bytes zwischen Adressen und Mnemonic nicht an, aber mit einem "Test-Assembly" plus dem M-Befehl kommt man trotzdem an das gewünschte Suchmuster.


    Wir assemblieren STA $1008 testweise nach $033C. Das ist der Anfang des Tape-Buffers, da stört das gerade keinen. :) Heraus kommt $8D $08 $10 als Suchmuster. Mit H 1200 7FFF 8D 08 10 erhalten wir nur einen Treffer und disassemblieren noch ein paar Befehle davor, die uns zeigen wo die Anzahl der Leben gespeichert ist - ein scharfer Blick zeigt uns den Befehl LDA $3F an Adresse $3275:



    Das nächste Suchmuster ist für DEC $3F (wobei wir der Form halber ein BRK hinterher schieben, um das "Testassembly" hinter dem DEC-Befehl aufzuräumen), dies sind die zwei Bytes $C6 und $3F. Mit dem entsprechenden H-Kommando erhalten wir wiederum nur einen Treffer, bei $3338, ...



    ... und das Disassembly zeigt uns hier ganz klar einen typischen "Test auf Null Leben übrig". :D


    Bleibt nur eins: wir ersetzen den Befehl DEC $3F durch 2 NOPs, beenden MINIMON und fragen BASIC ganz lieb, wohin die äquivalenten POKEs hingehen sollen - und mit welchem Wert:



    Damit schalten die zwei POKEs POKE13112,234:POKE13113,234 unendlich viele Leben in GMD frei. Die POKEs werden nach LOAD und vor RUN eingegeben.



    Nachtrag: die Info bezieht sich auf das erste Release des Spiels vom 6. Juni 2022 (+/-) . Mittlerweile gibt es eine Version 1.5 - da liegt der Befehl DEC $3F möglicherweise woanders.