Beiträge von Diddl im Thema „ZoomFloppy - IEEE-488 Laufwerke“

    Gute Neuigkeiten für die IEEE-488 Zoom Sache:

    Bitte melde dich an, um diesen Link zu sehen., der Entwickler des CBMXfer hat sich ein Zoomfloppy zugelegt und passt sein CBMXfer an für IEEE-488 Erfordernisse.


    Falls es jemand nicht kennt, - CBMXfer ist ein Bitte melde dich an, um diesen Link zu sehen..

    Danke Steve!!


    Quelle: Bitte melde dich an, um diesen Link zu sehen.

    Wo finde ich denn die Anschlussbelegung für den Bumble-B?


    Bitte melde dich an, um diesen Link zu sehen.

    Die Firmware kannst du von Bitte melde dich an, um diesen Link zu sehen. holen. Aber nicht die Bumble, sondern die Cheap 1 in dem Fall. Die Bumble hat eine Hardware wie das Zoomfloppy mit Hardware Driver (7406) und separaten Input und Outputs.

    Der IEEE-488 Support ist jetzt offiziell im OpenCBM verankert. Leider gibt es keine Binaries, deshalb findet man vorläufig auf Bitte melde dich an, um diesen Link zu sehen. alles was für IEEE-488 notwendig ist.

    Das sind inoffizielle Binaries, basierend auf den aktuellen GIT Snapshot.

    Endlich kann man auch 8050 und 8250 Disketten einlesen und zurück schreiben mit dem Zoomfloppy. :)

    Der Sourcecode für Zoomfloppy und OpenCBM wird von Nate Lawson ins GIT eingearbeitet und steht dann dort zur Verfügung.


    Das war es erst mal von meiner Seite, wenn keine Fehler Probleme mehr auftreten. Es läuft erst mal alles so weit.
    Mittelfristig steht auf der Todo noch:

    • XS-1541 Support für das OpenCBM (sofern Bedarf da ist)
    • Turbo Routinen für die 8050 und 8250


    Das wird aber wohl noch einige Zeit dauern bis es soweit ist.

    ===================
    A new test release of a patched OpenCBM is available for tester in my upload directory.


    File: OpenCBM-04.zip (including new, improved Zoomfloppy firmware RC5)


    It is working now:

    - device detection for 3040, 4040, 8050, 8250, SFD-1001 (as 8250)
    - CBMCTRL
    - CBMCOPY
    - D64COPY for 4040 (thanks to TNT) and I think for 2031 also
    - D82COPY for 8050, 8250 and SFD-1001


    Thanks to all tester!

    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.


    Mit der Soft-ID bin ich mir nicht sicher, aber die Disketten Kopie ist nicht sauber wenn die Soft ID nicht übereinstimmt. Vorallem die 8050 meckert immer "ID mismatch" wenn man beide Laufwerke verwendet.

    Meine Aussage oben terifft aber auch auf die 1541 zu. Fast alle Routinen die lesend zugreifen, nutzen denselben "Block lesen" Code. Und dem gibt man Track, Sector und ID mit. daraus errechnet sich der Header, und der Header wird exakt gesucht. Nach 90 Versuchen kommt Lesefehler.

    Der Befehl "I0" geht zur Spur 18 (bei der 1541) und Sucht nach Sync. Das erste Byte nach Sync muss ein Header Startbyte sein. Danach wird der Header fertig gelesen und, im Falle von Flag "ID übernehmen" wird die ID gespeichert.

    Wenn "ID Mismatch" auftritt, und wenn ein Flag gesetzt ist, wird automatisch der "I" Befehl ausgeführt. Wann dieses Flag verändert wird, muss ich ggf. noch nachforschen.

    Wenn ein Spurwechsel durchgeführt wird, kommt dieselbe Routine zum Tragen, wie beim "I0" Befehl. Nur hier ist das Flag nicht gesetzt um die ID zu übernehmen. Stimmt die Track Nummer aber die ID nicht, dann kommt es zum "ID mismatch" und gegebenenfalls zum automatischen "I" Befehl (falls das Flag gesetzt ist.

    ----

    Langer Rede kurzer Sinn:

    - Beim Zurückschreiben der D82 Imagedatei auf Diskette kann man die Hard ID zur Zeit nicht so leicht ändern

    - Daher hat die Zieldiskette die ID des letzten Formatiervorgang

    - Wenn man eine exakte Kopie will, muss man zuvor ein Format mit der "richtigen" ID machen.

    - Für die meisten Disketten ist es egal, wenn die ID nicht passt, aber es ist nicht schön

    - Wenn die BAM nicht übereinstimmt, reagiert das DOS 2.5 manchmal sauer. Beim DOS 2.7 konnte ich es nicht nachstellen, habe aber auch kein funktionierendes Doppellaufwerk mit DOS 2.7 (8250).

    Längerfristiges Ziel ist es, die Formatierung des Track beim Zurückschreiben gleich mit zu machen, falls die ID nicht passt.

    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.

    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.

    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.

    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?

    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

    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

    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.

    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?

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

    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. ;)