Posts by darkvision

Quote from Pusti64

StartMP3_64/128 wird angezeigt. Irgendetwas musst Du da gegenüber dem allerersten Image geändert haben, weil da wurde dieses NewMouse128 immer brav mit assembliert.

Hier wird es ja auch mit assembliert... und wenn StartMP3_128 angezeigt wird, dann müssten da noch viel mehr Programme fehlen.

In den Images die ich gestern hochgeladen habe, werden zuerst die Systemprogramme assembliert, da ist StartMP3 die letzte aus der Gruppe. Danach werden die Programme assembliert, z.B. der GEOS.Editor. Der dürfte dann bei Dir auch nicht vorhanden sein. Ist das Ziel-Laufwerk zu beginn komplett leer oder liegen da noch Dateien aus einem vorherigen Build?

P.S. hast Du die AutoAssembler-Dateien angepasst? Wie hast Du die Laufwerke verteilt, also was ist Quelltext-Laufwerk, was Ziel-Laufwerk? Dann stelle ich das mal hier genauso ein...

Was zeigt denn der MegaAssembler am Ende an, d.h. wenn das assemblieren beendet ist? Wie auf meinem ScreenShot, nur mit einer anderen "letzten" Datei?

Und wenn Du den AutoAssembler-Modus beendest und s.NewMouse128 manuell assemblierst? Funktioniert das?

Dann gibts noch "ass.MP128_PRG". Zum Schluss einfach mal diese AutoAssembler-Datei auswählen. Da werden alle Programme assembliert, da müsste zum Schluss auch NewMouse128 assembliert werden...

Quote from Pusti64

Die letzte Objektdatei welche erzeugt wird heißt, StartMP3_128

Ich hab neue Images hochgeladen. Dort hab ich das AutoAssembler-System aktualisiert. Damit klappt jetzt auch das assemblieren mit 1581 und DiskWechsel. Dazu hab ich auch die Reihenfolge angepasst damit ein Diskwechsel entfällt. Die letzte Datei die jetzt assembliert wird ist NewMouse128, siehe Screenshot.

Quote from wweicht

Als ich schon im Bett lag, viel mir ein: Ich hatte ass.MP64_1 gestartet statt ass.MP128_1.

Kein Problem... du glaubst gar nicht wie oft mir das schon passiert ist.

P.S. In den neuen Images ist auch das Problem mit dem Namen des Hintergrundbildes behoben...

Quote from Pusti64

Ob ich bei der Geschwindigkeit aber etwas lesen kann, weiss ich noch nicht

Hat die SCPU128 keinen 2/20MHz Schalter?

Quote from wweicht

Ich probiere morgen Abend nochmal. Aber auch das kann eigentlich nicht sein.

Wenn Du das nochmal testest dann bitte mit aktivierten Symboltabellen. Da sollten dann alle Symbole für MakeKernal aufgelistet werden. Was zeigt denn Flag64_128 an?

Ich hab eben den Code auf Vice128 assembliert. Da ist dann MakeKernal 64/128 40/80Zeichen.

MegaAssembler sucht aber fehlende Dateien auf allen Laufwerken. Ist vielleicht auf einem der anderen Laufwerke eine Kopie der Datei vorhanden?

Der Code-Ausschnitt oben zeigt ja das über das Flag :Flag64-128 auf C64/128 geprüft wird. Und das Flag wird nur im Source-Code zum Kernal definiert. Und die externe Symboltabelle, egal ob C64 oder C128, ist immer src.GEOS_MP3.ext (das hat einen ganz praktikablen Grund...). Wenn also MakeKernal als 64Only assembliert wird muss Flag64_128 auf C64 stehen... nur dann wird das z-Flag auf 64Only gesetzt.

Quote from Pusti64

Warum diese fehlt, weiss ich auch nicht so recht, weil diesbezüglich beim Kompilieren auch keine Fehlermeldung kam.

Ich bin sowieso gerade dabei die AutoAssembler-Dateien zu überarbeiten. Wenn man nur mit 1581-Laufwerken und Diskwechsel arbeitet, dann läuft der Prozess momentan nicht bis zum Ende durch.
Am C64 hab ich gerade das neue System getestet... da steht dann als letzte Datei "NewMouse64". Ich teste das jetzt mit VICE128. Wenn das klappt aktualisiere ich die /current-Version. Da hab ich dann auch schon Werners Fehler zum Hintergrundbild korrigiert. Ich frage mich warum bei Dir die NewMouse128 fehlt. Wird denn die Datei beim assemblieren in MegaAssembler angezeigt?

