Could there be (or is there already) a graphical front end menu that could launch any of the MegaYume and/or NeoYume games?
@pik33 has a menu that can launch P2 applications (and he just built individual emulator binaries hardcoded to launch a respective game). Making one that can launch emulated games "properly" should be easy, but there's two tricky parts: The first being to launch the emulator with some sort of parameter passed. I guess they can be passed in some format through the upper 16K (this would make this not work with debug builds, but it seems like the least hassle). Another potential tripping point with that is that I don't think flexspin can retrieve the 8.3 name for a file when LFS is enabled (as it is in pik's menu loader).
This is a simple binary loader. The selected binary is loaded into the PSRAM, then a dedicated cog other than #0 stops all the other cogs except the PSRAM driver (there is no HUB code executing after this), moves the binary to the HUB RAM, stops the PSRAM driver, coginit #0,#0 and stops itsef. As the NeoYume can be compiled with a predefined game to load, the MIcroDOS menu simply loads the proper binary.
After the binary is loaded, the loader no longer exists in the P2 memory, so its LFN file system has no effect on the loaded binary.
@pik33 said:
After the binary is loaded, the loader no longer exists in the P2 memory, so its LFN file system has no effect on the loaded binary.
Yea, but if you passed a file path into the loaded binary, it would matter, since it wouldn't be able to open /sd/longdirectory/longfilename.bin. You'd have to give it /sd/longdi~1/longfi~1.bin. I am looking into what it takes to convert LFN paths to short paths, should be straightforward.
@Wuerfel_21 said:
MegaYume can quit to it's own menu (Ctrl+Esc on Keyboard or holding Start+Down for 5 seconds on the controller) and this is all easily controlled from the high-level code, you can change it to reset the P2 instead (launching another binary is sadly not a thing flexspin VFS can really do). NeoYume is more prickly because the menu code and associated C runtime is kicked out of memory as soon as the game launches. If I refactor the Z80 to use the memory arbiter for high ROM (which would also fix Metal Slug 3's audio) I might(?) be able to cut free some 64k. If I could then reduce the menu code to that size (help @ersmith the nu backend is still busted), I could have menu quit in there, too.
The MegaYume upper code at least starts up and can print characters now (I fixed several issues in the nucode runtime that were blocking that). I don't have external memory to test with, so not sure if any games can actually start up.
@Wuerfel_21 said:
MegaYume can quit to it's own menu (Ctrl+Esc on Keyboard or holding Start+Down for 5 seconds on the controller) and this is all easily controlled from the high-level code, you can change it to reset the P2 instead (launching another binary is sadly not a thing flexspin VFS can really do). NeoYume is more prickly because the menu code and associated C runtime is kicked out of memory as soon as the game launches. If I refactor the Z80 to use the memory arbiter for high ROM (which would also fix Metal Slug 3's audio) I might(?) be able to cut free some 64k. If I could then reduce the menu code to that size (help @ersmith the nu backend is still busted), I could have menu quit in there, too.
The MegaYume upper code at least starts up and can print characters now (I fixed several issues in the nucode runtime that were blocking that). I don't have external memory to test with, so not sure if any games can actually start up.
Thanks very much for looking into those cases directly.
Still very obviously broken though. MegaYume's file chooser is very broken, which you should be able to see without any memory board (though @Rayman may be happy to hook you up with one of those 96MB ones). Just have to press a key on the keyboard (or comment out the code that wait for it after printing the opening screen.
Meanwhile NeoYume just does this:
More importantly, it seems that you broke the ASM backend!
Further test: hardcoding games with DIRECT_BOOT in config doesn't work for either emulator. Seems that the file library is properly broken.
Oh, @ersmith, it seems going up to the root directory (where the sd mount point lives) in megayume's menu crashes now (could be older bug, I don't normally do this), both on nu and asm backends. The Version 6.0.0-beta-v5.9.28-47-g18bd553b Compiled on: Feb 14 2023 I have installed on my PATH doesn't have this bug. Might bisect later.
Yep root directory crash is recent bug, introduced somewhere between where native output got broken (I think 149c4dbbd46f7f2b266caaa79c69af6b3b7ae6e8) and where it got fixed ([61e59818fc05b26c7a89ebc769f2bd8d5bcb81e3] fix problem in native code with labels and -H)
@Rayman : Thanks for the kind offer. I hope that this bug, at least, we can resolve without extra hardware, but I'd love to take a look at external RAM at some point.
@Wuerfel_21 : I'm not completely sure this is a flexspin bug, although it probably is. The C library does sometimes need locks internally, and it looks like MegaYume is grabbing all of them; why is that?
@ersmith said:
@Wuerfel_21 : I'm not completely sure this is a flexspin bug, although it probably is. The C library does sometimes need locks internally, and it looks like MegaYume is grabbing all of them; why is that?
The lower code needs certain locks with hardcoded numbers, so I made it allocate all locks and then return the ones that aren't needed. MegaYume uses locks 7 through 10. Mostly for their event-signalling ability. There is no special significance to the numbers used, I just picked them to be in the middle to avoid conflicts (debugger uses 15 - allocated through a similar method)
@ermsith e9dc5570a083242a30cec48775208c67fd130b09 has working USB again. Also no more root directory issues. MegaYume on Nu can load and execute games, but the filechooser is constantly refreshing for some reason. Also the version info at the top is missing.
NeoYume on nu is very broken still and gets stuck when trying to load anything.
I think something is going wrong with sprintf calls in both cases.
@Wuerfel_21 : thanks for the feedback. Varargs functions were broken in nucode when called from Spin (they need special handling which was happening in CheckTypes, but that function doesn't happen in Spin). It should be fixed now.
@ersmith said:
@Wuerfel_21 : thanks for the feedback. Varargs functions were broken in nucode when called from Spin (they need special handling which was happening in CheckTypes, but that function doesn't happen in Spin). It should be fixed now.
Very cool and good. MegaYume works now. NeoYume fails to build with neoyume_upper.spin2:617: error: incompatible types in parameter passing: expected const any unknown type but got string pointer to const byte.
Line in question is c.sprintf(tmpstr,@"WAIT=%2d DELAY=%2d CLK=%-5s DAT=%-5s",PSRAM_WAIT,PSRAM_DELAY,PSRAM_SYNC_CLOCK?@"SYNC":@"ASYNC",PSRAM_SYNC_DATA?@"SYNC":@"ASYNC")
Also, can we make sure that if the build errs, the output binary is deleted?
@Wuerfel_21 : sprintf should be working now even for NeoYume (the type checking code was messed up, it should be fixed). As for output binary being deleted, it should be doing that already, at least it did in the samples I tried.
@ersmith actually, scratch that, was using the wrong script. Owie. sprintf is fixed, but loading is still broken in NeoYume (seems to commonly hang on LOAD_SROM or randomly crash...).
Comments
This is a simple binary loader. The selected binary is loaded into the PSRAM, then a dedicated cog other than #0 stops all the other cogs except the PSRAM driver (there is no HUB code executing after this), moves the binary to the HUB RAM, stops the PSRAM driver, coginit #0,#0 and stops itsef. As the NeoYume can be compiled with a predefined game to load, the MIcroDOS menu simply loads the proper binary.
After the binary is loaded, the loader no longer exists in the P2 memory, so its LFN file system has no effect on the loaded binary.
Yea, but if you passed a file path into the loaded binary, it would matter, since it wouldn't be able to open
/sd/longdirectory/longfilename.bin. You'd have to give it/sd/longdi~1/longfi~1.bin. I am looking into what it takes to convert LFN paths to short paths, should be straightforward.Okay, here is a function to that extent...
In C because it has to be, spin can't access structs.
#include <stdio.h> #include <string.h> #include <filesys/fatfs/ff.h> // Convert LFN path to short path // File must actually exist... // Returns NULL on fail char *long_to_short(char *path) { char *out = _gc_alloc_managed(strlen(path)+1); char *temp = _gc_alloc_managed(strlen(path)+1); const char *separator = "/"; strcpy(out,separator); strcpy(temp,path); if (*temp != '/') {printf("relpath!\n");goto bad;} // relative path not ok // Handle drive ID (first token) char *token = strtok(temp,separator); if (strcasecmp(token,"sd")) { printf("bad drive %s\n",token); goto bad; // Wrong drive } strcat(out,token); struct __using("filesys/fatfs/fatfs.cc") *ffs = ((struct vfs *)__getvfsforfile(__getfilebuffer(), out, NULL))->vfs_data; char *vf_path = temp+strlen(token)+1; while (token=strtok(NULL,separator)) { token[-1] = '/'; strcat(out,separator); FILINFO f; if (ffs->f_stat(vf_path,&f) != FR_OK) {printf("stat fail %s!\n",vf_path);goto bad;} #ifdef FF_USE_LFN if (f.altname[0] != 0) { strcat(out,f.altname); } else { strcat(out,f.fname); } #else strcat(out,f.fname); #endif } _gc_free(temp); return out; bad: _gc_free(temp); _gc_free(out); return NULL; } int main() { mount("/sd",_vfs_open_sdcard()); printf("test: %s\n",long_to_short("/sd/longdirectory/longfilename.bin")); // Will print "/sd/LONGDI~1/LONGFI~1.BIN". Requires that the file actually exists. }The MegaYume upper code at least starts up and can print characters now (I fixed several issues in the nucode runtime that were blocking that). I don't have external memory to test with, so not sure if any games can actually start up.
Thanks very much for looking into those cases directly.
Still very obviously broken though. MegaYume's file chooser is very broken, which you should be able to see without any memory board (though @Rayman may be happy to hook you up with one of those 96MB ones). Just have to press a key on the keyboard (or comment out the code that wait for it after printing the opening screen.
Meanwhile NeoYume just does this:
More importantly, it seems that you broke the ASM backend!
Further test: hardcoding games with DIRECT_BOOT in config doesn't work for either emulator. Seems that the file library is properly broken.
@ersmith would be happy to send you a care package
Oh, @ersmith, it seems going up to the root directory (where the
sdmount point lives) in megayume's menu crashes now (could be older bug, I don't normally do this), both on nu and asm backends. TheVersion 6.0.0-beta-v5.9.28-47-g18bd553b Compiled on: Feb 14 2023I have installed on my PATH doesn't have this bug. Might bisect later.Yep root directory crash is recent bug, introduced somewhere between where native output got broken (I think
149c4dbbd46f7f2b266caaa79c69af6b3b7ae6e8) and where it got fixed ([61e59818fc05b26c7a89ebc769f2bd8d5bcb81e3] fix problem in native code with labels and -H)@Rayman : Thanks for the kind offer. I hope that this bug, at least, we can resolve without extra hardware, but I'd love to take a look at external RAM at some point.
@Wuerfel_21 : I'm not completely sure this is a flexspin bug, although it probably is. The C library does sometimes need locks internally, and it looks like MegaYume is grabbing all of them; why is that?
The lower code needs certain locks with hardcoded numbers, so I made it allocate all locks and then return the ones that aren't needed. MegaYume uses locks 7 through 10. Mostly for their event-signalling ability. There is no special significance to the numbers used, I just picked them to be in the middle to avoid conflicts (debugger uses 15 - allocated through a similar method)
@ermsith Just tried bleeding edge
3c567bf7f7ab92cf22b2145355f91b30fac26261, USB is now broken (both ASM and nu)@ermsith
e9dc5570a083242a30cec48775208c67fd130b09has working USB again. Also no more root directory issues. MegaYume on Nu can load and execute games, but the filechooser is constantly refreshing for some reason. Also the version info at the top is missing.NeoYume on nu is very broken still and gets stuck when trying to load anything.
I think something is going wrong with
sprintfcalls in both cases.@Wuerfel_21 : thanks for the feedback. Varargs functions were broken in nucode when called from Spin (they need special handling which was happening in CheckTypes, but that function doesn't happen in Spin). It should be fixed now.
Very cool and good. MegaYume works now. NeoYume fails to build with
neoyume_upper.spin2:617: error: incompatible types in parameter passing: expected const any unknown type but got string pointer to const byte.Line in question is
c.sprintf(tmpstr,@"WAIT=%2d DELAY=%2d CLK=%-5s DAT=%-5s",PSRAM_WAIT,PSRAM_DELAY,PSRAM_SYNC_CLOCK?@"SYNC":@"ASYNC",PSRAM_SYNC_DATA?@"SYNC":@"ASYNC")Also, can we make sure that if the build errs, the output binary is deleted?
@Wuerfel_21 : sprintf should be working now even for NeoYume (the type checking code was messed up, it should be fixed). As for output binary being deleted, it should be doing that already, at least it did in the samples I tried.
Yea, it's all working now. Load speeds don't seem to be significantly worse, which is also cool.
And no, there's plenty of cases where the output file isn't deleted on error. The sprintf type thing was one of those cases.
@ersmith actually, scratch that, was using the wrong script. Owie. sprintf is fixed, but loading is still broken in NeoYume (seems to commonly hang on LOAD_SROM or randomly crash...).