Hallo Besucher, der Thread wurde 14k mal aufgerufen und enthält 56 Antworten

letzter Beitrag von C=Mac am

Quelltext für MegaPatch64/128 als Dokumentation verfügbar!

    Vor ein paar Jahren (Link) war ich noch der Meinung das ich den Quelltext von MegaPatch evtl. nicht mehr wieder herstellen kann, da einige Disketten schon unlesbar waren. Aber ich hab ja schon vor ein paar Wochen den versuch unternommen die Hardware wieder aufzubauen. Die CMD HD funktioniert zum Glück noch, sogar mit RTC...
    Und jetzt, knapp 7 Jahre später bin ich zumindest einen kleinen Schritt weiter:


    Der Quelltext von GEOS MegaPatch 64/128 steht auf meiner Area6510 als Dokumentation zur Verfügung! 8) (Link)


    HINWEIS: Die Quelltexte werden wie beim MegaAssembler ebenfalls im geoWrite-Format bereitgestellt wenn der Code sich kompilieren lässt, sämtliche Demo-Routinen entfernt und der Code für MP64 und MP128 vereinheitlicht wurde. Also noch etwas Geduld ;) Die reinen Text-Dateien die im /doc-Verzeichnis zur Verfügung stehen sind *KEIN* funktionstüchtiger Quelltext, es fehlen sämtliche Icons.


    Momentan gibt es Zwei Code-Versionen:


    Eine reine MP64-Version, vermutlich meine Arbeitskopie. Und eine MP64_128-version, das dürfte der Code sein den ich mit Wolfgang abgestimmt habe. Da Wolfgang laut oben verlinktem Thread wohl damals nichts dagegen hatte, stelle ich mal beide Code-Versionen bereit um diese später ggf. zu vereinheitlichen.


    Jetzt gibt es in beiden Versionen leichte Unterschiede (zu finden im Verzeichnis zu MegaPatch64.rev0/diff). Diese müsste ich zuerst mal analysieren. Die Datumsangaben die in den diff-Dateien am Anfang vermerkt sind entsprechen den Datumsangaben auf meiner Festplatte. Daran kann man sehen wann welche Datei zuletzt bearbeitet wurde. Und einige aus meiner Arbeitskopie scheinen neuer zu sein... Mit dem diff-Viewer von GitLab wird das was der MP64_128-Datei fehlt in den diffs rot markiert.


    Danach müsste man die beiden Code-Versionen zusammenführen. Im MegaPatch64_128-Verzeichnis gibt es nämlich viele Dateien doppelt. Mein Ziel wäre es D81-Images für die MP64-Version bereitzustellen die dann um die speziellen 128er-Dateien ergänzt werden müssen um MP128 zu kompilieren (also eine Art AddOn-D71-DiskImage für MP128).


    Ich würde auch versuchen die ganzen Demo-Abfragen zu entfernen und eine Möglichkeit einzubauen die Seriennummer festzulegen.


    Das kann aber alles noch etwas dauern. Dazu muss ich mich auch mal mit dem C128 unter Vice beschäftigen.


    Bis dahin: Erstmal viel Spaß beim lesen :D
    Markus


    P.S. Wir können diesen Thread auch gerne für Fehlersuche und Behebung verwenden, falls jemand schon Fehler/Patches hat. bei Gelegenheit würde ich das dann abarbeiten. Verbesserungsvorschläge sollten wir uns für später aufheben wenn man mal in der Lage ist das vernünftig zu testen.

    Hi Pust64,
    naja... alles in einem geoWrite Dokument könnte schwierig werden ;)
    In de .rev1 sind es jetzt aber schon ein paar Dateien weniger, weil bei den 128er-Disks die doppelten 64er-Dateien weggefallen sind.


    Hab jetzt eben die rev.1 auf dem C64 "händisch" übersetzt, da die AutoAssembler-Dateien auf die RAMlink optimiert waren. Mit Partitionswechsel zwischendurch weil ja der gesamte Code nicht auf eine 1581 passt :( Und weil ich das jetzt unter VICE getestet hab funktionieren diese AutoFiles nicht. Mal überlegen wie man das optimieren kann. Aber mind 2x1581 Partition ist das absolute Minimum... 1xMegaAss+Objekt-Code, 1xSourceCode wobei man hier dann ggf. Disketten/Partitionen/Images wechseln muss.
    Ich hab unter VICE jetzt 4x1581 eingerichtet und musste dann im MegaAss nur auf das richtige Laufwerk wechseln. Alternativ wäre ein Native-Laufwerk denkbar, die meisten Desktops zeigen dann aber nur 144 bzw 240 Dateien an. Aber zum kompilieren müsste das trotzdem gehen. Das setzt dann halt CMD-Hardware oder ein existierendes MP3 voraus.


    Zumindest haben mir die AutoAss-Dateien geholfen die richtige BuildOrder der Quelltexte herauszufinden. Ohne die Infos wäre das jetzt nicht so einfach gewesen.


    Egal... das gute: Die Dateien kompiliert, auf eine leere 1581-Diskette gepackt und dann unter Laufwerk 8: gestartet, ohne Installation. Läuft :thumbsup:


    Der Grund für MakeBoot ist lediglich das der passende Laufwerkstreiber für das Boot-Laufwerk fest in den BootCode eingebunden wird und zumindest im Code den ich hier hab steht da die RAMLink als StandardTreiber... Bindet man schon beim kompilieren die 1581 ein, dann klappt das auch ohne MakeBoot, aber eben nur von einer 1581.


    Bei einigen Dateien war der freie Symbolspeicher hinterher kleiner als 1000Bytes. D.h. für Erweiterungen im MegaAssembler bleibt da nicht viel Platz.


    Markus


    P.S. unter Vice bei 500% hat das jetzt über 3h gedauert. Keine Ahnung wie man das auf einen real-C64 runter-skaliert, aber ohne Beschleuniger-Karte könnten da schon 12-15h zusammenkommen.

    Zitat von darkvision

    Wir können diesen Thread auch gerne für Fehlersuche und Behebung verwenden, falls jemand schon Fehler/Patches hat.

    Na, da fangen wir mal an ;-) .


    Ausgehend vom offiziellen Release von Anfang Januar 2000:


    nur MP3-64 deutsch


    - in der deutschen Tastaturbelegung sind die Tasten Z und Y vertauscht. Wird durch mein MP3-Patch behoben.


    MP3-64 und MP3-128


    - die Routine xFollowChain in G3_F_F_Chain.s arbeitet nicht korrekt. Hier hätte ich Ersatz. Der ist (leider nicht ganz Geos-Konform) in meinem MP3-Patch enthalten. Der Grund: Ich ändere das nach dem Booten von MP3 mit einem Auto_Exec nur im Speicher des Rechners. Da sind aber nur 50 Bytes für die Routine verfügbar, so dass ich am Anfang


    lda r3h
    pha


    und am Ende


    pla
    sta r3H


    weggelassen habe. Ich bräuchte dort 51 Bytes.
    Das betrifft alle Laufwerstreiber außer die 2 MSDOS-Treiber.


    - die Routine xGetBorderBlock in D3_GetBorderB.s arbeitet nicht korrekt.
    Das betrifft alle Laufwerstreiber außer die 2 MSDOS-Treiber.



    - im Geos-Editor wird die Einstellung "Bildschirmschoner aus" nicht gespeichert. Hier helfe ich mir mit einem kleinen Auto_Exec, dass die Variable "Flag_ScrSaver ($9fcd)" auf $80 setzt.



    schwerwiegend (in meinen Augen) aber noch ohne Lösungsansatz meinerseits - MP3-64 und MP3-128



    - sind bei der Installation des Laufwerks-Treibers "C=1541 (Cache)" nicht genug freie RAM-Bänke verfügbar, überschreibt er schon belegte RAM-Blöcke und installiert sich einfach. Folge: Absturz.


    Gruß
    Werner

    MegaPatch128 kompiliert und ohne Installation von einer frischen 1581 gebootet... Schluss für Heute :D


    Sieht so aus als wäre die vermisste MacTab_Main eine reduzierte MacTab mit nur wenigen Macros, Glück gehabt. Damit sind auch für MP128 alle Dateien vorhanden um den Code zu kompilieren.
    Kritisch sind nur src.GEOS_MP3.128 (30Bytes Restspeicher) und s.MP3.Edit.2 (41Bytes Restspeicher).


    wweicht: Danke für das Feedback. Ich schaue mir den Code dann bei nächster Gelegenheit an. Das gute ist ja das man jetzt nichts mehr patchen muss sondern den Code direkt ändern kann.


    Der nächste Schritt ist jetzt das entfernen der Demo-Routinen und die AutoAss-Dateien mit Anleitung. Das werde ich aber nur noch am C64 testen, danach lade ich den Code hoch dann jeder selber ggf. auch auf dem C128 testen.


    Hier noch ein Fehler aus einem Thema hier:

    Zitat von C=Mac

    Wird bei MP3 64 der "64er Mover" als Bildschirmschoner verwendet.
    Darf der Hacken bei: "C=REU: Schnellen Speicher-Transfer aktivieren" nicht gesetzt sein, sonst stürzt MP3 beim verlassen des Bildschirmschoners ab.

    Zitat von C=Mac

    Dies ist jedenfalls bei Verwendung der Ultimate REU der Fall, mit einer echten Commodore REU hab ich dies nicht getestet.

    Ich habe hier eine UltimateREU und konnte das nachvollziehen.
    Zur Info: Unter WinVICE und auf der UltimateREU (1541 Ultimate II+) am C128 DB habe ich grundsätzlich die CBM-REU und mit 4 MB eingerichtet. Probleme damit konnte ich bisher nicht feststellen. Bildschirmschoner sind bei mir aber immer abgeschaltet. Die stören mich nur ... ;-)
    Bei der 1541 Ultimate kann man auch GeoRAM (nicht gleichzeitig mit CBM-REU) in verschiedenen Größen einrichten. Auch die funktioniert mit MP3 mit 4 MB. Unter WinVICE funktioniert hier lediglich xscpu64 nicht, wenn CBM-REU und SCPU-RAM gleichzeitig benutzt wird.



    Zitat von darkvision

    MegaPatch128 kompiliert und ohne Installation von einer frischen 1581 gebootet...

    Das sieht doch schonmal ganz gut aus. Glückwunsch!! :lol23::respect:


    Nur sagt mir das Bild wieder mal, dass VICE wohl nicht richtig eingestellt ist ;-) . Die Streifen im Bild kann man wohl noch wegbekommen. Gilt für alle x64 und x128 (zumindest unter Windows).


    "Einstellungen - Video Einstellungen - VICII Renderer - Render Filter" auf "kein" stellen


    Bei x128 zusätzlich "Video Einstellungen - VDC Renderer - Render Filter" ebenfalls auf "kein" stellen.


    Das macht das Bild hier bei mir glasklar.




    Zitat von darkvision

    P.S. unter Vice bei 500% hat das jetzt über 3h gedauert.

    Nun, wenn ich mich nicht irre heißt das, das x64 mit ca. 5 MHz läuft. Das dürfte am echten C64 mit SCPU doch etwas schneller gehen (ich weiß, das der da auch nicht 20 MHz erreicht) ....


    Gruß
    Werner

    Zitat von wweicht

    Nur sagt mir das Bild wieder mal, dass VICE wohl nicht richtig eingestellt ist

    Ich find's schick, Retro halt :D Mich nervte nur der unnütze Bildschirmrand, aber Dank Deiner Tipps (Einstellungen/VIC) hab ich den jetzt abschalten können :thumbup:
    Hab auch endlich eine VKM-Datei für die Tastatur-Emulation hinbekommen. Irgendwie sind die Standards unter geoWrite für mich unbrauchbar gewesen.


    Interessant was man da alles an Fehlern gefunden hat... wundert mich das es bei der Menge an Code nicht noch viel mehr sind :rolleyes:


    Ja, mit der SCPU dürfte das schneller gehen. Ehrlich gesagt will ich auch wieder zurück an den C64, weg von VICE. Dazu müsste ich nur mal die Zeit (und Lust) finden mein neues Netzteil zusammenzustellen. Das 64er-NT wird schon mit 'ner RamLink echt heiß (mehr als nur Hand-warm). Da hänge ich bestimmt keine SCPU dran.

    Zitat von darkvision

    Der nächste Schritt ist jetzt das entfernen der Demo-Routinen und die AutoAss-Dateien mit Anleitung. Das werde ich aber nur noch am C64 testen, danach lade ich den Code hoch dann jeder selber ggf. auch auf dem C128 testen.

    Nur damit ich es - vielleicht - auch verstehe.
    Es geht darum ob das wiederherstellen des Codes funktioniert hat oder handelt sich um eine "neue" MP3-Version?



    Jetzt bin ich wieder Schuld. ;(:D


    Der Haken, bei "C=REU: Schnellen Speicher-Transfer aktivieren", wird aber bei jedem neuen Booten wieder automatisch gesetzt, soweit ich dies noch im Kopf habe.
    Benutze auf der SCPU-Anlage einfach einen anderen Bildschirmschoner und bei den Anderen ist er aus (mit dem Programm von Werner).


    Gruss C=Mac.

    Zitat von C=Mac

    Jetzt bin ich wieder Schuld.

    Naja, Du hast es hier im Forum erwähnt ;-) . Da wollte ich es gleich an Markus weiterleiten ...



    Nachtrag für @darkvision :
    Das beschriebene Bildschirmschoner-Problem ("64er Mover"; nur MP3-64) tritt auch mit einer echten CBM-REU (1 MB) auf. Hier kommt der Topdesk wieder und dann hängt MP3-64. Keine Mausbewegung mehr möglich, die Uhr im Topdesk steht. Da hilft nur noch ausschalten und neu starten....




    Zitat von C=Mac

    Es geht darum ob das wiederherstellen des Codes funktioniert hat oder handelt sich um eine "neue" MP3-Version?

    Soweit ich das sehe, ging es zunächst nur um das wiederherstellen des vorhandenen Codes. Aber das allein hilft z.B. beim DNP-Problem auf dem SD2IEC schonmal weiter. Ich habe das noch nicht genauer untersucht, aber es sieht so aus, dass bei der CMD-HD zusätzlicher Code ausgeführt wird (um ein Problem auf einer echten HD zu umgehen). Das führt wohl dazu, dass das SD2IEC hängt. Aber das gehört hier noch nicht her (es geht ja erstmal nur um Fehler im vorhandenen Code).
    Aber ich habe jetzt schon mal einen konkreteren Anhaltspunkt ........ ;-) .


    Gruß
    Werner

    Zitat von C=Mac

    Nur damit ich es - vielleicht - auch verstehe.
    Es geht darum ob das wiederherstellen des Codes funktioniert hat oder handelt sich um eine "neue" MP3-Version?

    Ja, geht erst mal nur darum den Code zu kompilieren der für das offizielle Release verwendet wurde. Da die aktuelle Code-Basis vom 17.12.99 stammt ist das nur wenige Tage vom Release-Build 060100 entfernt. Fehler beheben und eine einfachere Installation ermöglichen, das ist momentan alles. Neues wird es von mir in MP3 nicht geben (es sei denn man schiebt mir Code zu den ich mit aufnehmen kann...). Wenn der Code offen ist kann aber (fast) jeder MP3 selbst anpassen.


    Wie schon mal erwähnt hatte ich schon vor 20Jahren an was anderem gearbeitet. Start+Editor waren da schon deutlich verändert. Ob ich das aber an den C128 anpasse... fraglich. Der Code wird aber auch offengelegt, da kann dann jeder den Code an den C128 anpassen.

    Zitat von darkvision

    MegaPatch128 kompiliert und ohne Installation von einer frischen 1581 gebootet... Schluss für Heute :D


    Sieht so aus als wäre die vermisste MacTab_Main eine reduzierte MacTab mit nur wenigen Macros, Glück gehabt. Damit sind auch für MP128 alle Dateien vorhanden um den Code zu kompilieren.
    Kritisch sind nur src.GEOS_MP3.128 (30Bytes Restspeicher) und s.MP3.Edit.2 (41Bytes Restspeicher).

    @darkvision


    Nur mal so als Gedanke. Kannst Du denn deinen MegaAss nicht so stricken, dass der dafür verwendete Speicher in das SuperCPU-Ram verlegt wird?
    Wenn das nicht geht, dass man im MegaAss nur noch einen kleineren Speicherbereich dafür hat und bei Bedarf in das SuperCPU-Ram auslagert bzw. einlädt.


    Pusti64

    Zitat von Pusti64

    Nur mal so als Gedanke. Kannst Du denn deinen MegaAss nicht so stricken, dass der dafür verwendete Speicher in das SuperCPU-Ram verlegt wird?
    Wenn das nicht geht, dass man im MegaAss nur noch einen kleineren Speicherbereich dafür hat und bei Bedarf in das SuperCPU-Ram auslagert bzw. einlädt.

    Die Symboltabelle wird alphabetisch gespeichert, d.h. da werden in Pass1 ständig neue Werte einsortiert. Da müsste man dann ständig den Speicher "swappen". Ganz zu schweigen von dem Aufwand das Einzupflegen. Für die meisten Programme hat man mit der V3 ja eh schon 50% an Speicher gegenüber der V2, das sollte doch für alle anderen Projekte reichen.


    Nein, ich glaube da ist es dann besser die großen Programmpakete von MP in zwei Happen aufzuteilen und dann über (ich glaube) den d-Opcode zusammenzufügen. Geht ja nur um 2-3 Programmteile...

    Zitat von Freddy

    Seits Ihr sichers daß Ihrs von Quelltext redet und nicht von Quältext?

    Wieso? hast Du dir den Quältext mal angeschaut? :D

    Zitat von darkvision

    MegaPatch128 kompiliert und ohne Installation von einer frischen 1581 gebootet

    Da muss ich auch nochmal fragen:


    Das Bild zeigt, dass da Topdesk 128 für MegaPatch benutzt wird. Hast Du da auch was als Quelltext? Da steckt (in beiden Versionen, 64 und 128) auch mindestens 1 Fehler drin.
    Wenn RAM-TopDesk benutzt wird und dann wieder deaktiviert wird, wird in einem Fall die benutzte Speicherbank nicht freigegeben.... (u.a. dafür ist mein TD-Patch entstanden).


    Gruß
    Werner

    Hallo,
    na hier ist ja was los :-)


    Als ich mich 2014, mit meinen ersten Posts hier im Forum, auf die Suche nach dem MegaPatch 3 BUILD:FULL-090100.2020 (deutsch) begeben habe, hätte ich nie damit gerechnet, das der Quellcode einmal verfügbar sein wird und es sogar Fehlerbehebungen und womöglich Neuerung geben wird.


    Also erstmal vielen Dank dafür.


    Damals hatte ich in dem Post "Suche MegaPatch 3 BUILD:FULL-090100.2020 (deutsch) für die beste GEOS Hardware/Software Emulation" mich auch mit den Funktionalen unter Unterschieden zwischen der Version 150799.0852 und der Version 090100.2020 etwas beschäftigt. In der Version 090100.2020 ist wohl zum Einen der SuperRAM Laufwerk Treiber, welcher es ermöglicht die SuperRam Card als RAM-Laufwerk zu verwenden, hinzugekommen. Zum Anderen ist wohl auch noch die Unterstützung eines Parallelkabels zwischen RAMLink und der CMD-HD hinzugekommen. Wenn ich den Quellcode richtig deute sind beide funktionalen Erweiterungen enthalten. Oder?


    Hier nochmal das Bild von damals:


    Gruß
    Hans

    Hallo Hans,


    Toll recherchiert... ich hab das aktuell nicht getestet, aber nach den Screenshots, die ich gerade aus dem Build gemacht habe den ich dieser Tage selbst unter Vice kompiliert habe, dürfte alles dabei sein. Hier ist der Code ja auch schon als Dokumentation verfügbar, da sind die Treiber auch bereits aufgelistet.