Quote from wweicht

Klappt nicht. Schon im ersten Durchlauf bekomme ich einen Fehler: "Kann MP_MakeKernal nicht starten". Grund: Dieses Programm steht beim Assemblieren unter MP3-128 (Version von 2003) auf Geos64 only.

Das ist seltsam...

Das kann nur dann passieren wenn die Datei src.GEOS_MP3.ext vom C64 existiert. Dort wird nämlich das Flag ":Flag64_128" definiert. Am besten alle externen Symboltabellen vor einem Rebuild löschen, besonders wenn man für 64 und 128 kompiliert.

Quote from wweicht

Kann es sein, dass da der Mauspfeil geändert wurde? Hier ist jetzt wohl ein Mauspfeil drin, der dem originalen Geos-Pfeil zumindest stark ähnelt. Früher war da ein zierlicherer Pfeil drin.

Das kannst Du selbst wählen... die Datei s.NewMouse64 in geoWrite öffnen und :UseMousePic auf '1' setzen. Dann bekommt man wieder den "schlanken" Mauspfeil... Es reicht dann in MegaAssembler s.NewMouse64 neu zu "assemblieren" und die AutoExec zu starten.

Mit dem Mauspfeil in GEOS128 bin ich auch nicht zufrieden... aber so wie Du auch hab ich da eine Prioritäten-Liste... und da ist der Pfeil so ziemlich das letzte

Quote from wweicht

Kann es sein, dass da im Editor durch den längeren Dateinamen von "MegaScreen.pic" das eigentlich nötige abschließende "0" Byte überschrieben wird?

Korrekt... der Name des Hintergrundbildes hat im Source-Code eine feste Länge. Ist der Name bei einem anderen Bild länger dann wird das NULL-Byte überschrieben und ein Teil des Druckertreiber-Namens angezeigt.

Quote from Pusti64

Das 1581 Setup mit SuperCPU128 und RamLink funktioniert jetzt einwandfrei.

Ich glaub es ja nicht!!!!

Ich dachte es hagelt jetzt weitere Fehlermeldungen ganz anderer Art... aber das es bei Dir gleich startet... Super!

Quote from Pusti64

Ein klitzekleiner Fehler ist mir aufgefallen. Beim erstellen der Startdateien fehlt das Prg. NewMouseMode.

Hm... evtl.NewMouse128 ??? Das ist eigentlich die letzte Datei die kompiliert wird. Gab es da einen Fehler?

Quote from Pusti64

Welche Dateien genau muss ich jetzt ändern, damit ich das Ganze mit meiner HD1581 testen kann?

Für eine Installation ohne Setup? Wie oben gesagt:

Quote from darkvision

Die Laufwerksdaten wurden in die Dateien mp-d5-program/-G3_BootData/G3_Bootdata2 ausgelagert.

Ich hab das in die neuen Include-Dateien ausgelagert, damit man 1. keine Systemdateien verändern muss und 2. das gleich für C64/C128 geändert werden kann.
Damit das mit den AutoAssembler-Dateien funktioniert muss dann auch die Datei -A3_Disk#2 angepasst werden: Dort wird der Treiber für den Boot-Vorgang kompiliert. Anschließend die AutoAssembler-Dateien neu kompilieren lassen.

Die GEOS-Serien-ID muss man im Code nicht mehr unbedingt ändern... ich denke das hast Du schon selbst festgestellt

für das schnelle testen! Auch ein dickes Danke an Werner... Ich denke ohne euer Feedback wäre das System noch nicht da wo es es jetzt ist.

Quote from Pusti64

Okay, dann warte ich ab bis der 3.0rev2+3.01-Patches Code online ist und gebe dann zu diesem Thema Feedback

Dann lass Dich nicht aufhalten, ich hab den aktuellen Code hochgeladen

Es hat etwas länger gedauert als erwartet, aber es gab auch immer wieder kleinere Bugs die mich genervt haben und die ich beseitigen wollte. Aber jetzt steht der Source-Code zu MegaPatch64-128 v3.0rev3 online. Zum Download gehts hier entlang.

HINWEIS: Nach wie vor steht nur der Source-Code zum Download bereit!

