Hallo Besucher, der Thread wurde 6k mal aufgerufen und enthält 9 Antworten

letzter Beitrag von uwi_u am

Config-Editor?

  • Ich bin mit meiner WHDLoad-Installation auf HDF irgendwie unzufrieden und habe mir jetzt einen Schwung kleinerer SD-Karten besorgt, um von ADFs spielen zu können. Dabei hatte ich mir folgendes vorgestellt:


    Mehrere Spiele liegen als ADF auf der Karte, jedes Spiel bekommt eine eigene Config, die dann aus dem OSD ladbar ist.
    Im OSD kann man Configs laden, die da heißen "Default", 1, 2, 3, 4, usw.....
    Auf der Karte heißen die dann:


    Default -> minimig.cfg
    1 -> minimig1.cfg
    usw....


    Ist es möglich, bspw superfrog.cfg abzulegen oder wegen meiner auch minimigsuperfrog.cfg, damit diese im OSD als superfrog eingeblendet/ladbar ist?


    Desweiteren:
    Gibt es einen Config-Editor für Unix/Linux/Windows, damit ich mir die Configs nicht alle im Mist zusammenbauen muß?

  • Habe nun mal testen können. Klappt so erst mal nicht. Aber man könnte die config.c der Firmware anpassen. Was mich zum nächsten Problem bringt.
    Trotz Befolgen von https://github.com/mist-devel/…i/HowToCompileTheFirmware kriege ich die Firmware nicht kompiliert:
    -------------:~/mist/mist-firmware$ make
    /opt/arm-none-eabi/bin/arm-none-eabi-gcc -I. -Iusb -DMIST -MM cdc_control.c -MT cdc_control.d -MT cdc_control.o -MF cdc_control.d


    /opt/arm-none-eabi/bin/arm-none-eabi-gcc -I. -Iusb -DMIST -c -fno-common -O2 -fsigned-char -DVDATE=\"`date +"%y%m%d"`\" -o main.o -c main.c
    /opt/arm-none-eabi/bin/arm-none-eabi-gcc -nostartfiles -Wl,-Map,firmware.map -TAT91SAM7S256-ROM.ld -o firmware.elf crt.o Cstartup_SAM7.o fat.o fdd.o firmware.o fpga.o hardware.o spi.o hdd.o main.o menu.o mmc.o osd.o state.o syscalls.o user_io.o boot.o rafile.o idxfile.o config.o tos.o ikbd.o xmodem.o ini_parser.o mist_cfg.o archie.o usb/max3421e.o usb/usb.o usb/hub.o usb/hid.o usb/hidparser.o usb/timer.o usb/asix.o usb/pl2303.o usb/usbrtc.o usb/joymapping.o cdc_enumerate.o cdc_control.o
    /opt/arm-none-eabi/bin/arm-none-eabi-objcopy --output-target=ihex firmware.elf firmware.hex
    /opt/arm-none-eabi/bin/arm-none-eabi-objcopy: 'firmware.elf': No such file

    Makefile:62: recipe for target 'firmware.hex' failed
    make: *** [firmware.hex] Error 1
    -------------:~/mist/mist-firmware$


    Hat jemand ideen dazu?

  • Zitat von uwi_u


    /opt/arm-none-eabi/bin/arm-none-eabi-gcc -nostartfiles -Wl,-Map,firmware.map -TAT91SAM7S256-ROM.ld -o firmware.elf crt.o Cstartup_SAM7.o fat.o fdd.o firmware.o fpga.o hardware.o spi.o hdd.o main.o menu.o mmc.o osd.o state.o syscalls.o user_io.o boot.o rafile.o idxfile.o config.o tos.o ikbd.o xmodem.o ini_parser.o mist_cfg.o archie.o usb/max3421e.o usb/usb.o usb/hub.o usb/hid.o usb/hidparser.o usb/timer.o usb/asix.o usb/pl2303.o usb/usbrtc.o usb/joymapping.o cdc_enumerate.o cdc_control.o


    Dieses Kommando gibt keine Fehlermeldung. Demnach sollte es die Datei firmware.elf erzeugt haben. Ist sie da?


    Zitat von uwi_u


    /opt/arm-none-eabi/bin/arm-none-eabi-objcopy --output-target=ihex firmware.elf firmware.hex
    /opt/arm-none-eabi/bin/arm-none-eabi-objcopy: 'firmware.elf': No such file

    Makefile:62: recipe for target 'firmware.hex' failed
    make: *** [firmware.hex] Error 1


    Und diesem Kommando fehlt aber nun die Datei firmware.elf. Sehr merkwürdig. Eines der beiden Kommandos tut nicht was es soll ...

  • Vergesst, was ich geschrieben habe. Das Makefile funktioniert einwandfrei. Nur in meiner Virtuellen Maschine nicht. Habe Script und Make mal in einer nativen Linux-Maschine durchlaufen lassen und bekomme eine fertige Firmware.... dann kann ich ja jetzt mit dem Proggen anfangen ;)

  • Zitat von uwi_u

    Vergesst, was ich geschrieben habe. Das Makefile funktioniert einwandfrei. Nur in meiner Virtuellen Maschine nicht. Habe Script und Make mal in einer nativen Linux-Maschine durchlaufen lassen und bekomme eine fertige Firmware.... dann kann ich ja jetzt mit dem Proggen anfangen ;)



    Dann mal los und zauber für uns eine neue Firmware mit interessanten Zusatzfunktionen! :)

  • naja.... zaubern ist relativ.
    Was ich gerne wollen würde:


    Configs unter einem beliebigen Namen auf der Karte ablegen und laden können. Darin würde ich auch gerne speichern, welche ADF aus dem Filesystem geladen werden soll. Im struct configTYPE wird allerdings leider momentan nur ein


    typedef struct
    {
    unsigned char speed;
    unsigned char drives;
    } floppyTYPE;


    genutzt, dieses inkludiert nicht den Pfad des ADFs. Hier muß ich folglich ein wenig frickeln, bin gespannt, ob ich das mit meinen ingestaubten C-Kenntnissen hinbekomme. Nächster Schritt wäre dann das Einbinden eines XBox-Controllers (hatte ich woanders schon geschrieben) und was auch Cool wäre, wären Eingabe-Profile, die man sich in der mist.ini konfigurieren und im Betrieb über's OSD laden kann.
    Beispiel: In einem Spiel sind bestimmte Passagen mit USB-Gamepad einfacher als mit einem Joystick, ab einer bestimmten Stelle möchte man aber den 9-Pin-Joystick nutzen. Da gibt es m.W. momentan noch keine Lösung für, oder?
    Oder bspw. ein anderes Keymapping für das selbe Gamepad laden, ohne einen Reset durchzuführen.
    Aber das ist alles noch Zukunftsmusik ;)

  • Hm.... konzeptionell hängt es bei mir. Wie wähle ich denn einen "Floppy-Slot" (1-4) aus?


    Momentan bin ich soweit, daß ich in der Config.h ein weiteres Struct verschachtelt habe:



    Damit ist das floppyTYPE mit maximal 4 Floppys ausgerüstet....
    In der config.c werden dann in der Funktion ApplyConfiguration() nach dem Konfigurieren des Floppyspeeds und der Anzahl(!) der Floppy-Drives in Zeile 389 [ ConfigFloppy(config.floppy.drives, config.floppy.speed); ]
    die ADFs geladen:

    Code
    1. for (i=0; i<(config.floppy.drives-1); i++) {
    2. InsertFloppy(config.floppy.fdd[i].floppyconf);
    3. }


    Nur: Wohin? Die Funktion InsertFloppy(adfTYPE *drive); nimmt einen Pointer auf ein adfTYPE entgegen, aber m.E. steht in diesem struct nicht drin, um welches Laufwerk (fd0, fd1, fd2 oder fd3) es sich handelt:


    typedef struct
    {
    unsigned char status; /*status of floppy*/
    unsigned char tracks; /*number of tracks*/
    unsigned long cache[MAX_TRACKS]; /*cluster cache*/
    unsigned long cluster_offset; /*cluster offset to handle tricky loaders*/
    unsigned char sector_offset; /*sector offset to handle tricky loaders*/
    unsigned char track; /*current track*/
    unsigned char track_prev; /*previous track*/
    char name[22]; /*floppy name*/
    } adfTYPE;



    Oder ist das adfTYPE garnicht das geladene ADF, sondern das eigentliche Laufwerk, welches in der menu.c nur mit einem Filename gefüttert wird?