Hallo Besucher, der Thread wurde 2,7k mal aufgerufen und enthält 12 Antworten

letzter Beitrag von LXIV am

ZoomFloppy (Eigenbau) - nibtools geht nicht an Parallelport

    Hey,


    ich hab mir eine ZoomFloppy auf Lochraster nachgebaut. Angeschlossen ist sie an eine 1541 (mittellanges Board), sowohl seriell als auch parallel an UC3 der 1541.


    Das ganze funktioniert auch soweit. Mit d64copy kann ich Images lesen und schreiben. Wenn ich den Parameter -t parallel verwende, liest d64copy ein .d64 in 30 Sekunden und schreibt es in 40 Sekunden. Der Parallelport scheint also zu funktionieren, die Verdrahtung muss also korrekt sein.


    Dummerweise gehen die nibtools nicht. Ein "nibread -t test.nib" resultiert nur in folgender Ausgabe:



    Ich benutze die aktuellen Versionen von OpenCBM und nibtools aus dem GIT bzw. SVN unter Ubuntu 14.04. Ein Test unter Windows 7 brachte aber genau das gleiche Ergebnis.


    Das Kabel von der ZoomFloppy zur 1541 ist nur ca. 25cm lang, daran kanns also nicht liegen, oder? Das USB Kabel ist ebenfalls nur ~40cm lang. USB Kabel hab ich schon verschiedene ausprobiert, ebenfalls einen Hub mit eigener Stromversorgung.


    Ich hatte dann den Verdacht, dass der Port B vom AVR defekt sein könnte, also hab ich ihn an ein paar LEDs auf einem Steckbrett angeschlossen und ein kleines Testprogramm geschrieben. Ebenfalls Fehlanzeige, alle LEDs haben gleichmäßig geleuchtet ...


    Wenn ich statt der 1541 eine 1571 anschließe und das SRQ-Nibbling benutze, dann funktionieren nibread und nibwrite auch einwandfrei. Aber halt ohne den Parallelport zu benutzen.


    Eine 1541-II habe ich ebenfalls probiert, gleiches Ergebnis wie bei der 1541.


    Langsam bin ich echt ratlos. Hat vielleicht jemand einen Tipp, worans liegen könnte, oder was man noch versuchen könnte :?:


    Edit: hier noch ein Foto vom Aufbau:


    Zitat von Mario28

    Bist du dir sicher, dass die Verkabelung vom Parallelport richtig ist?
    Welche CPU benutzt du auf deinem Zoomfloppy-Nachbau?


    Ja, doppelt und dreifach überprüft und auch Verbindungen zu Nachbarpins ausgeschlossen. Ich hab ja geschrieben, d64copy funktioniert im Parallelmodus (-t parallel), nur eben nibread nicht.


    CPU ist ein Mega32U2, wie eben auf der ZoomFloppy.


    Hab noch ein paar Bilder angehängt.



    Kannst du nibtools selber übersetzen/builden? nibtools sendet beim Parallelport-Test bestimmte Bytes und überprüft die dann. Die könntest du mal auf dem Bildschirm ausgeben und schauen, ob es an einem, mehreren, oder allen Bits liegt. Ich würde im Sourcecode einfach mal zwischen "Testing communication" und "Failed port transfer test. Check cabling." suchen. Einfache String-Suche im Sourcecode und dann die Bytes mit einfachen "printf()" ausgeben, am besten natürlich binär, dann sieht man gleich, welche Bits unterschiedlich sind. Frag mich aber nicht, wie man nibtools übersetzt.

    OK, also test_par_port() in drive.c schickt ein Testpgrogramm an die Floppy. Die Floppy sollte dann 257 Bytes senden, 0 bis 255 in aufsteigender Folge und zum Schluss noch eine 0. Ich hab die Funktion jetzt so modifiziert, dass die Werte angezeigt werden: es sind ausschließlich 0xFF ...

    Soo, da fiel mir ja noch ein, dass ich einen Logikanalyzer rumliegen hab.



    So sieht das aus, wenn d64copy eine Diskette liest. Man kann schön die einzelnen Tracks und Sektoren erkennen.



    Und so sieht das aus, wenn nibread versucht, zu lesen. Irgendwelches undefinierbares Zeug.


    Wäre schön wenn sich jemand die Daten genauer anschauen könnte. Die Software dafür gibts für Win, Linux und Mac, ist nur 10MB: https://www.saleae.com/downloads

    Ich hab jetzt ein kleines Programm geschrieben, welches auf der 1541 läuft:



    Über OpenCBM wird das auf die Floppy geladen. Das Programm gibt einfach ein Byte auf dem Parallelport aus, inkrementiert dann um 1, gibt es wieder aus, und so weiter. So sieht das dann aus:



    Also, alles einwandfrei, nur scheint der 6502 so ziemlich genau alle 15ms eine Pause zu machen, aber ich denke das ist normal, oder?


    Könnte es vielleicht ein Problem bei der Synchronisation zwischen dem parallelen und dem seriellen Port geben?


    Die Pausen sind sehr schlecht, das ist aber möglicherweise nicht das Problem. Füg am Anfang deines Testprogramms mal ein "SEI" ein und schau mal, ob die Pausen dann verschwinden.

    Zitat von LXIV

    Und so sieht das aus, wenn nibread versucht, zu lesen. Irgendwelches undefinierbares Zeug.


    Ich hab das Programm jetzt nicht heruntergeladen. Der nibread-Screenshot sagt mir so natürlich nichts. Du könntest ja mal eine Logicanalyzer-Aufnahme vom nibread mit SRQ-Modus, als auch mit Parallelport-Anschluss machen. Also bis zu der Stelle, an der der Fehler beim Parallelport-Anschluss auftritt. Dann mal vergleichen. Im wesentlichen sollten ja dieselben Daten übertragen werden. Möglicherweise wird beim SRQ-Modus noch ein erweiterter Kabeltest gemacht, den kannst du ja ignorieren.

    Zitat von LXIV

    OK, also test_par_port() in drive.c schickt ein Testpgrogramm an die Floppy. Die Floppy sollte dann 257 Bytes senden, 0 bis 255 in aufsteigender Folge und zum Schluss noch eine 0. Ich hab die Funktion jetzt so modifiziert, dass die Werte angezeigt werden: es sind ausschließlich 0xFF ...


    Bist du dir sicher, dass es jedesmal ausschließlich 0xFF sind? Das könnte schon der Fehler sein. Dann wäre zu überlegen, wie das eigentlich passieren kann. Kannst du mal mit dem Logicanalyzer die Parallelport-Leitungen der Floppy 'abschnüffeln', während nibread die 0xFFs ausgibt? Sendet die Floppy schon die 0xFFs oder die richtigen Bytes?

    Zitat von Mario28

    Die Pausen sind sehr schlecht, das ist aber möglicherweise nicht das Problem. Füg am Anfang deines Testprogramms mal ein "SEI" ein und schau mal, ob die Pausen dann verschwinden.


    Jap, tun sie. Mit dem Programm



    sieht die Übertragung perfekt aus. Keine Pausen, keine Lücken, keine Glitches.


    Hier ist das Programm als Hex, falls es jemand braucht. Das kann man auch am C64 eintippen, mit M-W an die Floppy senden (Adresse 0x500) und dann mit U3 starten:


    Code
    1. 0xa2,0xff,0x8e,0x03,0x18,0x78,0xa2,0x00,0x8e,0x01,0x18,0xe8,0x4c,0x08,0x05



    Zitat von Mario28


    Bist du dir sicher, dass es jedesmal ausschließlich 0xFF sind? Das könnte schon der Fehler sein. Dann wäre zu überlegen, wie das eigentlich passieren kann. Kannst du mal mit dem Logicanalyzer die Parallelport-Leitungen der Floppy 'abschnüffeln', während nibread die 0xFFs ausgibt? Sendet die Floppy schon die 0xFFs oder die richtigen Bytes?


    Ja, der Screenshot oben zeigt ja den Abschnitt wo die Floppy die 256 Testbytes senden sollte. Da ist nur kurzes Gewackel und dann sind die Leitungen alle high, also 0xff.


    Ich hab mir mal den Übertragungscode von den nibtools genauer angeschaut, es wird ATN als Handshake benutzt, ich werde jetzt mal testen wie ATN in Relation zum Parallelport aussieht.