GEOS MegaPatch V3 Release 2018

Es gibt 1.222 Antworten in diesem Thema, welches 218.416 mal aufgerufen wurde. Der letzte Beitrag (2. Juli 2025 um 17:17) ist von darkvision.

  • Ich habe jetzt im Vice eine Konfiguration erstellt bei der die 1581 Laufwerk 8 ist.
    Jetzt läuft es tatsächlich.

    War meine Vermutung richtig :)

    Man kann die Dateien oder die Diskette auch von einem anderen Laufwerk starten, man muss dann aber die Diskette vor dem booten erst wieder "bootfähig" machen.

    Dazu unter GEOS auf dem neuen Laufwerk "GEOS.MakeBoot" starten und anschließend (wenn sich Adresse oder Laufwerkstyp geändert haben) den GEOS.Editor auf dem *neuen* Laufwerk starten und die Konfiguration einfach nur speichern. Danach kann man auch vom neuen Laufwerk/Adresse starten.

    Der Vorgang ist also immer erforderlich wenn sich Laufwerkstyp oder die Adresse des Laufwerks ändern.

  • Hab einen neuen Bitte melde dich an, um diesen Link zu sehen. hochgeladen (20241020).

    Damit sollten DNPs auf einem SD2IEC mit einem Soft-Schreibschutz (geändertes DOS-Flag) wieder funktionieren (Disk öffnen).

    Auch ein Fehler in Verbindung mit GEOS-Disketten und NativeMode wurde beseitigt (Verzeichnis öffnen).

    Das Problem mit schreibgeschützten DiskImages im SD2IEC ist kein GEOS/MP3-Problem, sondern ein Bitte melde dich an, um diesen Link zu sehen.. Daher gilt: Nicht auf schreibgeschütze DiskImages schreiben. Da das aber auch MP3 beim booten versucht kann man von solchen DiskImages nicht starten. Letzteres lässt sich evtl. lösen, da müsste ich mir die Stellen wo versucht wird zu schreiben mal genauer anschauen.

  • Da das aber auch MP3 beim booten versucht kann man von solchen DiskImages nicht starten. Letzteres lässt sich evtl. lösen, da müsste ich mir die Stellen wo versucht wird zu schreiben mal genauer anschauen.

    Sorry, dem konnte ich nicht widerstehen. Ich habe genau das gerade mal versucht, allerdings vor dem geplanten Update auf das aktuelle MP3. Was soll ich sagen, es hat zu 99,9% korrekt gestartet. DTopdesk beschwert sich am Ende, dass er die Programmdatei "DESK TOP" nicht fände. Höchsrwahrscheinlich bei den Versuch, die zum Schreiben zu öffnen.

    Nun, da kann ich auf "Abbrechen" klicken und habe dann einen weitgehend funktionsfähigen DESK TOP vor mich.

    Zugegen, im Gegensatz zu Werner habe ich auf dem MP3 DNP lediglich das MP3, DTopdesk (auch das Update steht noch aus) und einige Berkeley Applikationen drauf. Und natürlich Mega Asembler. Aber keine Autostaerts, die MP3 nicht von Haus aus mitbringt.

    Edit: Natürlich mit meiner Firmware, nicht mit der bzgl. Schreibschutz kaputten von Ingo.

    ---
    Meine Github-Projekte: Bitte melde dich an, um diesen Link zu sehen. Vice 3.2 Improved: Bitte melde dich an, um diesen Link zu sehen.
    1541 Ultimate II / Ultimate 64 Firmware Releases: Bitte melde dich an, um diesen Link zu sehen.
    1541 Ultimate II Update instructions: Bitte melde dich an, um diesen Link zu sehen.

  • Nun gut, auf einer wirkungsvoll schreibgeschützten DNP kann Geos nichts kaputt machen, also habe ich meine Firmware da gerade mal ein Validate machen lassen mit dem alten DTopdesk. Erst wiederholte Schreibschutzfehlermeldung und dann leeres Fenster...

    Nachtrag: Fehlt noch, das auszuprobieren, nachdem DTopdesk und MP3 geupdated worden sind. MP3 lädt weiterhin problemlos, DTopdesk bringt den Schreibschutzfehler nicht mehr beim Start. Aber wenn ich DTopdesk nach Basic beenden will, sprich Geos beenden. Dabei macht es keinen Unterschied, ob ich das Image mit dem FAT Attribut READ ONLY versehe, oder aber den "EL:$" Schutz verwende.

    ---
    Meine Github-Projekte: Bitte melde dich an, um diesen Link zu sehen. Vice 3.2 Improved: Bitte melde dich an, um diesen Link zu sehen.
    1541 Ultimate II / Ultimate 64 Firmware Releases: Bitte melde dich an, um diesen Link zu sehen.
    1541 Ultimate II Update instructions: Bitte melde dich an, um diesen Link zu sehen.

    Einmal editiert, zuletzt von markusC64 (21. Oktober 2024 um 18:16)

  • Aber wenn ich DTopdesk nach Basic beenden will, sprich Geos beenden. Dabei macht es keinen Unterschied, ob ich das Image mit dem FAT Attribut READ ONLY versehe, oder aber den "EL:$" Schutz verwende.

    DTopDesk sucht die Programmdatei, versucht die Daten zu speichern. Bei der alten Firmware kommt da "72,DISK FULL". Es findet aber keine Fehlerauswertung statt, daher auch keine Fehlermeldung.

    Danach sucht DTopDesk nochmals nach der Programmdatei um das VLIR-Modul für "GEOS beenden" nachzuladen. Hier greift dann wohl wieder der hartnäckige Fehler, der dann auch beim lesen des Verzeichnisses noch einen Fehler zurückgibt, der dann zur Dialogbox "Nochmal suchen?" führt. Das blinken signalisiert "$72,DISK FULL".

    Es geht aber wenn RAM-DeskTop aktiv ist, da dann nicht nach der Programmdatei gesucht werden muss um das Modul nachzuladen. Ist man dann im BASIC kann man den Fehlerkanal auslesen. Auch hier "$72,DISK FULL".

    markusC64 : Hast Du in Deiner Firmware schon so angepasst, das nach dem senden des Status der Fehlerstatus gelöscht wird oder ist das noch so das nur bei Read/Write was gelöscht wird? Bei letzteres würde ich das mal ergänzen, denn GEOS fragt den Fehlerkanal nicht 2x ab, daher wäre das eine gute Stelle, sofern es das Timing nicht zu sehr stört.

    Wenn es aber sonst mit dem booten von MP3 funktioniert, dann dürfte in MP3 ein Test ob überhaupt gespeichert werden muss, ausreichend sein um das auch bei ältere SD2IEC-Firmware hinzubekommen. Man muss dann halt vor dem Schreibschutz MP3 1x mit den richtigen Einstellungen starten und darf dann eigentlich auch die Konfiguration nicht ändern.

    Werde ich mir irgendwann mal anschauen müssen...

  • Hast Du in Deiner Firmware schon so angepasst, das nach dem senden des Status der Fehlerstatus gelöscht wird oder ist das noch so das nur bei Read/Write was gelöscht wird?

    Letzteres. Muss mir erst den Speeder nochmal genauer anschauen für die ausstehenden Optimierungen.

    ---
    Meine Github-Projekte: Bitte melde dich an, um diesen Link zu sehen. Vice 3.2 Improved: Bitte melde dich an, um diesen Link zu sehen.
    1541 Ultimate II / Ultimate 64 Firmware Releases: Bitte melde dich an, um diesen Link zu sehen.
    1541 Ultimate II Update instructions: Bitte melde dich an, um diesen Link zu sehen.

  • Gerade erst gesehen: Es gibt eine MP64 Version, welche beim booten KEINEN Fastloader nutzt? Die sollte dann auf dem Kung Fu Flash 2 lauffähig sein. 1MB REU ist ja vorhanden. Kann das jemand bestätigen?

  • Gerade erst gesehen: Es gibt eine MP64 Version, welche beim booten KEINEN Fastloader nutzt? Die sollte dann auf dem Kung Fu Flash 2 lauffähig sein. 1MB REU ist ja vorhanden. Kann das jemand bestätigen?

    Wo Du immer diese "Weisheiten" aufgreifst ist mir schleierhaft. Ja, es gibt eine MP3-Version die *GAR KEINEN* internen FastLoader verwendet, dennoch muss das Laufwerk über den seriellen Bus erreichbar sein und Block-Befehle unterstützen. Ich fürchte das ist beim KFF nicht gegeben.

    P.S. was mit einem KFF2 gehen sollte ist der REU-Support, also kann man das KFF2 als REU für MP3 verwenden. Wenn ein REU-PreLoad möglich ist kann man da ggf. ein MP3 drauf installieren, aber ohne extra Laufwerk hat man dann nur wenig Spaß damit. Ohne PreLoad müsste man ein Prog schreiben, das die REU aus einem VICE-Image befüllt und dann FBOOT ausführt, das dann MP3 aus der KFF2-REU startet. Aber daran werde ich mich nicht versuchen.

  • Es tut mir leid, wenn ich dich mit meinem Posting verärgert habe. Sorry!

    Das hast Du falsch verstanden... mich würde wirklich interessieren wo das steht. Die Version gibt es ja schon länger und wurde nie so beworben das es nur beim booten keinen FastLoader verwendet. Fakt ist das es FastLoader wie JiffyDOS unterstützt, aber es muss dennoch ein Laufwerk sein.

  • Sitzt das Problem wieder vor dem Bildschirm?

    Ich wollte die Installationdateien von MP64 auf 2 D64 ziehen. Sollte ja kein Ding sein. Dabei ist DAS pasiert. Es passiert jedes mal:

    Bitte melde dich an, um diesen Anhang zu sehen.

  • Sitzt das Problem wieder vor dem Bildschirm?

    Sieht fast so aus :wink: .

    Dir ist aber schon augefallen, daß das Kopieren auf eine 1541 (siehe dein Bild (rechts) ) nicht funktionieren kann? Dein Bild sagt, Du hättest alles auf eine Disk kopiert. Die Dateien ".1" und ".3" haben im Original zusammen über 700 Blöcke. Was paßt nochmal auf eine 1541-Disk :wink: ?

    Gruß

    Werner

  • Sitzt das Problem wieder vor dem Bildschirm?


    Ich wollte die Installationdateien von MP64 auf 2 D64 ziehen. Sollte ja kein Ding sein. Dabei ist DAS pasiert. Es passiert jedes mal:

    Ich vermute eher einen Fehler in DirMaster. Auffällig ist das die Dateien 1+3 eine Dateigröße haben, die um genau 256 Blocks kleiner ist. Evtl. kann Dirmaster keinen VLIR-Datensatz kopieren, der länger als 256 Blocks ist bzw. es tritt ein Überlauf auf.

    Unter GEOS2 lassen sich die Dateien aber problemlos kopieren, hab zum testen zwei RAMDisk1541 eingerichtet:

    Bitte melde dich an, um diesen Anhang zu sehen. Bitte melde dich an, um diesen Anhang zu sehen.

    Tipp: Setup+1+2+4+5 auf ein D64, Setup.3 auf ein zweites D64. Ich hab es zwar länger nicht mehr getestet, aber das SETUP fordert dann beim kopieren der Laufwerkstreiber nach dem zweiten D64. Am SD2IEC könnte man dazu eine SWAPLIST anlegen und per Knopfdruck dann das D64 wechseln.

  • Danke an euch beide! Ja, die Fileverteilung hatte ich auch so geplant. Aber das hatte sich dann ja schon vorher erledigt. Ich schreibe den Jungs von Style64 mal einen Bugreport.

  • Ich schreibe den Jungs von Style64 mal einen Bugreport.

    DirMaster unterstützt ja laut Website auch CVT... nur entpacken? oder auch packen?

    Falls packen auch geht, teste doch mal was bei Setup.1 und Setup.3 rauskommt. CONVERT hatte damals auch nur Support für max. 255 Blocks. Wenn das packen und entpacken dann nicht wieder die gleiche Dateigröße ergibt, dann wäre das auch noch ein Problem. DirMaster müsste dann auch G98 unterstützen.

  • Ich vermute eher einen Fehler in DirMaster

    Korrekt. Habe es probiert. Datei Bitte melde dich an, um diesen Link zu sehen. und Bitte melde dich an, um diesen Link zu sehen. extra je auf ein D64 kopiert. Größe stimmt nicht.

    DirMaster unterstützt ja laut Website auch CVT... nur entpacken? oder auch packen?

    Beides. Von G98 weiß das PRG nichts.

    Gruß

    Werner

  • Beides. Von G98 weiß das PRG nichts.

    OK, dann wäre das aber der nächste Bug, denn 1+3 nach CVT und wieder zurück dürfte dann eine defekte Datei liefern. Vielleicht steckt da auch ein GEOS -> CVT -> kopieren -> CVT -> GEOS-Vorgang dahinter. Wenn die Dateigröße dann wie beim kopieren um 256 Blocks kleiner ist, dann wäre das der Beweis dafür.

    Ich schreibe den Jungs von Style64 mal einen Bugreport.

    Obiges könnte man im BugReport dann evtl. erwähnen. Bei bedarf kann ich Infos zum G98-Format beisteuern.