Runtime Script Framework

[nk64]

Hi I've tidied up and consolidated a bunch of the hacks that we have discussed into what I'm calling the Runtime Script Framework.

Please consider it alpha quality and make a backup of your SD Card before you jump in. Let me know if any of the instructions can be improved.

It includes such things as:

• All the FBNeo subsystems including Neo Geo CDZ.
• Custom keymaps
• Boot logo control
• Changing the default startup screen

For those who are interested in the linuxy internals of this machine, please check out the Custom Scripts section. I have a scripts for:

• dumping the flash
• running a simple statically compiled binary (only hellow world at this stage and need to writeup how to compile)
• reboot the console
• dumping debug logging
• generating FBNeo dat files
• dumping os info, file listings and files

There are some areas of exploration that I'd be happy to receive help on:

• Plugging in a USB Ethernet dongle and seeing if we can configure the IP stack in order to connect to adbd over the network
• Compiling a utility to draw text to the framebuffer so that custom scripts can display some output as they go

[nk64]

For those who have already gotten some FBNeo subsystems working, please note there is a small difference in the requirements for the contents of the .redir files in those cases. (instead of cv/cv_heist.zip it now just needs to be cv/heist.zip

[horsiezoo]

in between WFH got
8 0 3933184 sda from cat /proc/partitions with usb stick plugged in so that's a start. Tried running fdisk :

${byobb} fdisk -l > "${output_dir}/fdisk.txt" 2>&1; /bin/sync

which creates an empty logfile 0 bytes, have I misunderstood the above cmd line usage at all ?

Also - unrelated :
Attempted to calc pi using busybox bc,

${byobb} echo "scale=1000; 4*a(1)" | bc -l > "${output_dir}/pi.txt" 2>&1; /bin/sync

output-
/mnt/extsd/roms/mame/pi.sh[21]: bc: not found

once again its likely me misusing the cmd line, OR : piping works differently.

bc --help outputs

BusyBox v1.31.1 (2020-02-24 14:35:54 +08) multi-call binary.

Usage: bc [-sqlw] FILE...

Arbitrary precision calculator

-q	Quiet
-l	Load standard math library
-s	Be POSIX compatible
-w	Warn if extensions are used

$BC_LINE_LENGTH changes output width

Also .2 : cat /dev/urandom > /dev/fb0 ---what does this do ? put the contents of urandom on fb0 to interrupt something ?

cheers ! (Sorry about the messy post, not after tech support just wondering if I'm on the right track)

[nk64]

I can't see an obvious problem with the fdisk command but maybe there is something in this thread that helps: https://busybox.busybox.narkive.com/MeZkC6rt/fdisk-problems

as for the bc command, I think you are missing the ${byobb} in front of it.

[nk64]

cat /dev/urandom > /dev/fb0 just fills the screen with a random pattern.
I am use it to indicate script progress until I can figure out how to write text to the screen (which I got working late last night)

Without it, the scripts appear to hang at the menu screen until the finish running when there is a brief black screen and back to the menu

also last night I managed to compile an evtest program which might help diagnose joystick capabilities.

[horsiezoo]

Thanks yes I actually had that page open! https://busybox.busybox.narkive.com/MeZkC6rt/fdisk-problems
Ah yes I see now fb0 = framebuffer. Very cool.
"googles evtest" - gotcha - input events. Yes that sounds pretty useful.
Did you manage to get a SDK to compile stuff ?
My thinking was to try copying sd files to usb drive then pointing to that for script output and if that works rom storage to potentially save sd slot wear
e.g : /mnt/sda/roms/

Anyways this is all a later on thing. Thx for the assist !

[horsiezoo]

I can't see an obvious problem with the fdisk command but maybe there is something in this thread that helps: https://busybox.busybox.narkive.com/MeZkC6rt/fdisk-problems

as for the bc command, I think you are missing the ${byobb} in front of it.

Yes you were correct, I understand how that works now thank you :

3.141592653589793238462643383279502884197169399375105820974944592307
81640628620899862803482534211706798214808651328230664709384460955058
22317253594081284811174502841027019385211055596446229489549303819644
28810975665933446128475648233786783165271201909145648566923460348610
45432664821339360726024914127372458700660631558817488152092096282925
40917153643678925903600113305305488204665213841469519415116094330572
70365759591953092186117381932611793105118548074462379962749567351885
75272489122793818301194912983367336244065664308602139494639522473719
07021798609437027705392171762931767523846748184676694051320005681271
45263560827785771342757789609173637178721468440901224953430146549585
37105079227968925892354201995611212902196086403441815981362977477130
99605187072113499999983729780499510597317328160963185950244594553469
08302642522308253344685035261931188171010003137838752886587533208381
42061717766914730359825349042875546873115956286388235378759375195778
18577805321712268066130019278766111959092164201988

Todo : add a timer or some kind of loop to output time to generate x no. digits, ala superpi

[Hello-dot-Jpg]

Awesome work once again nk64, did you end up using the toolchain from SigmaStar?

You may also be able to compile a shell to output to the frame buffer if getty is not present on the file system.

Are you also able to check if WPA Supplicant is on the filesystem if it is we should be able to configure a USB Wifi dongle to work
I think I have an old Ethernet dongle floating around I'll see if I can find it.

If you can compile the MiyooCFW or OnionOS emulators I think they already output debug/relevant info to the frame buffer.
https://github.com/TriForceX/MiyooCFW
https://onionui.github.io/docs

[nk64]

I haven't used anything fancy yet like the flythings SDK or SigmaStar tool chain.
I have just the basic ARM GNU Toolchain (I put up some info yesterday at the bottom of this page) about how I compiled the hello world.

The busybox_arm came statically pre-compiled from https://github.com/EXALAB/Busybox-static/tree/main

[nk64]

There is a wpa_supplicant.conf file but I don't know if it is hooked up.

/etc/wifi:
-rwxrwxr-x    1 0        0               83 Feb  7  2023 wpa_supplicant.conf*

[nk64]

@horsiezoo you've probably already got it but I was able to mount an external flash drive with these commands:

${byobb} blkid >> "${output_dir}/test-thumbdrive-lsblk.txt" 2>&1; /bin/sync

log "Mounting thumb drive"

{
	mkdir /tmp/exthdd
	mount /dev/block/sda /tmp/exthdd
	ls -laF /tmp/exthdd
	cat /tmp/exthdd/test.txt
	umount /tmp/exthdd
	rm -rf /tmp/exthdd
}  >> "${output_dir}/test-thumbdrive-mount.txt" 2>&1; /bin/sync

log "Done"

test-thumbdrive.sh User Script (previously referred to as Custom Scripts)

[horsiezoo]

Yes something of that nature, I’ve semi got a separate unmount script to manually run before powering off system. Actually just crossed my mind - run dmesg- does yours mention usb (presumably sd card) not unmounted correctly /run fsck? That’ll be the non graceful power off method - what happens if unmount sd card while system is running I wonder. If that doesn’t immediately freeze things that could be a more elegant shutdown method.

-edit : ok umount /mnt/extsd just freaks it out the next event that occurs and triggers a reboot . possibly could have predicted that. Hmm but not always… sometimes can still scroll through current menu and run scripts, r button doesn’t change column until reboot script run. — possibly due to not emptying “cache” as in your usb mount script. Interesting.

[horsiezoo]

Confirming what everyone probably already knows- there’s only drivers for FAT file systems, I’ve tried formatting usb drives to ex2 ….and other file systems, DMESG (very useful btw) reports that it cannot access a non FAT drive

[nk64]

I tried the poweroff and halt commands from the new busybox but no joy.

[ot644]

This really is impressive work. With all this in place everything really is covered and I don’t see what other future enhancements are possible (I’m sure you will prove me wrong). There is for me the one major issue with this console which is the inability to configure controls in game. The workaround of using keymap files is great but it is difficult and time consuming creating these json files using trial and error to get the right keys. Doing this per game is not realistic so I don’t see the likelihood of having more than a few keymap files in place. Maybe a future enhancement is some sort of utility that can assist with creating keymap files to simplify the process?

[nk64]

Yeah, that side of things sucks.

And a utility to help id a good idea.

I think that we might just need one keymap per emulator (for non fbneo) emulators where the out of the box one one isn't good enough. then one for each of the subsystems that fbneo supports, then for the arcade games fbneo seems to categorise the games into two groups (street fighter (baes on some complicated logic) and not street fighter)
and changes the mapping on the fly.

If we can can (as part of the custom keymaps) detect which of those two categories the game falls into we might just need two keymaps there.

dunno where mortal combat falls.

conceivably (like MAME) we could insert a check for a per emulated major hardware group keymap (cps1, cps2, neogeo, etc)

It is definitely an area where research is required.

[ot644]

Automatically detecting and assigning would be brilliant. There could always be a section in the script where we can override with custom keymaps in cases such as mortal kombat or other rare cases.

[ot644]

There is a small correction that needs to be made in 'emulator_wrapper.sh'. Destination_keymap_file_path needs to be changed as below for the copy to work. Note also the typo in keyremp which needs to be corrected.

Original:
destination_keymap_file_path="/keyremp/${keymap_filename}"

Modified:
destination_keymap_file_path="/mnt/extsd/keyremap/${keymap_filename}"

[nk64]

Thanks @ot644, I have fixed this bug in emulator_wrapper.sh

[ot644]

Also for the gmenu2x_wrapper.sh it is creating 2 log files. gmenu2x.log and gmenu2x.bin.log (which is empty). I believe wrapped_exe_logfile="${wrapped_exe}.log" should be changed to wrapped_exe_logfile="${0}.log" instead?

[nk64]

So there are a lot of places where things can go wrong and a few places where log files end up.

• /bin/gmenu2x.bin.log & /emus/{emudir}/{emu}.bin.log
  • These log files capture the output of gmenu2x and each emulator (as you rightly point out gmenu2x.bin.log doesn't seem to see much action (but under certain circumstances I can get the following output there:

 _MI_AO_OpenVqeLib: success
 _MI_AO_OpenSrcLib: Can not load libSRC_LINUX.so!
 _MI_AO_OpenG711Lib: success
 _MI_AO_OpenG726Lib: success
Couldn't open /mnt/extsd/ui/logo.png

If you are not interested in logging the output of the original binaries (and I guess the added wear and tear on your SD card), you can find the line log_exe=true in /_gt4286util/gmenu2x_wrapper.sh and emulator_wrapper.sh and set it to false.

Conceivably the *.bin.log could be consolidated into their respective *.log files but my original plan was to overwite the *.bin.log files at each run (because the emulators can generate a lot of text), while leaving the *.log files to grow unchecked until the user deletes them (because the log generates less text (well except in the case of gmenu2x)).

• /bin/gmenu2x.log and /emus/{emudir}/{emu}.log
  these log files are used for diagnosing any syntax or other errors in

  • /_gt4286util/scripts/emulator_wrapper.sh (generates a per emulator log)
  • /_gt4286util/scripts/gmenu2x_wrapper.sh

• /_gt4286util/output/log.txt
  all the User Scripts in /roms/MAME write their log messages to this file and then the output of individual commands those scripts run is often captured to the /_gt4286util/output directory.

I might just make a clear-logfiles.sh script so you can clear the slate before doing some testing.

[ot644]

One last thing. Running boot-logo-disable.sh doesnt seem to work. The show boot logo property below in the gmenu2x.log shows null and I cant seem to find the output log file for the boot-logo-disable.sh script.

/mnt/extsd/bin/gmenu2x: Arg0: /mnt/extsd/bin/gmenu2x
/mnt/extsd/bin/gmenu2x: ArgAll:
/mnt/extsd/bin/gmenu2x: Current Working Directory: /
/mnt/extsd/bin/gmenu2x: Wrapper Script: /mnt/extsd/_gt4286util/scripts/gmenu2x_wrapper.sh
/mnt/extsd/bin/gmenu2x: Sourcing wrapper script: /mnt/extsd/_gt4286util/scripts/gmenu2x_wrapper.sh
/mnt/extsd/bin/gmenu2x: Wrapped Exe: /mnt/extsd/bin/gmenu2x.bin
/mnt/extsd/bin/gmenu2x: Executing wrapped exe: /mnt/extsd/bin/gmenu2x.bin
/mnt/extsd/bin/gmenu2x: Property: persist.gt4286.show_boot_logo=
/mnt/extsd/bin/gmenu2x: Property: prop.gt4286.gmenu2x_run_once=true
/mnt/extsd/bin/gmenu2x: Executing wrapped exe with logging: /mnt/extsd/bin/gmenu2x.bin

The output directory for the script should be below.

output_dir="${GT4286UTIL_HOME}/output"
mkdir -p "${output_dir}"
logfile="${output_dir}/log.txt"; log () { echo "${this_file}: ${1}" >> "${logfile}" && /bin/sync; }

But i dont see an output directory.

PS D:_gt4286util> dir

Directory: D:\_gt4286util

Mode LastWriteTime Length Name

---

d----- 15/01/2025 10:33 AM bin
d----- 15/01/2025 10:33 AM res
d----- 15/01/2025 10:33 AM scripts

[ot644]

It looks like it is just used to display the pixels. I tried with no luck limiting the amount of data written to the frame buffer. In the end I just hashed it out of the scripts, they all work fine without it.

[horsiezoo]

Oh I understand now, yes that error is likely normal probably can be ignored

[nk64]

cat: write error: No space left on device

I had that once, but I can't remember the context. It is not normal to me so if get a chance to attempt to recreate it and then describe the scenario in a way that I can recreate it then maybe we can resolve it.

I don't know why, but I suspect that running a chkdisk the thumb drive might have resolved it for me. (but that seems unrelated to writing random data to the frame buffer so YMMV).

[nk64]

Oh wait, yeah I can see it in the emulator log file over and over again. it is from filling up the framebuffer with random data, and it is safe to ignore the error (I assume you get the screen filled with static when you have those lines in right?

I will fix it in the next release.

[ot644]

The static screen that’s right. I haven’t tried it but I guess you could echo some text to it rather than random data to limit the amount of data. I’m not sure how that will be interpreted and displayed on the screen though.

[nk64]

I splashed out on a $39 USB 3.0 to Gigabit Ethernet dongle to test but had no joy only to find when I dived into it that the USB Ethernet drivers are not included in the GT4286's Linux kernel. Though my USB dongle was detected by lsusb.

I found (as others) have mentioned that when I plugged in a powered USB hub, the device became powered on (and the power switch doesn't work as expected anymore).

There is a danger of damage to the device if you have two separated sources of 5v going in so please take care to only use one source of power if you are experimenting with powered hubs.

[ot644]

Not sure if anyone else is experiencing this but occasionally getting the below in fbneo when trying to start a rom. Deleting fbneo.bin.log resolves it. Usually happens when im fiddling around with keyremap files so not sure if it something im doing thats causing it but these log files do get quite large over time.

/mnt/extsd/emus/fbneo/fbneo: /mnt/extsd/_gt4286util/scripts/emulator_wrapper.sh[409]: can't create /mnt/extsd/emus/fbneo/fbneo.bin.log: Read-only file system
/mnt/extsd/emus/fbneo/fbneo: /mnt/extsd/_gt4286util/scripts/emulator_wrapper.sh[409]: can't create /mnt/extsd/emus/fbneo/fbneo.bin.log: Read-only file system

[ot644]

Disabling all logging by default makes sense and turning it on as needed for troubleshooting.

[horsiezoo]

it crossed my mind that it maybe possible to use small capacity sd cards as “cartridges “
A script that wraps Gmenu2x, circumvents logo.gif loads say fbneo + argument to run a game directly (I’m looking at you mortal kombat 2) completely skipping the ui and database, saving a bit of memory.
Kind of recoiling in horror about how much trial and error (swapping out sd cards millions of times) this would take

edit : on thinking about it that would stop Gmenu2x executing wouldn’t it or would it as that points to Gmenu2x.bin . what would happen if wrapped logo.gif or gamedb , as I assume thats next in the startup process . Ok this is going to take some working out

Would something like this work:

wrapped Gmenu2x .sh executes Gmenu2x binary then executes a emulator file
eg (missing all the wrapper stuff and correct terminology just for the concept)
cd /bin ./gmenu2x.bin cd /emu/fbneo ./fbneo.bin /whatever/mk2.zip

or would executing Gmenu2x cause the script to halt there? (Can more than one binary be executed in one line?)

a bit of testing:
— short answer no. That’s preventing something from loading so black screen note to self: don’t mess with stuff if you are half asleep

[nk64]

I wonder, Is there a game that you can't currently play that you know or suspect is due to insufficient memory?
Edit: Sorry I missed your reference to Mortal Kombat 2.

The way the gmenu2x executes the emulator is like a snake shedding it's skin where the snake is the emulator and the skin is gmenu2x. So I don't think that you will regain any memory attempting to bypass it.

I have added some info on the boot process but the key thing for your single game cartridges idea is to replace /bin/gmenu2x with a shell script like (totally untested):

#/bin/sh
cd /mnt/extsd/emus/fbneo
/mnt/extsd/emus/fbneo/fbneo.bin /mnt/extsd/roms/FBA/{game}.zip

You will probably only need the following files/folders on your cartridge:

• \emus\fbneo\*
• \roms\FBA\{game}.zip
• \bin\gmenu2x (the shell script above, not the real gmenu2x)
• \bios\* {or whatever is required for your game}

The actual gmenu2x binary file doesn't have to be involved in the process of launching a one shot emulator.

[nk64]

I don't think your mk2 issue is a RAM one unfortunately. I can see a Segmentation Fault is the last output of the game which often points to memory issues or memory corruption (eg from buggy code)
But I am able to load and play mslugx which has a much larger romset (~68MB compared to mk2's 16MB).
So I think it is more likely that the version of fbneo we have just has a broken driver for mk2 and mk3 (and mslug3 for that matter)

[horsiezoo]

Cheers yes my thinking was that gmenu handles key mapping/input? But regardless I got something like yours above setup yesterday and no go unfortunately eg : load emu binary instead of gmenu I used the gameboy one as that’s easier to configure.
And thanks re: fbneo 1.0.0.1 known issues