GeoDOS V2 Release 2018

Es gibt 313 Antworten in diesem Thema, welches 59.387 mal aufgerufen wurde. Der letzte Beitrag (11. Juni 2025 um 12:23) ist von darkvision.

  • Dann läuft die %-Anzeige auch deutlich schneller durch? 16Mb sollten selbst bei 2MHz am C128 ca.8-14min. benötigen. Falls es nur ein paar Sekunden sind... dann kommen die Befehle am 128er nicht am SD2IEC an...

    Jetzt wo Du es sagst, gefühlt keine Minute.
    Auch wenn die DNP's kleiner waren (1024 KB und 4096 KB), ist es selbst für ein D81 zu schnell.

    Gruss C=Mac.

  • Dann läuft die %-Anzeige auch deutlich schneller durch?

    habe es mit einem DNP mit 191 Blocks probiert. Störe mich etwas an den Größen-Angaben. Kann man das nicht mal vereinheitlichen? Im Editor steht 12208 kB und in geoDos 12244 kB oder so. Das verwirrt doch nur ....

    Während der Erstellung blinkt die Aktivitäten-LED in verschiedenen Intervallen. Sieht so aus als passiert da was. Erstellen dauert nur ca. 25 Sekunden. Beim Formatieren kommt dann gleich die Fehlermeldung und Error-LED blinkt. Auf SD-Karte kommt nichts an.
    Error-Kanal kann ich nicht abfragen. Nachdem aus GeoDOS nach Basic geprungen wird, kommt da die normale Einschalt-Meldung vom SD2IEC (73, ...)

    Falls es nur ein paar Sekunden sind... dann kommen die Befehle am 128er nicht am SD2IEC an...

    Aber irgendetwas passiert am SD2IEC (siehe oben)...

    Gruß
    Werner

  • Ich hab mir eben mal das C128-Assembler-Handbuch angeschaut.

    Da soll man SETBNK=$FF68 vor dem Aufruf von OPEN ausführen. Damit legt man wohl die Speicherbank für den Dateinamen fest. Ich meine das müsste unter GEOS AKKU=1/XREG=1/JSR SETBNK sein. Ich baue den Befehl mal ein... selber testen kann ich es aber nicht. Könnte aber erklären warum es am 128er evtl. nicht funktioniert.

  • Ich hab mir eben mal das C128-Assembler-Handbuch angeschaut.

    Schau mal hier: Bitte melde dich an, um diesen Link zu sehen.
    Da gibt es den Source-Code für die C64er und C128er Version von uIEC-Switch. Da steht drin, dass genau das (SETBnk) nicht funktioniert...

    Ich mag das Programm nicht sonderlich, da es nur ein SD2IEC erkennt, nur 3 Laufwerke unterstützt und der Wechsel zwischen unterschiedlichen Images nicht funktionieren kann. Da müßte ja für 1541, 1571 und 1581 das DOS-File für die MR-Emulation gewechselt werden. Und das ist nirgendwo im Code zu finden .... :wink: .

    Gruß
    Werner

  • Da gibt es den Source-Code für die C64er und C128er Version von uIEC-Switch. Da steht drin, dass genau das (SETBnk) nicht funktioniert...

    Stimmt. Da wird wohl etwas getrickst im GEOS128-Kernal... hab mir das unter VICE angeschaut. SETBNK besteht wohl nur aus zwei sta/stx-Befehlen, die kann ich auch "von Hand" nach $C6/$C7 schreiben. Danke für den Tipp!

  • Hab's nochmal versucht (D81).

    Die Prozentanzeige braucht nur ca. 12s, drei Sekunden später erfolgt die Fehlermeldung.
    Während der Prozentanzeige blinkt die rote (schreib) LED in unregelmässigen Abstände.
    Den Fehlerkanal kann ich leider nicht auslesen, beim Sprung in Basic oder Reset wird das SD2IEC wieder angesprochen und der Fehler gelöscht.

    Gruss C=Mac.

  • Ich hab einen neuen Bitte melde dich an, um diesen Link zu sehen. eingestellt. Das ist erst mal ein erster Versuch das Problem mit dem 128er und SD2IEC/CreateImages zu beheben, sonst keine Änderungen.

  • Und funktioniert, jedenfalls am C128. :thumbup:
    Am C64 hab ich es noch nicht überprüft, da ging es vorher schon.

    Getestet mit D81 und DNP (4 MB und 1 MB).

    Gruss C=Mac.

  • Am C64 hab ich es noch nicht überprüft, da ging es vorher schon.

    Muss man nicht prüfen, da ist nur ein Test auf C128 eingebaut und wenn ja dann wird die Bank korrekt gesetzt. Am C64 wird da kein neuer Code ausgeführt, da ist alles beim alten.

    Uff... Dachte schon das könnte länger dauern :puhh:

  • Ich hab einen neuen SnapShot

    Irgendwas scheint da auf Area6510 nicht zu stimmen. Habe vor einigen Minuten das neue GD-D81 heruntergeladen. Hier kamen nur ca. 30 kB an. Hatte ich irgendwann die letzten Tage schonmal bei einem anderen D81.
    Wenn ich die gesamte Area6510 herunterlade ist alles i.O. Erneuter versuch eben (D81) : auch ok. Seltsam, seltsam.

    Werde das nachher mit dem neuen GeoDOS-Snapshot auch nochmal probieren (191 Track DNP)....

    Gruß
    Werner

  • Irgendwas scheint da auf Area6510 nicht zu stimmen. Habe vor einigen Minuten das neue GD-D81 heruntergeladen. Hier kamen nur ca. 30 kB an. Hatte ich irgendwann die letzten Tage schonmal bei einem anderen D81.

    Naja... das ist ja eine größere Hosting-Platform, evtl. bauen die ab&zu etwas um. Ich hab aber eben den aktuellen SnapShot heruntergeladen, ohne Probleme. 800Kb. Wird von FireFox auch vor dem Download schon angezeigt.

  • Muss man nicht prüfen, da ist nur ein Test auf C128 eingebaut und wenn ja dann wird die Bank korrekt gesetzt. Am C64 wird da kein neuer Code ausgeführt, da ist alles beim alten.

    Ah, danke für die Info.


    Uff... Dachte schon das könnte länger dauern

    Siehste der C128 ist gar nicht so schlimm. *duckundweg* :D

    Hatte keine Probleme mit dem Download des Snapshot's.

    Gruss C=Mac.

  • evtl. bauen die ab&zu etwas um.

    Naja, in der Regel lade ich immer beides runter :wink: . Dann kann ich nach dem Download gleich direkt das D81 kopieren....

    Werde das nachher mit dem neuen GeoDOS-Snapshot auch nochmal probieren (191 Track DNP)....

    So, erster Test: neuen GeoDOS-Snapshot von C= REU Native gestartet und auf dem SD2IEC ein 191 Track DNP erstellen lassen. Dauerte ca. 9:10 Minuten. Alles OK, alles da wo es sein soll. Keine Probleme.

    Zweiter Versuch: GeoDOS aus einem UV von einem DNP (16 MB) auf dem SD2IEC gestartet. DNP gleicher Größe erstellen lassen. Das obige Prozedere läuft problemlos ab. Aber GeoDOS verabschiedet sich mit Systemfehler (Systemlaufwerk defekt oder nicht vorhanden) oder so).
    Auf was für Ideen die Anwender so kommen ....... ;-)) . Soweit ich mich erinnere, kann GeoDOS sowas auf echten CMD-Geräten aber wohl (noch ???) nicht am SD2IEC :wink: ....

    Gruß
    Werner

  • Zweiter Versuch: GeoDOS aus einem UV von einem DNP (16 MB) auf dem SD2IEC gestartet. DNP gleicher Größe erstellen lassen. Das obige Prozedere läuft problemlos ab. Aber GeoDOS verabschiedet sich mit Systemfehler (Systemlaufwerk defekt oder nicht vorhanden) oder so).
    Auf was für Ideen die Anwender so kommen ....... ;-)) . Soweit ich mich erinnere, kann GeoDOS sowas auf echten CMD-Geräten aber wohl (noch ???) nicht am SD2IEC ....

    Du hast Dir den Ast abgesägt auf dem Du sitzt: Nach dem erstellen des DNP ist das ja automatisch aktiv und damit ist GeoDOS auf einem anderen Image. Das kann nicht (und wird es auch nicht) funktionieren. Beim Partitionswechsel hab ich das schon unterbunden. Muss ich bei Format wohl auch noch machen... :gruebel

    Das Problem ist das einem das SD2IEC nicht mitteilen kann in welchem DiskImage es sich gerade befindet. Falls es das könnte wäre das denkbar das GeoDOS von einem anderen DNP gestartet wird und man dann ein anderes DNP öffnen kann. Aber das hat der Entwickler ja schon bestätigt das es nicht geht. Also darf GeoDOS das DNP nicht wechseln wenn es das Startlaufwerk ist. Danke für den Hinweis :)

  • GeoDOS aus einem UV von einem DNP (16 MB) auf dem SD2IEC gestartet.

    Was das geht?
    Ging mit der alten Version (2.951) nicht, jedenfalls nicht mit der HD und RL.
    Wurde GD aus einem UV gestartet, gab es nur eine Fehlermeldung.

    Aus dem Grund habe ich - bei MP3 - die GeoDOS-Datei im Root und den Rest im TD-Ordner.
    O.K. das sollte ich ja noch ändern.

    Gruss C=Mac.

  • Wurde GD aus einem UV gestartet, gab es nur eine Fehlermeldung.

    So richtig perfekt hat das wirklich nicht funktioniert. Aber ich hab da jetzt was angepasst.

    Ist zwar noch experimentell, aber startet man jetzt BootGD von einem UV heraus wo sich auch GeoDOS befindet, dann merkt sich BootGD auch das UV. Kopiert man jetzt BootGD auf ein anderes Laufwerk und wechselt auf dem NM-Laufwerk das Verzeichnis, dann lässt sich GeoDOS künftig auch über BootGD starten. Sofern das gleiche DiskImage im SD2IEC liegt. Bei einer HD/RL hätte das bisher auch schon von anderen Partitionen geklappt, aber nur vom Root-Verzeichnis heraus. Das UV wurde bisher nicht gespeichert.
    Damit sollte man künftig GeoDOS starten können ohne das man alle Dateien im aktuellen Verzeichnis hat. BootGD müsste reichen.

    BootGD war im letzten SnapShot schon zu groß, auf CMD-Laufwerken konnte das zum Absturz führen.

    Beim erstellen von UV auf NM gab es noch einen Fehler:
    Wenn man ein UV innerhalb eines UV erstellen wollte kam die Meldung "Das Verzeichnis konnte nicht erstellt werden"... Glatte Lüge: Das Verzeichnis ist da.

    Sortieren von NM-Verzeichnissen mit UVs prüft jetzt im aktuellen Verzeichnis auch die Verzeichnis-Header und korrigiert die entspr.Angaben. Auch wenn wweicht das als problematisch sieht:Das einzige Problem wäre m.M.n. das die Länge des aktuellen Verzeichnisses beim VALIDATE in den falschen Dateieintrag geschrieben wird. Es sei denn ich übersehen da etwas. Die anderen Angaben beziehen sich auch Verzeichnis-Header und Parent-Header, die ändern sich durch das sortieren aber nicht.
    Ich überlege mir noch das auch in VALIDATE einzubauen, aber für alle Verzeichnisse auf der Disk. evtl. als Option.

    Was UV angeht hab ich das mal mit den Verzeichnissen verglichen die man unter BASIC auf CMD-Laufwerken erstellen kann. Der einzige Unterschied in den Headern war das unter GEOS die Suche nach einem freien Sektor um +1 später beginnt. Also wo unter BASIC der Header eines neuen UV auf Tr=01/Se=41 liegt, da liegt er unter GEOS/GeoDOS bei Tr=01/Se=42. Aber ansonsten scheinen sich die Verzeichnisse so zu verhalten wie die unter BASIC erstellten.

    Mal sehen wann ich dazu komme das alles noch etwas besser zu testen.

  • Hallo,

    Auch wenn wweicht das als problematisch sieht:Das einzige Problem wäre m.M.n. das die Länge des aktuellen Verzeichnisses beim VALIDATE in den falschen Dateieintrag geschrieben wird.

    Ja, aber ... :wink:
    Ich mag es nicht, wenn auf meinen Disketten/Partitionen/UVs irgendwas geschrieben wird, was da nicht hingehört :bgdev .


    Aber ansonsten scheinen sich die Verzeichnisse so zu verhalten wie die unter BASIC erstellten.
    Mal sehen wann ich dazu komme das alles noch etwas besser zu testen.

    Stand: 26.11.:
    Bei den UVs steht immer noch drin, freie Sektoren dafür ab Track 1 Sektor 0 zu suchen. Ja ich weiss, kann man drüber streiten :wink: . Aber es sollte eigentlich Sektor $40 (64) sein. Wenn ich auf meiner FD in BASIC ein UV anlege (frisch formatierte Native-Mode-Disk), ist es so.

    Ein anderes "Problem" (wahrscheinlich gleiche Ursache): Wenn ich Dateien mit GeoDos kopiere, landet mindestens ein Block von TopDesk128 ebenfalls in den Bereich vor Sektor $40 (64). Auch das sollte eigentlich nicht sein :wink: .
    Zumindest TD128 scheint auch dieses Problem zu haben.

    Und ein Test scheint mir beim Anlegen von UVs ganz zu fehlen. Laut CMD-Handbüchern (CMD-HD Seite 13):

    "...
    Diese Datei ist anfänglich 2 Blocks groß und enthält einen Verzeichnis-Headerblock und ersten Verzeichnisblock. Beide Blocks stehen nebeneinander in der gleichen Spur. Wenn dies nicht der Fall ist, wird kein Verzeichnis erstellt.
    ..."

    Gruß
    Werner

  • Das Problem ist wohl größer:

    Warum zum Geier werden jetzt UVs im Geos-Format erstellt? Die müssten ja theoretisch 3 Blöcke belegen (2 von der UV-Definition und einer für den Border-Block). Ja, ich habe gesehen, dass der Border-Block der gleiche ist, wie beim DNP....

    Gruß
    Werner

  • Das Problem ist wohl größer:

    Warum zum Geier werden jetzt UVs im Geos-Format erstellt? Die müssten ja theoretisch 3 Blöcke belegen (2 von der UV-Definition und einer für den Border-Block). Ja, ich habe gesehen, dass der Border-Block der gleiche ist, wie beim DNP....

    Es werden standardmäßig keine Verzeichnisse im GEOS-Format erstellt... nur wenn die Disk bereits eine GEOS-Disk ist. Aber das Problem ist bereits behoben und ad-acta gelegt. Schlimmer ist das ein "MD:NewDir" über den seriellen Bus auf CMD-Laufwerken eine defekte BAM erzeugt. Ein "I0:" dazwischen reicht aus um den Fehler zu beheben. Ich vermute mal das hängt mit dem GEOS-TurboDOS zusammen. Das ließt evtl. die BAM aus dem Floppy-Speicher welche nach dem MD-Befehl auf die BAM des neuen UV verweist.

    Ich überlege mir jetzt noch ob ich den I0-Befehl drin lasse oder ganz auf das manuelle erstellen von Verzeichnissen wechsle.

    Wäre mit dem testen schon viel weiter wenn mir heute nicht an meinem TV der HF-Tuner "abgeraucht" wäre.. kein Bild mehr vom C64 über das Antennenkabel am TV (2ter C64 getestet, anderes Netzteil... liegt definitiv nicht am C64). Jetzt läuft das über SCART aber ohne Bild-in-Bild :cry: