PS2 FORTUNA Homebrew Launcher by VTSTech (BOOT.ELF replacement) v0.46

Allows you to choose what Homebrew Application (ELF) you want to load when you run Fortuna Project

  1. 1,626
    1,286
    347
    jolek

    jolek Senior Member

    Joined:
    Dec 29, 2017
    Messages:
    1,626
    Likes Received:
    1,286
    Trophy Points:
    347
    Gender:
    Male
    What do you think about change /\ into "Triangle" or
    SQU into "Square"?

    I mean at first I was thinking that this is upper d-pad button ( :dir up: ).
    SQU theoretically means Square, but if for some reason you'll give a full name for Triangle
    why not do the same thing for Square?


    What about use only "Run wLaunchELF", "Run Open PS2 Loader"...
    Most of apps OPL, wLe, PS2Ident have its versions at about page or it is showing at boot of it.
    I'm not sure however how it works (version info) for RetroArch...

    Not everybody will use ESR r9b, it could be also ESR GUI, as for Open PS2 Loader you can use Ifcaro or DB,
    SNES-Station it can be 0.2.4S SP193 fork or pinguinoctis MOD (0.2.6c)...

    I was also thinking about wLe, to run it from "mc?:/BOOT/BOOT.ELF".
    At least it is original path when you have FMCB on MC.
     
    VTSTech and TnA like this.
  2. 330
    416
    97
    VTSTech

    VTSTech Developer

    Joined:
    Apr 8, 2019
    Messages:
    330
    Likes Received:
    416
    Trophy Points:
    97
    Gender:
    Male
    Home Page:
    I could generalize the descriptions/versions a bit more. Those are just the versions I use.

    I imagine most people using FORTUNA are those that cannot use FMCB.

    If they want to use ESR GUI instead of ESR ... they can just name ESR GUI ... ESR.ELF ?

    That's all the lines I've got. Screen is pretty much full at this point.

    If I strip out versions and keep the descriptions really general, I could likely make it a two column menu with more options .. depending how many buttons we got left.
     
    Algol likes this.
  3. 1,626
    1,286
    347
    jolek

    jolek Senior Member

    Joined:
    Dec 29, 2017
    Messages:
    1,626
    Likes Received:
    1,286
    Trophy Points:
    347
    Gender:
    Male
    Yuup. The same thing can be done for other apps.
    It just that currently at least OPL is still in development, today you have 1406, tomorrow 1408,
    updating strings for that in your launcher can become pain in the a**.
    Probably also new version will need to released to keep it with this.
     
  4. 773
    1,392
    222
    sp193

    sp193 Developer

    Joined:
    Oct 13, 2014
    Messages:
    773
    Likes Received:
    1,392
    Trophy Points:
    222
    Location:
    Singapore
    Home Page:
    That's very old.

    IOP reboots are only like this. After which, you can load your required modules and so on. In the homebrew world, we have this problem with whose responsibility it is, to reboot the IOP. But I think it's better for all software to reboot the IOP themselves, due to the possibility that the user may copy the file to different devices and boot them with different software.
    Code:
    SifInitRpc(0);
    while(!SifIopReset("", 0)){};
    while(!SifIopSync()){};
    
    SifInitRpc(0);
    ...
    
    
    Some old homebrew software have lots of hackery involved here, for some reason. There's no need to flush the EE caches either.

    Please don't reboot with EELOADCNF. It's not present in all ROMs and some of them even cause unusual modules to load - like in the case of the SCPH-70000, NCDVDMAN gets loaded, which prevents sceCdRI() from working. In turn, HDD.IRX could not complete the unlock step and the uLaunchELF developers through that it was a hardware limitation of the SCPH-70000...

    It's unfortunate, but only the Sony documentation can clearly explain what you need to do with the kernel functions. Our homebrew SDK is largely based on the original code from Sony.

    If I remember right, the first SifInitRpc() call is required to give the IOP side the new receive address, particularly if the IOP-side SIFRPC implementation was already initialized. Sony recommended SifInitCmd(), but it doesn't seem to work that way here - it may be due to differences in library versions.

    Back to the question about whose responsibility it is to reboot the IOP - we do have software that:
    1. Expect the IOP to be already rebooted and contains the necessary modules to access the device.
    2. Do not require the IOP to be rebooted.

    The former causes problems when we involve different IOP module versions. This problem gets worse when we involve the HDD unit, since we usually involve the homebrew iomanX module and so on.
    So to enhance compatibility, FMCB doesn't reboot the IOP before booting any software. It only does so, when the software is booted from the HDD unit. FMCB also involves the basic modules from ROM, which includes SIO2MAN, MCMAN, PADMAN etc.

    For a similar reason, LaunchELF cannot have its SIO2MAN upgraded. Doing so, would break compatibility with some homebrew software. I really doubt you can maintain 100% compatibility, so you need to choose your methodology.

    The EE kernel's EELOAD module loads at 0x00082000. If you are using a late PS2SDK revision and use its libkernel, please use 0x00084000 instead. This is the same address that the EELOAD module from the HDD Browser loads at. This change came about because of the alarm function patch that Sony added, which is installed to 0x00082000.

    If you use our libkernel-nopatch instead of libkernel, then no runtime kernel patches will be installed. The advantage is that you get less bloat, but you need to be careful with using the bugged syscalls:
    SyscallDescription
    ExecPS2Unpatched SCPH-10000 & SCPH-15000 version only executes the target - without any form of cleanup. Similar to the TLB function patch, this stays resident.
    iWakeupThreadUnable to increase WakeUp Count (WUC) for the running thread.
    iRotateThreadReadyQueueDoes not change the running thread ID.
    iSuspendThreadDoes not change the running thread ID.
    ReleaseAlarmUnable to release the correct alarm.
    SetAlarmThe default alarm implementation lacks code for preventing the EE COP0 EIE bit from becoming 0, due to the DI instruction not being atomic.
    FMCB's main ELF is built with the normal libkernel, which takes care of ExecPS2(). The ELF loader itself is linked to libkernel-nopatch.

    I do remember something about this, but somehow I cannot seem to find any post from myself about the delete-protection bit. Sony did not document this and neither can I remember where I might have even tried this out...
    However, the OSDSYS has "This data cannot be deleted", along with "This data cannot be copied". Even the first version of it.

    Either way, these bits are only meaningful to the browser.

    @krHACKen, do you remember which was the delete-protection bit?

    The crosslinking of file clusters was done in the case of the "multi-installation" mode, since the memory card filesystem does not support symlinks.
    I kept the multi-installation mode because I know that some people want to save every KB of space on their memory cards.

    This is a lengthy topic, so I wrote an explanation here: https://www.psx-place.com/threads/fmcb-fhdb-v1-9-series-release-thread.13413/page-13#post-217725

    The use of sub-directories doesn't directly cause that.
    Sony placed some documented restrictions on saves - like no sub-directories are supported and there is a maximum filename length. However, these are likely only restrictions for the browser. I guess - they wrote that subdirectories are not allowed because the user cannot manage them.

    To get "corrupted data", the icon files must not be in order.

    The "launcher" is the very essence of FMCB itself. The only problem with the new consoles is that they just stop locating the memory card-based updates.

    Like you have suggested, the "Fortuna" exploit could boot FMCB. Since FMCB itself is already a properly-installed KELF, it can be booted without much extra code (once the path has been identified):
    Code:
    char *args[3];
    args[0] = "-m rom0:SIO2MAN";
    args[1] = "-m rom0:MCMAN";
    args[2] = "-x mc0:/BIEXEC-SYSTEM/osdmain.elf";
    LoadExecPS2("moduleload", 3, args);
    
    The boot ROM's ROMVER string can be used to determine the path.

    It is also possible for it to install a patch into kernel memory, much like the argument-passing patch that is installed by replacement EELOAD modules, for the SCPH-10000. The patch could check for the presence of the update and boot it directly, or patch the OSDSYS to do that. The former is simpler.
     
    Last edited: Dec 7, 2019
    reyzafany, akuhak, VTSTech and 6 others like this.
  5. 83
    235
    57
    krHACKen

    krHACKen Developer

    Joined:
    Nov 2, 2014
    Messages:
    83
    Likes Received:
    235
    Trophy Points:
    57
    I found some draft code in some project workdir. Don't know if this actually works :
    Code:
    /* Save to be protected/unprotected */
    char target_save[] = "mc0:/BEEXEC-SYSTEM/";
    
    /* 0x0000002D == Deleting Prohibited || 0x00000027 == None */
    int my_flag = 0x0000002D;
    
    
    int main()
    {
       fio_stat_t fio_stat;
    
       if(0 > fioGetstat(target_save, &fio_stat)) goto exit;
    
       fio_stat.mode = my_flag;
       fioChstat(target_save, &fio_stat, FIO_CST_MODE);
    
    exit:
       __asm__ __volatile__(
         "   li $3, 0x04;"
         "   syscall;"
         "   nop;"
       );
    
       return 1;
    }
    
     
    akuhak, Algol, svotib and 1 other person like this.
  6. 330
    416
    97
    VTSTech

    VTSTech Developer

    Joined:
    Apr 8, 2019
    Messages:
    330
    Likes Received:
    416
    Trophy Points:
    97
    Gender:
    Male
    Home Page:
    for some reason using wipeUserMem(); causes EE IOP Reboot loop (at least in PCSX2)

    Code:
    // Clear user memory
    // PS2Link (C) 2003 Tord Lindstrom ([email protected])
    //  (C) 2003 adresd ([email protected])
    //--------------------------------------------------------------
    static void wipeUserMem(void)
    {
       int i;
       for (i = 0x100000; i < GetMemorySize(); i += 64) {
         asm volatile(
          "\tsq $0, 0(%0) \n"
          "\tsq $0, 16(%0) \n"
          "\tsq $0, 32(%0) \n"
          "\tsq $0, 48(%0) \n" ::"r"(i));
       }
    }
    This is what ResetIOP(); will look like in 0.42

    Code:
    //thx sp193
    void ResetIOP()
    {
       SifInitRpc(0);
       while(!SifIopReset("", 0)){};
       while(!SifIopSync()){};
       SifInitRpc(0);
    }
    also commented those FlushCache()'s - didn't appear to break anything.

    I did try to port over using the embedded loader.elf from wLaunchElf. Got the loader.elf to compile, got it to compile as an object in FORTUNA Launcher, ultimately kept getting stopped by a compile error on FILEINFO, when taking required functions/defs from wLE
     
  7. 330
    416
    97
    VTSTech

    VTSTech Developer

    Joined:
    Apr 8, 2019
    Messages:
    330
    Likes Received:
    416
    Trophy Points:
    97
    Gender:
    Male
    Home Page:
    Right now I've only got my personal FMCB MC and a blank MC that I'm using to test FORTUNA stuff (and a chinese 64MB that i use for saves that i won't use for either of these). I'll be getting more MC in the next few days...

    I'll see about launching my FMCB osdmain.elf from mc1 and if that works I can make it an option for mc0

    UPDATE. Well this is a tough one to debug ... It does boot FMCB on mc1 -- But I'm not sure if that is because of a crash and it just reboots and launches FMCB as it would if any FMCB card is present or if it is because I'm attempting to call it...

    [​IMG]

    Would need someone to test v0.43 on a non-FMCB compatible system with the KELF installed to BAEXEC-SYSTEM (mc1) to see if it is truly launching osdmain.elf
     
    Last edited: Dec 9, 2019
    jolek likes this.
  8. 773
    1,392
    222
    sp193

    sp193 Developer

    Joined:
    Oct 13, 2014
    Messages:
    773
    Likes Received:
    1,392
    Trophy Points:
    222
    Location:
    Singapore
    Home Page:
    Why not programmatically test for the existence of FMCB?

    If your software really crashed, I doubt it will continue running. What made you think it crashed?
     
  9. 330
    416
    97
    VTSTech

    VTSTech Developer

    Joined:
    Apr 8, 2019
    Messages:
    330
    Likes Received:
    416
    Trophy Points:
    97
    Gender:
    Male
    Home Page:
    Well, If it crashed and rebooted. It would then launch FMCB ... with FMCB plugged in right ?

    Thou ... I don't think I've ever had a "crash/reboot" before. Black screen hangs. Weird colors. But i don't think it's ever rebooted. So perhaps it really is launching FMCB at the moment.

    I was pulling the EXEC dir earlier using OSDGetSystemExecFolder() in my Component Test homebrew - I just hard coded it for the moment. Pretty sure I just need to include OSDInit.h to use that one...
     
    Algol likes this.
  10. 330
    416
    97
    VTSTech

    VTSTech Developer

    Joined:
    Apr 8, 2019
    Messages:
    330
    Likes Received:
    416
    Trophy Points:
    97
    Gender:
    Male
    Home Page:
    So this is what current v0.43 build does for me.

    FORTUNA non FMCB card in mc0, Freshly created FMCB in mc1

    At first menu. Hit SELECT and launch osdmain.elf from FMCB, No FMCB logo and I get a modded menu. (FMCB does actually exist here)

    If I hit START to launch osdmain.elf from mc0 on FORTUNA card (this does not exist). I get FMCB logo like the system just rebooted (because FMCB card is still present...)
     
    Algol and jolek like this.
  11. 773
    1,392
    222
    sp193

    sp193 Developer

    Joined:
    Oct 13, 2014
    Messages:
    773
    Likes Received:
    1,392
    Trophy Points:
    222
    Location:
    Singapore
    Home Page:
    If you used LoadExecPS2(): EELOAD will fall back to OSDSYS if the target file does not exist. OSDSYS will be booted with no arguments, which causes it to run the full boot sequence. If you are not using a late PS2, then OSDSYS would locate and boot an update, like FMCB.
     
    VTSTech and Algol like this.
  12. 330
    416
    97
    VTSTech

    VTSTech Developer

    Joined:
    Apr 8, 2019
    Messages:
    330
    Likes Received:
    416
    Trophy Points:
    97
    Gender:
    Male
    Home Page:
    Ah, So it's not a crash, but it's an intended fallback.
     
  13. 330
    416
    97
    VTSTech

    VTSTech Developer

    Joined:
    Apr 8, 2019
    Messages:
    330
    Likes Received:
    416
    Trophy Points:
    97
    Gender:
    Male
    Home Page:
    Added Credits:

    pad.c/h from wLaunchElf 8d4a0c2 by AKuHAK and SP193
    libcdvd_add.c/h & OSDInit.c/h from PS2Ident v0.835 by l_Oliveira and SP193
    FORTUNA Project by krat0s (not included, icon.icn & icon.sys)
    Compiled with current PS2SDK as of Nov 2019
    Packed with PS2-Packer v1.1.0 by Nicolas "Pixel" Noble
     
    Last edited: Dec 13, 2019
  14. 330
    416
    97
    VTSTech

    VTSTech Developer

    Joined:
    Apr 8, 2019
    Messages:
    330
    Likes Received:
    416
    Trophy Points:
    97
    Gender:
    Male
    Home Page:
    [​IMG]

    v0.44
    Added support for HDLoader
    Added support for user specific CUSTOM1/2.ELF
    Removed a few 1s delays
    Code optimizations
     
    jolek, Algol and svotib like this.
  15. 330
    416
    97
    VTSTech

    VTSTech Developer

    Joined:
    Apr 8, 2019
    Messages:
    330
    Likes Received:
    416
    Trophy Points:
    97
    Gender:
    Male
    Home Page:
    [​IMG]

    New Install instructions:

    Rename FORTUNA_Launcher.elf (or BOOT-packed.ELF) to BOOT.ELF and copy BOOT.ELF, usbd.irx & usbhdfsd.irx to your mc0:/FORTUNA/ folder

    v0.45
    Now loading, referencing and including:

    /ps2dev/ps2sdk/iop/irx/usbd.irx
    /ps2dev/ps2sdk/iop/irx/usbhdfsd.irx

    Fixes red screen when using USB.

    Must be in mc0:/FORTUNA/ for now
     
    jolek and Algol like this.
  16. 773
    1,392
    222
    sp193

    sp193 Developer

    Joined:
    Oct 13, 2014
    Messages:
    773
    Likes Received:
    1,392
    Trophy Points:
    222
    Location:
    Singapore
    Home Page:

    This is a bit tricky because of the number of people who worked on LaunchELF. But I'm sure you should not be crediting me since I didn't write that file.
    If the file was always there and mostly in that form, then perhaps it was added by the uLaunchELF developers (dlanor, E P et al). Or perhaps it was even there since the LaunchELF days (Mirikichi et al). Perhaps it'll be easier to credit the (u)LaunchELF developers instead.

    If you got OSDInit.c from my OSD Initilization package, that doesn't belong to PS2Ident.

    If you don't already know about it, we now have a v1.1.1 if you consider the last update I made, which was an attempt to fix the rare problem with bad files being made. The last hypothesis was that the magic word near the entry point was triggering a hardware restriction, which caused the EE to delete/incorrectly fetch data.
     
    VTSTech likes this.
  17. 330
    416
    97
    VTSTech

    VTSTech Developer

    Joined:
    Apr 8, 2019
    Messages:
    330
    Likes Received:
    416
    Trophy Points:
    97
    Gender:
    Male
    Home Page:
    I figured as the current maintainers of wLE that you guys were the most recent to have touched the pad.c/h file ... I added a bit about wLaunchELF using uLaunchELF code which itself uses LaunchELF code ... I don't know I'm going to be able to *really* determine who wrote what exactly...

    That's definitely where I got OSDInit.c/h from ... From [181208]PS2Ident.7z specifically. It is not your file ?

    [​IMG]

    Upon further analysis, I did comment one line of the file. That is only difference from the one in PS2Ident-src, Line 32 of OSDInit.c - I comment to remove this conflct with stdio.h

    Code:
    [email protected]:~/ps2homebrew/FORTUNA_Launcher$ make
    ee-gcc -D_EE -O2 -G0 -Wall  -I/usr/local/ps2dev/ps2sdk/ee/include -I/usr/local/ps2dev/ps2sdk/common/include -I.  -c FORTUNA_Launcher.c -o FORTUNA_Launcher.o
    ee-gcc -D_EE -O2 -G0 -Wall  -I/usr/local/ps2dev/ps2sdk/ee/include -I/usr/local/ps2dev/ps2sdk/common/include -I.  -c pad.c -o pad.o
    ee-gcc -D_EE -O2 -G0 -Wall  -I/usr/local/ps2dev/ps2sdk/ee/include -I/usr/local/ps2dev/ps2sdk/common/include -I.  -c OSDInit.c -o OSDInit.o
    OSDInit.c:32: conflicting types for `_ps2sdk_open'
    /usr/local/ps2dev/ps2sdk/ee/include/stdio.h:197: previous declaration of `_ps2sdk_open'
    ..
    make: *** [OSDInit.o] Error 1
    After commenting, it does compile, but with warnings

    Code:
    [email protected]:~/ps2homebrew/FORTUNA_Launcher$ make
    ee-gcc -D_EE -O2 -G0 -Wall  -I/usr/local/ps2dev/ps2sdk/ee/include -I/usr/local/ps2dev/ps2sdk/common/include -I.  -c OSDInit.c -o OSDInit.o
    OSDInit.c: In function `InitMGRegion':
    OSDInit.c:65: warning: implicit declaration of function `sceCdAltReadRegionParams'
    OSDInit.c: In function `WriteOSDConfigPS2':
    OSDInit.c:495: warning: control reaches end of non-void function
    ee-gcc -D_EE -O2 -G0 -Wall  -I/usr/local/ps2dev/ps2sdk/ee/include -I/usr/local/ps2dev/ps2sdk/common/include -I.  -c libcdvd_add.c -o libcdvd_add.o
    ee-gcc -mno-crt0 -T/usr/local/ps2dev/ps2sdk/ee/startup/linkfile -D_EE -O2 -G0 -Wall  \
      -o FORTUNA_Launcher.elf /usr/local/ps2dev/ps2sdk/ee/startup/crt0.o  FORTUNA_Launcher.o pad.o OSDInit.o libcdvd_add.o  -L/usr/local/ps2dev/ps2sdk/ee/lib  -lc -lcdvd -lpatches -ldebug -lpad -lc -lkernel
    
    I'll look for v1.1.1 of ps2-packer
     
    Last edited: Dec 14, 2019
    Algol likes this.
  18. 773
    1,392
    222
    sp193

    sp193 Developer

    Joined:
    Oct 13, 2014
    Messages:
    773
    Likes Received:
    1,392
    Trophy Points:
    222
    Location:
    Singapore
    Home Page:
    It was, but I didn't expect anyone to use that one because it's (older and was) tailored for PS2Ident itself. I've even forgotten that PS2Ident had a copy of that file.

    I was about to say it's available on Github, but then I saw that I tagged it as 1.1.0. So I was wrong and you might already have the latest version, particularly if you built it yourself.
     
  19. 330
    416
    97
    VTSTech

    VTSTech Developer

    Joined:
    Apr 8, 2019
    Messages:
    330
    Likes Received:
    416
    Trophy Points:
    97
    Gender:
    Male
    Home Page:
    I've managed to make the OSDInit.c/h & libcdvd_add.c/h work from the OSD Initalization package (https://sites.google.com/view/ysai187/home/projects/initializing-the-ps2psx) - You wrote those?

    I cloned ps2-packer repo, after apt-get install'ing some ucl and zlib stuff got it to compile :)
    (I wasn't using this before, But I will use it now, 26 commits between this and what I was using)

    Using OPL's Makefile for inspiration, I'm now creating packed binary automatically with compile :)

    Code:
    [email protected]:~/ps2homebrew/FORTUNA_Launcher$ make
    Building FORTUNA Launcher 0.46 ...
    make BOOT-packed.ELF
    make[1]: Entering directory '/home/vtstech/ps2homebrew/FORTUNA_Launcher'
    ee-gcc -D_EE -O2 -G0 -Wall  -I/usr/local/ps2dev/ps2sdk/ee/include -I/usr/local/ps2dev/ps2sdk/common/include -I.  -c FORTUNA_Launcher.c -o FORTUNA_Launcher.o
    ee-gcc -D_EE -O2 -G0 -Wall  -I/usr/local/ps2dev/ps2sdk/ee/include -I/usr/local/ps2dev/ps2sdk/common/include -I.  -c pad.c -o pad.o
    ee-gcc -D_EE -O2 -G0 -Wall  -I/usr/local/ps2dev/ps2sdk/ee/include -I/usr/local/ps2dev/ps2sdk/common/include -I.  -c OSDInit.c -o OSDInit.o
    ee-gcc -D_EE -O2 -G0 -Wall  -I/usr/local/ps2dev/ps2sdk/ee/include -I/usr/local/ps2dev/ps2sdk/common/include -I.  -c libcdvd_add.c -o libcdvd_add.o
    ee-gcc -mno-crt0 -T/usr/local/ps2dev/ps2sdk/ee/startup/linkfile -D_EE -O2 -G0 -Wall  \
      -o FORTUNA_Launcher.ELF /usr/local/ps2dev/ps2sdk/ee/startup/crt0.o  FORTUNA_Launcher.o pad.o OSDInit.o libcdvd_add.o  -L/usr/local/ps2dev/ps2sdk/ee/lib  -lc -lcdvd -lpatches -ldebug -lpad -lc -lkernel
    Stripping ...
    ee-strip -o BOOT-stripped.ELF FORTUNA_Launcher.ELF
    Compressing ...
    ~/ps2homebrew/ps2-packer/ps2-packer -v BOOT-stripped.ELF BOOT-packed.ELF
    PS2-Packer v1.1.1-unofficial-09ac9c6 (C) 2004-2005 Nicolas "Pixel" Noble
    This is free software with ABSOLUTELY NO WARRANTY.
    
    Compressing BOOT-stripped.ELF...
    Loading stub file /home/vtstech/ps2homebrew/ps2-packer/stub/lzma-1d00-stub.
    Stub PC = 01D0001C
    Removing 0 zeroes to section...
    Loaded stub: 00002B14 bytes (with 000001EC zeroes) based at 01D00000
    Opening packer /home/vtstech/ps2homebrew/ps2-packer/lzma-packer.so.
    Preparing output elf file.
    Packing.
    ELF PC = 001000D8
    Removing 1 zeroes to section...
    Loaded section: 0000EF2C bytes (with 000060D5 zeroes) based at 00100000
    Section packed, from 61227 to 22696 bytes, ratio = 62.93%
    Final base address: 01CFA740
    Writing stub.
    All data written, writing program header.
    Done!
    File compressed, from 68228 to 33844 bytes, ratio = 50.40%
    make[1]: Leaving directory '/home/vtstech/ps2homebrew/FORTUNA_Launcher'
    
     
    Last edited: Dec 14, 2019
    TnA and jolek like this.
  20. 1,626
    1,286
    347
    jolek

    jolek Senior Member

    Joined:
    Dec 29, 2017
    Messages:
    1,626
    Likes Received:
    1,286
    Trophy Points:
    347
    Gender:
    Male
    I've been thinking, what about do the same thing with your launcher as it is done with FMCB configurator?
    I mean, when main screen will be launch, press :but select: to enter configurator to set path for an app, edit its name...
    For that probably 2 .ELF and 1 config (.CNF) file will be needed.
    One for launching apps (OPL, wLe...), second for launching configurator, third for config (to load\save).

    We will have almost the same thing as we will have FMCB.
     

Share This Page