Einige Anmerkungen:
Mein Code bis Ende 1999 hat zwar Ergänzungen von W.G. für den C128 beinhaltet, allerdings wurden hier und da Änderungen vorgenommen um die Kompatibilität zum C128 zu verbessern. Die Änderungen sind nicht alle in den Master-Code eingeflossen. Das dürfte das Hauptproblem mit der 3.0.rev2 und dem C128 gewesen sein.
Ich habe jetzt die Version von 1999 als Grundlage genommen und habe versucht den Code von 2003 zu rekonstruieren. Der jetzt veröffentlichte Code (unter /megapatch64_128/archive/3.01/rev1) ist bis auf wenige Ausnahmen (GEOS-ID, Standard-Laufwerks-Setup) zu 100% Binär-kompatibel mit der Version von 2003. Getestet wurde aber nur die 128er/Deutsch-Version.
Sämtliche Änderungen/Ergänzungen zum Original -Code kann man hier nachlesen. Das diff beinhaltet alle Änderungen zwischen dem Code von 1999 und der Version von 2003.

Die Version 3.0rev2 hat aber bereits einige Erweiterungen erfahren. Daher ist derzeit die Version 3.0rev3 aktueller als der Code von 2003, beinhaltet aber alle Änderungen der 2003er-Version. Zur Kontrolle findet sich hier ein diff '2003-vs-3.0rev2'.

Ich hab das Setup auch unter GEOS64v2.5 unter VICE getestet. Dabei gab es noch einen "Crash": Beim konfigurieren der Startdisk hängt das SETUP ggf. wenn es Probleme mit der aktuellen Uhrzeit gibt. Das Update-Programm stoppt/startet die Uhrzeit jetzt vor dem Update-Vorgang. Momentan scheint alles reibungslos zu laufen.

Wer den Code kompilieren will:
Die Laufwerksdaten wurden in die Dateien mp-d5-program/-G3_BootData/G3_Bootdata2 ausgelagert. D.h. wenn man ein anderes Startlaufwerk einbinden will, dann müssen diese Dateien angepasst werden (ggf. zusätzlich AutoAssembler-Dateien anpassen). Kopieren der Dateien auf ein NativeLaufwerk mittels geoDOS oder DualTop, TopDesk ist dazu nicht geeignet!!!

DIE EMPFOHLENE INSTALLATIONSMETHODE IST ABER DAS SETUP ÜBER STARTMP3_64/128!

Nach wie vor ist das 4-Laufwerks-Setup die bevorzugte Methode um MP3 zu kompilieren. Ich werde aber demnächst auch andere Varianten testen.
Grundvoraussetzung ist ebenfalls MegaAssembler V3.9.

Patches für die Version 3.0r2 gibt es nicht: Die Änderungen waren einfach zu umfangreich. Die Version 3.0r3 sollte aber alle Änderungen der Version 3.01 enthalten. Wenn alles funktioniert werde ich die Versionsnummer auf 3.10 hoch-stufen.

Have fun compiling MegaPatch! (and sorry for all the trouble...)

P.S. Screenshot mit MP3 und dem klassischen Desktop 2.0... da werden Erinnerungen wach!

Hallo Werner,

Quote from wweicht

Ich habe jetzt ein wenig damit herumprobiert und kann das Problem jetzt etwas eingrenzen (MP3-64 rev 2 Patch1).

auf Grund Deiner Fehlerbeschreibung hab ich mir die Routine zum einfärben des Logos nochmals angeschaut und ich glaube ich hab den Fehler gefunden.

Beim beschreiben des FarbSpeichers ist das Y-Register nicht korrekt initialisiert. Hängt aber von der GEOS-Routine FillRAM ab.und damit ob man es unter GEOS64 oder MP3-64 installiert. Je nach System wird wohl beim beenden der Routine ein andere Wert im Y-Register übergeben und entweder es funktioniert oder eben nicht. Ich hab bisher MP3rev2 fast immer unter MP3 installiert. Die paar mal wo mir das aufgefallen ist war wohl unter GEOSv2/2.5. oder aber ein Zwischenstand bei dem die DoLogoColor-Routine mit zufällig anderen Werten im Y-Register aufgerufen wurde. Ich hab das fehlende LDY #$00 ergänzt und damit sollte das Problem Geschichte sein.

Ich schmeiß jetzt mal den C64 an und teste den 3.0rev2+3.01-Patches auf der realen Hardware. Soweit ist nämlich jetzt alles fertig. Danach wandert der Code heute online... hoffentlich mit funktionierender StartMP3-Farblogo-Routine

Quote from wweicht

Das wundert mich jetzt wieder. Das gab es es doch schon vor MP3 für Geos 128.

