Posts by ZAK256

    Hallo,
    ich habe mal mir mal Gedanken gemacht, wie ein modernes Disk Image Tool aussehen könnte und welche Anforderungen es erfüllen sollte.


    Eine sehr kurze Beschreibung eines Disk Image Tools wäre wohl:
    Ein Disk-Image-Tool ist ein Tool, welches Dateioperationen (wie Kopieren,Verschieben, Löschen) zwischen einem Disk-Image und einem anderen Dateisystem ermöglicht.


    Aber diese Beschreibung ist echt kurz. Deshalb jetzt mal etwas detaillierter im Frage-Antwort-Format.


    Welche Disk-Image Formate sollen unterstützt werden?

    • D64
    • D71
    • D81
    • DNP
    • D1M, D2M, D4M, DHD (Container-Format)
    • G64, G71, FDI, NIB, DFI
    • D80, D82
    • T64
    • X64
    • LNX

    Anmerkungen:

    • Die Formate D64, D71, D81 sind muss.
    • Das DNP Format sollte danach auf der Prio-Liste stehen.
    • Die Container- Formate D1M, D2M, D4M, DHD sollten danach angegangen werden.
    • Bei den Low-Level G64, G71, FDI, NIB, DFI sollte es wohl genügen, wenn man G64 nur lesend unterstützt.
    • Die Formate D80, D82 währen ein Nice-to-have.
    • T64 wäre dann das Letzte auf meiner Prio-Liste


    Welche Spezialitäten der Disk-Image Arten sollen unterstützt werden?

    • D64: 40 Tracks (Speed DOS, Dolphin DOS, ProLogic DOS)
    • D64: mehr als 144 Dateieinträge im Directory
    • D71: Einseitig formatiert (oben/unten)
    • D81: 1581-Unterpartitionen
    • DNP: CMD-Unterverzeichnisse
    • D1M, D2M, D4M, DHD: CMD-Partitionen
    • Bei allen Arten: Directory Manipulationen

    Anmerkungen:

    • Die Liste ist wohl schon selbsterklärend.
    • Wahrscheinlich fehlen noch ein paar Punkte.


    Welche Dateiarten sollen unterstützt werden?

    • SEQ (sequentiell)
    • PRG (Programm)
    • USR (USER-Datei)
    • REL (relativ)
    • GEOS-Datei

    Anmerkungen:

    • GEOS Dateien halte ich für ein Muss.
    • Vielleicht könnte man am ehesten auf relative Dateien verzichten.


    Wie kann der Commodore DOS Dateiname im Dateisystem erhalten werden?

    • SEQ (sequentiell) >> Sxx
    • PRG (Programm) >> Pxx
    • USR (USER-Datei) >> Uxx
    • REL (relativ) >> Rxx
    • GEOS-Datei >> CVT

    Anmerkungen:

    • Ob der PC64 Ansatz mit seinen P00, S00, R00, U00 Dateien die richtige Lösung ist, weiß ich auch nicht.
    • An dem CVT Format für die GEOS Dateien führt wohl kein Weg vorbei.


    Welche normalen Aktionen/Befehle sollen unterstützt werden?

    • Inhaltsverzeichnis anzeigen (DIR)
    • Partitionen anzeigen (bei den Container-Formaten D1M, D2M, D4M, DHD)
    • Anzeigen
    • Editieren
    • Kopieren
    • Bewegen
    • Umbenennen
    • Löschen
    • Verzeichnis anlegen

      • 1581 Unter Partition
      • CMD Unterverzeichnis
    • Verzeichnis wechseln

      • 1581 Unter Partition
      • CMD Unterverzeichnis
    • Diskettennamen und Disketten-ID ändern (auch von 1581 Unter Partition und von CMD Unterverzeichnissen)
    • usw.
    • Dateieigenschaften (file attibutes) ändern

      • Nur lesen
      • Versteckt
      • Archiv
      • System
      • Datum
      • Zeit
    • Datei Informationen anzeigen (Bei GEOS Dateien erfolgt eine erweiterte Ausgabe)

    Anmerkungen:

    • Die Aktionen welche Änderungen am Disk-Image vornehmen müssen fehlerfrei sein!
    • Vielleicht sollte man sogar eine Protokoll System einbauen, welches alle vorgenommen Änderungen an einem Disk-Image aufzeichnen kann. (Lade Block XX, Schreibe Block XX alte Blockdaten neue Blockdaten usw.) So könnte man Fehler in an den Änderungen am Disk-Image vielleicht viel schneller erkennen.
    • Für die Basis Funktionen solle es Test Funktionen geben, die dessen Funktion überprüfen. Ich denke da in richtig TDD (Testgetriebene Entwicklung).


    Wie soll eine Funktion zum Anlegen von neuen leeren Disk Images aussehen?

    • Disk Image Format Auswahl
    • Diskettennamen / ID
    • Fehlerinformationen Ja/Nein
    • Als GEOS Diskette erstellen
    • 35 oder 40 Spuren (Speed DOS/ Dolphin DOS / ProLogic DOS)
    • usw.

    Anmerkung:

    • Die Dialoge für das Anlegen von neuen leeren Disk Images können sehr umfangreich werden, da jedes Format seine eigenen Parameter mitbringen.
    • Bei den Container Formaten D1M, D2M, D4M, DHD halte ich es fast für sinnlos schon Partitionen anzulegen. Vielleicht macht eine Native Partition noch Sinn.


    Wird auch eine Funktion zum Formatieren von Disk Images benötigt?

    • Ja
    • Nein

    Anmerkung:

    • Eine solche Funktion ist eigentlich nur bei den Containerformaten D1M, D2M, D4M, DHD sinnvoll, da hier einzelne Partitionen formatiert werden können.
    • Aber auch das Formatieren von 1581 Unter Partition wäre sinnvoll.


    Ist eine Funktion zum Überprüfen von Disk Images nötig?

    • Ja
    • Nein

    Anmerkung:

    • Eine solche Funktion halte ich schon für sinnvoll.
    • Es müssten auch GEOS Disketten geprüft werden können.


    Sollen auch Packer/Archiv Funktionen integriert werden?

    • Ja
    • Nein


    Welche Dateiauswahloptionen sollen zur Verfügung stehen?

    • Gruppe auswählen (englisch: Select Group)
    • Gruppenauswahl rückgängig (englisch: Unselcet Group)
    • Auswahl umkehren (englisch: Invert Selection)
    • Auswahl wiederholen (englisch: Restore Selection)


    Wie soll die korrekte Anzeige des PETSCII erfolgen?

    • Verwenden einer modernen Schriftart >> z.B. die C64 TrueType (TTF) Fonts von Style
    • Umschaltung der Zeichensätze (Großschrift/Grafikzeichen und Groß-/Kleinschrift)


    Welche Plattformen sollen unterstützt werden?

    • Windows 10 (64-Bit)
    • macOS (64-Bit)
    • Linux (64-Bit)
    • Amiga?

    Anmerkung:

    • Hier stellt sich die Frage, soll die Anwendung Plattformübergreifend entwickelt werden?
    • Oder versucht man eine Programmiersprache zu wählen, welche einfach auf andere Plattformen zu übertragen ist. Ich denke da z.B. an ANSI C
    • Bleibt die Wahl des richtigen GUI-Toolkits, welches sowohl mit der Programmiersprache aber auch mit der Plattform verbunden ist.
    • Trennt man bei der Umsetzung die GUI vollständig von der Logik und schafft man es vielleicht so wenigsten einen Teil Plattformunabhängig zu realisieren? Also z.B. die gesamte Logik in ANSI C programmieren und nur eine separate GUI für jede Plattform. Aber ist ANSI C wirklich eine gute Idee?
    • Oder doch lieber auf Java setzen, welches es mit samt einem GUI-Toolkit für fast jede Plattform gibt?
    • Aber auch Free Pascal ist eine Überlegung wert, da es auch ein plattformübergreifendes GUI-Toolkit mitbringt. Und Free Pascal erzeugt richtige EXE Programme und auch richtige DLL und das auf jeder unterstützten Plattform.
    • Man könnte die gesamte Logik auch mit einer Free Pascal DLL umsetzen, welche auf allen Systemen kompilierbar ist. Dann muss man aber noch einen Weg finden, um auf den verschiedenen Plattformen mit der jeweiligen DLL geschickt zu kommunizieren.


    Welche Programmiersprache soll verwendet werden?

    • ANSI C
    • C
    • C++
    • C#
    • Java
    • Pascal
    • Python
    • Perl

    Anmerkungen:

    • Ja, welche der Sprachen ist zukunftssicher?
    • Ich würde eine einfache Sprache bevorzugen, damit Viele Entwickler Änderungen durchführen können.


    Welches GUI-Toolkit soll verwendet werden?

    • plattformübergreifend:

      • GTK+ (in Java z. B. via SWT)
      • Qt
      • wxWidgets
      • Tk
      • FLTK
      • Swing (in Java)
      • JavaFX
      • FireMonkey (FMX, in Delphi)
      • Lazarus Component Library (in Free Pascal)
    • Windows:

      • Microsoft Foundation Classes (MFC)
      • Visual Component Library (VCL, in Delphi)
      • Win32 (WinAPI)
      • Windows Presentation Foundation (WPF)
      • Windows Forms (.NET)
    • macOS:

      • Cocoa
      • Carbon

    Anmerkungen:

    • Auch muss man sich fragen, welches der GUI-Toolkit ist zukunftssicher.
    • Kann man mit dem entsprechenden GUI-Toolkit auch die gewünschten Anforderungen umsetzen? Ich denke dabei z.B. an das Positions-Genaues-Einfügen per Drag & Drop. Also das Einfügen genau zwischen 2 Zeilen in einer Liste. Dies wird meistens mit einer Linie Zwischen den 2 Zeilen verdeutlicht.
    • Die Plattformabhängigkeit ist bei der GUI-Toolkit Auswahl natürlich die wichtigste Frage.


    Wie soll Grafische Benutzeroberfläche aussehen?

    • Zwei-Fenster

      • F-Tasten / Schaltflächen
      • Drag & Drop
      • Copy & Paste
    • Ein-Fester

      • Drag & Drop
      • Copy & Paste
    • Mehrfach-Dokument-Oberfläche (MDI)

      • Drag & Drop
      • Copy & Paste

    Anmerkungen:

    • Die Zwei Fensteransicht ist bekannt vom Norton Commander und wurde z.B. beim Star Commander und 64Copy eingesetzt.
    • Die Ein-Fester-Technik ist vom Windows Explorer her bekannt und wird z.B. vom DiskImagery64 eingesetzt.
    • Mehrfach-Dokument-Oberfläche (MDI) ist meines Achtens etwas aus der Mode gekommen. Z.B. hatten ältere Versionen von MS Excel eine Mehrfach-Dokument-Oberfläche. DirMaster verwendet auch eine Mehrfach-Dokument-Oberfläche.
    • Star Commander und 64Copy können weder Drag & Drop noch Copy & Paste. Oder ging Drag & Drop in MS-DOS schon?
    • Erst durch die Drag & Drop Methode, kann ein Positions-Genaues-Einfügen einer Datei in ein Disk Image erfolgen. Da die Dateinamen in einem Disk Image, bei der Anzeige nicht sortiert werden, ist ein Positions-Genaues-Einfügen schon irgendwie nützlich. Das geht zwar schon in Richtung Directory Manipulation, aber hier würde ich mal eine Ausnahme machen.
    • Für richtige Directory Manipulation würde ich einen speziellen Editor anbieten aber das ist ein anderes Thema.


    Wie soll mit den Commodore DOS Dateinamen im Dateisystem umgegangen werden?

    • max. Anzahl Zeichen in einem Dateinamen
    • Zeichensatz (zulässige Zeichen)
    • Groß-/Kleinschreibung
    • unzulässige Zeichen
    • unzulässige Dateinamen


    Wie muss der Zugriff auf eine Datei in einem Disk-Image erfolgen?

    • Ausschließlich über den Dateinamen
    • Ausschließlich über die Position/Index im Inhaltsverzeichnis (DIR)
    • Über Dateinamen und über die Position/Index


    Was soll geschehen, wenn Commodore DOS Dateinamen eines Images nicht eindeutig im Dateisystem abgelegt werden können (Doppelte Dateinamen)?



    Anmerkungen:

    • Die max. Anzahl von Zeichen in einem Dateinamen sollte für moderne Dateisysteme kein Problem darstellen. Die 16 Zeichen des Commodore DOS sollten alle modernen Dateisysteme speichern können.
    • Die Unterscheidung der Groß-/Kleinschreibung ist schon eher ein Problem, da viele Betriebssysteme standardmäßig keine Unterscheidung der Groß-/Kleinschreibung durchführen, selbst dann wenn das Dateisystem dies unterstützt (z.B. Windows+NTFS).
    • Die zulässigen und unzulässigen Zeichen können auch noch ein Problem darstellen. Durch Directory-Manipulationen sind fast alle 256 Zeichen in den Dateinamen in einem Disk Image möglich. Damit haben aber moderne Dateisysteme ihre Schwierigkeiten.
    • Die Frage ist, ob man eine geeignete Unicode Konvertierung findet, welche jeden Fall abdeckt.
    • Oder ist der PC64 Ansatz mit seinen P00, S00, R00, U00 Dateien eher eine Lösung für das Dateinamensproblem.


    Wie soll die Dateiarten im Dateisystem abgelegt werden?

    • Als Dateiendung (.SEQ .PRG .USR .REL .CVT)
    • Als PC64 Datei (P00, S00, R00, U00)


    Wie soll die Eingabe von PETSCII erfolgen?

    • Virtuelle Tastatur mit allen PETSCII Zeichen


    Unter welcher Lizenz sollte die Entwicklung erfolgen?

    • MIT-License
    • Apache License
    • GNU General Public License (GPL)
    • GNU Lesser General Public License (LGPL)
    • Mozilla Public License (MPL)
    • BSD License

    Anmerkungen:

    • Die Entwicklung sollte auf jeden Fall Open Source sein.


    Benötigt man eine Batch-Verarbeitung von Funktionen?

    • Kommandozeile
    • Batch-Verarbeitung per GUI

    Anmerkungen:

    • Der Star Commander kann eine Batch-Verarbeitung per Kommandozeile.
    • Der DirMaster besitzt ein Fenster (GUI) für die Batch-Verarbeitung.


    Benötigt man eine Ansteuerung von echten Commodore Laufwerken wie es z.B. der Star Commander ermöglicht?

    • Ja
    • Nein

    Anmerkung:

    • Ich denke für die Ansteuerung von echten Laufwerken gibt es andere Tools (z.B. ZoomFloppy), welchen diese Aufgabe besser erfüllen können.
    • Natürlich wäre die Ansteuerung von echten Laufwerken integriert im modernen Disk Image Tool eine feine Sache :-)


    Welche Anzeige Optionen sollen vorhanden sein?

    • Spaltenmodus (englisch: Column mode)

      • Kurz (englisch: Brief)
      • Voll (englisch: Full)
      • Breit (englisch: Wide)
      • Info (nur bei Zwei-Fenster Absicht sinnvoll)
      • Quick View (englisch: Quickview) (nur bei Zwei-Fenster Absicht sinnvoll)
    • Sortierreihenfolge (englisch: Sort order)

      • Name (englisch: Name)
      • Erweiterung (englisch: Extension)
      • Zeit (englisch: Time)
      • Größe (englisch: Size)
      • Unsortiert (englisch: Unsorted)
      • Reverse
      • Filter für Fenster
    • Norton Commander

      • Dateiname

        • Einschließen
        • Ausschließen


      • Dateidatum

        • Nach
        • Vor


      • Dateigröße

        • Über
        • Unter
      • Attributfilter

        • Versteckt
        • Nur lesen
        • Verzeichnis
        • System
        • Archiv
        • Kein
    • Star Commander

      • Hidden files
      • All fieles
      • PC executable files
      • PC archive files
      • CBM image files
      • CBM archive files

    Anmerkung:

    • Sobald die Sortierung nicht mehr über Index erfolgt, bzw. wenn ein Filter angewendet wird, dann ist ein Positions-Genaues-Einfügen z.B. per Drag & Drop nicht mehr möglich.
    • In modernen Anwendungen sind Listen meist auf allen sichtbaren und unsichtbaren Spalten sortier- und filterbar.


    Welche externen Funktionen (Funktionen, welche nichts mit der Übertragung bzw. Anzeige von Dateien zu tun haben) soll integriert werden?

    • BAM Editor

      • Block Anzeigen/Ändern
    • Dateianzeiger

      • Bilder (HiRes, Koala, Amica Paint, Art Studio, Artist, Blazing Paddle;, Centauri, Cheese, CDU, Dolphin Ed, Drazpaint, Face Paint, GeoPaint, GeoPhotoAlbum, Garfield, Giga Paint, Giga Paint MC, Hi Eddi, Image System, Image System MC, Interpaint, Interpaint MC, Micro, Mono Magic, OCP, Paint Magic, Picasso, Rainbow, Run Paint, Saracen, Vidcom)
      • Assembler, Basic, Doodle, Font, HEX, SEQ
      • GEOS

        • GeoWrite
        • GeoPaint
        • GeoPhotoAlbum
        • usw.
    • Dateikonverter

      • Bilder
      • Basic
      • GEOS

        • GeoWrite >> RTF
        • GeoPaint >> PNG
        • usw.
    • Disk Images Converter

      • D64 >> G64
      • G64 >> D64
      • D64 >> ZipCode 6-pack
      • ZipCode 6-pack >> D64
      • G64 >> ZipCode 6-pack
      • ZipCode 6-pack >> G64
      • usw.
    • Directory Editor

      • Dateien Verschieben
      • Dateinamen ändern auch nach dem "
      • Fertige Linien zur Auswahl zur Verfügung stellen

    Anmerkungen:

    • An dieser Stelle kommt mir dir Gedanke, das man vielleicht eigene Plug-Ins / Add-Ons unterstützen sollte. So hätte man die Möglichkeit die Anwendung zu erweitern.


    In welche Sprachen soll die Anwendung zur Verfügung stehen?

    • Deutsch
    • Englisch
    • andere

    Anmerkung:

    • In einer modernen Anwendung sollte es möglich sein die Anwendungssprache zu ändern.
    • Deutsch und Englisch sollten da auf jeden Fall zur Auswahl vorhanden sein.
    • Die Anwendung sollte so gestaltet sein, das es möglich ist diese auf einfache Weise in andere Sprachen zu übersetzen. Ich denke da z.B. an XLIFF oder an Windows NET (*.resx) oder Java (*.properties).


    So das soll erst einmal reichen. Vielleicht hat der Eine oder Andere noch ein paar andere Ideen oder Anregungen zu diesem Thema.


    Gruß
    Hans

    Hallo,
    ich habe mal ein paar Tests bezüglich des Ex- und Imports von Geos Dateien mit der neuen DirMaster Version 3.1.2 gemacht.


    DirMaster 3.1.2:
    Exportieren von Geos Dateien von einem D64 Image auf einen PC Datenträger
    per Drag&Drop:

    • Werden Geos Dateien per Drag&Drop aus einem Image auf einen PC Datenträger gezogen, entstehen CVT Dateien.
    • Diese Dateien haben auch die Dateiendung CVT.
    • Die entstanden CVT Dateien sind durchaus brauchbar.
    • Die entstanden CVT Dateien sind leider nicht CLEAN, sie beinhalten leider noch Informationen welche beim Wiederherstellungsprozess nicht benötigt werden.

    • Auch die Dateikennung ist etwas abweichend "SEQ formatted GEOS file". Eigentlich gibt es nur die 2 bekannten Dateikennungen "PRG formatted GEOS file V1.0" und "SEQ formatted GEOS file V1.0".
    • Was ist eigentlich der Unterschied zwischen einem CVT mit der Dateikennung "PRG formatted GEOS file V1.0" und einem CVT mit Dateikennung "SEQ formatted GEOS file V1.0"?
    • Aber dennoch die exportierten CVT Dateien sind durchaus brauchbar.

    per Batch Export:

    • Auch beim Export von Geos Dateien per Batch Export werden dieselben CVT Dateien (wie beim Drag&Drop Export) exportiert.
    • Nur die Dateiendungen sind dabei nicht CVT sondern wohl USR, was etwas unschön ist.

    Import einer CVT Datei von einem PC Datenträger in ein D64 Image
    per Drag&Drop:

    • Werden CVT Dateien per Drag&Drop von einem PC Datenträger auf ein Image gezogen, enstehen GEOS Dateien.
    • Geos zeigt diese Dateien auch mit dem korrekten Icon an.
    • Ein Validate unter Geos bringt aber eine Fehlermeldung "Abgebrochen wegen Diskfehler: I:02 Lfwk. B track FF sector 01 (hex)" sobald eine CVT Datei auf ein Image gezogen wurde.

      • Der Fehler entsteht da die ersten 2 Byte des Info-Blocks falsch sind!
      • Die ersten 2 Byte des Info-Blocks sind $FF $01
      • Nach einer Korrektur der ersten 2 Byte des Info-Blocks auf $00 $FF klappt ein Validate unter Geos tadellos.

    DirMaster 3.1.1:

    • Der Export von Geos Dateien von einem D64 Image auf einen PC Datenträger ist in der Version 3.1.1 unbrauchbar.
    • Es werden keine (brauchbaren) CVT Dateien erzeugt.
    • Manche Geos Dateien werden gar nicht erst exportiert.
    • Der Import der Version 3.1.1 hat genau das gleiche Verhalten wie die Version 3.1.2 gezeigt! -> Gleicher Fehler beim Info-Block!

    Fazit:

    • Der Export von Geos- Dateien zu wurde in der Version 3.1.2 korrigiert.
    • Der Fehler mit den ersten 2 Byte im Info-Block besteht weiterhin.

    Gruß
    Hans

    Hallo,
    ich habe gerade mal in der Wolke nach dem deutschen 1581 Handbuch gesucht.
    Leider bin ich da nicht fündig geworden. :(


    Kann das bitte mal jemand die Wolke stellen.


    Danke und Gruß
    Hans

    Weil die RL kann auch die 15xx emulieren (nur die Diskette) und zusätzlich Native Partitionen.
    Diese Partitionen werden vom Cevi als Disklaufwerk erkannt und auch so behandelt.
    Auch für MP3 ist z.B. eine 1541-Partition, eine 1541-Diskette und von diesen können mehr als 4 auf der RL existieren.
    Diese können unter MP3 mit dem Befehl C=J ausgewählt und gewechselt werden.

    Ach, ich hab ja auch die Treiber CMD RL 1541, CMD RL 1571, CMD RL 1581 unterschlagen.
    Die Treiber CMD RL 1541, CMD RL 1571, CMD RL 1581 und CMD RL Native können jeweils bis zu 4 mal als MP3 Laufwerk verwendet werden.
    Mit diesen Treibern hat man dann Zugriff auf die RAMLink Partitionen mit der jeweilige Partitionsart. Die Partition wird bei den MP3 Laufwerken über den untern kleinen Pfeil ausgewählt wenn ich mich nicht irre.


    Also,

    • mit dem CMD RL 1541 Treiber kann man mittels dem Befehl C=J auf eine der, auf dem RAMLink vorhandenen, 1541 Partitionen (das können mehr als 4 sein) umschalten
    • mit dem CMD RL 1571 Treiber kann man mittels dem Befehl C=J auf eine der, auf dem RAMLink vorhandenen, 1571 Partitionen (das können mehr als 4 sein) umschalten
    • mit dem CMD RL 1581 Treiber kann man mittels dem Befehl C=J auf eine der, auf dem RAMLink vorhandenen, 1581 Partitionen (das können mehr als 4 sein) umschalten
    • mit dem CMD RL Native Treiber kann man mittels dem Befehl C=J auf eine der, auf dem RAMLink vorhandenen, Nativen Partitionen (das können mehr als 4 sein) umschalten

    So korrekt?

    Nicht getestet, aber wenn man von einer HD81 bootet, und dann vier RAM-Laufwerke einrichtet, dann müsste Reboot zwar von der HD81 gestartet werden, die Konfiguration wird aber beim ReBoot aus dem Speicher übernommen. Aber mal ehrlich... muss man das haben?
    Ich kann das aber mal testen... keine Ahnung ob das funktioniert.

    Nein, das muss man nicht haben :)


    Aber was echt toll wäre, ist eine Möglichkeit den Bootvorgang des MP3 in VICE zu beschleunigen, welche auch mit realer Hardware realisierbar ist. Da VICE weder das RAMLink noch eine CMD HD emulieren kann, fehlt irgendwie ein großer permanenter Speicher (16 MB Festplatte oder so) und eine Möglichkeit schnell zu booten. Ich denke da an einen MP3 Treiber für das IDE64 http://www.ide64.org/ (IDE64 Native, IDE64 1541, IDE64 1571, IDE64 1581 oder so ähnlich). Wenn man dann noch vom IDE64 den MP3 booten könnte wäre das echt perfekt. Und ich glaube dafür findet sich auch der eine oder andere der diesen Treiber auf realer Hardware benutzen möchte.

    Die letzte Spalte: die separaten SuperRAM, C=REU und GeoRAM-Native-Treiber können je nur 1x genutzt werden. Alles andere würde ein zusätzliches Speichermanagement erfordern das evtl. wieder wegfallen könnte wenn MP3 die vollen 16Mb als GEOS-DACC unterstützt und nicht nur 4Mb. Daher mach ich mir die Arbeit dazu vorerst nicht. Also geht nur 1xSuperRAM, aber das in jeder Kombination mit 1xC=REU oder 1xGeoRAM.

    Ok, also kann man die Treiber SuperRAM Native, C=REU-Native, GeoRAM-Native jeweils nur 1mal verwenden. Das reich wohl auch.


    Nur den Treiber CMD RL Native kann man bis zu 4mal verwenden und somit bis zu 4 RAM Laufwerke im MP3 erstellen. Ein zusätzliches Speichermanagement im MP3 ist da wohl nicht notwendig, da der Treiber CMD RL Native die vorkonfigurierten Partitionen des RAMLinks benutzt. D.h. die Partitionierung des RAMLinks muss außerhalb vom MP3, mit einem entsprechenden Tool, erfolgen. Ist das so korrekt?


    Die Erweiterung des GEOS-DACC von 4MB auf 16MB wäre schon toll :)
    Aber wenn ich das richtig sehe würde dies, das Problem auch nur für eine der möglichen vorhanden Speichererweiterungen lösen.


    Ach ja ich hatte in meiner Tabelle leider noch eine Spalte vergessen. Zwischen den 2 letzten Spalten müsste noch die Spalte RAM Native eingefügt werden. Mit dem Treiber RAM Native sollten auch fast immer max. 4 RAM Laufwerke möglich sein, sofern genügend DACC-Speicher dafür vorhanden ist. Bin mir nicht sicher wieviel Speicher die kleinste mögliche Native Partition belegt.


    Desweitern ist mir noch aufgefallen, das Anlegen von 4 RAM Laufwerken macht eigentlich nur dann sinn, wenn man von einem dieser Laufwerke auch den MP3 Booten kann. Und wenn ich das richtig sehe ist genau dies nur dann geben, wenn eines der RAM Laufwerke eine RAMLink Partition ist. Stimmt das so?

    Hallo,
    ich habe mal eine Liste von allen mir bekannten Speichererweiterungen erstellt. In die Liste habe ich zusätzlich noch Hardware-"Emulationen" (Ultimate-II+, Turbo Chameleon 64) und eine Emulationssoftware (VICE) aufgenommen, da nur diese den maximalen Speicherausbau unterstützen. In der Legende unter der Tabelle ist angeben, was die jeweilige Tabellenspalte beinhaltet.


    Ich hoffe die Tabelle ist so korrekt. Ich bin mir z.B. nicht sicher, ob wirklich mehrere RAM Laufwerk außerhalb des System-RAMs angelegt werden können.


    Also, bitte überprüft meine Angaben in der folgenden Tabelle.


    RAM-Art Hardware/Software MB KB System-RAM (DACC) RAM 1541 RAM 1571 RAM 1581 RAM Laufwerk außerhalb des System-RAMs
    RamLink RamLink 16 16384 4 MB max. 4 max. 4 max. 4 max. 4 mit dem Treiber 'CMD RL Native'
    RAMCard RAMCard 16 16384 4 MB max. 4 max. 4 max. 4 max. 4 mit dem Treiber 'SuperRAM Native'
    RAMCard VICE 16 16384 4 MB max. 4 max. 4 max. 4 max. 4 mit dem Treiber 'SuperRAM Native'
    C=REU Modell 1700 0,125 128 ? - - - -
    C=REU Modell 1764 0,25 256 0,25 MB max. 1 - - -
    C=REU Modell 1750 0,5 512 0,5 MB max. 2 max. 1 - -
    C=REU Super 1750 Clone 0,5 512 0,5 MB max. 2 max. 1 - -
    C=REU CMD1750 0,5 512 0,5 MB max. 2 max. 1 - -
    C=REU CMD 1750XL 2 2048 2 MB max. 4 max. 4 max. 2 -
    C=REU Ultimate-II+ 16 16384 4 MB max. 4 max. 4 max. 4 max. 4 mit dem Treiber 'C=REU-Native' von 2018
    C=REU Turbo Chameleon 64 16 16384 4 MB max. 4 max. 4 max. 4 max. 4 mit dem Treiber 'C=REU-Native' von 2018
    C=REU VICE 16 16384 4 MB max. 4 max. 4 max. 4 max. 4 mit dem Treiber 'C=REU-Native' von 2018
    GeoRAM GeoRAM 0,5 512 0,5 MB max. 2 max. 1 - -
    GeoRAM BBG RAM 1 1024 1 MB max. 4 max. 2 max. 1 -
    GeoRAM NeoRAM 2 2048 2 MB max. 4 max. 4 max. 2 -
    GeoRAM Turbo Chameleon 64 4 4096 4 MB max. 4 max. 4 max. 4 -
    GeoRAM VICE 3.1 4 4096 4 MB max. 4 max. 4 max. 4 -
    GeoRAM Ultimate-II+ 16 16384 4 MB max. 4 max. 4 max. 4 max. 4 mit dem Treiber 'GeoRAM-Native' von 2018
    GeoRAM VICE mit Patch 16 16384 4 MB max. 4 max. 4 max. 4 max. 4 mit dem Treiber 'GeoRAM-Native' von 2018


    Legende:

    • RAM-Art.......................................................Hier ist die Art des Speichers, welchen der MP3 kennt, angegeben. Der MP3 kennt die 4 Speicherarten RamLink, RAMCard, C=REU, GeoRAM.
    • Hardware/Software.......................................Hier ist der Name der Speicherweiterung, der Hardware-"Emulation" bzw. der Emulationssoftware angeben.
    • MB...............................................................Kapazität der Speichererweiterung in MB
    • KB................................................................Kapazität der Speichererweiterung in MB
    • System-RAM (DACC)......................................Hier ist angeben wieviel Speicher dem MP3 System RAM (DACC) zur Verfügung steht. Maximal 4 MB.
    • RAM 1541.....................................................Hier ist angeben, wie viele 1541 RAM-Laufwerke angelegt werden können.
    • RAM 1571.....................................................Hier ist angeben, wie viele 1571 RAM-Laufwerke angelegt werden können.
    • RAM 1581.....................................................Hier ist angeben, wie viele 1581 RAM-Laufwerke angelegt werden können.
    • RAM Laufwerk außerhalb des System-RAMs.....Hier ist angeben, wie viele Native RAM-Laufwerke außerhalb des System-RAMs angelegt werden können.


    Wenn VICE es unterstützen würde könnte ich einen ScreenShot präsentieren der vier RAM-Native-Laufwerke zeigt und jedes Laufwerk liegt auf einer anderen Speichererweiterung (RamLink, C=REU, GeoRAM, RAMCard).

    Cool! :thnks:
    Fragen: Es müssen vier unterschiedliche Speichererweiterung sein, um die maximale Speicher Kapazität zu nutzen? Also 2mal C=REU oder 2mal GeoRAM funktionieren nicht? Funktioniert das technisch überhaupt 2mal C=REU oder 2mal GeoRAM im RamLink zu betreiben?


    Ok, wenn ich mal von den vier unterschiedliche Speichererweiterung ausgehe, kommt man mit realer Hardware C=REU (CMD 1750XL 2MB) + GeoRAM (NeoRAM 2 MB) + RAMCard 16 MB + RamLink 16 MB auf 36 MB. Oder gab es noch größere richtige Speichererweiterungen?


    Um jetzt mit Hardware-"Emulationen" auf den Maximalwert von 64 MB zu kommen, müsste man 2 Ultimate-II+ am RamLink betreiben. Die eine emuliert eine C=REU mit 16 MB die andere emuliert GeoRAM mit 16 MB. Die Frage ist funktionieren 2 Ultimate-II+ am RamLink?


    In Vice kann man leider kein RAMLink emulieren. Man kann eine RAMCard mit 16 MB und C=REU mit 16 MB und wohl GeoRAM mit 16 MB (mit dem Patch von MarkusC64) emulieren. Man kann durchaus eine C=REU und GeoRAM zur gleichen Zeit emulieren. Ich frage mich nur, wie dies ohne RAMLink mit realer Hardware gehen soll.


    Gruß
    ZAK256

    Hallo Lars,

    Erstellt wurde der Lister mit dem Borland C++ Builder 5 und der Windows API

    danke für diese Informationen, ich habe diese zur Liste von Disk-Image-Tools im Wiki hinzugefügt

    und hat selbstverständlich GeosSupport (wird ja sogar in dem Screenshot gezeigt)

    Ja, die Spalte "Geos Dateien" war etwas verwirrend. Ich habe die jetzt geändert in "Geos Datei Import/Export". Damit ist das Exportieren einer GEOS Datei aus einem Disk-Image bzw. das Importieren einer GEOS Datei in ein Disk-Imgage gemeint. Meist kommt dazu das CVT Format zum Einsatz. Habe jetzt aber einen Hinweis auf die Exportfunktionen des D64Lister hinzugefügt. Die Exportfunktionen des D64Lister sind ja eher Konvertierungen in ein PC lesbares Format.

    "Zeigt nur den Inhalt eines D64 Disk-Image an." halte ich auch untertrieben

    Ja, das ist wiklich untertrieben, bei dem Funktionsumfang deines Prgogramms. Der Hinweis war auf die Fähigkeiten hinsichtlich der Dateioperationen (wie Kopieren, Verschieben, Löschen) zwischen einem Disk-Image und einem anderen Dateisystem bezogen. Ich habe den Text jetzt aber abgeändert, schau mal ob dies jetzt ok ist.


    ... wüsche einen schönen Urlaub


    Gruß
    Hans

    Na dann fang ich glich mal an.
    Hab den Abschnitt „Siehe auch“ mit einem Verweis auf die Seite https://www.c64-wiki.de/wiki/Liste_von_Disk-Image-Tools hinzugefügt. Und in der Liste von Disk-Image-Tools hab ich den Link auf die neue interne Seite umgestellt (also http://www.hardworks.de/d64lister/index.php entfernt).


    Vielleicht kann Lars etwas über die benutzte Programmiersprache, das verwendete GUI-Toolkit und die angewandte Entwicklungsumgebung verraten. Ich würde dies Informationen gern der Seite https://www.c64-wiki.de/wiki/Liste_von_Disk-Image-Tools hinzufügen.


    Danke und Gruß
    Hans

    Hallo,
    na hier ist ja was los :-)


    Als ich mich 2014, mit meinen ersten Posts hier im Forum, auf die Suche nach dem MegaPatch 3 BUILD:FULL-090100.2020 (deutsch) begeben habe, hätte ich nie damit gerechnet, das der Quellcode einmal verfügbar sein wird und es sogar Fehlerbehebungen und womöglich Neuerung geben wird.


    Also erstmal vielen Dank dafür.


    Damals hatte ich in dem Post "Suche MegaPatch 3 BUILD:FULL-090100.2020 (deutsch) für die beste GEOS Hardware/Software Emulation" mich auch mit den Funktionalen unter Unterschieden zwischen der Version 150799.0852 und der Version 090100.2020 etwas beschäftigt. In der Version 090100.2020 ist wohl zum Einen der SuperRAM Laufwerk Treiber, welcher es ermöglicht die SuperRam Card als RAM-Laufwerk zu verwenden, hinzugekommen. Zum Anderen ist wohl auch noch die Unterstützung eines Parallelkabels zwischen RAMLink und der CMD-HD hinzugekommen. Wenn ich den Quellcode richtig deute sind beide funktionalen Erweiterungen enthalten. Oder?


    Hier nochmal das Bild von damals:


    Gruß
    Hans

    Hi,


    im C64 Wiki gibt es eine Seite mit einer Liste von Disk-Image-Tools. (siehe https://www.c64-wiki.de/wiki/Liste_von_Disk-Image-Tools)
    Diese Seite habe ich mal erstellt. In der Liste ist zu fast jedem Tool die Programmiersprache angeben und bei vielen dieser Tools ist der Quellcode öffentlich verfügbar.


    Z.B. der D64 Editor ist in Visual Basic geschrieben und der Quellcode kann von der Seite http://www.d64editor.com/heruntergeladen werden. Visual Basic kommt VBA schon recht nahe.


    Gruß
    Hans

    Hallo,


    ich habe mir mal folgendes ausgedacht, bin mir nur nicht sicher ob dies technisch umsetzbar ist.


    Die Laufwerkskomponenten (Motor, Steppmotor und Schreib-/ Lesekopf) sind meine achtens alle per Stecker mit der eigentlichen Platine verbunden. Deshalb stelle ich mir ein Board vor, welches einfach zwischen die Laufwerkskomponenten und der Commodore Platine gesteckt wird. Somit könnte den Umbau auch ein Laie (wie ich) durchführen, da nur die Steckverbindungen gesteckt werden müssen. Das neue Board könnte dabei die Kontakte von verschiedenen Versionen von Laufwerken (1541-1, 1541-2, 1541-3, 1541-II, usw.) anbieten, da ich glaube das es da unterschiede gibt.


    Durch einen Schalter (oder sogar per Software) könnte das neue Board an bzw. ausgeschalten werden. Ist das neue Board ausgeschalten, so kann das Laufwerk wie gewohnt am C64 benutzt werden.


    Das neue Board hätte Einfluss auf alle Komponenten des Laufwerks. Es kann also die Drehzahl des Motor beeinflussen, den Kopf positionieren und die Daten vom Schreib-/ Lesekopf verarbeiten. Somit sollte der Erstellung von G64 Images nichts im Weg stehen. Ich würde sogar noch einen Schritt weitergehen und gleich P64 (oder FDI) Images erstellen, da man die Daten (also die Pulse) vom Schreib-/ Lesekopf zur Verfügung hat.


    Das einzige was dann noch fehlt ist eine Index Erkennung per Loch, aber man kann nicht alles haben :-)



    Ich habe mich auch gerade mit den Taktraten ein wenig beschäftigt, da ich mir die Frage beantworten wollte, ob man mit einer 1541 auch andere Schreib- bzw. Lesegeschwindigkeiten als die 4 bekannten (307692, 285714, 266667, 250000 Bits/sec) verarbeiten kann.
    Bei der 1541 steuert wohl der VIA2 über einen Teiler (programmierbarer Zähler) den Takt des Gate Arrays (325572-01). Das Gate Array (325572-01) arbeitet dann mit verschiedenen Taktraten 1.2307 MHz (16/13), 1.1428 MHz (16/14), 1.0666 MHz (16/15), 1 MHz (16/16).


    Das des Gate Array (325572-01) steuert dann wohl selber die Schreib- /Lesekopf Leitungen des Laufwerks an. Somit haben die Taktraten wohl einen direkten Einfluss auf die Schreib-/ Lesegeschwindigkeit.


    Dies ist sehr gut in dem SERVICE MANUAL MODEL 1540/1541 DISK DRIVE auf Seite 10 „The Clock Circuits“ beschrieben.



    Bei der 1541-II arbeitet das Gate Array wohl immer mit einer festen Taktrate. Die Steuerleitungen (DS0 und DS1) des VIA2 sind direkt mit dem Gate Array (251828) verbunden. Die Steuerung der Schreib- /Lesekopf Leitungen des Laufwerks werden nicht direkt vom Gate Array übernommen. Dazu kommt der SONY CX20185 (oder kompatible) Chip zum Einsatz.
    Leider habe ich keine Beschreibung gefunden, wie das Gate Array (251828) bzw. der SONY CX20185 dabei hinsichtlich der Schreib- bzw. Lesegeschwindigkeiten arbeitet.



    Also, so hundertprozentig konnte ich mir meine Frage nicht beantworten. Kann man mit einer 1541 bzw. 1541-II wirklich nur mit den 4 bekannten Schreib- bzw. Lesegeschwindigkeiten (307692, 285714, 266667, 250000 Bits/sec) arbeiten. Oder kann man mit Tricks auch in anderen Geschwindigkeiten lesen bzw. schreiben?

    Erstmal vielen Dank für eure Antworten. :thnks:

    Die Liste sieht so etwas verwirrend aus,

    Was genau ist denn so verwirrend?

    denn CBM DOS nützt kein individuelles Aufzeichnungs-Verfahren

    Warum soll das CBM DOS ein individuelles Aufzeichnungs-Verfahren verwenden? Welche Aussage von mir lässt darauf schließen?


    - es werden nur 35 der 40 Spuren genützt (modifizierte Syteme wie z.b. Speeddos oder Dolphindos können auch all 40 Spuren nützen)

    Korrekt, deshalb hab ich in der Commodore DOS Spalte auch nur 35 Spuren eingetragen. Auf die 40 Spuren Varianten habe ich verzichtet, da ich dafür eine separate Spalte anlegen müsste.


    - es werden die Spuren anders nummeriert (von 1-35 statt 0-39), wobei Spur 1 nach CBM Rechnung exakt auf Spur 0 liegt.

    Korrekt, und das kann man in der Tabelle auch erkennen. Die Spur 0 (96 TPI) liegt genau auf Spur 0 (48 TPI) und liegt genau auf Spur 1 nach CBM Rechnung. Das ist in Zeile 4 der Tabelle zu sehen.


    - der Spur-0 Anschlag würde sich bei einem reinen 48TPI System (mit 40 Spuren Steppermotor) ca. auf -0,5 befinden (wenn 0 die erste lesbare Spur ist). Bei CBM ist der Anschlag jedoch aufgrund des 80 Spuren Steppers bei 0,75 (wenn 1 die erste Spur ist)

    Korrekt. Meine Angaben beziehen sich aber alle, auf die Commodore Laufwerke. Also Laufwerke mit einem 48 TPI Schreibkopf und einer 96 TPI Mechanik. Ich habe die Angaben nur aus verschiedenen Sichtweisen betrachtet. Dies ist auch bei den Angaben in der Tabelle so. Also bezieht sich die 48 TPI Spalte nicht auf ein reines 48 TPI System (mit 40 Spuren Steppermotor) sondern auf ein 48 TPI System (mit 80 Spuren Steppermotor), wie es die Commodore Laufwerke aufweisen. Deshalb befindet sich der Anschlag an der ungefähren Position der Spur -0,25 (bei 48 TPI). Die Spur -0,25 (48 TPI) entspricht dann der Spur 0,75 nach CBM Rechnung und der Spur -0,5 (96 TPI).


    Besser wäre eine Liste mit einer Spalte 'Position' (1-80), und daneben welchen diese nach der jeweiligen Nummerierung entspricht? (MFM 40, MFM 80, CBM 35)

    Eine solche Liste kann ich gern noch erstellen. Es ging mir aber in meiner Tabelle darum, die Positionen der einzelnen Spuren und die Position des Anschlags, in den verschiedenen Sichten, genau gegenüberzustellen. Eigentlich wollte ich noch eine Spalte Radius in die Tabelle aufnehmen. Darauf habe ich aber verzichtet, da ich dachte das verwirrt mehr als es hilft. Auf jeden Fall entspricht jede Zeile einem bestimmten Radius, welcher in allen 3 Sichten genau derselbe ist. Somit ist auch die Position des Anschlags in allen 3 Sichten dieselbe. Und auch die Position der Lichtschranke ist in allen 3 Sichten dieselbe.
    Zur Verwirrung könnten die Angaben der normaler weise nicht benutzten Halben-Spuren geführt haben. Ich wollte aber dass in jeder Spalte eine entsprechende Angabe enthalten ist. Z.B. Spur 3 (96 TPI) entspricht der Spur 1,5 (48 TPI) und entspricht der Spur 2,5 nach CBM Rechnung.

    Ich bin mir auch gar nicht sicher, ob die negativen Spuren wirklich einen Mehrwert in der Tabelle bringen. Im Grunde ist der 0-Anschlag ja bei Spur 0, auch wenn er in der Praxis vielleicht leicht darunter liegt. Keines der Laufwerke kann tatsächlich die niedrigeren Spuren verwenden, daher sind sie eigentlich irrelevant.

    Die negativen Spuren habe ich nur mit in die Tabelle aufgenommen, um zu verdeutlichen wie die ungefähren Werte für die Position des Anschlags zu Stande kommen.

    So, ich starte mal einen Versuch meine jetzigen Vermutungen, so verständlich wie möglich zu formulieren. Deshalb habe ich mal meine Vermutungen aus 4 verschiedene Sichtweisen aufgeschrieben.


    Aus 96 TPI - 80 Spuren Sicht:
    Der Anschlag befindet sich zwischen Spur -1 und Spur 0 also ungefähr bei Spur -0,5. Der Schreibkopf befindet sich nach dem Anschlagen (BUMP) auf der Spur 0. Die Lichtschanke bei einer 1570/1571 befindet sich an der Spur 0. Das bedeutet, befindet sich der Schreibkopf auf der Spur 0 ist die Lichtschranke "unterbrochen". Die Erste für den Schreibkopf erreichbare Spur ist die Spur 0. Die Spuren werden von 0 bis 79 gezählt.


    Aus 48 TPI - 40 Spuren Sicht:
    Der Anschlag befindet sich zischen Spur -0,5 und Spur 0 also ungefähr bei Spur -0,25. Der Schreibkopf befindet sich nach dem Anschlagen (BUMP) auf der Spur 0. Die Lichtschanke bei einer 1570/1571 befindet sich an der Spur 0. Das bedeutet, befindet sich der Schreibkopf auf der Spur 0 ist die Lichtschranke "unterbrochen". Die Erste für den Schreibkopf erreichbare Spur ist die Spur 0. Sie Spuren werden von 0 bis 39 gezählt.


    Aus Commodore DOS Sicht:
    Der Anschlag befindet sich zwischen Spur 0,5 und Spur 1 also ungefähr bei Spur 0,75. Der Schreibkopf befindet sich nach dem Anschlagen (BUMP) auf der Spur 1. Die Lichtschanke bei einer 1570/1571 befindet sich an der Spur 1. Das bedeutet, befindet sich der Schreibkopf auf der Spur 1 ist die Lichtschranke "unterbrochen". Die Erste für den Schreibkopf erreichbare Spur ist die Spur 1. Die Spuren werden von 1 bis 35 gezählt.


    Aus MS-DOS bzw. CP/M (MFM) Sicht:
    Diese Sicht entspricht genau der 48 TPI - 40 Spuren Sicht!



    Und hier nochmal in Tabellenform:

    @ZAK256, Diskettenseite 0 ist unten und Seite 1 ist oben. Wenn du mal eine 1541 aufmachst, dann wirst du sehen, daß der S/L-Kopf unten ist.


    Ja, da hab ich mich verschrieben, es geht um die Unterseite (Seite 0) der Diskette.


    It depends how you count, but keep in mind the 1541 is a wide (40-track) RW head in an 80-track capable mechanism, hence you can seek to "half tracks". Because of this, the first available "slot" the 1541 can write data on is the second track available if it were a thinner 80-track RW head.


    That would mean a 1541 can access track 1 of a 96 TPI (80 tracks) drive. Or another view on track 0.5 (semi-track) of a 48 TPI (40 tracks) drive. And that track is what the Commodore Dos calls track 1? Is that what you mean?
    But what about a 1571 in MFM mode that wants to access an MS-DOS or CP/M floppy disk? This access must have access to track 0. Track 0 (usually called track 00) is exactly the same for a 96 TPI (80 tracks) drive and a 48 TPI (40 tracks) drive. In both types of drives I only ever found the radius 2.25 in (57.15 mm) for track 00 in all specifications.
    In German:
    Das würde bedeuten, eine 1541 kann auf der Spur 1 eines 96 TPI (80 Spuren) Laufwerks zugreifen. Oder anderes betrachtet auf Spur 0.5 (halb-spur) eines 48 TPI (40 Spuren) Laufwerks. Und diese Spur nennt das Commodore Dos dann Spur 1? Ist das, was du meinst?
    Aber was ist mit einer 1571 im MFM Modus, welche auf einen MS-DOS oder CP/M Diskette zugreifen will? Dieser Zugriff muss doch auf die Spur 0 zugreifen. Die Spur 0 (meist mit Spur 00 bezeichnet) ist bei einem 96 TPI (80 Spuren) Laufwerk und einem 48 TPI (40 Spuren) Laufwerk genau dieselbe. Bei beiden Laufwerksarten habe ich in allen Spezifikationen immer nur den Radius 2.25 in (57.15 mm) für die Spur 00 gefunden.

    ..., schlägt aber gegen den Anschlag, und bleibt damit auf seiner vorigen Step-Position stehen, nämlich auf Spur 1.


    Die Frage ist nur ist das die Spur 1 eines 96 TPI (80 Spuren) Laufwerks oder eines 48 TPI (40 Spuren) Laufwerks?

    ZAK256 :
    Die Spuren werden von aussen nach innen gezählt, d.h. Spur 1 ist ganz aussen (und somit auch länger, also mit mehre Sektoren als z.b. Spur 35), während Spur 35 bzw. 40 ganz innen sind.
    Deshalb wurde für die 40 Spuren das Fenster nach innen erweitert.


    Ja, dies Spuren werden von außen nach innen gezählt. Das ist mir bekannt. Es geht hier um die äußerste Spur, also um die Spur mit dem größten Radius. Und das auf der Unterseite (Seite 0) der Diskette. Die Fenstererweiterung ist interessant, spielt aber für die Position äußerste Spur wirklich keine Rolle.





    Um meine eigentliche Frage etwas anschaulicher zu gestellten habe ich mal folgende Tabelle erstellt. Die Tabelle zeigt Erst einmal für ein 96 TPI (80 Spuren) Laufwerk und für ein 48 TPI (40 Spuren) Laufwerk die Radius Werte der einzelnen Spuren. Diese Laufwerke sollten MS-DOS bzw. CP/M Disketten verarbeiten können. Den maximalen Radius und auch den minimalen Radius der Spuren habe ich in mehreren Spezifikationen gefunden. Diese Radius –Werte und dessen Spuren nehme ich als Grundlage für die weitre Betrachtung. Die Commodore Laufwerke sind nun weder 96 TPI (80 Spuren) Laufwerke noch 48 TPI (40 Spuren) Laufwerke. Die Commodore Laufwerke haben einen 48 TPI (40 Spuren) Schreibkopf aber eine 96 TPI (80 Spuren) Mechanik (wie es r.cade so treffend formuliert hat). Da die 1570 und die 1571 über einen MFM Modus verfügen, können diese MS-DOS bzw. CP/M Disketten verarbeiten. Dazu ist es aber notwendig auf genau die richtigen Spuren zugreifen zu können. Das ist die Parallele zu den 96 TPI (80 Spuren) Laufwerken und 48 TPI (40 Spuren) Laufwerke und deren Spur-Radien. Aber welche Spuren (mit welchen Radien) verwendet das Commodore DOS und wie werden diese dabei Benannt (Nummeriert)? Und auf welche Spuren können die einzelnen Laufwerke überhaupt zugreifen?


    Ich hab mir mal diese Disketten für 35 Spuren angesehen. Die hatten ja wirklich eine kleinere Öffnung für den Schreib-/Lesekopf. Siehe Link
    Aber die Öffnung wurde an der innen Seite vergrößert. Die Position der Spur 0, sollte sich durch diese Erweiterung nicht verändert haben.
    Eines der „Ur-Laufwerke“ die Shugart SA400 (siehe Manual) sollte genau solche 35 Spur Disketten mit kleiner Öffnung verarbeiten. Die Diskette SA-104 sollte eigentlich genau eine 35 Spur Diskette mit kleiner Öffnung sein. In der Spezifikation (auf Seite 2 im Manual) ist genau der Radius 5,715 cm (57,150 mm) für die äußerste Spur angeben.
    Also das mit Spur -5 verwirrt mich etwas.

    Vielen Dank für eure Antworten.


    Wenn ich das richtig sehe, benutzen alle Commodore Laufwerke wirklich die "echte" Spur 0. Das Commodore DOS "nennt" diese Spur (also Spur 0) aber Spur 1.
    Oder andersherum, das was das Commodore DOS mit Spur 1 bezeichnet ist eigentlich die Spur 0.
    Und laut dem Dokument ECMA-70 (Seite 12) müsste die Spur 0 (von Seite 0, also der Oberseite) die Spur sein, welche einen Radius von 57,150 mm (57,150 mm - 0/48 * 25,4mm = 57,150 mm) besitzt.
    Leider kann man dies sehr schlecht nachmessen. Oder gibt es hier noch andere Vergleichsmöglichkeiten?




    Mich haben glaube ich, folgende Aussagen aus dem Buch "Die Floppy 1570/1571" (Markt & Technik Verlag AG ISBN 3-89090-185-9) verwirrt:
    Zitat Seite 46:
    "Commodore verwendet in seinem Format nur die Spuren 1 bis 35; andere Hersteller nutzen alle
    möglichen Spuren von 0 bis 39 für ihr Format aus und beschreiben jede Spur mit Sektoren der
    Größe von 512 Byte."


    Zitat Seite 47/48:
    "An dieser Stelle sei auf die Zählweise eingegangen, wie sie beim Computer üblich ist. Ein
    Computer zählt nicht von 1 an, sondern er benutzt die 0 als erste Zahl. Wenn wir also 21
    Sektoren auf einer Spur haben, so sind das die Sektoren von 0 bis 20. Auch die erste Seite einer
    Diskette (Vorderseite) ist grundsätzlich Seite 0, die andere Seite demnach Seite 1 (Rückseite).
    Bei den Spuren im Commodore-Format verhält es sich genauso, obwohl wir von Spur 1 bis 35
    zählen. In Wirklichkeit besteht das Commodore-Format
    nämlich aus 36 Spuren (0 bis 35). Die Spur 0 wird lediglich nicht beschrieben, da sie als
    Anschlagpunkt für den Schreib-jLesekopf definiert ist."