GEOS MegaPatch 64/128 als SourceCode verfügbar!

Zitat von wweicht

Auch wenn ich ReBoot-System dazu nehme, verweigert das System weiterhin, die Installation fortzusetzen (es fehlen Systemdateien).

Am C64 konnte ich das zuerst nicht nachvollziehen. Hab es dann am C128 versucht und siehe da... gleicher Fehler.
Ich hab mir dann die Prüfroutine angeschaut und da war ein ziemlicher Bock drin. Das es am C64 funktioniert ist purer Zufall. Wenn es bei der 2003er Version funktioniert hat (nicht extra getestet), dann war das ebenfalls Zufall, denn der Code ist dort 1:1 mit dem gleichen Fehler vorhanden.
Hab das jetzt korrigiert und jetzt reicht es sowohl am C64 als auch am C128 System und Disktreiber zu kopieren. Es kommt zwar die Meldung das Dateien fehlen, aber keine wichtigen Systemdateien und man kann die Installation fortsetzen.

Ich hab bei der Gelegenheit noch einen Fehler im 80Z-Modus behoben. Es gibt eine Routine welche die Farben vom C64 in das Format im 80Z-Modus konvertiert, die hat nicht richtig funktioniert weswegen im 40Z-Modus Dialogboxen einen schwarzen Titel hatten und im 80Z-Modus einen weißen. Auch die Anzeige des freien Speichers beim Benutzer-Setup war Schwarzer Text auf weißem Grund, richtig ist weißer Text auf schwarzem Grund. Der Fehler trat nur dann auf wenn man eine andere Vordergrund-/Textfarbe gewählt als "Schwarz" hat und der Hintergrund "Schwarz" sein sollte.

Auch das falsche Farb-Card in MEGASCREEN.PIC sollte behoben sein und die Version meldet sich jetzt als REV3.

Die Dateien sind vom 17.7.18/11Uhr, ChangeLog ist hier.

Ich hoffe das damit jetzt alle größeren (und kleineren) Probleme behoben sind. Falls ja, dann würde ich die Version hochstufen und Setup-Images erstellen, allerdings ohne TopDesk. Aber mit dem SourceCode kann ja jetzt jeder eigene Pakete zusammenschnüren. Man kann auch relative einfach StartMP3 beibringen zusätzliche Dateien einzubinden. Dazu muss man nur die Datei mp-d3-system/-G_FilesMP3 anpassen:

Wie man sieht ist das kein Hexenwerk (wichtig sind nur die Zeilen mit +/- am Anfang). Falls es da noch Fragen gibt helfe ich da gerne auch beim testen aus. Oder jemand erstellt Zusatz-Diskimages mit TopDesk und weiteren Patches

Zitat von Pusti64

Bleibt noch die Frage, warum eine CMD-HD unter Topdesk lauter läuft als unter GeoDOS?
Benutzt GeoDOS hier eigene Treiber?

Ich kann hier nur mutmaßen: Ziel ist es natürlich so wenige Diskzugriffe wie notwendig durchzuführen. Ich denke das hab ich bei den Kopierroutinen in GeoDOS umgesetzt. Der TopDesk ist ja aus einer anderen Zeit und da saßen andere Programmierer dran. Kann durchaus sein das beim kopieren vor dem schreiben von Datenblöcken jedes mal Routinen wie OpenDisk oder GetDirHead usw aufgerufen werden, d.h. es wird häufiger zwischen der Datenspur und der Verzeichnisspur hin- und her-gewechselt.

GeoDOS prüft z.B. auch schon vor dem kopieren ob Dateien auf der Zieldiskette vorhanden sind. Wenn TopDesk das während dem kopieren macht dürfte auch jedes mal ein FindFile aufgerufen werden was dann jedes mal die komplette Verzeichnisspur bis zum Ende durchackert...

Wer Lust hat kann ja mal in den HD-treiber eine Debug-Routine einbauen, z.B. immer die Rahmenfarbe wechseln wenn eine der Routinen aufgerufen wird. Man müsste dazu ja nur ein "inc $d020" (c64) an passender Stelle einbauen. Wenn meine Vermutung stimmt dürfte das bei GeoDOS weniger heftig blinken als beim TopDesk wenn man die gleichen Dateien kopiert.

Unter VICE64 hab ich z.B. beim kopieren mit DualTop oder TopDesk im Warp-Modus häufiger diesen "JAM"-Error und ich muss einen RESET ausführen. Mit GeoDOS passiert das so gut wie nie (zumindest sehr sehr selten...). Dürfte also eher an der Programmierung der Kopierroutinen liegen.

Ich denke das zu korrigieren wäre einiges an Programmierarbeit. Mit den Treibern hat das m.M.n. nichts zu tun. Bis auf die DOS-Disk-Geschichte nutzt GeoDOS die Standard-Diskroutinen.

P.S. Nicht wundern falls auf den aktuellen MP3-Disketten in /current noch ein "defektes" Titelbild enthalten ist: Ich erstelle gerade die Bilder für die nächste Version und da würde das dann sowieso ausgetauscht Aber das Problem mit dem fehlerhaften Farb-Card ist definitiv behoben...