Das kann durchaus sein, dann hat W.Grimm nur vergessen mir den Code zum Abgleich zurückzuschicken. Fast alle Änderungen die ich jetzt gefunden hab waren auf den C128 bezogen. Bei der Masse an Dateien und ohne Git&Co nur via Mail/SnailMail wundert es mich das es nur so wenige Differenzen waren
Es gab ja durchaus einen Austausch, ich hab hier auch noch einige TopDesk-Disketten mit der OVP (Sprich: Briefumschläge...). Da der Grund-Code in der 128er-Version gut zu meiner Version passt und es nur die 128er-Anpassungen waren dürfte der Code-Fluss in einer Richtung besser funktioniert haben als in die andere Ist aber OK... wenn man sich überlegt wie man hier vor 20Jahren gearbeitet hat. Und W.G. wusste ja das mich der 128er nur wenig interessiert hat.

Ich hoffe jetzt mal das die Änderungen jetzt dazu führen das der Code sich direkt starten lässt (mit SCPU128). Die HD-PP-Treiber hab ich jetzt auch durch. War auch wieder nur eine Ergänzung für den 128er. Ich hab eben nochmal einen Final-Build gemacht und werde morgen die Dateien nochmal abschließend vergleichen. Ist zwar etwas umständlich über VICE+Speicher-Dump. Aber damit hab ich die Dumps gleich auf dem PC und kann mittels bindiff auf Unterschiede testen.

Schade das die HP von W.Grimm nicht mehr online ist. Kann mich noch an die Anfangszeiten erinnern wo ich mit W.G: und damals auch Michael Renz getroffen habe (Ich glaub das war sogar bei W.G. Zuhause...) und die Zukunft von MP3 zu besprechen. Das mit M.R. ist ja nix geworden aber W.G. hat das ja super gemacht.

Beim MegaPatch-Logo ist mir aber trotzdem ab&zu ein kleiner Fehler aufgefallen, in der ersten Zeile, das letzte Farbcard hat ab&zu die Farbe vom Text (hellblau). Hab das bisher nicht weiter verfolgt und weiß gerade nicht mehr in welcher Version...

Zwischenstand:
Ich hab bis auf die HP-PP-Treiber jetzt den Code der 3.01/2003 vollständig nachgebaut, d.h. die erzeugten Dateien entsprechen jetzt 1:1 der 128er-Version von 2003. Bei den Treibern hat W.G. an einigen stellen das umschalten auf den 1MHz-Modus beim 128er deaktiviert (wenn auch nur unvollständig), das gilt für alle RAMLink und RAMDrives.
Gab noch eine Ergänzung im Editor der auch 64Net als "RTC"-Gerät akzeptiert (kann ich natürlich nicht testen).

Wenn ich den Source-Code sortiert habe mach ich mal ein Diff, das kann man dann als Changelog V3-2000 -> V3.01-2003 verwenden.

Hab das aber nur mit der 128er-Version/Deutsch gemacht. Bei den anderen (64er und Englisch) verzichte ich vorerst mal darauf. Die Änderungen hab ich dann in meine Version übernommen (sofern sinnvoll...). Werde die neuen Änderungen dann als Patch#2 entweder am Wochenende oder nächste Woche auf die Area6510 online stellen...

Die Version von 2003 hat bereits den 1581-Treiber als Standard eingebaut. Könnte also sein das sich die entpackten Setup-Dateien direkt von einer 1581 starten lassen wenn man das Setup nach "Systemdiskette überprüfen" beendet. Getestet hab ich das bisher aber auch noch nicht.

wweicht: Danke fürs testen. Werde ich mal nachstellen wenn ich den Code für die 3.01 fertig habe. Ich denke aber das Problem lässt sich leichter lösen als der Crash mit der SCPU.

Ich hab bis jetzt (einschließlich GEOS128.0/1/2/3) nur eine Systemkritische Routine gefunden (die Sache mit dem Bankwechsel). Ansonsten gab es nur kleinere Korrekturen. GEOS128.0-2 sind schon binär-kompatibel. An der 3er arbeite ich gerade.

GEOS128.3 beinhaltet auch den Spooler. Hier hat Wolfgang wohl eine neue Funktion hinzugefügt. Was die genau macht hab ich noch nicht herausgefunden, aber trotzdem mal in den Code übernommen damit ich die Datei weiter mit dem Release von 2003 vergleichen kann.

Gab es damals Informationen darüber das etwas am Spooler verändert wurde? Hat da jemand was mitbekommen?

Quote from wweicht

