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...
XU1541-Kabel
-
Sid -
1. März 2007 um 07:09 -
Erledigt
Es gibt 83 Antworten in diesem Thema, welches 22.746 mal aufgerufen wurde. Der letzte Beitrag (
-
-
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 -
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?
ZitatNutzt 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 ZeilenCodedeb 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'? -
Wer ist bereit sich die Datenstrucktur und die Vorgehensweise diverser Betriebssysteme und c64 Emulatoren auf einem USB Stick anzusehen?

-
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
:baby:
Schade, das dass nicht standardisiert ist.
So darf man dann immer wieder für jede Plattform neue Treiber machen.,...
-
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:
Code
Alles anzeigen[s2k@myhost xu1541]$ make make -C lib make[1]: Entering directory `/home/s2k/xu1541/lib' make[1]: Für das Ziel »all« ist nichts zu tun. make[1]: Leaving directory `/home/s2k/xu1541/lib' make -C misc/ make[1]: Entering directory `/home/s2k/xu1541/misc' make -C ../lib/ make[2]: Entering directory `/home/s2k/xu1541/lib' make[2]: Für das Ziel »all« ist nichts zu tun. make[2]: Leaving directory `/home/s2k/xu1541/lib' cc -I/usr/include/ -I/usr/include -I../include/ -Wall -s -L/usr/lib -o usb_echo_test usb_echo_test.c -L../lib -lxu1541 -lusb cc -I/usr/include/ -I/usr/include -I../include/ -Wall -s -L/usr/lib -o read_event_log read_event_log.c -L../lib -lxu1541 -lusb make[1]: Leaving directory `/home/s2k/xu1541/misc' make -C update_tool/src/ make[1]: Entering directory `/home/s2k/xu1541/update_tool/src' make ../xu1541_update make[2]: Entering directory `/home/s2k/xu1541/update_tool/src' make -C ../../lib/ make[3]: Entering directory `/home/s2k/xu1541/lib' make[3]: Für das Ziel »all« ist nichts zu tun. make[3]: Leaving directory `/home/s2k/xu1541/lib' cc -g -Wall -pedantic `libusb-config --cflags` -I../../include/ -I/usr/include/ -c -o xu1541_update.o xu1541_update.c cc -g -Wall -pedantic `libusb-config --cflags` -I../../include/ -I/usr/include/ -c -o ihex.o ihex.c cc -g -Wall -pedantic `libusb-config --cflags` -I../../include/ -I/usr/include/ -c -o flash.o flash.c cc xu1541_update.o ihex.o flash.o -o ../xu1541_update -L ../../lib/ -lxu1541 `libusb-config --libs` -lusb -s rm xu1541_update.o flash.o ihex.o make[2]: Leaving directory `/home/s2k/xu1541/update_tool/src' make[1]: Leaving directory `/home/s2k/xu1541/update_tool/src' make -C firmware make[1]: Entering directory `/home/s2k/xu1541/firmware' Makefile:36: Warnung: Die Befehle für das Ziel ».S.o« werden überschrieben ../bootloader/Makefile.common:17: Warnung: Alte Befehle für das Ziel ».S.o« werden ignoriert make[1]: Für das Ziel »all« ist nichts zu tun. make[1]: Leaving directory `/home/s2k/xu1541/firmware' make -C bootloader -f Makefile-avrusb make[1]: Entering directory `/home/s2k/xu1541/bootloader' Makefile-avrusb:41: Warnung: Die Befehle für das Ziel ».S.o« werden überschrieben Makefile.common:17: Warnung: Alte Befehle für das Ziel ».S.o« werden ignoriert avr-gcc -Wall -Os -Iusbdrv -I. -I../include/ -mmcu=atmega8 -c usbdrv/usbdrv.c -o usbdrv/usbdrv.o avr-gcc -Wall -Os -Iusbdrv -I. -I../include/ -mmcu=atmega8 -x assembler-with-cpp -c usbdrv/usbdrvasm.S -o usbdrv/usbdrvasm.o avr-gcc -Wall -Os -Iusbdrv -I. -I../include/ -mmcu=atmega8 -c usbdrv/oddebug.c -o usbdrv/oddebug.o avr-gcc -Wall -Os -Iusbdrv -I. -I../include/ -mmcu=atmega8 -x assembler-with-cpp -c biostable.S -o biostable.o avr-gcc -Wall -Os -Iusbdrv -I. -I../include/ -mmcu=atmega8 -c main.c -o main.o avr-gcc -Wall -Os -Iusbdrv -I. -I../include/ -mmcu=atmega8 -o bootldr-avrusb.bin usbdrv/usbdrv.o usbdrv/usbdrvasm.o usbdrv/oddebug.o biostable.o main.o -Wl,--section-start=.textbiostable=1ff0,--section-start=.textfirmwaretable=16f0,--section-start=.textadd=1700,--section-start=.text=1800,--section-start=.data=00800360 /usr/bin/avr-ld: section .textbiostable [00001ff0 -> 00001ff5] overlaps section .bss [00001fca -> 00002001] make[1]: *** [bootldr-avrusb.bin] Fehler 1 rm usbdrv/oddebug.o usbdrv/usbdrvasm.o usbdrv/usbdrv.o biostable.o main.o make[1]: Leaving directory `/home/s2k/xu1541/bootloader' make: *** [bootloader-avrusb] Fehler 2Getestet auf 2 unterschiedlichen Systemen, gentoo und arch, der selbe Fehler. Hab keine Ahnung vom Bootloader-Zeug.
dann:
Code
Alles anzeigen[root@myhost misc]# ./usb_echo_test -- XU1541 USB test application -- -- (c) 2007 the opencbm team -- -- http://www.harbaum.org/till/xu1541 -- -- http://sourceforge.net/projects/opencbm -- Device reports BIOS version 2.14. Device reports firmware version 1.15. Device reports capabilities 0x00f7. Device is not in bootloader mode. === Running standard echo test === 256 echo test transmissions successful! === Running irq disabled echo test === GOOD: No error sending control message. USB errors may (and even should) be reported in the following lines. Expected error: error sending control message: Protocol error! Expected error: error sending control message: Protocol error! Expected error: error sending control message: Protocol error! Expected error: error sending control message: Protocol error! Echo successful Echo successful Echo successful Echo successful Echo successful Echo successful USB timeout states: 4 GOOD: Device/USB link successfully recovered from disabled target irqCode
Alles anzeigen[root@myhost misc]# ./read_event_log -- XU1541 event log dumper -- -- (c) 2007 by Till Harbaum -- -- http://www.harbaum.org/till/xu1541 -- Device reports BIOS version 2.14. Device reports firmware version 1.15. Device reports capabilities 0x00f7. Device is not in bootloader mode. Event log buffer size: 64 Event log: booted by external reset Unknown event! Unknown event! Unknown event! Unknown event! Unknown event! Unknown event! Unknown event! Unknown event! Unknown event! Unknown event! Unknown event! Unknown event! Unknown event! Unknown event! Unknown event! Unknown event! Unknown event! Unknown event! Unknown event! Unknown event! Unknown event! system started Unknown event! Unknown event! Unknown event! Unknown event! Unknown event! Unknown event! Unknown event! Unknown event! Unknown event! Unknown event! Unknown event! Unknown event! Unknown event! Unknown event! Unknown event! Unknown event! Unknown event! Unknown event! Unknown event! Unknown event! Unknown event! Unknown event! Unknown event! Unknown event! Unknown event! Unknown event! Unknown event! Unknown event! Unknown event! Unknown event! Unknown event! Unknown event! Unknown event! booted by watchdog reset Unknown event! Unknown event! Unknown event! Unknown event! Unknown event! Unknown event!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.
Codeusb 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 -71Auf 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.
-
Von der Bitte melde dich an, um diesen Link zu sehen. :
ZitatIt 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 :-)... -