GeoDOS V2 Release 2018

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

  • 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.

    Dies habe ich auch gemerkt und gedacht "oh,nee".
    Aber ist ja schon bekannt. ^^


    Schlimmer ist das ein "MD:NewDir" über den seriellen Bus auf CMD-Laufwerken eine defekte BAM erzeugt.

    Wenn ich es richtig verstehe, bedeutet dies:
    Wenn ich mit GeoDOS ein UV auf einem CMD-Laufwerk (Native-Mode) erstelle, wird die BAM zerstört?

    Wenn ja.
    Muss ich sagen, nö.
    Jedenfalls nicht auf der CMD-HD (Native-Partition 4 MB und 16 MB), UV's werden ohne Probleme erstellt und das Aufräumen (GD und TD 128) zeigt keinen Fehler an.
    Die HD hängt im Moment am C128D und da ist sie nur mit dem seriellen Port verbunden, dies erst noch mit einer über 2m langen Strippe am TV vorbei.

    Gruss C=Mac.

  • standardmäßig keine Verzeichnisse im GEOS-Format erstellt... nur wenn die Disk bereits eine GEOS-Disk ist

    Ich halte es generell für "Blödsinn", UVs im Geos-Format zu erstellen.

    - Wer hat das eigentlich eingeführt? Ja ich weiss, auch ältere Programme (z.B. CLI) machen sowas
    - Was bringt das für einen Vorteil? Im ungünstigsten Fall habe ich mehrere Border-Blocks auf einer Partition/DNP
    - Was passiert eigentlich, wenn ich so ein UV mal im BASIC umbenenne? Entweder wird der Teil ab $90 gelöscht (keine Ahnung) oder das UV hat jetzt 2 unterschiedliche Namen....

    So wie ich das sehe, funktionieren BASIC-UVs problemlos, zumindest auf SD2IEC.....

    Wenn ich mit GeoDOS ein UV auf einem CMD-Laufwerk (Native-Mode) erstelle, wird die BAM zerstört?

    Ich glaube, da ist die Version gemeint, an der darkvision gerade gearbeitet hat...
    Übrigens, seit gestern Abend gibt es einen neuen geoDOS-Snapshot.

    Gruß
    Werner

  • Wenn ich es richtig verstehe, bedeutet dies:
    Wenn ich mit GeoDOS ein UV auf einem CMD-Laufwerk (Native-Mode) erstelle, wird die BAM zerstört?

    Nein, nicht wirklich. Es wird nur eine falsche BAM eingelesen was dazu führt das plötzliche alle Sektoren "frei" sind. Beim nächsten speichern kommt dann das böse erwachen.
    Aber das ist kein Problem der CMD-Hardware, eher der Laufwerkstreiber bzw. in dem Fall von GeoDOS. Wie gesagt über den "I0"-Befehl lässt sich das "beheben". So ist es im aktuellen SnapShot noch gelößt.

    Ich halte es generell für "Blödsinn", UVs im Geos-Format zu erstellen.

    Geb ich Dir Recht, macht keinen Sinn... war auch nie eine Überlegung das so zu machen. Es wurde aber zum erstellen eines neuen UV der Header des aktuellen Verzeichnisses (ROOT) verwendet und wenn das eine GEOS-Disk war wurde das in das UV übernommen. Wie gesagt, schon erledigt.

    - Was passiert eigentlich, wenn ich so ein UV mal im BASIC umbenenne? Entweder wird der Teil ab $90 gelöscht (keine Ahnung) oder das UV hat jetzt 2 unterschiedliche Namen....

    Da kann man lustige Sachen machen: Wenn Du ein UV öffnest dann kann man über "Diskette umbenennen" den Namen im Header ändern. Der ändert aber nicht den Directory-Eintrag im Eltern-Verzeichnis. Man muss also bei "Diskette umbenennen" entweder den ROOT-Header direkt einlesen oder zuvor in das Hauptverzeichnis zurück wechseln. Ich muss mal schauen wie das unter GeoDOS gehandhabt wird...
    Du kannst das Verzeichnis aber jederzeit in BASIC umbenennen. Das ändert nichts an der GEOS Unterstützung. Wenn BASIC auch den Header anpasst dann hast Du den neuen Namen auch in GEOS.

    Für Programme die nicht mit UV von NativeMode-Laufwerken umgehen können ist ein UV wie eine andere Diskette.

  • Igitt!!!! Ein neuer "BUG" am SD2IEC, oder GeoDOS, oder MegaPatch???

    Ich überspiele gerade mit dem aktuellen SnapShot Disketten von der FD2000 (je 2x1581 je HD-Disk) auf das SD2IEC. Dazu erstelle ich mir mit GeoDOS auch zuerst zwei neue D81-Images, danach kopiere ich über die 1:1-DiskBackup Funktion die Disks von der FD auf die SD2IEC-Images.

    Wenn ich direkt nach dem Copy GEOS in Richtung BASIC verlasse und mir das Verzeichnis anzeigen lasse werden da immer "3160 Blocks free" angezeigt. Auch mit 100+ Dateien im Verzeichnis.

    Verlasse ich das Image über "CD<-" und wechsle dann erneut in das DiskImage, dann stimmt die Anzeige der freien Blocks...

    Beim nächsten Test muss ich mal sehen ob der Speicher auch unter GEOS so "falsch" angezeigt wird... wäre ja fatal.

    P.S. unter GEOS und GeoDOS wird die korrekte Anzahl an freien Blocks angezeigt. Verlasse ich GEOS in Richtung BASIC und lade das Verzeichnis vom SD2IEC über "LOAD´$´,8" dann erhalte ich 3160 Blocks free. Es sieht so aus als würde das SD2IEC nicht mitbekommen das sich die BAM geändert hat... evtl. weil die BAM durch das schreiben von Sektoren direkt geändert wird und nicht über das speichern von Dateien.

  • Was passiert eigentlich, wenn ich so ein UV mal im BASIC umbenenne? Entweder wird der Teil ab $90 gelöscht (keine Ahnung) oder das UV hat jetzt 2 unterschiedliche Namen....

    Da kann man lustige Sachen machen: Wenn Du ein UV öffnest dann kann man über "Diskette umbenennen" den Namen im Header ändern. Der ändert aber nicht den Directory-Eintrag im Eltern-Verzeichnis.

    Das war bis jetzt immer so, jedenfalls unter Wheels (CMD-Hardware), mit GeoDOS habe ich es noch nicht probiert.

    Hat man ein UV umbenannt, hat sich nur der Name der Datei "Dir" geändert.
    Nach dem öffnen des UV hiess es ("die Diskette") immer noch wie vor dem Umbenennen.

    Ist aber bei Images auf dem SD2IEC und Ultimate 2+ das selbe.
    Ändere ich den Name des Images, bleibt der Name des Inhalts ("Diskette") bestehen.

    Bei der HD ist es das Selbe mit den Partitionen und hier kommt noch zusätzlich die Partitionsliste hinzu. :D


    Igitt!!!! Ein neuer "BUG" am SD2IEC, oder GeoDOS, oder MegaPatch???

    :Ssshock:

    Gruss C=Mac.

  • :Ssshock:
    Gruss C=Mac.

    Na, ganz so schlimm isses ja nicht. Es ist zwar reproduzierbar, aber wenn juckt schon die Anzahl der freien Blocks unter BASIC :D
    Ich seh das in der Zwischenzeit eher als "optischen Mangel" in der SD2IEC-Firmware.

    Wie so die meisten Features in GeoDOS hab ich wieder was ergänzt was mir die letzten Tage beim Backup meiner alten Disketten auf das SD2IEC gefehlt hat:

    Ich hab GeoDOS beim formatieren/erstellen von SD2IEC-Images den Verzeichnis-Browser spendiert, man kann also jetzt festlegen wo das Image abgelegt werden soll.
    Ausserdem kann man jetzt alle Formate erstellen, egal welcher Laufwerkstyp gerade eingestellt ist. Man bekommt aber den Hinweis das man den Laufwerkstreiber manuell einstellen muss. Das dazu passende Laufwerks-ROM (DOS15xx.BIN) kann man aber direkt nach dem formatieren laden. Also muss man nur noch den GEOS.Editor starten und den Treiber einstellen um das Laufwerk/DiskImage nutzen zu können. Das laden des ROMs ist nach wie vor nur für 1541/71/81 erforderlich. Das laden des passenden GEOS-Treibers ist für alle Typen erforderlich.

    Ich lade ja alle Treiber nach dem starten direkt ins RAM. Damit reicht es für mich den GEOS.Editor mit in das GeoDOS-Verzeichnis zu kopieren.

    Was noch ergänzt wird ist das erstellen neuer SD2IEC-Verzeichnisse im Browser.
    Ich teste das jetzt noch etwas... dann gibt's nen neuen SnapShot.

  • Hallo Bitte melde dich an, um diesen Link zu sehen. ,

    auf Deinem Area6510 hat Du im geoDOS-Source-Code (Datei: cbm.Part_NDir.s, Zeilen 672-673) noch drin stehen:

    ldy #$90 ;Für Kompatibilität mit 1541/71.
    jsr CopyDirName

    Meiner Meinung nach kann das noch entfallen. Habe es zumindest in meinem Programm für Topdesk nicht mehr drin. Egal ob RAMNative, SD2IEC-Native oder CMD-FD-Native, der Diskname wird hier immer richtig angezeigt. Ich glaube, das Problem gibt es irgendwie nur bei D81s .....

    Außerdem prüft mein Programm die Lage der 2 Sektoren (Header und Dir-Block) eines UVs. Laut CMD-Handbüchern müssen die im gleichen Track direkt nebeneinander liegen. Hatte bei einer älteren geoDOS-Version schonmal das "Problem", dass der Header auf Track 1 und der erste Dir-Block auf Track 4 oder 5 lag. Hat zwar augenscheinlich auch funktioniert, aber .... :wink: .

    Wenn alles klappt, werde ich heute noch das Programm hier im Forum veröffentlichen (für MP3-128). Die MP3-64-Version folgt im Laufe des Wochenendes. Die UV-Erstellen-Routine ändert sich nicht mehr, nur der Aufbau der Oberfläche des Programms....

    Gruß
    Werner

  • ldy #$90 ;Für Kompatibilität mit 1541/71.
    jsr CopyDirName

    Stimmt, gilt nur für Disknamen.
    P.S. Dachte zuerst das ist falsch, habs dann für Disknamen korrigiert... aber wenn ich so nachdenke:
    SwapDskNmData aus dem GEOS-MegaPatchtreiber prüft beim lesen/schreiben eines Blocks r1L/r1H. Wenn der Sektor der aktuelle DiskHeader ist dann wird der Name von $04<->$90 getauscht. Beim erstellen des Blocks reicht es nach $04 zu schreiben. Öffnet man das Verzeichnis darf man den Disknamen/Verzeichnis-Namen aber nur in $90 ändern.

    Laut CMD-Handbüchern müssen die im gleichen Track direkt nebeneinander liegen.

    Das wäre mir neu... das kann ja nur notwendig sein wenn der Programmierer zu Faul war den Track zu kopieren und einfach nur den Sektor um +1 erhöht hat um auf das verzeichnis zuzugreifen nachdem er den Header eingelesen hat. In welchem der CMD-Bücher steht denn das?
    Das zu ändern wäre ja kein Problem... Das Worst-Case-Szenario wäre ja das auf der Disk noch 255 Blocks frei sind, auf jedem Track einer, aber man trotzdem kein neues Verzeichnis erstellen kann.

  • In welchem der CMD-Bücher steht denn das?

    Im deutschen Handbuch zur CMD-FD auf Seite 27 unter "Native-Modus-Unterverzeichnisse" (liegt hier als blauer Ring-Ordner vor) und im deutschen Handbuch zur CMD-HD auf Seite 13 (gleiche Überschrift, liegt mir als PDF vor) .

    Gruß
    Werner

  • Im deutschen Handbuch zur CMD-FD auf Seite 27 unter "Native-Modus-Unterverzeichnisse" (liegt hier als blauer Ring-Ordner vor) und im deutschen Handbuch zur CMD-HD auf Seite 13 (gleiche Überschrift, liegt mir als PDF vor) .

    OK... im englischen Handbuch zur RAMLink steht das ähnlich, wenn auch etwas präziser.

    Zitat

    These blocks are always located next to each other on the same track, and if two adjacent blocks cannot be found, no directory will be created.

    Ich schau mir das mal näher an... Danke für den Hinweis.

  • Ich schau mir das mal näher an... Danke für den Hinweis.

    Hier ( Bitte melde dich an, um diesen Link zu sehen. ) ist mein Programm für MP3-128. Diesen Test habe ich da eingebaut ("TD2Com3.scr"). Sind nur ein paar Bytes...

    Gruß
    Werner

    PS: SourceCode ist da enthalten

  • Hier ( CMD-Untervezeichnisse (und mehr) unter Topdesk V4 in MP3 ) ist mein Programm für MP3-128. Diesen Test habe ich da eingebaut ("TD2Com3.scr"). Sind nur ein paar Bytes...

    Schau ich mir bei Gelegenheit mal an, allerdings hab ich da schon Code vor Augen... so wie Du sagst, sind nur ein paar Bytes... hat aber für mich aktuell nur LowPrio... da ich davon ausgehe das dies eh nur auf CMD-Laufwerken evtl. ein Problem sein kann... und ich CMD aktuell noch getrennt behandele.

  • Ausserdem kann man jetzt alle Formate erstellen, egal welcher Laufwerkstyp gerade eingestellt ist.

    :thumbsup:

    Was mich grad wieder zur einer verrückten Frage führt, wie immer. :D

    Wäre es möglich Imageart übergreifend zu kopieren?
    Zum Beispiel Daten sind in einem D81, werden aber in einem DNP benötigt.

    Und ja, ich hab keine Ahnung was dies wieder für ein Programmieraufwand ist und ob überhaupt möglich. :nixwiss:

    Gruss C=Mac.

  • Wäre es möglich Imageart übergreifend zu kopieren?
    Zum Beispiel Daten sind in einem D81, werden aber in einem DNP benötigt.

    Unter BASIC ja, unter GEOS auch, mit getrennten Laufwerken und getrennten SD2IECs :bgdev

    Ansonsten wird das schwierig, weil die Laufwerkstreiber Sektor-orientiert arbeiten, ein Treiber für die 1571 kann also nicht alle Sektoren eines DNP lesen weil auch eine bestimmte Anzahl von Sektoren je Track begrenzt. Theoretisch geht da vieles, in der Realität begrenzt leider der Speicher für den Laufwerkstreiber die Möglichkeiten. Wenn man alles über Bord wirft, jegliche Kompatibilität zu existierenden GEOS-Programmen, dann kann man da was machen, aber wer will das schon?

  • Unter BASIC ja, unter GEOS auch, mit getrennten Laufwerken und getrennten SD2IECs

    Ach, das geht. :D


    Ansonsten wird das schwierig, weil die Laufwerkstreiber Sektor-orientiert arbeiten, ein Treiber für die 1571 kann also nicht alle Sektoren eines DNP lesen weil auch eine bestimmte Anzahl von Sektoren je Track begrenzt. Theoretisch geht da vieles, in der Realität begrenzt leider der Speicher für den Laufwerkstreiber die Möglichkeiten. Wenn man alles über Bord wirft, jegliche Kompatibilität zu existierenden GEOS-Programmen, dann kann man da was machen, aber wer will das schon?

    Hab ich vermutet, das es mehr als ein Fallstrick geben wird.
    Und nein, nicht alles über Bord werfen.
    Danke für die Erklärung.

    Gruss C=Mac.

  • Ich hab GeoDOS beim formatieren/erstellen von SD2IEC-Images den Verzeichnis-Browser spendiert, man kann also jetzt festlegen wo das Image abgelegt werden soll.
    Ausserdem kann man jetzt alle Formate erstellen, egal welcher Laufwerkstyp gerade eingestellt ist.

    Neuer Bitte melde dich an, um diesen Link zu sehen. online. Zusätzlich kann man beim erstellen von DiskImages auch neue Verzeichnisse erstellen. Nicht wundern: GeoDOS wechselt dann auch gleich in das neue Verzeichnis. Mit "OK" kann man dann weitermachen (oder über die anderen Befehle "<=" und ".." wieder das Verzeichnis wechseln).
    Ich hab auch einige Hinweistexte ergänzt was man tun muss wenn man den Format-Typ wechselt.

  • Neuer Bitte melde dich an, um diesen Link zu sehen. online. Zusätzlich kann man beim erstellen von DiskImages auch neue Verzeichnisse erstellen. Nicht wundern: GeoDOS wechselt dann auch gleich in das neue Verzeichnis. Mit "OK" kann man dann weitermachen (oder über die anderen Befehle "<=" und ".." wieder das Verzeichnis wechseln).Ich hab auch einige Hinweistexte ergänzt was man tun muss wenn man den Format-Typ wechselt.

    Danke für den neuen SnapShot.
    Hier ein kleiner Test von mir. Ich hoffe er ist allgemein verständlich. :)

  • Hier ein kleiner Test von mir. Ich hoffe er ist allgemein verständlich.

    Mal ne Frage dazu:

    Welchen uIEC-Man benutzt Du? Gib mir mal Klasse, Datum und Uhrzeit an.

    Hintergrund:

    Die älteren Versionen des uIEC-Man setzen beim öffnen immer per "MR:"-Befehl die file based MR emulation. Das heißt: Ist das Laufwerk als 1541 in MP3 angemeldet, wird dos1541 gesetzt, bei 1571 dos1571, bei 1581 dos1581 und bei Native habe ich den genauen Dateinamen nicht parat (hat sich hier einige male geändert, steht aber in der Anleitung). Mit dem SD2IEC-Treiber von MP3 ist egal was da eingestellt ist. Möglicherweise kommt es dadurch zu Problemen.....

    Gruß
    Werner

  • Mal ne Frage dazu:
    Welchen uIEC-Man benutzt Du? Gib mir mal Klasse, Datum und Uhrzeit an.

    Hintergrund:

    Die älteren Versionen des uIEC-Man setzen beim öffnen immer per "MR:"-Befehl die file based MR emulation. Das heißt: Ist das Laufwerk als 1541 in MP3 angemeldet, wird dos1541 gesetzt, bei 1571 dos1571, bei 1581 dos1581 und bei Native habe ich den genauen Dateinamen nicht parat (hat sich hier einige male geändert, steht aber in der Anleitung). Mit dem SD2IEC-Treiber von MP3 ist egal was da eingestellt ist. Möglicherweise kommt es dadurch zu Problemen.....

    Gruß
    Werner

    Hallo Werner, danke für Deine Antwort/ Frage!
    Hier meine Daten für den UIEC Manager.

    128er: Manager V1.08 23.10.14 17.34 Uhr
    Run V1.00 18.11.11 08.57 Uhr

    64er : Manager V1.06 23.10.14 17.39 Uhr
    Run V1.00 18.11.11 08.57 Uhr

    Gruß Jojo