Wolfgang hatte damals ein Patch dafür und noch weitere Beschleunigungen für Geos 128 und SCPU 128 programmiert

Nachdem ich bei der Fehlersuche nicht wirklich weitergekommen bin versuche ich jetzt den Code für die V3.01 von 2003 nachzubauen, d.h. ich versuche binär-kompatible-Setup-Dateien zu erstellen. Dabei hab ich in der Kernal-Sprungtabelle schon einen Unterschied beim Bank-Wechsel gefunden und in die rev.2 übernommen. Da das eine zentrale Routine ist kann das schon einen Effekt auf die SCPU haben da hier bei der 2003er-Version auf 1MHz umgeschaltet wurde und in der rev.2 nicht.
GEOS128.0 stimmt jetzt schon 1:1 mit der 2003er-Version überein. Bei der GEOS128.1 muss ich zuerst die behobenen Fehler wieder rückgängig machen damit ich das vergleichen kann.

Ich bin ja noch auf der Fehlersuche... aber die FD81 und HD81 Treiber hab ich bereits verglichen. Ein Binärvergleich der aktuellen Treiber mit denen von 2003 hat keinen Unterschied gezeigt. Ich werde die anderen Treiber auch noch prüfen, aber momentan bin ich erstmal dabei die Kernal-Dateien zu vergleichen.

Quote from wweicht

Allerdings wenn ich zuenig freien Speicher habe, dann löscht der Treiber einfach was anderes. Bei mir zum Beispiel den Taskmanager (1 Task eingestellt). Ist das so gewollt?

Ja, ist so gewollt. Musste zwar selbst suchen, aber hier steht das ab Zeile #420.

Quote from Pusti64

Jetzt bleibt die Konfiguration beim Laufwerk 2# (55%) mit Absturz nahe $7FFE hängen.

Super! (auch wenn es trotzdem nicht läuft...)
Denn zwischen 55% und 60% liegt nur eine Routine:

Ja, da ist ein überflüssigen jmp AutoInstall-Befehl, aber zwischen der Anzeige 55% und 60% liegt nur die Routine InstallDkDev. Da hatte ich heute ganz andere Bereiche geprüft. Die Routine prüft beim Erst-Start auf physikalische Laufwerke und richtet diese dann ein. Passt also zum Start-Szenario ohne SETUP das System zu booten.

Unabhängig davon hab ich beim de-assemblieren aber einen Unterschied in den SCPU-Routinen gefunden der aber nur den 64er-Net-Treiber betrifft. Gibt es den überhaupt für den C128? Falls ja, dann schaltet MP3-128-2003 mit SCPU in den 1MHz-Modus, meine Version prüft auf 64Net und bleibt dann trotzdem bei 20MHz wie bei einem RAMLaufwerk. Wäre abseits den Crashs mal interessant zu wissen ob der Code überhaupt Sinn macht oder nur von der 64er-Version übernommen wurde. Da müssten sich ja Änderungen bei den "Disk-Zugriffszeiten" ergeben...

Egal, erst mal Danke fürs testen. Das hilft mir weiter und ich muss nicht ziellos auf Verdacht irgendwelche Routinen prüfen.

Lag ich mit meiner Vermutung richtig

Ich hab jetzt trotzdem mal den überarbeiteten Source-Code für den Editor und das Update-Tool GEOS64/128.MP3 auf die Area6510 geschoben. Sind nur vier Dateien die man austauschen muss. Mehr dazu in der README. Auf dem 128er/VICE hab ich das eben getestet. Mal überlegen ob man den Init-Vorgang nicht auch im 80Z-Modus ausführen kann...

Es gibt auch ein diff das die Änderungen auflistet.

Der Editor zeigt jetzt während der Konfiguration eine Fortschrittsanzeige an, siehe ScreenShot. Das kann man im SourceCode ändern, momentan noch in der (neuen) Datei "- G3_Editor.Init", gleich auf Seite.1. Da könnte man jetzt auch erkennen wo die Init-Rotuine hängen bleibt.

Übrigens:
Wer beim kompilieren eine aufgeräumtes Ziel-Laufwerk haben möchte kann im übrigen in der Datei ass.Options einiges einstellen (ext.Symboltabellen löschen und Objektdateien löschen). Setzt man beides auf "TRUE" dann bekommt man auf dem Ziellaufwerk (fast) nur die wichtigen MP3-Dateien.

Da der SuperCPU Code im Editor in der Init-Routine relativ gering ist hoffe ich mal den Unterschied bald zu finden...