• Hallo zusammen,


    hat sich einer von euch schon mal Uno2IEC angeschaut? Ich hab mir gedacht, dass wär doch mal ne nette und einfache Möglichkeit seinem Commodore D64-Dateien anzubieten.
    Also Arduino Nano mit MABP6 verbunden, apt-get install arduino qt-creator (und vieles anderes mehr) und schon ist alles schön bunt, nur geht's nicht. Also ein bisschen mehr
    Ausgaben eingeschalten, einen Rechenfehler in mainwindow.cpp gefixt und ... geht immernoch nicht.
    Nach LOAD"$",8 kommt nur "?DEVICE NOT PRESENT ERROR".
    Es klang so schön, aber es ist nie so einfach.


    Also, hat das schonmal jemand versucht und evtl. sogar zum Laufen gebracht? Oder hat Tipps zum testen?


    Gruß Roman

    Das Genie beherrscht das Chaos

  • Wenn ich mich irre, ist das ein Floppy Emulator, habe das Teil aber selbst noch nie in Aktion gesehen.

    Viele Grüsse
    Roman
    --------------------------------------------------------------------------------------------------------------
    ...auch das Zukünftige wird ein Morgen haben, das es zum Gestrigen werden lässt...


    Viele Grüsse aus der Schweiz
    https://webnose64.ch

    • Offizieller Beitrag

    Habe kurz mal reingeschaut.
    Der Ansatz scheint auf den ersten Blick der gleiche zu sein wie bei der XD-2031 Firmware , die für für das XS-1541 und das petSD zu haben ist.
    Die Vorteile scheinen mir eher bei XD-2031 zu liegen:
    - Wird noch weiterentwickelt
    - Einfacher Kontakt zu den Entwicklern (Vereinsmitglieder fachat und for(;;))
    - Unterstützt neben dem seriellen IEC-Bus auch den paralellen IEEE-488 Bus


    Wenn die passende Hardware fehlt: Das XS-1541 ist sehr einfach aufgebaut und kann relativ leicht nachgebaut werden.


    Gruß
    Christian

  • 8o Wieso hab ich das noch nie vorher gefunden?


    Mit Benutzerhandbuch und ausführlicher Compile-Anleitung! :love: (In Latex :mrgreen: )
    Nur Eclipse ist nicht so mein Freund. Das mag mich einfach nicht ...
    Im XS-1541-Schaltplan sind die meisten Teile zusätzlich zum AVR nicht für die Kommunikation
    auf dem IEC, sondern zum Programmieren oder Anbinden an den PC. Wenn ich da einen
    Nano V3 verwenden möchte sehe ich eigentlich nur ein Problem in der Frequenz des Quartz.
    Der ist beim XS 14,... beim Nano 16MHz. Komm es da auch ein günstiges Teilungsverhältnis
    ans oder reicht es die Frequenz in der Firmware anzupassen?


    Gruß
    Roman

    Das Genie beherrscht das Chaos

  • Hallo Roman,


    an Eclipse soll es nicht scheitern: das kannst Du durch jeden anderen Editor Deiner Wahl ersetzen. Die Taktfrequenz der MCU ist auch eher nebensächlich, solange die MCU in der Lage ist, zuverlässig bei 115200 Baud Daten zu übertragen, wovon ich bei einem Arduino-Board einfach mal ausgehe. Aber leider hat der AVR des Nano V3 nur 2 KB RAM, was für XD-2031 in seiner derzeitigen Form zu wenig ist: 2471 Bytes plus ein paar mehr für den Stack werden momentan verlangt.


    Im Gegensatz zu uno2iec unterstützt XD-2031 neben dem Server (PC) auch direkt an die MCU angeschlossene Datenträger, sprich: SD-Karten. Damit nun Daten zwischen den beiden transferiert werden können, sind ein paar Puffer (sprich: RAM) auf dem Gerät notwendig. Man müsste die Software etwas skalierbarer machen (optional Einzelteile des Codes von der Firmware in den Server schieben), um am Ende auch Geräte wie das Nano V3 mit sehr wenig RAM und ohne direkt angebundene Massenspeicher zu unterstützen.


    Einfacher dürfte sein, ein größeres Board wie den Arduino Mega zu verwenden, oder sich ein XS-1541 auf einer Lochrasterplatine zurecht zu basteln. Oder etwas Geduld mitbringen und auf mein neues petSD warten :fp:


    Nils

  • Hallo Nils,


    ich würde es gern mit dem Nano probieren. Ich hab mal HAS_IEEE beim XS-1541 entfernt (Makefile) und noch im xs1541/ieeehw.[hc] ein #ifdef HAS_IEEE um alles gesetzt.
    Ersteres hat mich auf 1999 Bytes RAM gebracht, zweiteres nochmal 3 Bytes weniger.
    In cmd.c in der Funktion command_to_name werden Strings verwendet, die m.E. auch im RAM liegen. Die werden aber alle nur in Debug-Ausgaben verwendet, wenn ich das
    richtig sehe. Müsste dann nicht einfach ein return IN_ROM_STR("Foo"); an der Stelle auch funktionieren? Compilieren lässt es sich.
    Das würde ja schon mal "massig" RAM sparen. ;)


    Gruß Roman

    Das Genie beherrscht das Chaos

  • Freut mich, dass Du unerschrocken genug bist, damit herum zu basteln! :thumbup:
    Mit unter 2000 Bytes bist Du da auch auf einem guten Weg! Das könnte wirklich etwas werden, und das wäre wirklich super!


    Um Deine weiteren Fragen zu beantworten, sei mir erlaubt, erst etwas zur Architektur des verwendeten AVR-Controllers auszuholen:


    AVRs haben Harvard-Architektur der übelsten Sorte. Es gibt also nicht einen gemeinsamen Speicher (wie bei der von-Neumann-Architektur) für Daten (RAM) und Programm (Flash), sondern der ist strikt getrennt. Bei AVR sogar so sehr getrennt, dass RAM und Flash nicht einfach an verschiedenen Adressbereichen liegen, sondern die MCU mit verschiedenen Maschinenbefehlen darauf zugreifen muss. Um passenden Code erzeugen zu können, muss zur compile-time bekannt sein, ob ein Zeiger auf das RAM oder das Flash zeigt. Die Funktionen der Standardbibliothek erwarten ihre Parameter alle im RAM. Mit strcpy() könnte man z.B. keinen String aus dem Flash in das RAM kopieren. Dafür gibt es in der avr-libc Funktionen mit angehängtem _P bzw. _p, das wäre also hier z.B. strcpy_P(). Bei anderen Prozessoren, wie z.B. PIC18 von Microchip heissen diese Funktionen, die auf das Flash zugreifen können, aber wieder anders, weshalb wir das in XD-2031 abstrahiert haben. Aufgedröselt wird das über common/archcompat.h, da wird z.B. unser IN_ROM_STR(s) in das AVR-spezifische PSTR(s) gewandelt, wenn ein AVR verwendet wird.


    Die große String-Tabelle, die von command_to_name() verwendet wird, liegt schon im Flash, da kann man kein RAM mehr sparen. Siehe auch firmware/cmdnames.c. Der von command_to_name() gelieferte String liegt aber wie Du richtig erkannt hast, im RAM. Dazu gibt es in cmdnames einen Puffer von STRLEN (=10+1) Bytes RAM und command_to_name() holt den passenden Namen aus dem Flash und kopiert ihn in diesen Puffer im RAM, damit spätere Funktionen (wie z.B. strcpy) den String dort vorfinden, wo sie ihn erwarten: im RAM. Was man nun machen könnte, ist STRLEN zu reduzieren und dadurch auf die Unterstützung von langen Befehlsschreibweisen zu verzichten: bei einer echten Floppy löscht man Dateien üblicherweise mit dem S-Befehl. Man kann den Befehl aber auch ausschreiben und SCRATCH FOO sagen, so unterstützt das auch die XD-2031 firmware. Wenn Du STRLEN nun auf zwei reduzierst (z.B. für CD), könnte man damit immerhin 8 Bytes RAM sparen.


    Ein return IN_ROM_STR("foo") würde nicht funktionieren, da ein Zeiger auf RAM erwartet wird, IN_ROM_STR() aber auf etwas im Flash verweist. Das compiliert nur deshalb ohne Fehler, weil der Compiler nicht erkennen kann, was erforderlich ist und was geliefert wird. Einfach gesprochen sieht der nur Adressen, kann aber nicht wissen, ob diese Adresse z.B. 0x0834 nun im Flash oder im RAM liegt.


    Hast Du im xs1541-Makefile MCU angepasst? Müsste 328p für Dich sein.
    In der config.h musst Du noch F_CPU auf die verwendete Takt-Frequenz anpassen.
    In hwdefines.h musst Du dann noch die Port-Belegung entsprechend anpassen, falls nicht schon geschehen.

  • An bestehendem Code rumfrickeln, so dass es nachher trotzdem noch funktioniert, macht mir Spaß. Gut zu wissen ist auch immer,
    dass es schonmal funktioniert hat. ;)
    Das mit der Harvard-Architektur war mir klar. Ich hab schon ein bisschen mit ATtinys experimentiert. Wobei mir das mit Strings ausgeben
    immer etwas Kopfzerbrechen verursacht hat.
    Die Anpassungen an die Nano HW muss ich noch machen - danke für die Hinweise auf die richtigen Stellen.
    Aber das mit den Command-Strings aus dem Flash probier ich noch, das würde nochmal 64 Byte bringen (1996 -> 1932) und zu verschenken
    hab ich nix ;)

    Das Genie beherrscht das Chaos

  • Viel Erfolg!


    Prima wäre, wenn Du den Code auf github forken könntest und anschließend ein pull-request mit Deinen Änderungen machst. Das erleichtert uns das Nachvollziehen der tatsächlichen Änderungen und das Einbinden derselben sehr.

  • Sobald was läuft werde ich gern meine Änderungen zurückspielen.
    Noch habe ich aber ein paar Fragen:
    Wozu dient eigentlich IEC_SATN_INT? Das steht auf PCINT3 (PA3), habs aber nirgends im Code gefunden.
    command_to_name wird m.E. nur ein Debug-Ausgaben (debug_printf) verwendet. Du meintest, dass das für die
    ausgeschriebenen Befehle (z.B. SCRATCH) verwendet wird. Wo finde ich das?
    In den debug_printfs mit command_to_name wird mit . == CMD_NONE ? ... : command_to_name der Fall "-" abgefangen.
    Ist das nötig? Der ist doch im switch/case behandelt.
    Im Schaltplan ist IEC-Reset mit PD6 verbunden, im Code find das aber nicht. Stimmt das?


    Sorry für die vielen Fragen. Ich versuch es zu verstehen.


    Gruß Roman

    Das Genie beherrscht das Chaos

  • Wozu dient eigentlich IEC_SATN_INT? Das steht auf PCINT3 (PA3), habs aber nirgends im Code gefunden.

    Das ist obsolet, ich habe es zwischenzeitlich entfernt. Im Quelltext findet sich immer wieder mal auskommentierter Code, Andre scheint ganz gerne etwas für später aufzuheben, wohl um sich die Mühe zu ersparen, das wieder zu finden. Bei mir selbst bin ich natürlich blind in diesen Dingen ;)


    command_to_name wird m.E. nur ein Debug-Ausgaben (debug_printf) verwendet. Du meintest, dass das für die
    ausgeschriebenen Befehle (z.B. SCRATCH) verwendet wird. Wo finde ich das?

    Das ist ein Missverständnis. Nicht command_to_name() wird für die ausgeschriebenen Befehle benötigt, sondern das von command_to_name() verwendete Array cmd_tab[], zu finden in firmware/cmdnames.c ab Zeile 36. Wenn command_to_name() wirklich nur für Debug-Ausgaben verwendet wird, könnte man auf diesen Puffer im RAM natürlich gänzlich verzichten, wenn man sich z.B. eine Art debug_printf_p baut.


    In den debug_printfs mit command_to_name wird mit . == CMD_NONE ? ... : command_to_name der Fall "-" abgefangen.
    Ist das nötig? Der ist doch im switch/case behandelt.

    Das konnte ich nicht finden. Welche Zeile in welcher Datei meinst Du damit?


    Im Schaltplan ist IEC-Reset mit PD6 verbunden, im Code find das aber nicht. Stimmt das?

    Ja. Der Bus-Reset wird bislang von der Firmware gänzlich ignoriert. Schaden tut das aber nicht, da beim Reset automatisch alle Ports als Eingang verwendet werden. Schöner wäre natürlich, wenn das Gerät auch auf einen Bus-Reset reagieren würde. Ich habe #147 dafür angelegt: https://github.com/fachat/XD2031/issues/147


    Sorry für die vielen Fragen. Ich versuch es zu verstehen.

    Deine Fragen und Deine Mitarbeit sind sehr willkommen! Nur weiter so! :OK:


  • Zitat von »ChaosRom«
    In den debug_printfs mit command_to_name wird mit . == CMD_NONE ? ... : command_to_name der Fall "-" abgefangen.
    Ist das nötig? Der ist doch im switch/case behandelt.


    Das konnte ich nicht finden. Welche Zeile in welcher Datei meinst Du damit?


    IM ZIP-File XD2031-0.9.2.zip, Verz. XD2031-0.9.2/firmware


    cmd.c:149: debug_printf("CMD=%s\n", nameinfo.cmd == CMD_NONE ? "-" : command_to_name(nameinfo.cmd));
    name.c:252: debug_printf("CMD=%s\n", result->cmd == CMD_NONE ? "-" : command_to_name(result->cmd));

    Das Genie beherrscht das Chaos

  • OK, das Vorkommen in name.c habe ich gefunden und entfernt. In cmd.c wurde es offenbar schon entfernt.


    Kann es sein, dass Du an den über ein Jahr alten Quellen des letzten Releases arbeitest? Das solltest Du nicht tun, der Code ist hoffnungslos veraltet. Bitte hol Dir gegebenenfalls einen aktuellen snapshot als zip von github oder noch besser: klone direkt.


    Gehe dazu in ein Verzeichnis Deiner Wahl und gib am Terminal folgendes ein:


    Code
    git clone https://github.com/fachat/XD2031.git
  • So, ich hab aufgegeben :traurig:


    Aber 8-) atmega1284 ist bestellt!


    Im Ernst, bei dem runtergeladenen ZIP das als stable mit Version 0.9.2 "angepriesen" wurde (von Anfang 2013), sah ich ja
    noch eine Chance. Aber mit dem neuesten Stand aus github bin ich NACH entfernen der IEEE-Funktion immer noch bei
    150% bei Flash und RAM. Dann degradier ich jetzt halt den Nano zu einem ISP (spart Platz gegenüber dem STK500) und
    nehm doch den dicken, überdimensionierten 1284. Wahnsinn 16k RAM, wer braucht denn sowas ;)


    Wenn ich da weiter bin, meld ich mich wieder ...

    Das Genie beherrscht das Chaos