Posts by strik

    Das sieht "eigentlich" so aus, wie es aussehen sollte. Da bin ich jetzt etwas ratlos.

    Ist das ein 32-bittiges oder ein 64-bittiges Vista? Und: Kannst du mir die opencbm.dll und opencbm-xum1541.dll aus dem c:\windows\system32-Verzeichnis (!) mal schicken?

    Wenn du auf der Kommandozeile bist (dort, wo du den Befehl eingibst) und "dir" (ohne Anführungszeichen) eingibst, siehst du dann auch eine opencbm.dll oder opencbm-xum1541.dll? Falls ja, sind es die gleichen wie in c:\windows\system32, oder andere? (Datum, Uhrzeit und Größe vergleichen)

    Befinden sich auf deinem Rechner noch andere opencbm.dll Dateien, vielleicht von anderen Installationsversuchen? Kannst du da mal nach suchen (die Windows-Suchfunktion sollte die finden)?

    Das sieht in der Tat ganz gut aus. Das libwdi-Problem ist kein Problem, du hast den Treiber ja mit ZADIG installiert. ZADIG nutzt die libwdi intern, genauso wie mein Installer.


    Existiert die Datei c:\windows\system32\opencbm.conf? Was steht da drinnen? Existieren die Dateien c:\windows\system32\opencbm.dll und c:\windows\system32\opencbm-xum1541.dll?

    Ich könnte das Programm auch für die 1581 anpassen. Dafür benötige ich nur die äquivalenten Adressen 1541 <-> 1581

    So einfach ist das nicht. Die 1541 benutzt bei $1800 und $1C00 jeweils eine VIAs (6522), die 1581 hat allerdings eine CIA (6526, 8520 oder 8521). Das läßt sich nicht einfach so umsetzen, weil die Chips unterschiedlich angesprochen werden und auch anders extern verdrahtet sind.

    Hast du relevante Code-Abschnitte? Dann könnte man sich das mal gemeinsam anschauen.

    Die Schaltpläne der 1581 findest du hier: http://www.zimmers.net/anonftp…rives/new/1581/index.html, der relevante Part dürfte das hier sein: http://www.zimmers.net/anonftp…ives/new/1581/1581-17.gif

    1541: http://www.zimmers.net/anonftp…rives/new/1541/index.html, bzw. http://www.zimmers.net/anonftp…ort-251748-rev.E-left.gif und http://www.zimmers.net/anonftp…rt-251748-rev.E-right.gif

    Falls das Programm dann auch noch eigene Zugriff auf die Disk umsetzt dann wird es eh düster: Während die 1541 einen eigenen Buscontroller (BC, $1C00) hat, wird das ganze bei der 1581 per MFM-Controller (WD1770 der WD1772) umgesetzt. Diese sind komplett anders aufgebaut.

    Das muss ich ja in der Eingabeaufforderung bei i386 einfeben, richtig? Da kommt bei mir "NO PLUGIN DRIVER!:" Das System kann die angegebene Datei nicht finden.

    Dann ist die Installation nicht ordentlich durchgelaufen.
    Ich konnte es mangels Vista-System nicht testen.

    Kannst du mal folgendes machen: Unter Vista eine "privilegierte" Eingabeaufforderung (wie heißt die genau bei Windows? JEdenfalls das, wo man sich als Administrator anmeldet und den "UAC"-Prompt bekommt; bei Windows 10 mit der rechten Maustaste auf die Eingabeaufforderung, dann mit "Als Adminstrator öffnen" (oder so ähnlich) anmelden) - also, eine privilegierte Eingabeaufforderung ("elevated" im englischen Windows) öffnen und dort den Install-Befehl install.cmd ausführen. Dann lass es durchlaufen und schicke mir die Ausgaben.

    Dann probiere es nochmal. Sofern "NO PLUGIN DRIVER!" wieder kommt, muss ich mir die Ausgaben anschauen.

    Als ich nun einen Doppelklick auf firmware-update.bat gemacht habe, kam leider wieder Ernüchterung.

    Aber die Meldung ist doch gut: Du willst die Firmware updaten, allerdings ist die Version des Files (8) die gleiche, die schon auf der ZF ist (8).
    Also weigert er sich. Man müsste zum Erzwingen die Option -f (--force) mitgeben, aber das braucht man nun nicht.

    Was sagt denn "cbmctrl detect"?

    Das bedeutet, das HS-DOS hat beim NEW Befehl noch irgend welche Assembler-Befehle, bevor er zum üblichen NEW Befehl springt oder?

    Fast. Zarathustra macht es. Es löscht das letzte vom C64 erhaltene Byte (in $85), indem er es mit $FF überschreibt. Dann löscht es noch den Drivestatus für Laufwerk 0 ($FF).

    Warum es das macht ist mir nicht ganz klar.

    Umgekehrt, bei "Zarathustra Speed" wurde aus "SCRATCHED" dann "GELOESCHT".

    Ähm... Richtig, gut aufgepasst.


    Was meinst du damit (abgesehen von der "DOS-Meldung" nach Einschalten/Reset)?

    $E5B4: "FULL" vs. "VOLL"

    Weils grad schön ist: Ich hab noch ein ROM aus einem anderen Laufwerk. Vermutlich gleichen Inhalts zumindest ist bei Adresse $1b90 auch der Hinweis "(C) OE&OJ" zu finden.

    Fehlerkanal gibt aber "Zarathustra Speed" aus

    Das sind auch fast die einzigen Unterschiede der beiden ROMs:


    Also: HS-DOS sendet "GELOESCHT" statt "SCRATCHED" nach einem Löschen (01,FILES SCRATCHED,..) und weitere kleine Text-Anpassungen (oberer Block)
    Der einzige inhaltliche Unterschiest ist bei $e36 (also $ee36 in der Floppy), wo JSR $FB60 bei HS-DOS, und JSR $D307 bei Zarathustra steht.

    $D307 ist "original" in der 1541 so.

    Das ist der NEW-Befehl: Original werde die Kanäle freigegeben ($D307). Bei $FB60 ist hingegen ein Patch:
    LDA #$FF
    STA $85
    LDA #$00
    STA $FF,X
    JMP $D307

    Completely uninstall all old versions

    Hopefully, there are not old version*s*! There should be one version only. Otherwise, he is begging for problems!


    Funktioniert diese Version auch mit Vista?

    Da ich kein Vista habe konnte ich es nicht testen. Ich gehe aber davon aus.

    Aber die Aussage von r.cade ist richtig: Die alte Version am besten vorher deinstallieren (zumal ich nicht weiß, was bei dir alles so drauf ist), und dann die neue installieren. "Eigentlich" sollte es auch ohne Deinstallation gehen, da es aber inzwischen alle möglichen, krude installierten Versionen gibt, würde ich dafür nicht meine Hand ins Feuer legen.

    Bitte Beachte, dass neuere OpenCBM die libusb1 (anstatt libusb0 bei OpenCBM <= 0.4.99.99) benötigen. Beim Installieren der 0.4.99.103 fragt er dich, ob du die Treiber aktualisieren willst. Sag ja, sonst wird es nicht funktionieren.

    Ich habe schon einen Bug-Report, dass das Update der Treiber fehlgeschlagen ist. Sollte OpenCBM sich nach dem Update darüber beschweren, kein ZF zu finden, dann aktualisiere die Treiber bitte selber mit ZADIG (anstatt 'libusb-win32' in 0.4.99.99 dann auf 'WinUSB' wechseln).

    Weißt du wie man das OpenCBM plugin updated ???

    Du musst OpenCBM neu installieren. Es muss mindestens eine 0.4.99.100 sein, damit sie mit der FW 08 zurechtkommt.


    Mir ist auch noch in den Sinn gekommen, dass ich mal zu anfangs das Serial von der ZF abgezogen hab. Hoffe, dass das jetzt nicht groß ausschlaggebend für den Ausfall der 1571 ist, oder es mir die ZF abgeschossen hat.

    Damit habe ich noch nie einen Schaden gehabt, ausschließen kann man es aber nicht.

    Am besten niemals unter Strom rumstecken. Besser:
    - 1571 und ZF stromlos
    - alle Verkabelungen herstellen (außer ZF in USB-Port)
    - ZF in USB-Port einstecken
    - 1571 einschalten.

    Zum Abstöpseln in umgekehrter Reihenfolge.

    Ich betreibe hier mal Leichenfledderei des Threads:

    Beim Durchschauen alter deutscher RUN-Ausgaben bin ich in der Ausgabe 7/85 auf der Seite 24 auf einen ganzseitigen Bericht des Laufwerks gestossen.

    Ok, ich hatte dich falsch verstanden. Ich dachte, dass das "ATmega32U2 DFU" Gerät dauerhaft wäre.

    Offenbar hast du gerade mindestens 2 Probleme. Gehen wir sie nacheinander an:


    Problem 1: Fehlender Treiber für das "ATmega32U2 DFU" Gerät:

    ==================================================


    Führe aus:

    1. ZF anstecken
    2. "xum1541cfg update xum1541-ZOOMFLOPPY-v08.hex" eingeben. Der Vorgang wird allerdings mit einer Fehlermeldung abbrechen! ("no device found for updating")
    3. Jetzt mit ZADIG für das "ATmega32U2 DFU" Gerät einen Treiber installieren. Das ist diee ZF, allerdings im Bootloader-Modus, in dem sie programmiert werden muss. Windows weiß aber nicht, dass es das gleiche Gerät ist, deshalb behauptet es, keinen Treiber zu finden.
    4. Wenn du mit ZADIG erfolgreich den Treiber installiert hast kannst du den Schritt 2 wiederholen. Jetzt sollte er durchlaufen.


    Problem 2: HEX-Datei ist fehlerhaft

    ===========================



    Allerdings sehe ich in deinem Screenshot, dass das System behauptet, dass xum1541-ZOOMFLOPPY-v08.hex kein gültiges HEX-File wäre. Da scheint beim Herunterladen etwas schiefgelaufen zu sein. Die Datei muss so aussehen (nur der Anfang):

    Ansonsten wirst du es nicht flashen können.

    Das ZF befindet sich im sogenannten DFU-Modus. Das heißt, dass es darauf wartet, vom PC aus per USB programmiert zu werden.

    Hast du das ZF abgesteckt und wieder neu eingesteckt, und/oder neu gebootet?

    Falls der Eintrag in der Systemsteuerung stehen bleibt, dann hat dein ZF die Firmware verloren.

    Kein Problem, das kann man einfach beheben:


    1. Zuerst mit ZADIG einen neuen Treiber für das DFU-Device installieren - und zwar so, wie du es für das ZF selbst gemacht hast (bei alten OpenCBM <= 0.4.99.100: libusb-win32, ansonsten WinUSB)
    2. Die neue Firmware herunterladen: Z.B. hier: https://github.com/OpenCBM/Ope…um1541-ZOOMFLOPPY-v08.hex, dann auf "RAW" klicken und die Datei unter dem Namen xum1541-ZOOMFLOPPY-v08.hex abspeichern.
    3. Dann in die Kommandozeile wechseln, ins Verzeichnis mit xum1541cfg.exe wechseln und mit "xum1541cfg update xum1541-ZOOMFLOPPY-v08.hex" die neue Firmware aufspielen


    Normalerweise sollte das ZF sofort funktionieren. Manchmal benötigt es aber eine kleine Nachhilfe, indem man es kurz vom USB abzieht und wieder neu einsteckt. Zumindest andere XUM1541-Geräte benötigen das manchmal.

    Im Verzeichnis /usr/lib fehlt der Softlink libopencbm.so -> libopencbm.so.0, ohne den der Emulator Vice die Auswahl eines "real device" nicht zulässt.

    So, ich habe rumgespielt, gelesen, usw.



    Dann bin ich hierauf gestossen: https://www.debian.org/doc/debian-policy/ch-sharedlibs.html


    D.h., zumindest laut Debian wird der Link von .so auf .so.0 nicht als Teil der Library, sondern als Teil des Entwicklungspaketes (-dev) angesehen. Das macht auch Sinn, weil bei gleicher Versionsnummer die Library kompatibel sein muss, bzw. sich bei inkompatiblen Änderungen die Versionsnummer (.so.0) ändern muss.


    Und tatsächlich, wenn du libopencbm0-dev installierst, dann ist der Symlink vorhanden.


    Von daher gehe ich davon aus, dass das kein Fehler in der Paketierung von OpenCBM ist, sondern vielmehr ein Fehlverhalten von VICE, weil es nicht explizit eine Version anfordert. Damit linkt sich VICE auch gegen eventuelle zukünftige Versionen von OpenCBM, was ein Fehler wäre und einen Crash oder anderes Fehlverhalten erzeugen könnte.

    Im Verzeichnis /usr/lib fehlt der Softlink libopencbm.so -> libopencbm.so.0, ohne den der Emulator Vice die Auswahl eines "real device" nicht zulässt.

    Danke für den Hinweis. Ich habe einen Fix eingecheckt.


    EDIT: Ok, vergiss es. Der Fix funktioniert nicht. Ich schaue, was da schiefläuft, und liefere es nach.


    Zudem fehlt die udev rule 45-opencbm-xum1541.rules im Verzeichnis /etc/udev/rules.d, damit man auch ohne root zu sein Zugriff hat.

    Nein, sie fehlt nicht, sie ist nur in /usr/lib/udev/rules.d zu finden.

    Der Grund, warum sie dort zu finden ist, kann man hier nachschauen: https://unix.stackexchange.com…es-d-which-to-use-and-why

    Wo gebe ich diese Kommandozeile in 1. denn ein ?

    Variante 1: Windows-Taste, dann "Eingabeaufforderung" eintippen (ohne Anführungszeichen), auswählen und dann "Enter". Nun musst du das Verzeichnis kennen, in das du OpenCBM installiert hast. Dorthin wechselst du mit dem Befehl "cd /d ...verzeichnisname...", wobei du "...verzeichnisname..." mit dem Namen des Verzeichnisses ersetzt. Danach kannst du die genannten Befehle eintippen.

    Variante 2: Gehe über den Explorer in das Verzeichnis, in dem OpenCBM installiert ist. Dann gehst du eine Verzeichnisebene nach oben (mit dem Pfeil nach oben). Nun "Shift" Drücken und gedrückt halten, dazu rechte Maustaste auf das Verzeichnis, in dem OpenCBM ist. In dem sich öffnenden Menü dann "Eingabeaufforderung hier" auswählen. Bei neueren Windows kann dort auch "PowerShell-Fenster hier öffnen" erscheinen, das kannst du alternativ auch nutzen.


    Mit den Informationen aus den Befehlen kann ich dir vielleicht weiterhelfen.