Hallo Besucher, der Thread wurde 202k mal aufgerufen und enthält 1222 Antworten

letzter Beitrag von darkvision am

GEOS MegaPatch V3 Release 2018

  • Das hört sich ja Erstmal ganz gut an.............


    Aber ich sehe das eher Kritisch, und als sehr Unsicher,

    auf Grund meiner Eigenen Erfahrungen mit meiner U1541................


    Hintergrund:


    Ich habe seit neusten, also seit ich die letzte neue FW für die U1541 eingespielt habe,

    probleme, wenn ich den Inhalt der Reu abspeichern will.

    Manchmal funktioniert das speichern des Reu-Inhaltes einfach nicht.

    Fragt mich nicht warum.......

    Die 1541 Ultimate arbeitet und speichert scheinbar ganz Normal,

    und dann hängt sich plötzlich alles auf.

    Das Reu Image wird zwar erstellt, hat aber scheinbar keinen Inhalt,

    also hat die Größe 0

    Die Taster an der U1541 Reagieren dann auch nicht mehr.

    Nur noch aus & Einschalten hilft............

    Und dann ist der Inhalt der Reu Natürlich weg..............:poop:

    Seitdem mache ich immer 2-3 Kopieen vom Reu-Inhalt, auf meinen Stick


    Evl. hat ja noch jemand das selbe Problem, wie ich??? Dann Bitte melden!!!


    Is alles erst seit der letzten Firmware.........


    Zum Glück sind USBsticks heutzutage groß genug, sodaß man gleich mehrere Kopieen der Reu darauf abspeichern kann..........

    Nur Für den Notfall, und den hatte ich ja schon mehrere Male..............


    Was für eine Endlose Arbeit, wieder alle Applikationen,ACCs, Fonts

    (und was weiß ich noch alles) wieder in die Reu zu kopieren..................

    Und ich weiß nie, ob das Speichern das nächste mal klappt oder nicht...........


    Trotz allem, wenn das richtig funktionieren würde, mit der Batch-Datei, wäre das schon eine Tolle Sache.................


    Grüße

  • Hallo,


    ich habe mich mal mehr oder weniger intensiv mit dem Assemblieren vom aktuellen MegaPatch 64/128 (Stand 13.09.2021) befasst. Dabei sind mir ein paar Sachsen aufgefallen:


    1.

    Auf Area6510 im Verzeichnis \src\megapatch64_128\current befindet sich die Datei "README.md". Sie beschreibt das Vorgehen zum erstellen von MP3. Diese Datei scheint nicht mehr aktuell zu sein ;-) :


    - unter "Szenario #1" sind die minimalen Größen der einzelnen Laufwerke genannt. Zumindest bei Lfw C: scheint es etwas wenig zu sein...


    - unter "###MakeInstall" muss es jetzt heißen: "MakeSetup..." und nicht mehr "MakeInstall..."


    - unter "###StartMP:" sind noch die alten Dateinamen aufgeführt. Diese sollten jetzt "SetupMP..." lauten



    2.

    Unter MP3-128 läßt sich nur MP3-128 problemlos assemblieren. Bei MP3-64 gibt es einen Fehler "Kann 'MP_MakeKernal' nicht starten". MegaAssembler zeigt in der Kopfzeile noch an: "sSStick64.2" "P:2" "S1"


    Ich habe mir das mal angesehen. Die Datei 'MP_MakeKernal' hat beim Assemblieren das Bildschirmflag "nur Geos 64" ($80) aktiv. Damit ist die Ursache klar ;-) .


    3.

    Unter MP3-64 lassen sich sowohl MP3-64 als auch MP3-128 problemlos erzeugen. Die Datei 'MP_MakeKernal' bekommt hier das Bildschirmflag "40 und 80 Zeichen" ($40). Deshalb gibt es hier keine Probleme.


    Ob das Ändern des Bildschirmflags bei 2. etwas bringt oder noch mehr Probleme macht, habe ich nicht getestet. Aber wenn man MP3-64 unter MP3-128 erzeugt, dürfte das schneller gehen, da da mit 2 MHz gearbeitet wird...



    Ansonsten habe ich bisher keine Probleme mit dem "neuen" (13.09.2021) MP3 festgestellt.



    Wenn gewünscht, kann ich die von mir erstellten (inoffiziellen) Installationsdateien für MP3-64/128 hier als D81 zur Verfügung stellen...


    Gruß

    Werner

  • Ob das Ändern des Bildschirmflags bei 2. etwas bringt oder noch mehr Probleme macht, habe ich nicht getestet. Aber wenn man MP3-64 unter MP3-128 erzeugt, dürfte das schneller gehen, da da mit 2 MHz gearbeitet wird...

    Ich assembliere die 128er Version unter MP64... so herum gibt es keine Probleme... und die 2MHz... naja, bei VICE/WARP-Modus mit 2000-4000% auf einem RAMLink-Laufwerk spielt das kaum eine Rolle...

    Aber danke fürs testen, mal sehen ob ich da noch was ändere... evtl. nur das Bildschirmflag ändern, wobei dann ggf. halt nur die linke hälfte des Bildschirms genutzt wird. Für MakeKernal aber kein Problem...

    Wenn gewünscht, kann ich die von mir erstellten (inoffiziellen) Installationsdateien für MP3-64/128 hier als D81 zur Verfügung stellen...

    Bitte gerne...................

    Die Version behebt ja dann nur den Bug mit SetNextFree... der in den letzten 20Jahren keinem aufgefallen ist und der ein sehr konstruiertes Szenario benötigt, damit der Fehler überhaupt zum tragen kommt. Deswegen MP3 neu installieren macht keinen Sinn, ausser man hat am installieren selbst viel Spaß ;)

  • Ich lade es mal herunter, weil ich ohnehin in den nächsten Tagen meine MP3 Version aktualisieren wollte... da bietet es sich natürlich an, die aktuelle zu nehmen.

  • Hab ich korrigiert...

    2.

    Unter MP3-128 läßt sich nur MP3-128 problemlos assemblieren. Bei MP3-64 gibt es einen Fehler "Kann 'MP_MakeKernal' nicht starten". MegaAssembler zeigt in der Kopfzeile noch an: "sSStick64.2" "P:2" "S1"


    Ich habe mir das mal angesehen. Die Datei 'MP_MakeKernal' hat beim Assemblieren das Bildschirmflag "nur Geos 64" ($80) aktiv. Damit ist die Ursache klar ;-) .

    Ich hab das Flag auch mal auf $40 gesetzt. Für GEOS64 ist das ja uninteressant, damit läuft der Vorgang jetzt aber auch unter MP128 durch...

    Ansonsten habe ich bisher keine Probleme mit dem "neuen" (13.09.2021) MP3 festgestellt.

    Kein Problem, aber MakeSetup128 war auch auf "40Z" eingestellt, MakeSetup64 dafür auf 40+80Z. Hab ich auch mal angepasst. Allerdings nutzt das Programm MakeSetup64 Grafikroutinen, die dann am 128er im 80Z-Modus nur die linke Bildhälfte beschreiben. Für den Zweck des Programms spielt das aber keine Rolle...


    Vom Gefühl her dauert es am 128er unter VICE/WARP-Mode ähnlich lange, bis die Versionen erstellt sind. VICE läuft dann hier nur mit ca. 2000%, aber evtl. gleicht das die 2MHz im 128er-Modus wieder aus. Für mich also kein Vorteil, da nutze ich lieber die RAMLink im 64er-Modus von VICE.


    Beim kopieren der Dateien musste ich allerdings TopDesk verwenden, da die Disk#4 mit dern Laufwerkstreibern mehr als 144 Dateien enthält, und dualTop128 die nicht kopieren kann.

    Beim kopieren der Dateien ist mir dann aufgefallen, das bei sehr langen Dateinamen TopDesk in dem roten Kopierstatus-Feld bei der Anzeige des Namens außerhalb des Feldes schreibt. Bei sehr langen Namen (z.B. "WWWWWWWWWWWWWWWW") schreibt die Routine dann sogar bis in das "GEOS"-Feld...

    Entweder müsste man den Text "Kopiere ggf. Ersetze" in "Kopiere/Ersetze" ändern/ggf. weiter einkürzen oder die Textausgabe über ":rightMargin" in $0037 begrenzen und später wieder zurücksetzen.

    Kopiert man nur eine Datei, dann tritt das Problem nicht auf, da hier nur "Kopiere <name>" angezeigt wird.

    Nur im 80Z-Modus getestet... TopDesk128 hat zwar "40+80Z" als Flag gesetzt, startet aber immer im 80Z-Modus...

  • Hab ich korrigiert...

    Ich hab das Flag auch mal auf $40 gesetzt.

    MakeSetup64 dafür auf 40+80Z. Hab ich auch mal angepasst.

    Danke ;-)


    Beim kopieren der Dateien musste ich allerdings TopDesk verwenden, da die Disk#4 mit dern Laufwerkstreibern mehr als 144 Dateien enthält, und dualTop128 die nicht kopieren kann.

    Beim kopieren der Dateien ist mir dann aufgefallen, das bei sehr langen Dateinamen TopDesk in dem roten Kopierstatus-Feld bei der Anzeige des Namens außerhalb des Feldes schreibt

    Ist bekannt/gemeldet (siehe DT128-Native-Copy Test für MegaPatch128 ) und ein Lösungsvorschlag existiert auch ...


    Gruß

    Werner

  • Ist bekannt/gemeldet (siehe DT128-Native-Copy Test für MegaPatch128 ) und ein Lösungsvorschlag existiert auch ...

    Danke... Hatte ich mir fast gedacht... :)

    Dann ist das auch erledigt... Ich teste noch ob ich beim Bildsystem von MP3 die temp.Dateien am Ende standardmäßig löschen soll, aktuell steht die Option noch auf FALSE... Dann lade ich die neuen Source-Disketten hoch... Am Code hat sich sonst nichts geändert...

  • Kurzer Zwischenstand:

    Wollte eigentlich die neuen Source-Disks hochladen, aber ich dachte mir wenn ich schon das README überarbeite, dann teste ich auch mal Szenario#2, also BUILD nur mit Disk-Laufwerken.


    Unter einem reinen GEOS 2.0 mit 3x1581 gibt es mit MegaAss ein Problem, denn der DiskWechsel wird zwar angezeigt, aber weil der Bildschirm während dem assemblieren "bereinigt" wird sieht man die DiskWechsel-Dialogbox nicht (Vorder- und Hintergrundfarbe sind gleich).


    Hab das jetzt mal angepasst... und am 64er läuft damit unter GEOS 2.0 der BUILD durch... man muss halt ab&zu Disketten wechseln, aber Hey... das ist ja nichts neues :D


    Ich will das jetzt auch nochmal mit dem 128er testen... 40/80Z... danach sehen wir weiter.


    Im LEMON-Forum hab ich mich auch wieder mal mit GateWay beschäftigt... wenn ich mich noch recht erinnere gibt es da noch einen Bug in MP3 mit der Dateiinfo-Funktion in GateWay: Das Icon wird nicht korrekt angezeigt. Mal sehen ob mir dazu noch was einfällt...

  • Hallo,


    am 03.10. wurde ein neuer Quellcode für MP3-64/128 veröffentlicht, mit dem weitere Fehler behoben werden. U.a. kann MP3-64 und MP3-128 jetzt problemlos von jedem System (MP-64 oder MP-128) aus assembliert werden.


    Ich habe mich mal daran gemacht, die neue Version auf meinem C128 DCR ohne irgendwelche Beschleuniger (SCPU, Chamäleon, o. ä.) zu assemblieren. Dabei habe ich aus MP3-128 und MP3-64 heraus jeweils beide Systeme erstellen lassen. Meine Konfiguration (für das assemblieren): A: RAMNative, B: RAMNative, C: FD1581, D: SD2IEC Native. Benutzt habe ich jeweils Szenario #1 aus der Anleitung zum Quellcode.

    Es müssen je 2 Durchläufe durchgeführt werden. Der erste dauerte ca. 12 - 20 Minuten (wurde jeweils handgestoppt). Der 2. Durchlauf erfolgte unbeobachtet und dauerte zwischen ca. 8 und ca. 10 Stunden. Hier nutzte ich die Zeit, die MegaAssembler nach dem jeweilgen 2. Durchlauf angezeigt hat. Das Ergebnis zeigt die Summe der Zeiten aus den je 2 Durchläufen (ganz schöner Aufwand ;-) ... ).


    aus MP3-128 heraus MP3-128 assembliert: 8 Stunden 55 Minuten

    aus MP3-128 heraus MP3-64 assembliert: 8 Stunden 38 Minuten

    aus MP3-64 heraus MP3-128 assembliert: 10 Stunden 14 Minuten

    aus MP3-64 heraus MP3-64 assembliert: 10 Stunden 7 Minuten



    Jetzt geht's ans Installieren und Testen ....

    Habe bisher nur mal schnell einmal die 128er- und 64er Version installiert und gestartet. Dabei gab es keine Probleme.


    Wer auch probieren will, anbei die neu erstellten Setup-Programme. Achtung: Keine "offiziellen" Binäries.


    Gruß

    Werner

  • Das Ergebnis zeigt die Summe der Zeiten aus den je 2 Durchläufen (ganz schöner Aufwand ;-) ... ).

    Jetzt verdoppele mal den Aufwand, dann siehst Du warum ich nicht sofort immer neue Builds einstelle. Deutsch/Englisch/64/128 und das ganze dann 1xStandard und 1xKernaltreiber... sind jedesmal 8 builds... unter VICE dauert das gefühlt je Build ca. 20min. Dann die passenden Binaries auf die SETUP Disketten verteilen, und dann jeden Build zumindest 1x installieren...


    Wenn man jetzt sieht wie lange das an einem Stock-C64/C128 dauert ist glaub ich klar das man dafür einen Turbo oder VICE benötigt. Mit einem U64 geht das bestimmt schneller, ist für mich aber keine Option. VICE ist da viel bequemer.


    Was mich wundert: Der 128er ist nur ca. 15% schneller als der C64 ? Ich dachte der hat 2MHz ?

    Aber ich glaube bei den ganzen RAM-Zugriffen schaltet die REU auf 1MHz, und da hier fast die ganze Zeit auf Disk zugegriffen wird kommen die 2MHz nicht voll zur Geltung. Hast Du eine CREU verwendet ?


    Die 64er Version hab ich eben auch auf meinem real-C64 getestet. Gab nur ein "Problem" mit dem Start von der RAMLink wenn diese keine Adr. 8-11 hat (in meinem Fall #16): Dabei wird der Inhalt einer RAMDisk (Bei mir Laufwerk B:) bei jedem Neustart gelöscht. Ändere ich die Adresse auf #11 oder starte von einem SD2IEC dann bleibt der Inhalt erhalten.

    Ich müsste mal einen deutlich älteren Build raussuchen ob das schon immer so war... aktuell hat sich da nichts geändert. Eigentlich sollte man ja nur von 8-11 starten...


    Die 128er Version hab ich schon unter VICE128 installiert. Der TaskManager funktioniert mit TD128 wieder wie er soll... zumindest ist mir da nichts aufgefallen.


    Mal sehen ob ich am WE dazu komme die restlichen sechs builds zu assemblieren.

  • Was mich wundert: Der 128er ist nur ca. 15% schneller als der C64 ? Ich dachte der hat 2MHz ?

    Aber ich glaube bei den ganzen RAM-Zugriffen schaltet die REU auf 1MHz, und da hier fast die ganze Zeit auf Disk zugegriffen wird kommen die 2MHz nicht voll zur Geltung. Hast Du eine CREU verwendet ?

    Davon gehe ich auch aus. Und der Zugriff auf die FD1581 dürfte auch nur mit 1 MHz erfolgen...


    PS: Werner hat bestimmt eine 1541 Ultimate II+ für die REU Emulation benutzt. Aber auch die nutzt nur 1 MHz für die REU.

  • Davon gehe ich auch aus. Und der Zugriff auf die FD1581 dürfte auch nur mit 1 MHz erfolgen...

    Alle Disk-Laufwerke werden nur mit 1MHz angesprochen...

    Ausnahme: RAMLink-, RAMDisk- und HD-Parallelport mit 2MHz. Aber beim REU-Transfer werden die RAMDisk-Treiber dann doch ausgebremst, da der Zugriff über die REU-Register immer mit 1MHz erfolgt.


    Wenn ich da nichts übersehen habe müsste RAMLink am 128er schneller gehen als ein RAMDisk-Laufwerk. Aber bei 8+h spielt das kaum eine Rolle.

  • Jetzt verdoppele mal den Aufwand, dann siehst Du warum ich nicht sofort immer neue Builds einstelle.

    Das war auch eine Motivation für mich, das mal wie beschrieben durchzuziehen ;-) . Es ist ein enormer Aufwand der da getrieben werden muß !!!!

    Das kann man nicht hoch genug schätzen. Danke!


    Klar, mit den älteren Vice-Versionen (vor GTK-Vice) kann man die Geschwindigkeit zur Erstellung enorm steigern. Wollte aber auch mal zeigen, wie sowas am realen C64/128 aussehen würde...


    PS: Werner hat bestimmt eine 1541 Ultimate II+ für die REU Emulation benutzt.

    Genau, die eine RAM (D:) ist 12 MB, die andere (A:) 3,x MB.


    Gruß

    Werner