XU1541-Kabel

Es gibt 83 Antworten in diesem Thema, welches 22.792 mal aufgerufen wurde. Der letzte Beitrag (24. Juli 2010 um 07:55) ist von 7Saturn.

  • So einen Bausatz mit geflsahtem Chip würde ich auch nehmen.
    Ich versuche jetzt zwar mal, mich in das AVR Thema einzuarbeiten, aber so richtig Zeit habe ich nicht...

    Bitte melde dich an, um diesen Link zu sehen.- Bitte melde dich an, um diesen Link zu sehen.- Bitte melde dich an, um diesen Link zu sehen.
    -
    User ignorieren? AdBlock!www.forum64.de##ARTICLE[data-user-id="xxxxx"]

  • Nabend

    Hab grad mein XU1541 fertig gelötet, auf Lochraster. Verschwindet nachher sowiso in meiner 1541-II, mit USB Buchse. Quasi ein USB Diskettenlaufwerk für CBM Disks *g*.
    Das mit dem Update über USB ist übrigends ne wucht :).

    Nur, ähm... wie bau ich mir jetzt opencbm aus dem CVS zusammen?
    Bin da grade bissel verwirrt was da wo in welchem ordner wie aktuell ist ;).

    Edit:
    OK, man braucht den kram aus CBM4WIN. Jetzt crasht es bei cbmforng.a65 :(.
    Ist wohl mein CC65 zu alt.

    Mfg
    Suschman

    3 Mal editiert, zuletzt von Suschman (17. Juni 2007 um 10:02)

  • Zitat

    Original von Suschman
    Hab grad mein XU1541 fertig gelötet, auf Lochraster.


    Glückwunsch.

    Zitat


    Das mit dem Update über USB ist übrigends ne wucht :).


    Blöderweise kann damit noch nicht alles upgedatet werden. Wenn das fertig ist wollen wir das xu1541 aktiver bewerben.

    Zitat


    Nur, ähm... wie bau ich mir jetzt opencbm aus dem CVS zusammen?
    Bin da grade bissel verwirrt was da wo in welchem ordner wie aktuell ist ;).


    Die jeweils aktuellsten Versionen im CVS (achtung, nicht im SVN, das ist nur im Testbetrieb!) sollten funktionieren. Also xu1541 Bootloader, Firmware, sowie das cbm4win Verzeichnis.

    Nutzt du Windows oder Linux? Für Windows ist nur der Weg der Kompilierung mit dem Windows DDK (heißt inzwischen "WDK") getestet und unterstützt.

    Zitat


    OK, man braucht den kram aus CBM4WIN. Jetzt crasht es bei cbmforng.a65 :(.
    Ist wohl mein CC65 zu alt.


    Kann gut sein. Ich weiß, dass ich bei meiner Arbeit an cc65 2 oder 3 Bugreports bzgl. cc65 (ca65) an Uz geschickt hatte. Am besten, du testest eine einigermassen aktuelle Version von cc65. Ich persönlich nutze ide 2.11.0 unter Windows, und 2.11.9 unter Linux.

    HTH,
    Spiro

  • Zitat

    Blöderweise kann damit noch nicht alles upgedatet werden. Wenn das fertig ist wollen wir das xu1541 aktiver bewerben.


    Bis auf den Bootloader selber ist doch damit die Firmware austauschbar?

    Sag mal, leuft der Paralelle Speeder-Modus zur Floppy schon?

    Zitat

    Nutzt du Windows oder Linux? Für Windows ist nur der Weg der Kompilierung mit dem Windows DDK (heißt inzwischen "WDK") getestet und unterstützt.


    Linux. Bootloader und Firmware laufen...

    Zitat


    Kann gut sein. Ich weiß, dass ich bei meiner Arbeit an cc65 2 oder 3 Bugreports bzgl. cc65 (ca65) an Uz geschickt hatte. Am besten, du testest eine einigermassen aktuelle Version von cc65. Ich persönlich nutze ide 2.11.0 unter Windows, und 2.11.9 unter Linux.


    Hatte ein Package von 2004 (oder so) aus bequemlichkeit installiert. Muss ich den cc65 halt auch aus dem source bauen.

    Mfg
    Suschman

  • Zitat

    Original von Suschman
    Bis auf den Bootloader selber ist doch damit die Firmware austauschbar?


    Ja. "Dummerweise" haben die letzten Firmwares einige Features, so dass sie mit älteren (> 7 Tage) Bootloadern nicht mehr funktionieren.

    Hintergrund: Ich will Bootloader und Firmware mehr verheiraten. Der Bootloader soll eine Art BIOS werden. Ansonsten gibt es viele Programmteile, die in beiden Teilen vorkommen und den wertvollen Speicherplatz verbraten. Insbesondere der USB-Code, der den größten Brocken ausmacht, soll nur noch einmal vorhanden sein.

    Es wird bald wieder einen Umbau geben, der ältere Versionen inkompatibel macht. Zur Zeit erlaube ich mir das noch, deshalb bewerben wir das xu1541 nicht aktiv. Jemand, der sich das selbst zusammenbaut, kann auch noch "mal eben" den Bootloader neu flashen. Jemand, der das Teil nur erwirbt, wird das eventuell nicht können und eventuell sauer sein, wenn er keine Updates mehr machen kann und z.B. keinen Bugfix mehr bekommt.

    Zitat


    Sag mal, leuft der Paralelle Speeder-Modus zur Floppy schon?


    Ja, allerdings ist er nur unwesentlich schneller als der s2 Modus. Er lohnt sich also zur Zeit leider nicht. Der parallele Modus eines XP1541 ist jedenfalls deutlich schneller. Genaue Untersuchungen, warum das so ist, stehen noch aus, auch wenn wir da einen Verdacht haben.

    Zitat


    Linux. Bootloader und Firmware laufen...


    Gut. Wie gesagt, dann nutze am besten das aktuelle CVS auf Bitte melde dich an, um diesen Link zu sehen.


    Zitat


    <cc65>
    Hatte ein Package von 2004 (oder so) aus bequemlichkeit installiert. Muss ich den cc65 halt auch aus dem source bauen.


    Jo. Für Debian gibt es noch ein Paket auf meiner Seite. Wenn du in /etc/apt/sources.list die Zeilen

    Code
    deb     http://www.trikaliotis.net/download/debian/cc65/ binary/
    deb-src http://www.trikaliotis.net/download/debian/cc65/ source/


    ergänzt, dann kannst du das für Debian Sarge und/oder Debian Etch nutzen. Das soll laut Report auch für Ubuntu funktionieren.

    Gruß,
    Spiro

  • Hallo. Gibts dazu was Neues..?
    Der Link zu Till's Seite scheint tot zu sein..?
    Wo findet mal Schaltplan + Firmware etc.

    Gibts Bausätze/Fertiggeräte?

    Peter

  • Till hat das Projekt vor ein paar Tagen als gescheitert erklärt. Seine Web-Seiten hat er bereits vom Netz genommen. Er begründet diesen Schritt damit, dass es keine sichtbaren Fortschritte in der Entwicklung gab (und das ganze zu einem "großen, undokumentierten Durcheinander" wurde).

    Wer weitere oder genauere Infos möchte, sollte vielleicht mal bei Till direkt nachfragen.

    Vielleicht kann strik nochmal genauere Infos geben?

  • Hallo,

    ok, dann will ich mal.

    Richtig, Till hat das Projekt aus seiner Sicht gecancelled. Letztendlich hat er das Interesse daran verloren, was seiner Aussage nach auch daran lag, dass es so schleppend voran ging.

    Das XU1541 wird aber nicht sterben, die Unterstützung in OpenCBM ist schon fertig; was fehlt ist "eigentlich" nur noch die (automatische) Installation und ein paar Tests.

    Die Aufbauanleitung für das XU1541 wird "in Kürze" auch wieder im Netz erscheinen. Bitte habt etwas Geduld. Ansonsten einfach mal bei "Internet Archiven" nachschauen. Die .BRD und .SCH Files für EAGLE gibt es im OpenCBM CVS.

    Gruß,
    Spiro

  • ich habe mir auch mal Überlegungen, zu eine USB Lösung für die 1541, gemacht.
    Allerdings habe ich eine anderen Ansatz verfolgt. Ich wollte das die 1541 als D64 File in einem Fat Kleid im Filesystem erscheint.
    Das währe dann auf allen Systemem ohne Software lauffähug, wie einen USB Stick.
    Dazu wollte ich zB. Sdkartenleser mit einem Chip erweitern, der dann die 1541 anspricht.
    Das Programm währe recht simpel, da es eine iec Master sein müsste. Ausserdem müste es ein starres fatgerüst simmulieren und die daten zum sd slot übergeben.
    Ich stelle dies als Anregung hir ein, da ich selbst vorerst keine Gelegenheit habe das anzufangen.

    Wer Deteils wissen möchte, bitte mich ansprechen.

  • Allerdings habe ich eine anderen Ansatz verfolgt. Ich wollte das die 1541 als D64 File in einem Fat Kleid im Filesystem erscheint.
    [...]
    Das Programm währe recht simpel, da es eine iec Master sein müsste.


    Die Idee ist nicht schlecht (und ich hatte darüber auch schon mal nachgedacht).

    Nachteil: Dieses Device ist entweder extrem langsam (Original-IEC-Routinen), oder es muss einen eigenen Fastloader mitbringen. D.h., die ganze Logik, die zur Zeit in OpenCBM steckt, muss in das GErät hinein - und noch mehr, weil ja das FAT - wenn es zum Lesen auch recht einfach ist, wie du schon schriebst - simuliert werden muss.

    Wenn man allerdings auch schreiben will wird es kompliziert: Die FAT-Struktur gibst dann ja nicht mehr du vor, sondern das schreibende Gerät!

    Ich sage nicht, dass es nicht machbar ist, sondern nur, dass es einiges mehr an Arbeit ist, als du bislang glaubst. ;)

    Gruß,
    Spiro


  • Wenn
    man allerdings auch schreiben will wird es kompliziert: Die
    FAT-Struktur gibst dann ja nicht mehr du vor, sondern das schreibende
    Gerät!


    Ohne Cache für die komplette Diskseite würde das kaum funktionieren:


    Solange Du eine bestehende FAT-Datei änderst (entspräche: Schreiben auf
    die .d64-Diskette) kannst Du hoffen daß das System die Sektoren an Ort
    und Stelle beläßt.


    Aber wehe ein uneingeweihter User löscht die Pseudo-.d64 und ersetzt
    sie durch eine neue. Dann schreibt das System im Extremfall die
    gesamten 170k, bevor es die neue FAT schreibt. Das Interface braucht
    aber die FAT, um die soeben übermittelten 170k Daten sinnvoll auf die
    Diskette zu verteilen. Nur die Fake-FAT und das Fake-Directory
    schreibzuschützen geht auch nicht, weil der Computer bestenfalls
    Schreibfehler meldet und schlimmstenfalls gar nix davon mitbekommt.
    Noch dazu hat jedes Betriebssystem im Zweifel seine eigene
    Vorgehensweise beim Schreiben von Dateoen auf ein FAT-Laufwerk...


    Und spätestens wenn man auf einzelne Dateien zugreifen will, braucht
    man eh eigene Programme. Oder hat USB 'ne generische Klasse für'Netzwerklaufwerke'?

    KI-Verwendung in diesem Posting: Rechtschreibkontrolle des Browsers.
    Abweichungen aufgrund des technischen Fortschritts oder individueller Vorlieben vorbehalten.

  • Wer ist bereit sich die Datenstrucktur und die Vorgehensweise diverser Betriebssysteme und c64 Emulatoren auf einem USB Stick anzusehen?
    :winke:

  • warum nicht einfach über zwei vendor spezifische usb kommandos die 1541 als blockdevice direkt ansprechbar machen?

    Zitat


    Wer ist bereit sich die Datenstrucktur und die Vorgehensweise diverser Betriebssysteme und c64 Emulatoren auf einem USB Stick anzusehen?

    das ist zum scheitern verurteilt, zumindest so wie du dir das vorstellst. wie mc71 schon sagte, ohne cache für die komplette fat plus das zu schreibende d64 wird das in die hose gehen. selbst *wenn* man sich das auf ein paar existierenden betriebssystemen angucken würde und evtl dann ans laufen kriegen würde...spätestens beim nächste update könnte sich schon wieder alles ändern.

  • Danke für die Erklärung :lauh3: :baby:
    Schade, das dass nicht standardisiert ist.
    So darf man dann immer wieder für jede Plattform neue Treiber machen.,... :schreck!:

  • Zitat


    Schade, das dass nicht standardisiert ist.

    das ist schon standardisiert. nur nicht auf der block ebene, da würde es schlicht keinen sinn machen.

  • Hallo,
    Richtig, Till hat das Projekt aus seiner Sicht gecancelled.
    [...]
    Die Aufbauanleitung für das XU1541 wird "in Kürze" auch wieder im Netz erscheinen.


    Gibbet nun wieder hier: Bitte melde dich an, um diesen Link zu sehen.

    Gruß,
    Spiro

  • so, exumieren wir das Ding hier mal.

    Hab gerade etwas Zeit, da wollte ich mich dem Dingen mal widmen... Kurz auf Lochraster geklöppelt, passt soweit. Hab nur ein paar kleine Problemchen:

    Getestet auf 2 unterschiedlichen Systemen, gentoo und arch, der selbe Fehler. Hab keine Ahnung vom Bootloader-Zeug.

    dann:

    Irgendwas stimmt da nicht.

    Zu guter letzt: wie kriege ich das mit opencbm-cvs zusammen?

    Danke

  • so, nach einem Tag rumfummeln und Informationen von 100000 Seiten zusammensuchen kompilliert das Zeug endlich tadellos. allerdings schmiert jede opencbm-app ab.

    Code
    usb 1-1: USB disconnect, address 3
    usb 1-1: new low speed USB device using uhci_hcd and address 4
    usb 1-1: configuration #1 chosen from 1 choice
    usb 1-1: usbfs: USBDEVFS_CONTROL failed cmd xu1541_update rqt 192 rq 1 len 0 ret -84
    usb 1-1: reset low speed USB device using uhci_hcd and address 4
    usb 1-1: usbfs: USBDEVFS_CONTROL failed cmd usb_echo_test rqt 192 rq 255 len 4 ret -71
    usb 1-1: usbfs: USBDEVFS_CONTROL failed cmd usb_echo_test rqt 192 rq 255 len 4 ret -71
    usb 1-1: usbfs: USBDEVFS_CONTROL failed cmd usb_echo_test rqt 192 rq 255 len 4 ret -71
    usb 1-1: usbfs: USBDEVFS_CONTROL failed cmd usb_echo_test rqt 192 rq 255 len 4 ret -71

    Auf mehreren Maschinen getestet.

    Edit: So, mal ein paar andere ATmega8's getestet.. bei den -16PI hab ich meistens obiges Problem, bei den -16PU gibts keine Ausgabe. Funktionieren tuts trotzdem nicht, cbmctrl reset zieht nicht mal die Resetleitung nach Unten...

  • Falls jemand das XU1541 nachbauen will ohne alles von Grund auf mit Lochraster zu machen, kann ich nur das AT90USB162 Board von Olimex empfehlen, damit geht das ganz einfach: Bitte melde dich an, um diesen Link zu sehen.

    Bitte melde dich an, um diesen Link zu sehen. --- Bitte melde dich an, um diesen Link zu sehen. --- Bitte melde dich an, um diesen Link zu sehen.

  • Von der Bitte melde dich an, um diesen Link zu sehen. :

    Zitat

    It can not be connected to a C64 in order to act as a virtual disk drive. This is due to the fact that the software USB solution used in this project prevents the AVR from being able to react fast enough on incoming requests (the USB stack requires that no other hardware interrupts are being used).

    Dabei geht's vermutlich um ATN-Kram? Beim SD2IEC wird ATN aber auch nur gepollt (= nix Interrupts), das scheint also zu reichen?
    Da die AVRs aber auch fast nichts kosten, wäre es ggf. eine Überlegung wert, zwei (z.B. über SPI?) zusammenzukoppeln und einen für die zeitkritischen IEC-Sachen, den anderen für USB zu nehmen. Die IEC-Seite wäre durch SD2IEC quasi abgedeckt :-)...

    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.