letzter Beitrag von darkvision am
Mir ist im Vergleich zu GeoDOS noch aufgefallen, dass meine HD beim Kopieren unter MP128/64 deutlich lauter bzw. am rattern ist.
Von wo, nach wo wird kopiert?
Was wird verwendet (Partitionart, Unterverzeichnisse etc.)
Hat auch immer wieder Probleme beim kopieren, siehe hier MP3 Patch und Laufwerksverwaltung und folgende.
Die Verzeichnisse dürfen nicht den gleichen Namen haben siehe Beitrag 193.
Gruss C=Mac.
Das weiss ich doch 
Dieses rattern der HD ist unter der 2003 Version bei höheren Partitionen zu hören und ich hatte mich über die Jahre schon daran gewöhnt. Weil ich bisher nie groß bzw. gar nicht mit GeoDOS kopiert habe.
Also daher vielleicht etwas für die spätere Dodo-Liste.
Pusti64
Von wo, nach wo wird kopiert?Was wird verwendet (Partitionart, Unterverzeichnisse etc.)
Hat auch immer wieder Probleme beim kopieren, siehe hier MP3 Patch und Laufwerksverwaltung und folgende.
Die Verzeichnisse dürfen nicht den gleichen Namen haben siehe Beitrag 193.
Probleme habe ich nicht mit dem Kopieren. Das funktioniert alles einwandfrei. Nur das meine HD unter MP128/64 beim Zugriff auf höhere Partitionen halt lauter ist als unter GeoDOS.
Pusti64
Sorry, dann hab ich Dich falsch verstanden.
Mir ist auch schon aufgefallen das die HD unter MP3 anders "klingt", als unter Wheels.
Mit GeoDos habe ich zu wenig gearbeitet, um es mit Sicherheit zu sagen.
Gruss C=Mac.
Muss mal sehen, wann ich dazu komme.
Und vor allem muss ich eine kleinere Testpartition machen, so 16MB zu kopieren dauert. 
Gruss C=Mac.
Ja, ist so gewollt. Musste zwar selbst suchen,
OK, Danke. Hatte ich in der Richtung so schon vermutet ... 
.
Zum Problem mit SCPU kann ich nicht viel beitragen, ich erinnere mich aber, dass es da irgendeine Inkompatibilität zwischen RamLink und SCPU 128 in Bezug auf Geos 128 gab. Wolfgang hatte damals ein Patch dafür und noch weitere Beschleunigungen für Geos 128 und SCPU 128 programmiert. Vielleicht macht das jetzt auch Probleme in MP3-128 rev2 ....
Gruß
Werner
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.
Hallo darkvision,
Nachdem ich bei der Fehlersuche nicht wirklich weitergekommen bin
Ich habe jetzt hier mit MP3-128 rev2 Patch#1 herumprobiert.
Dabei habe ich MP3-128 rev2 gearbeitet (unter VICE).
Unter WinVICE die Disk#1 auf C: und Disk #2-#5 auf D: (je RAMNative). Anschließend die 4 Patch#1-Dateien auf D: kopiert (überschreiben). Jetzt MegaAss V2.9 gestartet, VICE auf "Maximale Geschwindigkeit" - "Kein Limit" eingestellt und das Assemblieren gestartet. Wow. Nach etwa 19 Minuten war das fertig (beide Durchgänge) . Die VICE-Geschwindigkeit schwankte dabei zwischen 500% und 1000% . Dann die Setup-Dateien mit meiner Standard-Geschwindigkeit 200% erzeugt.
In VICE dann nur die Komplett-Installation mit diesem Setup-Dateien durchlaufen lassen (in 40 Zeichen mit einem Geos128 mit originalem Geos-Desktop) - Kein Problem.
Jetzt die Setup-Dateien auf Diskette kopiert und am C128DB weitergemacht. Auch hier Geos 128 mit originalem Geos V2.0-Desktop. Egal ob 40- oder 80-Zeichen, das benutzerdefinierte Setup funktioniert nicht. Dabei habe ich "Startdateien" und "Laufwerkstreiber" kopiert. Hier aber nur 1541, 1541Cache, 1571, 1581, 1581DOS, RAM1541, RAM1571, RAM1581, RAMNative, FD1541, FD1571, FD1581, FDDOS und FDNative kopiert.
SCPURamNative, die HD- und RL-Treiber wurden nicht installiert.
Selbst wenn ich jetzt "ReBoot System" dazu installiere, meldet mir MP3 :
"Es wurden nicht alle Systemdateien auf der Startdiskette gefunden. Diskette nicht startfähig. Bitte Systemdateien ergänzen".
Es sind dann 18 Dateien auf der Ziel-(Start-)-Disk.
Dabei ist mir bei 80-Zeichen noch aufgefallen, dass Geos 128 nach der Fehlermeldung und dem Versuch das Setup erneut zu starten mit "Systemfehler nahe $5d57" abstürzt. Also jedesmal Geos 128 neu booten...
Irgendwie scheint das Setup einen der nicht installierten Laufwerks-Treiber noch irgendwie / irgendwo zu brauchen .....
Komplett-Installation läuft in 40- und 80-Zeichen komplett durch und funktioniert dann auch.
Gruß
Werner
Nicht das ich wüsste. Vielleicht weiss ja Werner etwas, weil er ja diese letzte Version direkt von Wolfgang bekommen hat.
Pusti64
Vielleicht weiss ja Werner etwas, weil er ja diese letzte Version direkt von Wolfgang bekommen hat.
Ja, aber das ist aber "erst" 15 Jahre her. Keine Ahnung ob da damals ein ChangeLog dabei war. Auf jeden Fall nicht im D81, das ich damals auf elektronischen Weg (Mailbox, BTX, E-Mail) bekam. Erinnere mich nur, dass Wolfgang das wohl komplett unter VICE erstellt hat und wohl nochmal weitermachen wollte. Das wurde dann ja nichts.
Schaue aber in den nächsten Tagen mal in den alten GO64! (habe ich noch bis 12/20004) ob sich da was findet. Vielleicht wissen ja andere auch noch was .... .
Gruß
Werner
Probiere es bitte mal aus, eine ganze Partition unter GeoDOS und MP64/128 zu kopieren und gib dann bitte mal Feedback.
Danke und Gruß Pusti64
Hab es heute mal probiert, nicht wirklich erfolgreich.
Aber der Reihe nach.
Verwendet wurde die C64-Anlage.
A: RL Native
B: FD 2000 Native
C: HD Native bzw. 1581
D: 1541 II
SCPU on, 20 MHz, 16 MB-RAM
1. Versuch
Mehrere Dateien (Multi File) von einer Native-Partition (aus Unterverzeichnis) auf eine andere Native-Partition (Root-Verzeichnis) mit TopDesk.
Nicht möglich, HD "klickt" nur wild rum und die LED's blinken hektisch.
Hab dann abgebrochen.
Unter GeoDos erhalte ich nur die Fehlermeldung: Datei nicht gefunden. 
2. Versuch
Zwei 1581-Partitionen erstellt.
Unter TopDesk:
Diskkopie zwischen Partitionen nicht möglich (ausser ich bin zu blöd).
Mehrere Dateien (Multi File) von einer 1581-Part auf die andere möglich.
Eindeutige Geräusche.
Unter GeoDos:
Diskkopie von einer 1581-Part auf die Andere möglich.
Würden die LED's nicht blinken, würde man es gar nicht bemerken.
Es gibt somit einen Unterschied zwischen TopDesk und GeoDos.
Wobei bei Verwendung von Native-Partitionen mit Unterverzeichnisse bleib ich lieber bei Wheels.
Gruss C=Mac.
Kurzbericht zu MegPatch 64 Rev2 Patch #1
Habe diese Version jetzt auch mal kurz angetestet. Wichtig ist hier: Das Assemblieren (AutoAssembler) klappt nur, wenn ein MegaPatch V3 64 läuft. Unter MegaPatch 128 geht es nicht. Liegt wohl daran, dass da Dateien erstellt werden, die "Geos64 only" sind.
Das Ganze lief hier unter WinVice (xc64sc) und dauerte knapp 60 Minuten.
Beim Assemblieren und Erstellen der Setup-Dateien gab es keine Probleme. Dann das Setup auch aus einem laufenden MP3 gestartet. Sowohl "Benutzerdefiniert" als auch "Komplett-Installation" laufen problemlos durch. Auch die SCPU (xscpu64) funktioniert tadellos.
Im Setup selber ist mir ein kleiner Schönheits-Fehler (Grafik-Darstellung) aufgefallen:
Der Text "MegaPatch ... " oben sieht etwas seltsam aus. Der Farbverlauf beginnt erst ganz rechts am "a" des Wortes "Patch" und rechts ist der "Build-Text" nicht zu erkennen. Letzteres liegt aber wohl an den Farbeinstellungen. Wenn ich im Screenshot (GeoPaint) die Farbe abschalte, ist der Text komplett lesbar. Da steht wohl Vordergrund- und Hintergrund-Farbe auf schwarz....
Zur Verdeutlichung hier mal ein ScreenShaot vom Setup.
Es sind noch ein paar weitere Tests nötig. So habe ich nur mit WinVice gearbeitet und bisher immer die Installation aus MP3 heraus gestartet....
Gruß
Werner
Kommando zurück. Der Fehler trat nach einem 2. Assemblierversuch heute nicht mehr auf.
Gestern hatte ich unter x64sc.exe mit der Einstellung "Maximale Geschwindigkeit" - "Kein Limit" assembliert. Das dauerte knapp eine Stunde. Die Geschwindigkeit lag beim Assemblieren bei etwa 340%.
Heute habe ich aus Neugierde im C64-Mode von x128.exe nochmal assembliert. Hier lagen die Geschwindigkeiten zwischen 1200% und 700% (41 Minuten Dauer). Bei der Installation der neuen Setup-Dateien tritt der Fehler nicht mehr auf (habe es gerade im C64-Mode von x128 und mit x64sc probiert). Der Farbverlauf geht komplett über den Text "MegaPatch" und rechts sind alle 3 Zeilen einfarbig und komplett zu lesen.
Also: Kein Fehler im Source Code vorhanden.
Gruß
Werner
Ich hatte mich schon gewundert, wie ausgerechnet in einem Bild jetzt so ein Fehler herkommen soll
Pusti64
Prima! 
Pusti64
Ich hatte mich schon gewundert, wie ausgerechnet in einem Bild jetzt so ein Fehler herkommen soll
Der Fehler in dem Bild ist nicht nur in dem Bild, er war bei insgesamt 5 Installationen von meinem 1. selbst erstellten MP3-64-Setup unabhängig voneinander unter verschiedenen Voraussetzungen (xscpu64, x64sc, x128 (im C64-Modus)) genaus so wie in dem Bild zu sehen vorhanden. Deshalb ging ich davon aus, es muß irgendwas mit den Setup-Dateien nicht stimmen.
Das Bild ist übrigens so entstanden:
Mein altes MP3-64 (2000) gestartet und von dieser Boot-Diskette das Programm "GEOS64.TaskMse" gestartet. Dieses Programm erlaubt mir an fast jeder Stelle (soweit ich weiß funktioniert das nur in der MP3-Datei-Auswahl-Box nicht, da die Dateiauswahl und die ScreenShot-Funktion den gleichen Speicherbereich benutzen) über gleichzeitiges drücken der rechten und linken Maustaste den TaskManager zu öffnen. Darin befindet sich die Screenshot-Funktion.
Also jetzt das Setup der neuen MP3-64-Version (vom ersten Assemblier-Versuch) gestartet. Fehler war zu sehen, TasManager aktiviert und ScreenShot erstellt (ist dann ein GeoPaint-Dokument). Dann TaskManager beendet und Setup abgebrochen.
Das Paint-Dokument in ein D64 kopiert und mit D64Lister unter Windows dieses Paint-Dok angesehen. Hier sieht man das komplette Bild und kann zwischen "Monochrom" und "Farbdarstellung" (Monochrom an oder aus) umschalten. Dies entspricht 1:1 der Funktion "Farbe an" und "Farbe aus" in GeoPaint. Dort ist genau das zu sehen, was ich in meiner Fehlermeldung ( GEOS MegaPatch 64/128 als SourceCode verfügbar! ) beschrieben habe.
Im D64Lister dann das GeoPaint-Dok als BMP gespeichert und anschließend mit IrfanView das BMP als jpg gespeichert fürs Forum.
Wenn Du willst hänge ich das GeoPaintDok von der MP3-Screenshot-Funktion hier mal an. Dann kannst Du es Dir selber ansehen .
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).
Nun, bei mir war ja die Farbe komplett nach rechts verschoben .....
Wie und warum das passiert ist, kann ich nicht sagen. Es gab keine Fehlermeldungen beim Assemblieren, beim Erstellen des Setups und beim Kopieren der Dateien auf ein D81.
Der 2. Assemblier-Versuch hat dann ja hier geklappt, zumindest ist mir noch nichts aufgefallen .
Gab noch eine Ergänzung im Editor der auch 64Net als "RTC"-Gerät akzeptiert (kann ich natürlich nicht testen).
Jetzt wo Du es sagst, erinnere ich mich. Das dürfte aber das einzige neue gewesen sein. Vorher mußte man zum Lesen der PC-Uhr immer das Auto_Exec dafür starten...
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.
Das wundert mich jetzt wieder. Das gab es es doch schon vor MP3 für Geos 128. Hier mal ein Text von W.Grimms Webseite, die nun wohl endgültig nicht mehr erreichbar ist. Teilweise ist sie hier noch zu finden ( https://web.archive.org/web/20…5/http://c64.webgrimm.de/ ). Hier dann auf "Geos-Programme" klicken. Dort ist zu lesen:
Ich hatte es ja schonmal hier erwähnt. Die dazugehörenden Dateien sind übrigens auf der F64-Wolke im Geos-Software-Bereich in der GUC-Geothek auf Diskette 6.11a zu finden.
Gruß
Werner
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.
Bedeuted das etwa, dass da eventuell noch "Reserven" sind?
Pusti64
