ZoomFloppy - IEEE-488 Laufwerke

Es gibt 48 Antworten in diesem Thema, welches 7.882 mal aufgerufen wurde. Der letzte Beitrag (7. Juni 2011 um 09:53) ist von Diddl.

  • Die Beta 3 ist raus. Damit sind alle mir bekannten Probleme behoben.

    Es ist szusagen ein Release Kandidat. Wenn keiner mehr was findet ... :)


    Evtl. kann ich ja meinen sehr einfachen D80/D82 imager an das opencbm-zoomfloppy anpassen?


    Wäre schon mal eine gute Zwischenlösung. Auf kurz oder lang wird es eine Unterstützung seitens OpenCBM geben. Ich bin da schon beim Einlesen ...


    Vielleicht gibt auch mal einen OpenCBM Driver für das gute alte XS-1541 von mir. ;)

    Bitte melde dich an, um diesen Link zu sehen. --- Bitte melde dich an, um diesen Link zu sehen. --- Bitte melde dich an, um diesen Link zu sehen.

  • Ich muss mich da auch erstmal einlesen. Ich habe null Ahnung wie man mit den opencbm dlls die Floppy anspricht oder wie man ein Programm baut, das diese Dlls verwendet. Aber da gibts ja genug Beispielprogramme :)

    Mein existentes Programm muss aufgrund der genannten Problematik alles zu Fuss machen und sendet sämtliche TALK/UNTALK usw. Befehle selbst auf den Bus. Hier erhoffe ich mir eine Vereinfachung :)

    Code: Floppy Fehlerkanal abfragen - Ausserdem kann ich bei "drive not ready" den I: und N: Befehl verwenden und notfalls den Kopf manuell zurückschieben. Und Finger weg vom Stepper!
    10 open1,8,15                   : rem 8 ist die Geräteadresse und das kann man bei Bedarf natürlich anpassen
    20 get#1,a$:?a$;:ifst<>64goto20 : rem Das CLOSE 1 am Ende kann man sich sparen, weil beim RUN automatisch ein CLOSE ALL ausgeführt wird.
    RUN
  • Es gibt ja dieses D64copy aus den OpenCBM Tools, das macht ja schon fast alles. Nur die Drive Geometrie der D80 und D82 muss implementiert werden.


    Aber im Detail fehlt halt doch noch einiges, angefangen von der Laufwerkskennung über Floppy Code damit es etwas zügiger geht bzw. autointerleave (warp modus).

    Bitte melde dich an, um diesen Link zu sehen. --- Bitte melde dich an, um diesen Link zu sehen. --- Bitte melde dich an, um diesen Link zu sehen.

  • Ich verwende ein kleines Programm in der Floppy, das per Jobcode die Sektoren einliest, und auf diese Weise auch bei Blöcken mit Prüfsummenfehlern Daten zurückliefern kann. Einstellbarer Interleave ist auch möglich, aber viel bringts nicht. Das IEEE488 Protokoll ist nicht gerade schnell implementiert. Da erhoffe ich mir in Zukunft viel vom ZF, weil man ja bei nur einer Floppy am Bus nicht an das Protokoll gebunden ist. So dass man im Idealfall jedes Byte von der Disk quasi direkt zum ZF durchreichen kann. Da die Doppelfloppies aber zwei CPUs haben muss man aber doch einen Zwischenspeicher bemühen.

    Code: Floppy Fehlerkanal abfragen - Ausserdem kann ich bei "drive not ready" den I: und N: Befehl verwenden und notfalls den Kopf manuell zurückschieben. Und Finger weg vom Stepper!
    10 open1,8,15                   : rem 8 ist die Geräteadresse und das kann man bei Bedarf natürlich anpassen
    20 get#1,a$:?a$;:ifst<>64goto20 : rem Das CLOSE 1 am Ende kann man sich sparen, weil beim RUN automatisch ein CLOSE ALL ausgeführt wird.
    RUN
  • Ich verwende ein kleines Programm in der Floppy, das per Jobcode die Sektoren einliest, und auf diese Weise auch bei Blöcken mit Prüfsummenfehlern Daten zurückliefern kann.


    Das wäre schon mal sehr interessant für openCBM. Eventuell muss man aber noch weiter gehen und einen Code für den Disk Controller proggen.


    Hast du eine Methode um Laufwerke per M-R zu erkennen?

    Das standard OpenCBM erkennt meine SFD-1001 dos2.7 als 1541. Das liegt daran, weil die im ROM wie die 1541 an der Stelle FF40 zwei AA hat. Ich habe das verbessert, sodass OpenCBM nun wenigstens eine 8250 dos2.7 erkennt. Aber vielleicht hast du schon evaluiert, welche Speicheradressen sich am markantesten unterscheiden?

    Bitte melde dich an, um diesen Link zu sehen. --- Bitte melde dich an, um diesen Link zu sehen. --- Bitte melde dich an, um diesen Link zu sehen.

  • Hast du eine Methode um Laufwerke per M-R zu erkennen?

    Das standard OpenCBM erkennt meine SFD-1001 dos2.7 als 1541. Das liegt daran, weil die im ROM wie die 1541 an der Stelle FF40 zwei AA hat. Ich habe das verbessert, sodass OpenCBM nun wenigstens eine 8250 dos2.7 erkennt. Aber vielleicht hast du schon evaluiert, welche Speicheradressen sich am markantesten unterscheiden?

    Nein dazu hab ich mir noch nie Gedanken gemacht. Eine SFD von einer 8250 wird man so leicht nicht unterscheiden können, da nur das Controller ROM sich unterscheidet. DOS ROM und Speicherbelegung im RAM sind komplett identisch. Da es viele unterschiedliche Controller ROMs gibt, für jede Mechanikvariante ein eigenes, wird man mehr als nur ein paar Adressen prüfen müssen befürchte ich.

    Bei DOS2.7 kann man irgendwo im RAM das Disk Layout einstellen. Da es DOS 2.7 aber nur in SFD und 8050/8250 gibt steht da immer das gleiche.

    Ich hab bei mir noch eine Erkennung von 8050 Disks eingebaut, die sonst beim ersten Zugriff einen Fehler erzeugen. Außerdem wird so automatisch ein D80 image erzeugt. Ich glaube das hab ich gelöst durch einen Leseversuch auf der zweiten Seite per Jobcode.

    Code: Floppy Fehlerkanal abfragen - Ausserdem kann ich bei "drive not ready" den I: und N: Befehl verwenden und notfalls den Kopf manuell zurückschieben. Und Finger weg vom Stepper!
    10 open1,8,15                   : rem 8 ist die Geräteadresse und das kann man bei Bedarf natürlich anpassen
    20 get#1,a$:?a$;:ifst<>64goto20 : rem Das CLOSE 1 am Ende kann man sich sparen, weil beim RUN automatisch ein CLOSE ALL ausgeführt wird.
    RUN
  • Irgendwie schade, dass man nicht an die GCR Daten kommt, bei den großen Laufwerken.

    Auf der anderen Seite gibt es dadurch wahrscheinlich auch keine Sauereien in Form von wüsten Kopierschutz Mechanismen. Es sei denn, jemand hat die Laufwerk Elektronik modifiziert. Mal sehen, erst mal Normaldaten lesen und gucken, ob GCR überhaupt notwendig wird.

    ----

    Ich möchte Drivecode für die 8050 machen, der im Prinzip gleich funktioniert wie der Warp Code der 1541 (aber halt nicht GCR Daten sondern Echtdaten).

    + das Laufwerk bekommt eine Liste der zu lesenden Blöcke

    + es wird der nächste Block gelesen der am Kopf vorbeikommt

    + ist es ein (noch) zu lesender Block ---> zum Zoomfloppy senden

    + weitermachen bis alle Blöcke gelesen oder fehlerhaft bestätigt.


    Dadurch muss man sich nicht im um Interleave Geschichten sorgen. Lesen läuft so immer optimal schnell. Beim Schreiben muss man sich natürlich den optimalen Interleave überlegen.

    Bitte melde dich an, um diesen Link zu sehen. --- Bitte melde dich an, um diesen Link zu sehen. --- Bitte melde dich an, um diesen Link zu sehen.

  • Gerätekennung (cbmctrl detect) läuft jetzt für alle mir bekannten Geräte. Wenn jemand seine IEEE Geräte rein bringen will, soll er mir seine MAGIC numbers dafür mitteilen.


    OpenCBM ist angepasst:

    - cbmctrl :: 100%

    - cbmcopy :: 100%

    - d64copy läuft für 4040 Floppy mit dem Parameter "-t o"

    - d82copy - lesen von Images läuft jetzt. In zwei Wochen dürfte dann alles komplett sein.

    :freude

    Bitte melde dich an, um diesen Link zu sehen. --- Bitte melde dich an, um diesen Link zu sehen. --- Bitte melde dich an, um diesen Link zu sehen.

  • Ein Test Release von meinem gepatchten OpenCBM ist verfügbar für Tester im Upload Verzeichnis.


    es funktioniert:

    - Geräte Erkennung für 4040, 8050, 8250, SFD-1001 (als 8250)

    - CBMCTRL.EXE

    - D64COPY.EXE für 4040 und vermutlich 2031

    - CBMCOPY.EXE


    Datei: OpenCBM-IEEE-test_02.zip

    Bitte melde dich an, um diesen Link zu sehen. --- Bitte melde dich an, um diesen Link zu sehen. --- Bitte melde dich an, um diesen Link zu sehen.

  • Eben mal angetestet. Schade, noch kein D82COPY?

    Wie gesagt, momentan bin ich noch auf die SFD beschränkt.

    cbmctrl detect funktioniert.

    mit cbmcopy hab ich einige Dateien auf den PC kopiert. Das kommt mir angenehm schnell vor :)

    Bei cbmctrl dir 8 ist mir schon länger mal was aufgefallen, was auf eine Eigenheit der CBM Doppelfloppies hinweist. Der Befehle versucht auf beiden Laufwerken das Directory zu lesen, was in der SFD natürlich zu einem Fehler führt, zu bemerken an der langen Pause nach Ausgabe von Directory für Drive 0 und dem wilden Blinken am ZF. So wenigstens meine Vermutung. Eine Möglichkeit das zu lesende Drive anzugeben ist leider nicht vorgesehen.

    Ansonsten nur weiter so :) Das macht Lust auf mehr :)

    Code: Floppy Fehlerkanal abfragen - Ausserdem kann ich bei "drive not ready" den I: und N: Befehl verwenden und notfalls den Kopf manuell zurückschieben. Und Finger weg vom Stepper!
    10 open1,8,15                   : rem 8 ist die Geräteadresse und das kann man bei Bedarf natürlich anpassen
    20 get#1,a$:?a$;:ifst<>64goto20 : rem Das CLOSE 1 am Ende kann man sich sparen, weil beim RUN automatisch ein CLOSE ALL ausgeführt wird.
    RUN
  • Schade, noch kein D82COPY?


    Ist in Arbeit, dann ist die Anpassung erledigt, alle bekannten IEEE Laufwerke werden unterstützt. :)

    Bitte melde dich an, um diesen Link zu sehen. --- Bitte melde dich an, um diesen Link zu sehen. --- Bitte melde dich an, um diesen Link zu sehen.

  • Gute Neuigkeiten, Nate Lawson wird meine OpenCBM Patches im GIT einarbeiten. Es wird also Bestandteil des regulären OpenCBM Code werden. So spare ich mir die Veröffentlichung einer modifizierten Version samt Quellcode, wie es die Lizenz vorschreibt.


    x1541

    Wann kann man mit deinem 8050 Code, also dem Tool zum Lesen rechnen? Wirst du es als eigenes Tool führen? Oder soll es auch irgendwann mit dem OpenCBM verschmelzen? Was hast du denn nun genau vor? Das Tool wird wohl D80 und D82 lesen können, wird das Tool auch schreiben können? Brauchst du Hilfe oder möchtest du alleine an der Sache arbeiten?

    Bitte melde dich an, um diesen Link zu sehen. --- Bitte melde dich an, um diesen Link zu sehen. --- Bitte melde dich an, um diesen Link zu sehen.

  • x1541

    Wann kann man mit deinem 8050 Code, also dem Tool zum Lesen rechnen? Wirst du es als eigenes Tool führen? Oder soll es auch irgendwann mit dem OpenCBM verschmelzen? Was hast du denn nun genau vor? Das Tool wird wohl D80 und D82 lesen können, wird das Tool auch schreiben können? Brauchst du Hilfe oder möchtest du alleine an der Sache arbeiten?

    Wenn ich das so genau wüsste. Ich hab vorhin mal den vorhandenen Code gesichtet. Es ist ein sehr einfaches ASM Programm das die Jobcodes "verwaltet" und entsprechend der eingestellten Anzahl der Leseversuche wiederholt. Dazu eben ein C Programm das Sektor für Sektor (bzw. mit Interleave) dieses Programm anwirft um die Daten einzulesen. Darüber hinaus wird der Fehlercode des Jobs noch in eine extra Datei geschrieben (die Daten entsprechen genau der Fehlerinfo eines D64). Man könnte es hinten ans Image anhängen aber dann kommt kein Programm mehr mit den Images zurecht ...

    Gescheiter wäre es in ein vorhandenes Programm (Dein d82copy?) die Geschichte als vorläufigen "Turbo" einzubauen, bis was besseres da ist. Ich kann es Dir ja mal schicken? Was man aber mit dem Interleave macht? Ohne das bringts wohl nicht so viel.

    Wie nun der Aufwand wäre für die eine oder andere Variante kann ich noch nicht abschätzen, ich muss mir mal den source zu d64copy ansehen wohl.


    PS: vorhin hab ich mal probiert eine Datei per cbmcopy mit random Daten 4133 Blocks = 254*4133= 1049782 Bytes zu schreiben. Da kommt Disk full. Dann nochmal mit 2 Bytes weniger probiert. Auch Disk full. Dann Lust verloren.

    Aber einmal gab es nen 25,write error mitten drin. cbmcopy hat aber munter weiter gemacht daten zu senden, anstatt abzubrechen. Die Floppy tat aber nix mehr. Das ist nicht gut ;)

    Code: Floppy Fehlerkanal abfragen - Ausserdem kann ich bei "drive not ready" den I: und N: Befehl verwenden und notfalls den Kopf manuell zurückschieben. Und Finger weg vom Stepper!
    10 open1,8,15                   : rem 8 ist die Geräteadresse und das kann man bei Bedarf natürlich anpassen
    20 get#1,a$:?a$;:ifst<>64goto20 : rem Das CLOSE 1 am Ende kann man sich sparen, weil beim RUN automatisch ein CLOSE ALL ausgeführt wird.
    RUN
  • Da kommt Disk full. Dann nochmal mit 2 Bytes weniger probiert. Auch Disk full. Dann Lust verloren.

    Das File ist aber trotzdem auf Disk...

    Zurückgelesen, verglichen. Identisch :)

    9min zum Lesen, 12 min zum schreiben. Unter 7-8min kam ich per GPIB Karte auch mit angepasstem Interleave nicht. Bin mal gespannt was da noch drin ist :)

    Code: Floppy Fehlerkanal abfragen - Ausserdem kann ich bei "drive not ready" den I: und N: Befehl verwenden und notfalls den Kopf manuell zurückschieben. Und Finger weg vom Stepper!
    10 open1,8,15                   : rem 8 ist die Geräteadresse und das kann man bei Bedarf natürlich anpassen
    20 get#1,a$:?a$;:ifst<>64goto20 : rem Das CLOSE 1 am Ende kann man sich sparen, weil beim RUN automatisch ein CLOSE ALL ausgeführt wird.
    RUN
  • Da kommt Disk full.


    Disk full??? So große Dateien habe ich nie getestet, komm mir aber schräg vor. Eine SFD-1001 nehme ich an?


    Aber einmal gab es nen 25,write error mitten drin.


    Write Error? Dann muss deine Diskette was haben, nehme ich an.

    Ich hatte erst Fehlerkanal lesen drin alle 254 Bytes. Allerdings hat der Kopiervorgang dann gleich deutlich länger gedauert. Da es in der Regel ja keinen Fehler gibt und da eh am Schluss der Fehlerkanal ausgelesen und angezeigt wird, habe ich die Prüfung ausgebaut.

    Aber wenn ich es mir recht überlege, eine Prüfung alle 2KB wäre sicher sehr sinnvoll, bei so großen Dateien auf jeden Fall. Ich werde da einbauen.


    Gescheiter wäre es in ein vorhandenes Programm (Dein d82copy?) die Geschichte als vorläufigen "Turbo" einzubauen, bis was besseres da ist. Ich kann es Dir ja mal schicken? Was man aber mit dem Interleave macht? Ohne das bringts wohl nicht so viel.


    Ich bin einverstanden, schick es zu mir. Das ist sicher ein guter Anfang und viel besser als das reine Commodore DOS. Es wird halt etwas dauern bis es drin ist.

    Bitte melde dich an, um diesen Link zu sehen. --- Bitte melde dich an, um diesen Link zu sehen. --- Bitte melde dich an, um diesen Link zu sehen.

  • Danke für den Floppycode Nicolas.


    Wenn ich das ROM Listing richtig verstehe, dann sucht der Diskcontroller die Sektor Header immer aufgrund einer vorgegebenen Disk ID. "Sektor Header lesen" wird nur aufgerufen bei Spurwechsel und dem "I" Kommando.

    Ein theoretisch angenommener Kopierschutz, der einige Sektoren faked indem die ID verändert wird, hätte also folgende Auswirkung:

    + Sektoren mit fremder ID wären für das DOS quasi "unsichtbar"

    + Wenn man die ID des Sektor jedoch kennt, dann könnte man den Sektor mit einfachsten Mitteln lesen.

    + Ein Kopieren der Diskette ist aber sehr, sehr schwierig

    + Zum Schreiben des Fake Sektor ist auch schon relativ großer Aufwand nötig, meiner Meinung nach geht das nur mit Usercode für den Diskcontroller.

    =========

    Schritt 1 ist die Umsetzung von D82COPY mit normalen CBM Routinen

    Schritt 2 ist experimentieren mit simplen Usercode für den Buscontroller

    Man wird also nur nicht oder schlecht geschützte Disketten kopieren können, was bei der 8050 der Standardfall sein dürfte.

    --

    Beim Schreiben von Disketten lässt sich die ID mit Schritt 1 und 2 nicht ändern. Wenn man also ein D82 Image zurückschreibt, dann ändert sich in der regel die ID, weil man die ID des Image in die BAM kopieren muss, damit die Diskette lesbar bleibt.

    Will man also eine "gute" Kopie, dann muss man vorerst darauf achten, dass man die Diskette zuerst mit der korrekten ID formatiert. Ich werde einen Schalter einbauen, der dies optional automatisch macht.

    ========

    Aufgrund der Hardware zur GCR Codierung, sind bei der 8050/8250 bei weitem nicht soviele Kopierschutz Szenarien machbar. Denkbare Kopierschutz Methoden:

    + Sektorreihenfolge

    + fehlende Sektoren

    + illegale Sektornummern

    + Halbspur Schweinereien

    + Fake Header: Zusatzbytes (sichtbare Sondersektoren), illegale Header (unsichtbare Sektoren)


    Wenn man wüsste, dass solche Dinge tatsächlich gemacht worden sind, dann würde sicht ein "Sektor header Analyzer" in Form eines kleinen Diskcontroller Code anbieten.

    Ein Schalter im D82COPY (-a[nalyze) würde dann:

    + den analyzer code hochladen

    + der Diskcontroller würde jeweils eine ganze Spur lesen (nur Headerdaten: 8 bytes pro Sektor oder evtl auch mehr, für fake header)

    + OpenCBM würde dann eine Headeranalyse Datei ausgeben

    Die Headeranalyse Datei könnte Aufschluss darüber geben, ob und wie eine Kopierschutz aktiv ist. OpenCBM könnte mit Hilfe der Informationen in der Headeranalyse Datei dann auch alle zugehöreigen Sektor Daten auslesen. Allerdings müsste man sich ein neues Imagefile Format anstatt D82 überlegen.

    Bitte melde dich an, um diesen Link zu sehen. --- Bitte melde dich an, um diesen Link zu sehen. --- Bitte melde dich an, um diesen Link zu sehen.

  • Meine ZF ist jetzt wohl unterwegs. Mal gucken, wie lange es dauert und ob ich zum Zoll muss?!

    Mir ist noch eingefallen, dass ich zum Testen auch noch eine MSD SD-1 habe. Hast du nicht auch noch was zum Testen, Nicolas?

    Hab ich das jetzt richtig verstanden, dass ich der ZF eine neue Firmware flashen muss, wenn ich mit IEEE-488 Geräten testen will? Gibt es da eine Anleitung? Vielleicht sollte ich den Thread und meine PNs mal genauer lesen! ;)

  • Gibt es da eine Anleitung?


    Hab ich dir geschickt per PN, ist auch als Readme vorhanden im anderen ZIP. Ich wußte gar nicht, dass es noch weitere IEEE-488 Floppys gab.


    Mir ist noch eingefallen, dass ich zum Testen auch noch eine MSD SD-1 habe.


    MSD Super DIsk??? Kannte ich noch gar nicht.


    Ich wäre froh wenn du alle Magic Numbers bekannt gibst, also die Kennzahlen der unbekannten Laufwerke und Harddisks, dann könnte ich die automatische Laufwerks Erkennung von OpenCBM erweitern.

    Bitte melde dich an, um diesen Link zu sehen. --- Bitte melde dich an, um diesen Link zu sehen. --- Bitte melde dich an, um diesen Link zu sehen.

  • Wenn ich das ROM Listing richtig verstehe, dann sucht der Diskcontroller die Sektor Header immer aufgrund einer vorgegebenen Disk ID. "Sektor Header lesen" wird nur aufgerufen bei Spurwechsel und dem "I" Kommando.

    Bist Du da sicher? Vor allem dass die Soft-ID genommen wird? Das wäre völlig anders als bei z.b. der 1541 und passt auch logisch nicht. Wie kann denn die Floppy die Soft ID lesen ohne vorher auf die Hard-ID initialisiert zu haben? Sie würde ja den Sektor mit der BAM gar nicht finden.

    Mir ist noch eingefallen, dass ich zum Testen auch noch eine MSD SD-1 habe. Hast du nicht auch noch was zum Testen, Nicolas?

    Gut dass es Dich gibt. Hätte doch glatt meine MSD SD-2 vergessen :D

    Code: Floppy Fehlerkanal abfragen - Ausserdem kann ich bei "drive not ready" den I: und N: Befehl verwenden und notfalls den Kopf manuell zurückschieben. Und Finger weg vom Stepper!
    10 open1,8,15                   : rem 8 ist die Geräteadresse und das kann man bei Bedarf natürlich anpassen
    20 get#1,a$:?a$;:ifst<>64goto20 : rem Das CLOSE 1 am Ende kann man sich sparen, weil beim RUN automatisch ein CLOSE ALL ausgeführt wird.
    RUN
  • Mir ist noch eingefallen, dass ich zum Testen auch noch eine MSD SD-1 habe. Hast du nicht auch noch was zum Testen, Nicolas?

    Gut dass es Dich gibt. Hätte doch glatt meine MSD SD-2 vergessen :D

    Hehe, erst meine MSDs abstauben und dann nicht nutzen. Schämt Euch :D