XS1541 und 1571

Hallo!

Hat jemand das XS1541 mal mit einer 1571 ausprobiert?

Es will nicht. Siehe Logauszug. WIrd as Java-Tool noch weiterentwickelt und gibt es Sourcen?

Verwendetes JAVA-Prog und Firmware aus diesem Thread

Die Java-RXTX ist korrekt installiertt, sonst würde es mit "drive 1541" ja nicht funktionieren.

Interessanter ist warum durch simples Andern zu "drive 1571" in der Commandozeile diese Fehlermeldung erzeugt wird:

Oh in dem Jar file sind die Java-sourcen

gleich mal reinschauen

Wie erwähnt ist nicht die RXTX-Lib schuld.

Das erste Problem liegt in der Klasse Test_XS_1541, dort wird sobald eine drive manuel gesetzt wird floppy.setImageFile() nicht aufgerufen, somit ist dieser null

Das zweite Problem scheint in der Floppy Klasse und betrifft den Fall eines zu restorendesn Images, wenn die Floppy wie z.B. die 1571 mehr als zwei Disk-Seiten hat und das Image ebenso.
Die F_1571 Klasse liefert egal welche Imagegroesse immer das erste Array für einseitige Disks aus, weshalb eine Image Laengenprüfung in floppy.readImageFile() fehlschlägt.

Mal schauen ob ich nächste Woche dazu komme da was zu fixen.

Zitat von sauhund

du hast disks mit mehr als zwei seiten ???

Ja! Du nicht? Meine haben sechs, 4 sehr flache und 2 etwas groessere, auf diesen speichert man i.d.R. die Daten, aber ich denke das weist du schon

Es haette natuerlich besser heissen muessen: "... mt zwei Seiten und mehr ..."

So mal wieder on-topic

Zitat

Verwendest du ein voll beschaltetes IEC Kabel, mit SRQ leitung?

Ja, habe zur Sicherheit auch mal da Kable getauacht und durchgemessen.

Die Bedienung des seriellen XS1541 scheint mit der 1571 zu gehen. Sofern man einige Regeln einhält: Im 1571 Modus geht nix und im 1541 Modus (U0>M0) geht auch S2.

Ich beschäftige mich gerade mit der Java-Applikation, ich bezweifle das es jemals funktioniert hat doppelseitig Images (D71) zu lesen oder zu restoren.
Ich habe das F_1571 und das Test_XS_1541 Object soweit, dass er DiskImages in den Computer Speicher liest, doch er mag Sie noch nicht auf die Floppy rausschreiben. Ebenso mag er noch nicht lesen.
Ich Teile nur meinen Patch schon mal mit, evtl. hat auch Dddl noch eine Idee, ich würde mich über Feedback freuen.

BTW: folgendes finde ich sehr obscur, da im Floppy-Object alle Calls zusammen laufen, wenn man Kommandos an die Floppy sendet:

Kommando an eine 1571 mit dem F_1541 Objekt:

Kommando an eine 1571 mit dem F_1571 Objekt:

Mir ist nicht klar warum dies geschiet. Ich kann dies auch mit der Originalversion probieren: Selbes Ergebnis. Einen anderen Serial-Port hab eich auch schon getestet.

Zitat von Diddl

Ich muss gestehen, ich bin nicht sicher ob ich das 1571 Objekt voll getestet habe. Vielleicht ist es einfach nicht fertig designed.
Die Arbeit am Java Tool habe ich irgendwann abgebrochen, wo der Reiz des Neuen verschwunden ist. Wie gesagt, die öffentliche Resonanz auf das Tool war immer schon praktisch Null.

No offense, ich mag das XS1541 es sit IMO komfortabler und hat weniger Problem als die immer noch komplexe Anbindung via OpenCBM und XA oder XUM-Kabel.
Ich erwarte garnicht das alles funktioniert. Das tolle ist ja der Transfer wird im Kontroller gemacht und nicht wie bei OpenCBM wegen dem Timing auf dem Rechner gesteuert werden muss.

Noch cooler finde ich die JavaAPI, da sie easy den Zugriff erlaubt. Derzeit ist es der Part der das XS überhaupt benutzbar macht für mich.

BTW:
Ich habe noch was cooles gefunden: Ich habe eine Disk eingelegt. Das XS resetet, danach das XS in den 1541 Mode geschaltet und das Direktroy ausgeben lassen.
Anschliessend habe ich das XS in den 1571 Modus geschaltet und ebenfalls das Direktory versucht zu lesen. Danach hängt das XS.

Ab jetzt hängt das XS...

Warum?

cya

Ich meine mit es hängt, da die Led nicht mehr blinkt aber noch leuchtet. Eingaben auf der seriellen Konsole sind nicht mehr möglich.

Aber er hängt ja auch wenn ich ein simples Floppy-Commando z.B. U0>M1 an die Floppy sende. Wenn ich den Burstmodus rcihtig verstehe, wird dieser aber erst durch einen normalen IEC Transfer angestossen, in dem ein spezielles "U0....."-Kommando gesandt wird. IEC zur Bus-Kontrolle und Burst um via SRQ einen Datenstrom mit einem Kommando zu senden. Geht auch IECIN/OUT, also Zeichenweises lesen via Burst?

EDIT: Wenn ich die XS-Firmware genauer die iec.c richtig deute, scheinet auch Zeichenweises lesen und schreiben via Burst zu gehen.

Ich habe noch mal das Kabel überprüft das ist klar durch gängig auf allen 6Pins und ist auch nicht von der Art das ATN(Pin2) auf der Ummantelung übertragen wird. Ich werde die 1571 mal an einem C128 testen und ggf. mal die CIA tauschen. ABer nicht mehr heute.

So CIA in der 1571 getauscht und zwei weitere Kabel getestet. Am XS will der Burst-Modus nicht. Am C128 schon.
Zu guter letzt habe ich an der XS-Platine auch noch überprüft ob der SRQ richtig angeschlossen ist.

Diddl: Wo finde ich die FW-Sourcen zu der letzten XS-Firmwareversion? Im Web die haben einen geringeren Versionstand als die FW in der Java-API. Hast du ne Idee wo der Bock sein könnte?

Peter: schau mal in den ersten Post dieses Threads, dort ist ein Link zu FW und JavaApi, welche das Benutzen sehr einfache macht. Restore & Backup sind durch "wt" (writetrack) und "dt"(dumptrack) u.a. realisiert.