Beiträge von fachat

    Die Meldung über die xdconfig kannst Du ignorieren.


    Bei mir funktioniert es auf jeden Fall. Was genau passiert bei Dir? Was ist dass für eine Windows Fehlermeldung?


    Kannst Du einfach mal

    xdserver -v -d COM3

    Bzw mit Deiner COM Schnittstelle aufrufen aus einer cmd.exe? Bei verbundenem nano488 sollte eine Meldung des Devices auftauchen.


    Alles andere kommt danach.


    Also, bitte nicht so kurz vor der Zielgeraden aufgeben.


    Die xdserver.exe die einfach so unter Windows läuft ist ja das Ziel, sonst bräuchte man diesen ganze Aufwand ja gar nicht und könnte einfach mit cygwin arbeiten


    Dein Screenshot zeigt mir eine Fehlermeldung. Ich habe das mal gefixt und unnötige Referenzen die bei Dir nicht aufgelöst werden können entfernt.


    Bitte im XD2031 Verzeichnis mal ein "git pull" machen. Dann im pcserver Unterverzeichnis ein "make -f Makefile.win". Dann sollte da eine xdserver.exe rauskommen.

    Ich habe mal einen neuen Branch angelegt, in dem ich meine Windows patches gesammelt habe. Der Server ist halt ziemlich beschränkt - keine Netzwerkfunktionen, und auch keine lokalen Commands. Aber bei mir verbindet er sich jetzt ohne Probleme mit dem Nano488, auch aus der reinen Windows cmd.exe.


    Könnt ihr das mal probieren?


    Source ist hier:
    https://github.com/fachat/XD2031/tree/win


    Anleitung ist hier:

    XD2031/README.win at win · fachat/XD2031
    A filesystem server for Commodore 8-bit computers. Contribute to fachat/XD2031 development by creating an account on GitHub.
    github.com


    Ich habe die Installationskommandos aus der shell-Historie gezogen. Daher kann es Lücken geben, bei einigen bin ich mir auch nicht sicher ob sie nötig sind. Wenn Ihr merkt das was fehlt gebt bitte Bescheid.

    Also, wenn ich mir "msys2" installiere als Cross-compile-Umgebung unter Windows (siehe https://www.msys2.org/ ), und dann mit


    pacman -Syuu

    pacman -S base-devel make gcc curl

    pacman -S mingw-w64-x86_64-curl

    pacman -S mingw-w64-x86_64-toolchain

    pacman -S msys/libcurl-devel


    das system update, und div. tools installiere (wobei ich jetzt nicht mehr sagen kann was nur in der historie steht und was _wirklich_ nötig ist), dann kompiliert der server zu einem xdserver.exe


    Vielleicht kann das ja mal jemand nachvollziehen.

    Also damit als Makefile versucht mingw das zumindest zu kompilieren:


    ---

    CC=gcc


    OBJFILES= cerrno.o channel.o cmd.o cmdline.o dir.o drives.o handler.o in_device.o in_ui.o openpars.o provider.o resolver.o xcmd.o xdserver.o handler/curl_provider.o handler/di_provider.o handler/diskimgs.o handler/fs_provider.o handler/tcp_provider.o handler/typed_handl

    er.o handler/x00_handler.o os/os.o os/privs.o os/serial.o os/terminal.o posix/loop.o posix/socket.o util/array_list.o util/hashmap.o util/log.o util/mem.o util/registry.o ../common/charconvert.o ../common/cmdnames.o ../common/errnames.o ../common/filetypes.o ../common/n

    ame.o ../common/wildcard.o


    %.o: %.c

    gcc -g -W -Wall -pedantic -ansi -std=c11 -funsigned-char -I. -I../common -Ihandler -Ios -Iposix -Iutil -DSERVER -D_POSIX_C_SOURCE=200809 -c $< -o $@



    xdserver: ${OBJFILES}

    gcc ${OBJFILES} -o xdserver -lncurses -lcurl -lc

    ----


    Aber dann findet er curl nicht:


    Also, mingw64 installiert unter Windows. SIeht so aus als müsste ich das komplette Makefile neu schreiben. Vielleicht mag sich jemand dran versuchen, ich schaffe das nicht auf die Schnelle. Eigentlich muss man nur alle *.c files wie hier aus einer zufälligen Zeile compilieren. und dann linken (Ausgabe unter Linux mit "V=1 make"). Die Makefiles einfacher zu machen steht auch auf der Liste, bin ich aber auch noch nicht dazu gekommen...


    gcc -g -W -Wall -pedantic -ansi -std=c11 -funsigned-char -I. -I../common -Ihandler -Ios -Iposix -Iutil -DSERVER -D_POSIX_C_SOURCE=200809 -MMD -MP -MF obj/posix/.dep/tcp_provider.o.d -c handler/tcp_provider.c -o obj/posix/tcp_provider.o




    Unter Linux auch mal versucht, mxe zu installieren (siehe das doc/README.win in XD2031) - aber das schlägt beim Download der mingwrt (runtime?) fehl. Damit wäre ein cross-compile wohl möglich.


    Mehr werde ich dieses WE nicht mehr schaffen.


    Edit:

    gcc -g -W -Wall -pedantic -ansi -std=c11 -funsigned-char -I. -I../common -Ihandler -Ios -Iposix -Iutil -DSERVER -D_POSIX_C_SOURCE=200809 -c handler/tcp_provider.c -o obj/posix/tcp_provider.o

    sollte auch gehen (dann ohne dependency generation)

    Das scheint ein normaler Arduino nano zu sein. Der nano every hat einen Atmega m4809 drauf.


    Welche firmware hast Du denn draufgemacht? Die muss

    a) relativ aktuell sein (d.h. auch für genau dieses Device)

    b) es könnte sein dass die Firmware zu groß ist und ggf. den loader zerschossen hat. Deshalb habe ich immer den Programmer dafür. Der 328p ist nunmal echt ziemlich klein, da geht auch nicht alles in der Firmware deswegen (keine block-Zugriff, keine REL-files IIRC)


    Wenn mir jemand sagt wie ich die *.elf/*,hex files konvertieren muss, damit Du sie programmieren kannst mache ich das gern.


    Edit: hab die aktuelle firmware mal angehängt xd2031-2023-02-25-nano488-m328p.zip

    Ooh jeh, sorry für's späte Reinschauen. Bin gerade beruflich ziemlich ausgelastet.


    Zum ersten passen alte Firmware und neue Serverware nicht zusammen. Da hat es ein paar Updates im Protokoll gegeben.


    Hast Du einen Nano oder einen Nano Every? Zu ersterem braucht's m.E. den Programmer dazu, der Nano Every geht über die USB-Schnittstelle direkt zu programmieren.


    Gebaut wird die firmware mit "DEVICE=nano488 make" resp. "DEVICE=nano488e make", sie liegt dann unter "xd2031-firmware-<datum>/*nano488*/ als *.elf bzw. *.hex Datei.


    Im firmware-Verzeichnis, müsste man eigentlich einfach nur "DEVICE=nano488 make flash" bzw. "DEVICE=nano488e make flash" machen, dann wird der programmiert. Wie gesagt, mit Programmer für den nano, bzw. über USB für den nano every.

    Das ganze halt unter Linux ohne iDE.


    Wenn es mit Windows zu programmieren gehen soll ... da kenne ich mich überhaupt nicht aus.

    Da brauche ich meine Seite ja gar nicht selbst zu verlinken :)


    R6545 scheint in der Tat der am weitesten fortgeschrittene zu sein. Er erlaubt, soweit ich es mir wieder in Erinnerung hole, den indirekten Zugriff auf den Bildschirmspeicher - also so wie im C128. Die Register sehen auch sehr ähnlich aus, ich denke da hat einer vom anderen abgeschaut.


    Die Motorola chips haben aber zB das Feature, Display enable DE und Cursor enable CE um einen oder gar zwei Clock Cycles zu verzögern was der Rockwell nicht kann.


    Bzgl CPLD, ich habe eine abgespeckte Variante bereits in meinem MicroPET drin. In der Version Video4032.vhd etwas mehr Feature und kompatibler - dann aber nicht so flexibel wie ich es für den MicroPET gerne hätte...