Zitat von wweicht

Ich sprach ja auch nur von MP3-128. Meiner Meinung nach funktionierte das ja in MP3-64 schon .

Nein, beim C64 hat es zwar funktioniert, aber das war purer Zufall. Die Adresse innerhalb der Daten-Tabelle wurde falsch berechnet. Wenn in der falschen Adresse dann ein Wert <>$00 stand war alles i.O. MP64 hat dann mit einer Chance von 1:255 fehlende Dateien als "Keine Systemdatei" erkannt.

Wenn dort aber eine $00 stand dann hat das die Routine als "erforderliche Systemdatei" verstanden. Beim C64 standen an den falschen Adressen einfach zufällig die richtigen Werte, beim C128 stehen da an der falschen Adresse auch noch (unglücklicherweise) falsche Werte. Der Bug muss schon sehr lange enthalten gewesen sein, ich denke mal ab dem Zeitpunkt als das Setup umgestrickt wurde damit man das auf mehrere Disketten verteilen kann. Hat ja nur fast 20Jahre gedauert bis der Bug (und andere) behoben wurden. Da such ich jetzt nicht noch nach dem ersten auftreten

Zitat von Pusti64

Ich könnte zumindest die Topdesk128 Kopierroutine im GeoWrite-Format besteuern.

Ich lasse da mal die Finger von... wenn ich da mal Anfange müsste ich auch andere Sachen anpacken und würde am Ende das ganze Programm umstricken... nei nei...

Zitat von Pusti64

Allein das Überspielen auf den C128 dauert trotz uiec und SuperCPU128 ne halbe Ewigkeit:-)

Sorry... Ihr dürft halt nicht so viele Fehler finden Aber für das fleißige testen...

Ich "rette" meinen Datenbestand von der HD via GeoDOS und 3,5"-Disketten auf den PC, das dauert bestimmt noch länger... aber so kann ich die Disketten auch gleich inventarisieren. Wenn ich mir überlege mit was ich mich beschäftigen müsste wenn ich GeoDOS nicht entwickelt hätte. Selbst die geoWrite-Konvertierungsoptionen hab ich hier und da schon gut brauchen können nachdem ich zuerst gar nicht daran gedacht habe und eigenständige Tools ausprobiert habe (die natürlich nicht genau das konnten was ich gebraucht hab).

Zitat von Pusti64

Muss ich eigentlich beim HD81 Setup die Partitionsnummer eintragen oder kann die auf 0000 bleiben?

Nein, das ist nur für die RAMLink notwendig. Dort kann man ja via CP-Befehl die Partition wechseln und mit setzen der Adresse in ramBase dann aber auf eine ganz andere Partition zugreifen. Das hab ich früher (und ich glaube auch noch beim Original GeoDOS von vor 20Jahren) dazu verwendet die Partitionen auf der RAMLink zu wechseln, also gar nicht über die neue OpenPartition-Routine. Bei der HD geht das nicht, daher kann das hier immer auf #0 bleiben. Dort kann man ja nur von der Partition booten bzw zugreifen die gerade aktiv ist.

Das ist auch der Grund warum die AutoAssembler-Dateien eigentlich nur mit MP3 zu verwenden sind (sollte ich noch ins README aufnehmen). Auf einem Original-GEOS fehlt die Routine und da dürfte dann MegaAssembler abstürzen... oder ich baue in das Macro eine Abfrage auf die MP-DD3-Treiber ein und übergehe dann den Partitionswechsel).

Zitat von Pusti64

Bleibt leider bei GeosBoot 100% und die Startdiskette wird konfiguriert hängen.

"GEOS128.1" oder "GEOS128.BOOT" ? Bei letzterem und 100% ist eigentlich schon alles erledigt und das Programm sollte nur noch "OK" ausgeben und zurück zum Desktop springen.

Lässt sich den MP3 nach einem RESET von der HD starten?

Um das weiter einzugrenzen: Könntest Du die auf der HD kopierten Dateien auf eine 1571 oder auf die RAMLink übertragen und dort GEOS128.MP3 starten? Einfach alle Dateien wie GEOS, RBOOT, NewMouse... kopieren. Kein erneutes Setup/StartMP3 ausführen. GEOS128.MP3 installiert das MegaPatch im laufenden System und ruft dann ebenfalls MakeBoot auf. Nur um zu sehen ob es auf anderen Laufwerken funktioniert.

Parallel erstelle ich gerade einen Build für eine FD4000 unter VICE128. Das kommt der HD am nächsten. Wenn ich das hier reproduzieren könnte wäre das gut.

Zitat von Pusti64

Komisch, die 2. Installation von MP64 rev3 HD81 Setup verlief dagegen ohne Probleme komplett durch.

Also am C128 bleibts hängen und am C64 läufts durch? Wäre ja nicht so gut, wieder so ein C128/SCPU Bug, und das wo ich doch alle Routinen nachgebaut haben müsste. Vielleicht muss ich da doch nochmal ein Diff erstellen...