Hallo Besucher, der Thread wurde 26k mal aufgerufen und enthält 83 Antworten

letzter Beitrag von Masterhit am

XS-1541 / OpenCBM Betatest

    Zitat von dg0cao

    lasse ich :4 (oder welche Com ich auch verwende...) weg, als: nur cbmctrl -@xs1541 detect -- erkennt er nicht das eine XS drannhängt.


    Ok, probier mal "cbmctrl -@xs1541:0 detect", dann sollte es automatisch alle COM Ports durchsuchen.



    Zitat von dg0cao

    [plugins]
    default=xs1541:4


    Ich hätte eigentlich gehofft, dass dies so funktioniert ...



    Zitat von dg0cao

    eintrage gibt es eine Fehlermeldung...? Und bei vice nur den Hake bei IEC-Gerät aktivieren zu setzen, reicht nicht um die Lampe am XS1541 zu aktivieren. Ich müsste dem Vice beibringen den XS1541 zu nutzen... Muß ich vor dem Vice noch irgentwie opencbm starten?


    Wenn erst die automatische Erkennung funktioniert, dann funktioniert auch der VICE, keine Sorge.



    Zitat von dg0cao

    Fragen über Fragen. Sorry für meine lange Leitung...


    Du machst das sehr gut!


    Ich bin es, der das nicht richtig umgesetzt hat, und nun was lernt. Aber dafür sind Betatests ja da ...




    Wenn man beim opencbm.conf die Portnummer nicht mitgeben kann, dann wird es wohl das beste sein, du verlegst mittelfristig COM1 auf COM4 und das XS-1541 auf COM1. Oder brauchst du deine serielle Schnittstelle unbedingt auf COM1?


    Es geht offenbar nur die automatische Suche, wenn man default XS1541 einstellt. Deshalb sollte man die Suche so kurz wie möglich machen und COM1 verwenden.


    Das die automatische Suche zur Zeit gar nicht geht, das liegt wohl daran dass nicht, wie erwartet Port 0 übergeben wird. Ich überleg mir was ...

    Zitat von for(;;)

    Die watch-dog-timer-always-on-fuse ist gesetzt - springt da vielleicht der Watchdog an und bringt das Programm zum Erliegen?


    Warum, es läuft ja grundsätzlich. Und die COM Port Problematik ist mein Problem.



    Sobald ich das mit der Environment Variable drin habe, funktioniert mit hoher Wahrscheinlichkeit auch der VICE bei ihm. :)

    So... ich habe jetzt:


    - Das XS1541 geflasht
    - Das opencbm-zoomfloppy-Paket runter geladen und install.bat ausgeführt
    - Bestehende Dateien in \opencbm\bin mit denen aus dem XS1541-Paket überschrieben
    - In \opencbm\bin\opencbm.conf den Eintrag [xs1541] location=c:\opencbm\bin\opencbm-xs1541.dll hinzugefügt
    - XS1541 angeschlossen, wird in Systemsteuerung unter COM1 angezeigt
    - Angeschlossen ist eine 1571


    Dann habe ich cbmctrl -@xs1541:1 status eingegeben und bekomme:
    NO PLUGIN DRIVER!: Das angegebene Modul wurde nicht gefunden.


    Diese Meldung bekomme ich, egal welchen Befehl ich eingebe. Ich habe noch mit meinem xu1541 rumgespielt und -@xu1541, aber da bekomme ich die genau gleiche Fehlermeldung.


    Eine Idee, was da los sein könnte?

    Ich sag ja, OpenCBM ist sehr zickig bei der Installation an einigen PC's. Das Testproggi geht aber?




    Hier wie versprochen die neue DLL. Man kann nun mit

    Code
    1. SET XS1541_PORT=2

    den COM Port überschreiben. Man spart sich so das -@ und greift trotzdem sofort auf das richtige COM zu.


    .

    Hallo Diddl,


    habe die neue *.dll in windows/system32 kopiert und in denn Windows Variablen den XS1541_PORT=4 eingetragen. Cbmctrl funktioniert nun super. CBMxf erkennt auch das Directory (mehr habe ich noch nicht probiert) Nur Vice will nicht... Das ist auch nicht so ganz wichtig, evtl kommt ja noch ein Tip von Vice Benutzern...


    Danke Diddl, so kann man das schon sehr gut gebrauchen. Werde aber morgen noch weiter testen. Danke Danke.


    Gruß aus Stendal


    Harry

    Hallo for(;;)


    die Datei opencbm.conf steht in dem Verzeichniss Windows/System32/ Die Datei im Verzeichnis vom opencbm ist "nur" die zu installierende Datei, die die Installation dann ins System32 kopiert und dann scheinabr nicht löscht. Die relevante Datei, die Du editieren musst, steht aber in System32! Habe auch erst die falsche Datei erwischt...


    Gruß Harry

    Prinzipiell funktioniert das jetzt einigermassen, wenn auch furchtbar langsam.
    Wenn das cbmctrl beendet wird, bekomme ich aber immer noch einen Fehler:
    Die Anweisung in 0xbla verweist auf Speicher in 0xbla. Der Vorgang "read" konnte nicht auf dem Speicher durchgeführt werden. Klicken Sie auf "OK", um das Programm zu beenden.

    Bei mir funktioniert es nicht richtig. Das detect oder Dir ist extrem langsam, manchmal gehts, meistens nicht. Immer wieder timeout.


    mit CBMfer ist es möglich das DIR aufzurufen, das kopieren einer disk in *.d64 ist nicht möglich. Da habe ich eine halbe Stunde gewartet und es half nur den USB Adapter aus dem PC zu ziehen, dann wurde der Rechner extrem langsam. Das Aufrufen des Taskmanager ging fast nicht... Also habe ich den Rechner neu gebootet, gleich den Taskmanager gestartet und dann nochmal CBMxfer. Wärend dem Erstellen der *.d64 scheinbar nichts passiert (Prozessorauslastung zwischen 3 und 8%) habe ich gewartet. aber nichts. Status von CBMxfer stand bei 0%. Dann USB Stecker raus -> und Prozessorauslastung ging auf 100%. Verursacht durch d64copy.exe. Das Programm war aber vor dem Ziehen das USB Adapters des XS1541 garnicht gestartet (lt Taskmanager)... Was das nun bedeutet weiß ich auch nicht....????


    Gute Nacht


    Gruß Harry

    Ich konnte mit cbmxfer mir ebenfalls das Inhaltsverzeichnis und den Status der 1571 anzeigen lassen. Diskette formatieren oder Image auf Diskette schreiben hat sich beides aufgehangen.


    Das Lesen von der 8050 klappt prinzipiell, aber ich habe nach etlichen Minuten entnervt abgebrochen, als gerade einmal ein Drittel eingelesen war. In dieser Geschwindigkeit ist das nahe unbenutzbar, da ist die Diskette eher durchgescheuert als eingelesen. Ich habe dann die klassische XS-1541-Firmware genommen, die das in 4 Minuten, 17 Sekunden eingelesen hat.


    Diddl, ich hoffe, Du kannst da noch optimieren?

    Bei Zwei Testern funktioniert es zumindest rudimentär! Das habt ihr gut gemacht! :thumbsup:



    Zitat von for(;;)

    Die Anweisung in 0xbla verweist auf Speicher in 0xbla. Der Vorgang "read" konnte nicht auf dem Speicher durchgeführt werden. Klicken Sie auf "OK", um das Programm zu beenden.


    Diesen Fehler kenne ich nicht. Kannst du mir einen Tip geben, wie man das reproduziert? Oder kommt das bei dir immer?



    Zitat von for(;;)
    Code
    1. C:\>d82copy -@xs1541:17 -d 8050 8 petspeed.d80
    2. [Warning] non-standard number or tracks: 154
    3. 1: ****----***----***----***---- 0% 13/2083


    Stammt diese Warnung noch aus d64-Zeiten, oder sollte sie mich beunruhigen?


    Die Warnung ist ok. Eine 8050 hat nur 77 Tracks. Die 154 Tracks gibt es nur bei einer 8250 und bei der SFD-1001.


    Mit der Option -b sparst du sehr viel Zeit, wenn die Diskette nicht voll ist.


    Warum überschreibst du den Devicetyp auf 8050? Wird deine 8050 nicht automatisch erkannt? Wenn nein, könntest du mir einen Dump der oberen 16K zukommen lassen? Und die Ausgabe bei "cbmctrl detect" bitte.



    Zitat von for(;;)

    Diddl, ich hoffe, Du kannst da noch optimieren?


    Ja, da ist noch sehr viel drin. OpenCBM liest in einiegen Fällen byteorientiert statt blockorientiert. Das ist bei einem superschnellen IO Gerät wie dem XA völlig egal. Bei block- und streamorientierten Geräten wie dem XU, XUM und XS tut das weh, weil der Overhead für das Protokoll überhand nimmt.


    Die gute Nachricht: Nibread wird wahrscheinlich funktionieren mit dem XS-1541 Rev-D.


    Beim Nibwrite bin ich mir nicht sicher, ob das je gehen wird mit dem XS.



    Die IEEE-488 geschichten stecken ja noch in den Kinderschuhen. Aber da wird noch einiges kommen mit Floppycode und dergleichen.


    Das nächste Ziel ist aber S1, S2 und parallel Betrieb wie beim Zoomfloppy. Da steckt noch einiges an Arbeit drin.


    Letztlich wird auch der standard Modus noch schneller, wenn man den ganzen RS232 komplett im Interrupt macht.

    Zitat von Diddl

    Beim Nibwrite bin ich mir nicht sicher, ob das je gehen wird mit dem XS.


    Wenns mit dem Teensy Device funktioniert, sollte es mit dem XS-1541 doch genauso funktionieren. ist doch mehr oder weniger die selbe hardware.

    Naja, eher weniger, als mehr. Die verwenden zwar beide einen Atmel-AVR, aber dann hören die Gemeinsamkeiten auch schon auf.


    Insbesondere das USB-Interface ist komplett anders. Während das beim Teensy Bestandteil des Prozessors ist und somit recht frei konfiguriert werden kann, ist das beim XS-1541 ein fixes USB-seriell-Interface. Das hat den Vorteil, dass man sich um die Programmierung der USB-Treiber keine Gedanken machen muss und den Nachteil, dass man auf die virtuelle serielle Schnittstelle festgelegt ist.