XS-1541 mit sd2iec Firmware?

  • Wen es interessiert - ich habe eine neue Firmware für das XS-1541 entwickelt, mit dem ich den PC als Diskettenlaufwerk via USB nutzen kann.

    Aktueller Status: ALPHA

    Load und directory gehen, auch file name filter, error channel,
    am Save arbeite ich noch.

    Aktuell nur als Code-repository für Linux bei github verfügbar: github.com/fachat/XD2031

    Gruß,
    André
  • Mit dem avr-gcc 4.5.1 aus dem aktuellem CrossPack for AVR compilieren die Firmware-Quellen nicht. prog_uint8_t scheint den Ärger zu machen, ist auch als deprecated gekennzeichnet.

    Mit ein paar kleinen Änderungen compiliert es zumindest, mehr konnte ich noch nicht testen -- bin aber schon sehr gespannt, vor allem auf die IEEE-Routinen, die Du dankenswerterweise bearbeitet hast.

    Vielen Dank, dass Du Dein Projekt veröffentlicht hast!

    Unterschiede-Datei

    1. diff --git a/firmware/errormsg.c b/firmware/errormsg.c
    2. index 123d293..9840015 100644
    3. --- a/firmware/errormsg.c
    4. +++ b/firmware/errormsg.c
    5. @@ -41,7 +41,7 @@ const char PROGMEM longverstr[] = LONGVERSION;
    6. #define EC(x) x+0x80
    7. /// Abbreviations used in the main error strings
    8. -static const prog_uint8_t abbrevs[] = {
    9. +static const uint8_t abbrevs[] PROGMEM = {
    10. EC(0), 'F','I','L','E',
    11. EC(1), 'R','E','A','D',
    12. EC(2), 'W','R','I','T','E',
    13. @@ -59,7 +59,7 @@ static const prog_uint8_t abbrevs[] = {
    14. };
    15. /// Error string table
    16. -static const prog_uint8_t messages[] = {
    17. +static const uint8_t messages[] PROGMEM = {
    18. EC(00),
    19. ' ','O','K',
    20. EC(01),
    21. @@ -115,7 +115,7 @@ static const prog_uint8_t messages[] = {
    22. EC(127)
    23. };
    24. -static uint8_t *appendmsg(uint8_t *msg, const prog_uint8_t *table, const uint8_t entry) {
    25. +static uint8_t *appendmsg(uint8_t *msg, const uint8_t *table, const uint8_t entry) {
    26. uint8_t i,tmp;
    27. i = 0;
    Alles anzeigen
  • Danke für den Hinweis. Ich habe eben ein BETA1 tag gepusht. Damit sollte - denke ich - das IEEE Protokoll soweit ok sein.

    Nächste Schritte sind cleanup, Aufteilen des IEEE codes in einen HW-abhängigen und einen HW-unabhängigen Teil, und dann noch eigentliche Commands. Dabei dachte ich erstmal an CD (ChangeDirectory), Scratch, Rename, Initialize, UI (reset).

    Mit A(ssign) will ich IEEE drives (im Sinne von "$0" vs. "$1") an verschiedene directories am server binden. Ich muss mir aber noch überlegen, wie ich das so flexibel halte, damit ich z.B. auch von IEEE nach IEC und umgekehrt mappen kann...

    Demnächst mache ich wohl dann auch einen eigenen "XD2031" Thread hier auf...
  • Seufz... auch mit der aktuellen fw.hex aus dem git tut sich bei mir exakt gar nichts.

    LOAD und SAVE hängen sich auf, und fsser liefert nur "dir=/Users/j" und danach gar nichts mehr.
    Mit einem angeschlossenen Terminal-Programm kann ich den XS-1541-Prompt lesen (und bin etwas verwundert über die Ausgabe, die viel zu sehr an die alte XS-1541-Firmware erinnert...)

    Eine Idee, was ich machen könnte?
  • CBM 8296 mit Standard-BASIC 4.0

    XS-1541 REV. D mit 644p, low fuse 0xff, high fuse 0xd4, efuse 0xfc

    Firmware: Deine fw.hex aus dem git bzw. selbstgebaut mit AVR GCC 4.5.1 / avr-libc 1.8.0 aus dem CrossPack for AVR für Mac

    PC Server: läuft auf einem Mac mini, übersetzt mit GCC 4.2.1 (X-Code)
  • In der Tat nachdem ich heute viel getestet habe merke ich selbst, dass es wenn man das XS1541 einfach einschaltet nicht direkt geht :(
    Ich hatte immer nur RESET gedrueckt...

    Aber nach einem Druck auf den RESET button des XS1541 geht es bei mir!
    Das kommt dann mit dem - auch schon im README erwähnten - noch fehlenden RESET Command.

    Hier noch der Beispiel-Output bei mir - ich setze das auf setuid root und gebe nach Öffnen der seriellen Schnittstelle die Root-Rechte auf.
    Hast Du fsser als root gestartet?

    Quellcode

    1. fachat@linux-4k3b:~/8bitsvn/Projects/xs1541/xs1541/pcserver> make run
    2. ./fsser -d /dev/ttyUSB0 ../sample
    3. dir=../sample
    4. Real user ID=1000
    5. Effective user ID=0
    6. New effective user ID=1000
    7. <OPEN FILE: FOR CHAN:00 WITH NAME: $
    8. OPEN_DR()=0x804d008
    9. .
    10. ### XS-1541 v0.02.01 ###
    11. 1572 Bytes free, 14745 kHz
    12. <OPEN FILE: FOR CHAN:00 WITH NAME: $
    13. OPEN_DR()=0x804d008
    14. CONVERTED TO: LEN=22 01 04 01 01 00 00 20 12 22 2e 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 22 20 58 44 32 30 33 31 00
    Alles anzeigen


    Ach ja, offensichtlich muss ich die firmware Version noch ändern :)

    Aber dafür ist es ja eine BETA.

    Gruß,
    André
  • Auch das Drücke von RESET hat nichts gebracht. Ich habe das Makefile für meine Schnittstellenbezeichnung /dev/tty.usbserial-A9009SJS angepasst und dann erst als normaler Benutzer "make run", dann als root "make run" aufgerufen -- unverändert nüscht.

    Quellcode

    1. Nils-Eilerss-Mac-mini-2:pcserver j$ make run
    2. ./fsser -d /dev/tty.usbserial-A9009SJS ../sample
    3. dir=../sample
    4. ^Cmake: *** [run] Interrupt
    5. Nils-Eilerss-Mac-mini-2:pcserver j$ sudo su
    6. Password:
    7. sh-3.2# make run
    8. ./fsser -d /dev/tty.usbserial-A9009SJS ../sample
    9. dir=../sample
  • Hm, sorry, da kann ich im Moment nichts machen. Ich kann nur unter Linux testen. Der Code für die Initialisierung der seriellen Schnittstelle (ein notorischer Punkt unter Unix/-artigen) ist aus dem Netz.

    Ich habe den server jetzt unter einer etwas älteren SuSE Linux sowie unter (k)ubuntu 12.04 kompiliert und es lief.

    Vielleicht kann jemand anderes das mal unter MaxOS untersuchen.

    Gruß,
    André
  • Zu blöd, dass ich mir meine Linux-Box gerade zerschossen habe. Na, dann bin ich wohl erst mal mit Reparieren beschäftigt...

    Ich probier's dann unter Linux.

    edit:

    Linux-Box läuft wieder mit frischem Debian Squeeze und tadaaa: das XD2031 läuft auch! :)

    Der Wehmutstropfen: es kommt vereinzelt zu "device not present" Fehlern. Ist das bei Dir auch so? Das Directory mittels caT angezeigt kann man nun aber mit der Space-Taste verlangsamen, ohne dass es dadurch bedingt zu Abbrüchen kommt -- das ist schon mal ein riesen Schritt nach vorne.

    Habe mal Bilder von einem der Abbrüche beigefügt, vielleicht hilft es bei der Fehlersuche?

    Vielleicht ist das ATN-Acknowledge in Software einfach zu langsam? Wäre interessant, wie es sich mit Hardware-ATN-Acknowledge verhält, dazu könnte man noch ein LS86 und LS06 (wie bei der 2031) einflicken.
    Bilder
    • cbm.jpg

      249,09 kB, 1.513×3.268, 26 mal angesehen
    • pc.JPG

      246,31 kB, 4.320×2.432, 23 mal angesehen

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von for(;;) ()

  • BTW, "DIRECTORY" (oder "CATALOG", beides das gleiche) sind echte Resource-Hogs. Für jedes übertragene Byte wird ein TALK/SECTALK/DATA/UNTALK gemacht....
    Also viermal die Datenmenge, die nötig wäre...

    Auf der anderen Seite ein guter Protokolltest...
  • Ja, caT war durchaus als Protokolltest gedacht.

    Schlechte Nachrichten: wenn ich die Firmware selber baue, funktioniert caT gar nicht. Einfaches LOAD funktioniert dagegen.

    Meistens liefert es direkt "device not present" error, in sehr seltenen Fällen hängt es. Nach einem von caT verursachten "device not present" kommt es manchmal vor, dass auch ein schlichtes LOAD hängt.

    Ich habe die Firmware mit und ohne Debug-Ausgabe (981ff) getestet und sowohl unter der Linux-Kiste (gcc 4.3.5, avr-libc 1.6.8-2) gebaut, als auch auf dem Mac mit neueren Versionen (s.o.) -- das Verhalten ist bei allen Varianten das selbe.

    Was ist bei mir anders?

    edit:

    Ich glaube mittlerweile nicht mehr daran, das CBM IEEE-Busprotokoll stabil nur mit dem Software-ATN-Acknowledge erschlagen zu können. Wir hatten im Forum hier ja auch mal eine Diskussion darüber, ob das in Software schnell genug ist oder nicht. Die damalige Diskussion unterliegt nur leider einem Denkfehler, sie geht nämlich davon aus, dass beim Auftreten des ATN-Interrupts die selbigen auch frei gegeben sind. Das ist aber eben *nicht* immer der Fall, nämlich dann nicht, wenn schon ein anderer Interrupt (z.B. wegen der RS232-Kommunikation) abgearbeitet wird.

    Bei AVR sind verschachtelte Interrupts unter C auch eher die absolute Ausnahme, wenn auch prinzipiell möglich. Damit könnte z.B. der ATN-Interrupt behandelt werden, wenn gerade der RS232-Interrupt bearbeitet wird. Aber selbst dann hat man immer noch eine erhöhte Antwortzeit, da der derzeit bearbeitete Interrupt sich erst mal selbst ausknipsen muss, bevor er wieder neue (andere, sprich: ATN-)Interrupts zulässt.
    Ich könnte mir vorstellen, dass es so gerade eben klappen könnte, wenn man die ganze Interrupt-Bearbeitung nicht in C (wegen dem overhead) macht, sondern in Assembler -- allerdings macht man dann die nächste Dose Maden auf, die erst mal wieder eingesammelt werden möchte, nämlich ein gemischtes C/Assembler-Projekt.

    Deshalb würde ich auf Hardware-ATN-Acknowledge wechseln, wie das bei der 2031 gemacht wurde. Die verwendeten TTL-ICs sind allesamt nicht exotisch, vielleicht hast Du die ja noch bei Dir rumliegen.

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von for(;;) ()

  • hallo nils,

    würdes du mir ein petSD zum testen zusenden?
    oder dürfte ich es bei dir in leverkusen abholen,
    wenn ich joshy besuche?


    dann würde ich es erstmal hardwaremässig mit zwischenadapter am AVR
    und den IEC-leitungen ATN, NDAC, DAC und NRFD versuchen zu lösen.

    habe auch keinen lauffähigen cbm rechner.
    da würde mir aber toast_r sicherlich helfen.

    da gibt es aber auch einen, hier im forum, aus bergheim,
    kenne ihn von der doreco 12/2010. der auch einen cbm8032 hatt.
    name fällt mir gerade nicht ein.
    oder telespielator fragen, bin ja fast jede woche in bonn.

    gruß
    helmut
  • Wenn ich schlummernde petSD-Bestände hätte, sehr gerne. Aber ich habe nur behalten, was ich zum Entwickeln brauche und alles andere an Donald für seinen Shop abgegeben. Grüß Joshy von mir, wenn Du ihn siehst!

    Hast Du vielleicht eine Idee, ob und wie man die ATN-Acknowledge-Schaltung aus der CBM 2031, die ja insgesamt drei ICs (74LS86, 7406, 7414) verwendet vereinfachen könnte?
  • for(;;) schrieb:

    Hast Du vielleicht eine Idee, ob und wie man die ATN-Acknowledge-Schaltung aus der CBM 2031, die ja insgesamt drei ICs (74LS86, 7406, 7414) verwendet vereinfachen könnte?

    Ein 74LS136 (Quad-XOR mit Open-Collector-Ausgängen) würde exakt passen, bräuchte allerdings noch zwei Pullup-Widerstände.

    Quellcode

    1. 10 x=rnd(-1963):fori=1to81:y=rnd(1):next
    2. 20 forj=1to5:printchr$(rnd(1)*16+70);:next
    3. 30 printint(rnd(1)*328)-217

    sd2iec Homepage
  • Das wurde im Umbau 1541 -> 2031 verwendet, der vom 64'er Magazin veröffentlicht wurde und wäre quasi perfekt -- alles in einem IC erschlagen. Was mir allerdings Sorgen bereitet, ist sein IOL (low level output current) von gerade mal max. 16 mA vergleichen mit den stolzen 48 mA eines 7406 bzw. 75161. Der AVR des XS-1541 konnte IHMO 20 mA und da gab es schon mal Probleme bei mehreren Geräten.

    Oder auf Deutsch: funktioniert es noch, wenn (wie?) viele Geräte am IEEE-Bus angeschlossen sind?

    Hat jemand eine mit dem 64er Umbau zur 2031 umgebaute 1541 und kann berichten, ob/wann es Probleme gibt, wenn mehrere Geräte am IEEE-Bus hängen?

    Ich wüsste auch gerne, welcher IEEE-Interface-Chip bzw. welche Schaltung wie viele mA Buslast erzeugt, die ggfs. auf low gezogen werden sollen, aber da werde ich aus den Datenblättern der MC3446 bzw. SN75161 nicht richtig schlau.
  • for(;;) schrieb:

    Was mir allerdings Sorgen bereitet, ist sein IOL (low level output current) von gerade mal max. 16 mA vergleichen mit den stolzen 48 mA eines 7406 bzw. 75161. Der AVR des XS-1541 konnte IHMO 20 mA und da gab es schon mal Probleme bei mehreren Geräten.

    Ok, auf dieses Detail hatte ich nicht geachtet. Wie wäre es alternativ mit einem halb verwendeten 76LS86 und zwei Transistoren statt der beiden Inverter aus dem 7406? Die Schmitt-Trigger-Eigenschaft des 7414 sollte ja hinter dem Bustreiber-Baustein egal sein.

    Quellcode

    1. 10 x=rnd(-1963):fori=1to81:y=rnd(1):next
    2. 20 forj=1to5:printchr$(rnd(1)*16+70);:next
    3. 30 printint(rnd(1)*328)-217

    sd2iec Homepage
  • for(;;) schrieb:

    Was mir allerdings Sorgen bereitet, ist sein IOL (low level output current) von gerade mal max. 16 mA vergleichen mit den stolzen 48 mA eines 7406 bzw. 75161
    74ls136 sogar nur max. 8mA !!!

    aber was sehr schlimm ist, nur max. 5V am ausgang!
    das würde nicht lange gutgehen selbst mit nur einem gerät am iec-bus.

    7406 = max. 30V am ausgang
    7416 = max. 15V am ausgang

    selbst die stärkeren 7406 sterben oft am ser. iec bus vom C64
    nicht unbedingt an der belastung. die meisten haben ja nur max. eine
    floppy und einen drucker angeschlossen und trotzdem geht der 7406 kaput.

    vor ca. 30 jahren war der 7406 eine zeitlang sehr schlecht lieferbar
    und kostete mich bei abnahme von 100 stück bis zu 20 DM das stück!
    der normaler großhandel einkauf war unter 1 DM.

    da habe ich in der not, bei reparaturen, für meine guten kunden,
    damit diese nicht wochen warten müssen.
    (reparaturzeit bei commodore = monate, meine nur tage)
    einen der defekten treiber-inverter im 7406 durch einen mos-transistor ersetzt.
    dieser mos-transistor kostete ca. 2DM stück.

    den kunden wurde mitgeteilt das wen 7406 wieder lieferbar und nochmal defekt
    wird kostenlos original 7406 eingebaut.
    die reparierten, mit den mos-transistoren,
    habe ich mit einem defekt am 7406 nie wieder gesehen.

    in unserem test c64, waren auch die mos-transistoren,
    welcher zum testen von hunderten drucker interface benutzt wurde.
    an dem war die ser. buchse oft ausgeleiert und andere sachen defekt aber nie
    die mos-transistoren für den ser. iec-bus.

    welcher mos-transistor das dahmals war weis ich nicht mehr.

    aber seit ca. 20 jahren benutze ich den BS170 gerne.
    er kostet nur ca. 10 cent. treibt mit 500 (1200) mA 12 x mehr als ein 7406.
    sogar bis 60V und hat nur 10nS verzögerungszeit wie ein TTL IC.

    ich benutze ihn als inverter / treiber.

    und als ein nand-gatter mit einem invertierten eingang.
    z.b. als ersatzaufbau mit 2 gattern vom 7400.
    (pin 1+2 zusammen. pin 3 an pin 4. pin 5 ist der und-gatter eingang.
    der pin 1+2 ist der invertierte eingang und der pin 6 ist der ausgang)

    das gleiche aufgebaut mit nur einem BS170:
    der gate-pin ist der und-gatter eingang, der source-pin der invertierte eingang
    und der drain-pin ist der ausgang mit oder ohne widerstand für z.b. CS-leitungen usw.

    man braucht bei einem mos-transistor auch
    keinen basis (gate) widerstand. somit ideal als 1/6 7406 inverter ersatz.
    gate-pin ist der eingang, drain-pin der ausgang und source kommt an masse / gnd.
    alles ohne widerstände.

    Unseen schrieb:

    76LS86 und zwei Transistoren statt der beiden Inverter aus dem 7406
    74ls86 und zwei BS170 ;)

    for(;;) schrieb:

    Hast Du vielleicht eine Idee, ob und wie man die ATN-Acknowledge-Schaltung aus der CBM 2031, die ja insgesamt drei ICs (74LS86, 7406, 7414) verwendet vereinfachen könnte?
    sie benötigt nicht nur diese ICs ( oder 74ls86 und zwei BS170 )
    sondern viel schlimmer, eine freie portleitung an deinem AVR!
    für die zusätzliche ATN-A freigabe! (ATN-A PIN10 am 6522 in der 2031)

    habe in meinen alten schaltplänen bei den IEC-IEEE488 versionen,
    die ich noch finden konnte nachgesehen:

    1. IEC 1540/4031
    (war die erste version mit 4031 vor der 2031,
    toast_r hat eins der ersten von 1982 von mir umgebauten geräten ersteigert)

    2. 1540-IEC
    3. ultra electronic IEC 1541
    4. 2031/1540 I/O
    5. 1541 IEC+VC (für ser. und par. IEC)
    6. IEC1541
    7. IEC1541.1

    leider habe ich überal die ATN-schaltung aus der dahmaligen 4031 übernommen.
    welche auch in der späteren 2031 ist.

    deswegen wolte ich ein petSD zum testen. um möglichst eine schaltung
    herauszubekommen damit du nicht noch einen pin am avr opfern musst.
    oder dir zu helfen den fehler einzukreisen.

    habe auch schon darüber mit toast_r gesprochen und ihn gebeten
    etwas an der proxa7000 und IEC zu testen.