Hallo Besucher, der Thread wurde 1,6k mal aufgerufen und enthält 13 Antworten

letzter Beitrag von marty am

40 Track Formate?

  • Hallo,

    ich weiß, dass es verschiedene 40-Track-Formate für die 1541 gab. Peter Schepers listet beispielsweise Dolphin DOS und Speed DOS auf und sagt, w sich die BAM für die zusätzlichen Tracks befinden (https://ist.uwaterloo.ca/~schepers/formats/D64.TXT).
    Leider finde ich keine Information, wie man entsprechende Disketten (automatisch) erkennt.


    Daher meine Fragen:

    1. Was für Standard-40-Track-Formate gibt es, insbesondere zusätzlich zu den genannten? Unterscheiden sich die Versionen der Diskformate voneinander?
    2. Kann man sie automatisch erkennen (vermutlich an 18/0) oder zumindest Heuristiken nutzen?
    3. Gibt es Beispiel-D64 für die einzelnen Formate irgendwo, oder kann mir jemand welche schicken?
  • Ist da irgendwas zueinander kompatibel, oder hat da nicht wirklich jeder Speeder-Hersteller sein eigenes Sueppchen gekocht?

    Ich meine damals beim Professional DOS konnte man die 40T Disketten an der ID erkennen, die anstatt "2A" bei 35T mit "4A" formatiert wurde.

    Um das zu checken muesste ich aber meine Professional DOS Floppy wieder aus dem Keller holen. ;)

  • Ist da irgendwas zueinander kompatibel, oder hat da nicht wirklich jeder Speeder-Hersteller sein eigenes Sueppchen gekocht?

    Das weiß ich halt nicht. Da ich auch nicht viele 40-Track-Images habe.


    Ich sehe, dass VICE etwas mehr darüber schreibt: https://vice-emu.sourceforge.io/vice_16.html (unter Variations und die Liste von WoMo).

    Ich sehe, die Beispiel-Images wären wichtig.

  • Eigendlich alle Hardware-Speeder, die ein 40-Track Format nutzen, formatieren die Tracks 36 bis 40 mit der Speed Zone 0. Das bedeuted, es wird mit 17 Sektoren pro Track formatiert.

    Für die BAM wird der Bereich hinter dem Eintrag des Disknamen, auf Track 18;00 genutzt. Der Diskname steht ab Byte $90 bis $AF. Ab Byte $B0 stehen dann die BAM-Werte

    für die Tracks 36 bis 40. Einzig, die Erkennung ob 35 Tacks oder 40 Tracks, handhaben die Speeder mit einem Eintrag, meistens als 4 und 5 ID-Nummer, unterschiedlich. Das

    musste man dann Patchen um mit anderen Speeder kompatibel zu bleiben.

  • Die 40-Spur-Formate von cbmforng und EF3UTILS funktionieren jedenfalls aus Anwendersicht "einfach so".

    Nibtools von r.cade sind bis vor einiger Zeit von einem falschen Speed für Track 36-40 ausgegangen, weswegen die 40-Track-D64 aus der csdb nicht funktionierten, z.B. Starwars Demo oder "We come in peace". markusC64 ist aber dahintergekommen, und r.cade hat es inzwischen gepatcht.

  • Die Zusammenstellung in VICE dürfte es wohl ziemlich komplett abdecken.


    Womo und ich hatten damals mit Joe Forster viele und lange Diskussionen, wie die Erkennung von Disketten zu verbessern sein könnte. Lediglich Dolphin DOS erlaubt dies im Prinzip durch die Lückenbytes, wurde aber so im Star Commander nie implementiert. Der versucht einfach die Spur 36 zu lesen, und falls die formatiert ist, versucht er ein 40 track image anzulegen. Das kann klappen aber auch schief gehen ...


    sämtliche Methoden, das Format anhand des Inhalts von 18/0 zu erkennen sind wenig sicher, das kann schliesslich jeder Nutzer nach Belieben manipulieren. Lediglich wenn es einen "Standard" entspricht, kann das einen Hinweis auf das Format geben.


    was hast du denn genau vor?

  • Die Zusammenstellung in VICE dürfte es wohl ziemlich komplett abdecken.

    Da fehlt mindestens S-Jiffydos. Da das mein Favorit ist, ist das ein Problem. :-)

  • Ist es nicht möglich, die Speed Zonen der Tracks 36-40 zu messen um festzustellen, ob diese benutzt werden?

    ja, dann kannst du auch gleich alles nibblen. Das hat dann mit "Erkennung" nicht viel zu tun. Aber ich weiss ja auch nicht was strik so vor hat ;)

  • Da fehlt mindestens S-Jiffydos

    Hm... Über die Implementierung finde ich da nichts.

    NLQ, gibt es eine beschreibung, wie Block 18/0 aussieht (und eventuell auch andere, wenn sie verändert sind)

    Die Zusammenstellung in VICE dürfte es wohl ziemlich komplett abdecken.

    Danke. Ich würde mich auch wundern, wenn WoMo da nicht sehr genau gewesen wäre. :)

    was hast du denn genau vor?

    Ich will das Format erkennen und sicher lesen/beschreiben können. Also nicht unbedingt physikalisch, sondern im Image. Erst einmal zumindest.


    Deine Ausführungen sagen mir nun, dass ich das nicht automatisch erkennen kann sondern es dem Nutzer überlassen muss mitzuteilen, ob es ein 40-Track-Format ist und wenn ja, welches. Richtig?


    Ich hatte ja schon überlegt, ob man nicht schauen kann, "wo" freie Blöcke sind. Sprich, man sicht an den potenziellen Stellen, ob man dort "verräterische" Daten findet, die wie BAM-Einträge aussehen. Dummerweise geht das schief, sobald z.B. ein Image vollkommen voll ist: Wenn alles mit "0" voll ist dann kann man nicht unterscheiden, ob die Nullen ab $C0, ab $AC oder ab $90 relevant sind. (Wobei Prologic vielleicht noch "irgendwie" funktionieren könnte...


    Die 40-Spur-Formate von cbmforng und EF3UTILS funktionieren jedenfalls aus Anwendersicht "einfach so".

    cbmforng schreibt die erweiterte BAM ab $C0, laut der Beschreibung von Peter Schepers / VICE also das "SPEED DOS" Format.

    Eigendlich alle Hardware-Speeder, die ein 40-Track Format nutzen, formatieren die Tracks 36 bis 40 mit der Speed Zone 0. Das bedeuted, es wird mit 17 Sektoren pro Track formatiert.

    Soweit klar, daran habe ich nie gezweifelt. ;)


    Für die BAM wird der Bereich hinter dem Eintrag des Disknamen, auf Track 18;00 genutzt. Der Diskname steht ab Byte $90 bis $AF. Ab Byte $B0 stehen dann die BAM-Werte

    für die Tracks 36 bis 40

    Laut der VICE-Doku steht die "erweiterte BAM" (Tr. 36 - 40) bei Dolphin DOS von $AC-$BF, bei Speed DOS bei $C0-$D3 und bei Prologic DOS sogar von $90 - $A3, also direkt hinter die "normale" BAM. Dafür verschiebt es wohl den Diskettennamen von $90 auf $A4.

    Also einheitlich sieht für mich anders aus. ;)

    Ich habe bei der Suche nach 40-Track-Images dann auch ein Image für den Plus/4 gefunden (alphray.d64). Dummerweise sind dort alle Blöcke als belegt markiert, gemeinhin also "0" (Ausnahme: 18/15 ist frei). Daran kann man schön sehen, dass eine automatische Erkennung vollkommen ins Leere laufen würde.

  • Wenn es hilft, ich kann ein G64 spendieren, welches damit formatiert ist. Da kann man eigentlich ja alles entnehmen - mit etwas Aufwand (g64conv hilft sicherlich, siehe Signatur).

  • Wenn es hilft, ich kann ein G64 spendieren, welches damit formatiert ist. Da kann man eigentlich ja alles entnehmen - mit etwas Aufwand (g64conv hilft sicherlich, siehe Signatur).

    Danke. Sehr interessant.


    Es nutzt die BAM ab $C0, was für SPEED DOS Format spricht. Allerdings setzt es auch die DOS ID auf "4A" (statt "2A"), was für ProfDOS spricht... Daraus könnte man folgern, dass ProfDOS auch das SPEED DOS Format nutzt...