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

letzter Beitrag von Masterhit am

XS-1541 / OpenCBM Betatest

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


    Nein, beim Teensy steht ein USB high-speed (USB 2.0) mit 480MBit zur Verfügung. Von der Geschwindigkeit total überzogen, hat nur den Nachteil, dass es nur bestimmte Zeitslots hat, und daher nur bei großen Paketgrößen performant ist.


    Beim XS steht eine USB Bridge zur Verfügung, die intern mit full-speed (12 Mbit/s) arbeitet. In der Praxis jedoch eine RS232 abbildet, die kaum schneller als 115200 Bd arbeiten kann. Es stehen also keine USB Features zur Verfügung sondern nur eine virtualisierte, relativ langsame COM Schnittstelle.


    Noch dazu ist der USB AVR hoch spezialisiert auf Datenübertragung. Er hat grosse interne Buffer die vollautomatisch, fehlergeprüft übertragen werden.


    Der normale AVR hat einen ein Byte großen Sendebuffer, der automatisch übertragen wird. Über Handling , Protokoll, datensicherheit muss man sich selbst Gedanken machen. Interrupt maskieren über längere Zeit geht schon mal überhaupt nicht, sonst verliert man Daten.


    Es ist ein interessanter Versuch, das mit dem AVR zu machen. Aber letztlich ist es Knochenarbeit die ziemlich unnötig ist, angesicht der Tatsache, dass es eine fertige USB Lösung gibt. Aber erstens gibt es halt XS User die unterstützt werden sollen, und zweitens mach ich das ja hauptsächlich um was zu lernen.

  • ok, aber bis auf die USB-Anbindung müßte doch die Software gleich sein.
    Da war ich etwas zu schnell.


    Das bedeutet dann aber, man hat zwar einen Parallelanschluss an die Platine gebastelt, aber keine gedanken darüber gemacht ob das jemals unterstützt wird.
    Oder gibts momentan eine Software dafür?

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

    Das kommt immer, wenn das cbmctrl beendet wird.


    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.

    Unkenntnis? Muss man das nicht? Sieht nicht so aus, als ob die 8050 automatisch erkannt werden würde: cbmctrl detect gibt 8: 8250 dos2.7 aus -- ist aber nur eine 8050.
    Was meinst Du mit "dump der oberen 16K" und wie macht man das?

  • Das kommt immer, wenn das cbmctrl beendet wird.


    Seltsam, bei mir nicht. Verwendest du XP?



    Sieht nicht so aus, als ob die 8050 automatisch erkannt werden würde: cbmctrl detect gibt 8: 8250 dos2.7 aus -- ist aber nur eine 8050.


    Meine wird schon automatisch erkannt. Wusste gar nicht, dass es soviele ROM Versionen gegeben hat? Ich habe alle Floppys der XUM Betatester in die Erkennung eingegeben ...



    Was meinst Du mit "dump der oberen 16K" und wie macht man das?


    Mit

    Zitat

    cbmctrl download 8 0xc000 0x4000 > nils8050.rom

    kann man das machen.

  • ja, XP. Aber virtualisiert mit Parallels 5 unter Mac OS X 10.6.
    Der Zugriffsfehler erscheint immer dann, wenn das Programm seine Arbeit getan hat und planmässig beendet wird, und zwar sowohl bei cbmctrl als auch bei d82copy.


    Irgendwie komme ich mit dem Kopieren einseitiger Disketten so gar nicht zurecht und der -1 Parameter will irgendwie gar nicht.
    Wie macht man das denn richtig, einseitige Disketten einzulesen?
    Und wie, wenn man die mit einer 8250 formatiert hat, aber nur die erste Seite benutzt wird, und man diese dann mit einer 8050 einliest?



    Der -b Parameter spart aber wirklich jede Menge Zeit. Diese recht leere Visicalc-Diskette hat damit nur noch 7:31 gebraucht.


    ROM-Dump habe ich angehangen.

  • Irgendwie komme ich mit dem Kopieren einseitiger Disketten so gar nicht zurecht und der -1 Parameter will irgendwie gar nicht.
    Wie macht man das denn richtig, einseitige Disketten einzulesen?


    Bei dir funktioniert ja die Floppy Erkennung (noch) nicht richtig. Er geht bei dir ja offensichtlich fälschlicherweise von einer 8250 aus. Deshalb ist der Parameter

    Zitat

    -d 8050

    schon ok, solange die Floppy Erkennung noch nicht ok ist. Später wird man das nicht mehr benötigen.


    Wenn das d82copy weiss, dass es eine 8050 Floppy ist, geht es eigentlich immer von einseitigen Disketten mit 77 Spuren aus.




    Und wie, wenn man die mit einer 8250 formatiert hat, aber nur die erste Seite benutzt wird, und man diese dann mit einer 8050 einliest?


    Das geht eigentlich gar nicht, denn diese Disketten haben 4 BAM Blöcke und 154 Spuren, wovon nur die Hälfte lesbar ist. Du kannst auch keine 1571 Disketten einlesen auf einer 1541 Floppy. Deshalb auch die Fehlermeldung. Das enstehende Imagefile ist natürlich auch nicht ok, weil zu kurz.

  • Man kann doch mit einer 8050 Dateien von 8250-formatierten Disketten lesen, wenn diese nicht die zweite Seite belegen. Heisst das, man muss diese Disketten dateiweise auslesen und kann kein d80-Image mit d82copy erstellen?


    Eigentlich bin ich verwundert, dass die 8050 so ohne zu mucken mit diesen Disketten umgehen kann, trotz geänderter DOS-ID. Die 8250 funktioniert ja erst beim zweiten Zugriff mit einseitigen Disketten.


    Man kann das D82COPY natürlich schon anpassen, dass es nur eine Seite von einer zweiseitigen Diskette liest. Man muss das nur vorsehen und am Ende die zweite, fehlende Seite mit Nullen auffüllen. Ich hab an so etwas nicht gedacht, wo ich das D82COPY entwickelt habe.

  • Eigentlich bin ich verwundert, dass die 8050 so ohne zu mucken mit diesen Disketten umgehen kann, trotz geänderter DOS-ID. Die 8250 funktioniert ja erst beim zweiten Zugriff mit einseitigen Disketten.


    Wieso unterschiedliche DOS-ID?


    Laut meinen Unterlagen verwenden sowohl 8050 als auch 8250 die gleiche DOS-ID 2C.


    Der Fehler, der bei einer 8250 auftritt, die auf eine 8050-formatierte Diskette trifft, rührt IHMO daher, dass die 8250 eben aufgrund der Disk-ID NICHT unterscheiden kann, welches Format verwendet wurde und daher die BAM auch auf der zweiten Seite sucht, was den Illegal track or sector ergibt.


    Liege ich falsch?

  • Laut meinen Unterlagen verwenden sowohl 8050 als auch 8250 die gleiche DOS-ID 2C.


    Dass die ID gleich ist, erstaunt mich. Aber du hast vollkommen Recht!



    Der Fehler, der bei einer 8250 auftritt, die auf eine 8050-formatierte Diskette trifft, rührt IHMO daher, dass die 8250 eben aufgrund der Disk-ID NICHT unterscheiden kann, welches Format verwendet wurde und daher die BAM auch auf der zweiten Seite sucht, was den Illegal track or sector ergibt.


    Nein!


    Die BAM liegt in jedem Fall auf derselben Spur. Die 8050 hat 2 und die 8250 hat 4 BAM Blöcke. Auf der zweiten Diskettenseite sind nur Datensektoren. Man kann die zweite Seite auch nicht so einfach mit einer 8050 auslesen, indem man die Diskette umdreht.

  • Ich habe jetz einen Release im Test mit komplett überarbeiteten Kommunikationsroutinen (Protokoll Interrupt getrieben) und einem fast stream download Modus für die NIBTOOLS Routinen. Sobald das stabil läuft, mache ich einen weiteren Betatest.


    Leider ist am Nils XS-1541 Rev-D der parallel Connector inkompatibel zum Zoomfloppy. Deshalb kann ich da zur Zeit den parallel Modus nicht testen. Da muss ich mir erst ein Adapterkabel basteln. Aber S1 und S2 arbeiten schon mal ganz ok, und das D82COPY läuft jetzt auch etwas schneller. Besonders schnell ist es auch am Zoomfloppy nicht, weil es ja nur mit standard CBM Busroutinen läuft und U1/U2 Blocklese-/Schreib- Routinen.

  • Neue Erkenntnis (für mich neu): Diese USB Bridge ist der Hemmschuh!



    Hat wer ein XS-1541 mit einer richtigen seriellen Schnittstelle? Dann hat er Glück!



    Eine serielle Schnittstelle ohne USB Bridge funktioniert mit dem Open-CBM einfach unvergleichlich besser als diese USB Dinger. Mit einer echten RS232 hat man eine verlässliche und vorallem timing konstante Übertragung. Bei 115200 Bd kommt ein Byte in ca. 100µs an. Nicht so bei über USB simulierte RS232, da sind einem die Latenzzeiten des USB voll im Weg. Ein einzelnes Byte benötigt über die USB Schnittstelle oft deutlich über eine Millisekunde.


    Da OpenCBM leider oft dazu neigt, sehr kleine Pakete zu senden (oft nur einzelne Bytes), wirkt sich das sehr schlecht auf die Reaktionszeit und damit auf die Übertragunsrate aus. Bei großen Paketen kann der USB gut mithalten: T: sende mir 2K Daten, R: Datenpaket, das sind zwei Pakete, da spielen 2 Millisekunden Verzögerung keine Rolle. Werden die 2K jedoch byteweise übertragen, dann hat man 4000 Pakete!, wenn jedes Paket eine Latenzzeit von einer Millisekunde hat, dann verliert man schon VIER SEKUNDEN!



    Das ist der Grund, warum zB. das Directory lesen so abartig langsam läuft beim XS-1541 Rev.D. Bei meinem seriellen XS-1541 geht das jetzt eigentlich ziemlich flott, vorallem mit dem IEEE-488 Laufwerk.



    Beim letzten Test Release habe ich das Problem umgangen, indem ich einen Cache eingebaut habe. Wurde ein Byte angefordert, habe ich schon mal 254 bytes gelesen. Alle weiteren Anforderungen einzelner Bytes laufen dann superschnell über den Cache.


    Das Problem fängt an, sobald ein Programm aus zwei Kanälen liest: Download eines Files aus Kanal 0, zwischendurch lesen des Fehlerkanal 15. Oder zwischendurch von einer anderen Floppy ... Fazit: man kann Caching nicht so einfach in einem Gerätedriver machen. Nicht wenn man dem Zielgerät (Commodore Floppy) nicht mitteilen kann, dass man die letzten gelesenen 251 Bytes verwerfen soll, und der Filepointer zurück gestellt werden soll. Sowas unterstützt das Zielgerät einfach nicht.



    Schlussfolgerung: auf einem XS-1541 mit USB Bridge wird OpenCBM nicht performant laufen! Auf einem XS-1541 mit richtiger seriellen Schnittstelle ohne USB wird es klappen.



    Natürlich könnte man alle Routinen umstellen auf größere Daten Pakete. Dann klappt es auch mit der USB Bridge. Also alle Tools des openCBM anpassen. Das Problem ist, OpenCBM ist auch ein API für Drittanbieter wie NibTools, CBM-Xfer usw. Diese Programme können auch byteweise lesen, das API bietet es ja an, da ist es nicht mehr so leicht die alle USB tauglich zu machen ...


    Übrigens leidet auch das Zoomfloppy an diesem USB Latenz Problem. Da ist es halt nicht ganz so tragisch, weil Nate das durch diverse Tricks optimiert hat, die aber nur bei voller USB Kontrolle zur Verfügung stehen. Tatsache ist, das Directory wird mit einem XA-1541 kabel schneller gelesen, als mit dem Zoomfloppy.

  • Also ZoomFloppy -> Müll.
    Gut das ich gestern meine 2 Stück bekommen habe. :)


    Nö! So will ich das nicht interpretiert sehen.


    USB + Mini Datenpakete (bzw. einzelne Bytes) = schlechte Performance.



    Das Zoomfloppy selbst ist genial! Ich bin sehr froh dass ich meine beiden Zoomfloppy habe. Das Zoomfloppy kann nix dafür, dass der USB diese Schwäche hat. Im Normalfall macht es ja auch nichts, wenn man von vornherein alles auf größere Pakete auslegt. Das OpenCBM bietet halt Einzelbytezugriff, weil es historisch bedingt durch das X-Kabel völlig problemlos gewesen ist.

  • Ich habe das Paket-Versendemanagment jetzt auf die USB Bridge optimiert und die Handshakes auf ein Minimum reduziert. Es geht jetzt eigentlich alles recht flüssig. Die 1 Byte Transfers merkt man schon noch, wie halt auch beim Zoom. Aber ich denke man kann jetzt ganz gut damit leben, irgendwann wird wohl auch jemand die OpenCBM Tools optimieren auf größere Paketgrößen.


    Wenn endlich die bestellten Gender Changer da sind, dann kann ich auch die parallelen Routinen testen. Dann gibts endlich den zweiten Test. :)

  • Prima,


    da habe ich schon überlegt, einen RS232 Wandler von Po**n ranzustricken, so wie ich das von anfang an eigentlich wollte. Denn ich habe immer Probleme mit USB... Irgentwie ist das nicht meine Schnittstelle. Selbst mein Laptop stürzt manchmal mit einem Bluescreen (usb fehler) ab. Selbst wenn kein (externes) USB Gerät dran ist. Naja meistens geht es ja und bequem ist USB auch, weil es gleich 5V liefert für den AVR. Und wenn ich an meinem Hauptrechner bin und einen passiven Hub zwischenstecke, geht fast jedes USB Gerät...


    Danke Diddl für den Zwischenbericht. Freu mich schon auf die nächste Runde


    Gruß aus Stendal


    Harald Redlin

  • Hallo Ace,


    weil ich nicht genau weiß, ob es lt Forumsregeln erlaubt ist, Firmen zu nennen... Ich wollte jetzt nicht die ganzen AGBs durchgehen, für einen Beitrag. Und es gibt sicher Firmen, die genausoetwas liefern und evtl sauer sind, wenn ich sie nicht nenne...


    OK. Beim nächsten Mal schreibe ich die Firma aus (oder schweige)


    Gruß aus Stendal


    Harald Redlin