All main emulator sources missing: PicoDrive, FCEUX, Ohboy, MAME4All, FBA, GnGeo, Stella, Handy... #260
Replies: 19 comments 84 replies
-
|
We are working on this, there was many stuff in many place and many of them dissapeared. Please be patient. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks, I really appreciate it. I hope these sources are not gone forever. If we can find and upload them, I'll work on updating FCEUX and PokeMini, and fixing bugs in them. |
Beta Was this translation helpful? Give feedback.
-
|
I can't even find the PicoDrive source the current release of PicoDrive on this platform was built from! After some digging, I've found the original source, but that has over a hundred forks! And it's two versions behind the current release we're using: https://github.com/notaz/picodrive Can we please-please link to our sources? Pretty please?? Otherwise what's the point in calling this a free and open source project. All this is so counter-productive... :@ (Having to individually hunt and beg for sources to already built software we're using on the platform. If it's released on the platform, if we're using it, it needs to have the source available!) It's not open source if the source is not freely available and easy to find. And it's completely counter-productive if we have to repeat the same work that has been done before just to play catch-up. It's a total mess. As it stands, this project is closed source when it comes to all its main emulators -- which make up the heart of the project! |
Beta Was this translation helpful? Give feedback.
-
|
In fact, I'm now questioning why the source code for all these emulators is not bundled with the binaries in the CFW release. I really think that should be made a policy of this project. If you're going to build something for the platform, pack and bundle your source code with it! |
Beta Was this translation helpful? Give feedback.
-
|
Whatever personal change/tweak I want to make to any of these emulators, I'm constantly running into the same problem: where is the open source code that's supposed to be available? What code was this binary compiled from? It's frustrating to say the least..! And it makes this project practically closed source -- open to only the select few who were involved in building each emulator/binary. |
Beta Was this translation helpful? Give feedback.
-
|
This needs to be top priority for this project! Not put in the discussions section and hidden away! This is the most important thing for the next release! No new features take precedece over this! This means the future and progress of this project. It's not going to advance if it remains closed. |
Beta Was this translation helpful? Give feedback.
-
Nobody is lowering the importance of this, I totally agree that this is important (and it is something that should be available for the next release). I have only been moving to "discussions" things that have no direct relationship with the CFW and its components (kernel, uboot, daemon, etc ...). It does not mean that they are unimportant. |
Beta Was this translation helpful? Give feedback.
-
|
Nobody here disagrees with you. The original dev kind of abandoned this project and it was left in a pretty messy state. We (well, mostly @TriForceX) have been trying to clean it up. Any help you can provide would be appreciated. |
Beta Was this translation helpful? Give feedback.
-
|
Something I was working on but stopped a while back was getting continuous integration set up. I got it working for one repo, but then realized I was using the older tool chain. So then I started trying to get a docker image put together that could run buildroot to build the new tool chain, but I haven't gotten that working yet. |
Beta Was this translation helpful? Give feedback.
-
|
(https://github.com/nfriedly/miyoo-toolchain and MiyooCFW/gmenu2x#6 are what I have so far on that front - it's not necessarily the most important thing to move this project forward, but I do think that having the CI set up and a doctor images that are ready to go for compiling would help reduce a bit of friction.) |
Beta Was this translation helpful? Give feedback.
-
|
I'm out with family for the next couple of days, but I might have some time to get back to it next week. Something I'd like to see in the long-run is the ability to run a single command and have buildroot compile everything from source and creat an image file that's ready to write to a microSD. |
Beta Was this translation helpful? Give feedback.
-
|
Sounds great. Although having to deal with makefiles and knowing how to compile things is kind of a Linux C(-based) building essential know-how, and perfectly fine for when we need to edit/update the software. The current documentation (in the "Making Games" section of the Wiki), written by Crait and Gameblabla, is quite sufficient for setting up the build environment to anyone who is at all familiar with Linux (or a Unix-design-based system). What it's not fine for is when a user simply wishes to change their boot-logo, for example. They shouldn't need to know how to build the toolchain, use makefiles, and compile a source to accomplish a simple customisation for their device, or a button swap in an emulator, etc. But you're right, this would make things a lot easier for working with the source -- provided it's used as the main tool for building for the project, is always up-to-date and works reliably. I've never worked with Docker before, so I'm not sure how all this works. Do Docker images work on Windows, too, or are they Linux-specific? I take it it's somewhat similar to AppImage in concept? (https://appimage.github.io/) |
Beta Was this translation helpful? Give feedback.
-
|
Docker works on windows, I think it just runs a Linux virtual machine under the hood :-) I don't know much about appimage, but yeah, it sounds similar. |
Beta Was this translation helpful? Give feedback.
-
|
@TriForceX, @MiyanoOsu has found the base source code for all the emulators for which we're missing the source code: https://github.com/steward-fu/miyoo/releases This is the source from the 1.2 build for all the emulators and apps bundled with it. For the current, 1.3 build and its subversions, have there been any updates made to these apps and emulators, or were the same pre-built and stable binaries copied to and re-used in the next release? Do you remember? |
Beta Was this translation helpful? Give feedback.
-
Yes, these are the old ones (from miyoo 1.2 / NxHope from 2018/2019 when steward were working with us together), we already have them! dont worry! btw some of these sources are outdated versions of the current ones and have never been maintaned/updated... |
Beta Was this translation helpful? Give feedback.
-
|
Outdated as in earlier version of the code, or outdated as in won't run on the new system? o.O When I asked for the sources to these emulators, why weren't these sources shared with me if you already knew about them? I'm starting to get bad vibes here... I'm not sure what happened between you guys, why you parted ways, but that shouldn't have an impact on the availability of this source code and on the future of the project. If I/we need to revert to an earlier version of the source code in order to keep things open and available, I readily will. Better to have an earlier version of the program compiled for the system with the source code open than a newer one with the source code lost/closed. |
Beta Was this translation helpful? Give feedback.
-
|
One thing I really like about the 1.2 source for these programs from the get-go is that the build process and requirements for each program is well documented. This is how source code is supposed to be shared in an open source project -- so that anyone can pick it up and work with it. |
Beta Was this translation helpful? Give feedback.
-
|
FYI, when the cfw was started in 2018, steward, me and other 2 people worked on the cfw directly, and there was other people who supported us getting the compiled stuff and packaging in each cfw version for all the console, unfortunately the work was not very coordinated, until 1.3.3 different files were being kept in each cfw package, so it was very messy (for example the 1.3.3 cfw of bittboy does not have the same kernel version as that of pocketgo, so not all things work same in all, that was a huge mistake that have been happening on 1.3.3 and the older ones). Because of that i have been reordering many things and trying to get everything in order, i already have almost all the sources of the apps, and things related to the CFW such as kernel, daemon, uboot, etc ... they are also all in order, so When I have a little more time available I will finish uploading everything and I will make the release 1.4.0 with everything ordered to follow a single standard from now on. |
Beta Was this translation helpful? Give feedback.
-
|
I see. Having a single, unified build/distribution that caters to all devices equally sounds like an excellent idea. (And I know, it's not easy. Again, if you need help, let me know.) |
Beta Was this translation helpful? Give feedback.
-
|
If you have all this on your plate, let me/us handle sorting the apps/emulators and their source code, then. I feel the apps/emus are crucial to this project, that the future of the proect depends on them being open and available. |
Beta Was this translation helpful? Give feedback.
-
|
Sources for PokeMini and PicoDrive found and updated (with the switched buttons and default behaviour fixed/consolidated): PokeMini: https://github.com/Rezzy-dev/pokemini Binary builds for the update also provided -- check the "releases" section. ;) Working on FCEUX, OhBoy, and Handy next. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks! |
Beta Was this translation helpful? Give feedback.
-
|
Handy and OhBoy are done, too (up-to-date source found, and A-B buttons fixed): Handy: https://github.com/Rezzy-dev/handy-rs97 Binary builds for download also provided. :) Handy is perfect and up-to-date (newer, with even better game support, than the stock version supplied with the Miyoo CFW)! :) OhBoy is up-to-date with the main source (and features a cleaned up, updated UI), but has one unresolved issue: that accessing its file browser in the UI crashes the emulator. To prevent this, and until the peculiar bug is fixed, I've disabled the internal ROM browser and "Mono Palette" and "Border Image" selection options in the menu/settings. You can still set/change these manually by editing the "video.rc" configuration file of OhBoy (in "/mnt/.ohboy/"). FCEUX is still giving me a headache. :( I've never compiled with scons before. When I compile the source with make, it builds successfully, but fails to run on the Miyoo device. If anyone has worked with the FCEUX source before and/or has any helpful tips/pointers, I'd really-really appreciate it if you could help me figure this out. Thanks. |
Beta Was this translation helpful? Give feedback.
-
|
Small update -- fixed screen rotation for Handy (so Klax and a few other games now have the vertical layout they're supposed to have): https://github.com/Rezzy-dev/handy-rs97/releases/tag/update |
Beta Was this translation helpful? Give feedback.
-
|
Small update -- big progress: I finally got to the bottom of what's wrong with the FCEUX source. (Scons is not needed to compile -- make is sufficient. There were just a few things in the code that needed to be fixed for compatibility with the current Miyoo CFW.) It now compiles and runs successfully. There are just a few more quirks I need to clean up, and FCEUX will be up-to-date and fixed, too. :) |
Beta Was this translation helpful? Give feedback.
-
|
FCEUX is done, too -- finally! :D (Getting this source working with today's Miyoo CFW was quite the challenge -- but compiling should now be simple, going forward.) FCEUX: https://github.com/Rezzy-dev/fceux Binary build for convenience/simplicity provided. Note that this build/download is an update, so you'll need the emulator's original files to install this over. I've cleaned up and consolidated FCEUX's menu/UI to better fit in with the rest of the emulators on the system (visually, as well as in order and function). Switched A-B and X-Y buttons fixed. :) |
Beta Was this translation helpful? Give feedback.
-
|
These are the logical reasons why I made the decision to stick with the old, Steward Fu source in this case, and to fix it up and bring it up-to-date. It's not old, actually. It's current and more up-to-date as it pertains to the Miyoo CFW now than the "2019-08-07" and "newer" sources. |
Beta Was this translation helpful? Give feedback.
-
|
There is only one Miyoo/core feature that's incomplete in the Steward Fu and this source over the stock build, and that's the frameskip setting. The initial implementation is there (and disabled), but setting the number of frames to skip doesn't work at the moment. But I actually didn't find it important, because by default it's off, and frameskip on a 2D game has never improved the experience. It matters for 3D games and performance-heavy games, but for NES/Famicom games on the Miyoo hardware, it's quite an irrelevant setting in my honest opinion and testing. It serves to improve nothing. I thought about implementing it, but the "newer" sources were also missing it, as far as I recall. |
Beta Was this translation helpful? Give feedback.
-
|
@Rezzy-dev |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
It's optimised/tweaked for the RG handhelds, and it won't compile with the Miyoo toolchain. Like I said. Even if you manage to compile it, it won't run on Miyoo. It's been changed too much -- tweaked too much to work on RG and other handhelds instead. And there's nothing newer about this code, feature-wise, as it pertains to the Miyoo platform. The software has the same features, it is working the same. Nothing worthwhile has been updated from the Steward Fu FCEUX source in it as it pertains to the Miyoo platform. It has actually regressed since -- receiving many tweaks that broke its compatibility with the Miyoo CFW. |
Beta Was this translation helpful? Give feedback.
-
|
Everything you said sounds right, but as I said the framedrop is very visible and the FPS counter constantly shows 59-60fps (like there was some hidden fps capping). I've tried refreshing memory multiple times, but that didn't help and as soon I switched back to earlier build everything went to normal. However I've noticed that I might get similar performace during first few seconds of gameplay, but it will decrease very fast (cpu throttling?). Tested on Ninja Gaiden [USA] |
Beta Was this translation helpful? Give feedback.
-
|
Moved the FCEUX-specific discussion here (so as we don't clutter up this thread): #294 |
Beta Was this translation helpful? Give feedback.
-
|
(Moving here to avoid derailing the other thread), @Rezzy-dev said:
I think irixxxx maintains Picodrive these days, both his own fork of notaz's upstream and the libretro version, and should have freq-mod's donated V90 so it should be "officially" supported when the next release of the standalone version happens. |
Beta Was this translation helpful? Give feedback.
-
|
Yes, and upgrades/changes have been made to Picodrive to expand support to Game Gear games and for the 32X, CD, and other specialised gear for the Mega Drive from what @Apaczer tells me (if I understood it correctly). Irixxxx's version is considerably ahead of the current build and source code -- a lot of changes have been made. The source code I've uploaded is the source code for the currently bundled build, with one change: the start-up overlay message (containing the ROM's region, native framerate, and other misc. details) has been disabled (commented out) -- as most users will find this annoying/distracting, and not very useful. It was also inconsistent with the UI workings of the rest of the emulators on the system. |
Beta Was this translation helpful? Give feedback.
-
|
I mentioned before that I was gathering the source code of all the apps available for miyoocfw, I have been adding them here https://github.com/MiyooCFW/apps but I would like to know your opinion before continuing. do you think it would be better to add each source directly with the physical files inside? because currently I have been adding it as submodules, which is a direct link to the original repository, but lately I thought: what if the owner of the current repository no longer receives pull-requests or does not generate builds? and the other problem is that most of the repositories do not have the files compiled in the releases, so they must be compiled by hand or obtained from external sources (google drive, dropbox, etc...) Do you think it would be a better idea if we go reuploading all the repositories there? and bring us the commits from the original repositories when necessary to each source code folder? |
Beta Was this translation helpful? Give feedback.
-
lol 😂 no, i just have bad experiences forking projects that are usually dead, removed, unattended, etc. also this github re-fork problem is annoying. Remember at the beginning i didnt intended to add any support for non-cfw stuff like apps/games/emus... Im just looking for the best way to hold them now due your interests. (because non-cfw stuff is not my particular interest) |
Beta Was this translation helpful? Give feedback.
-
|
Thanks :-) Also, after thinking about it for a minute I'm pretty sure that the reason GitHub blocks you from forking |
Beta Was this translation helpful? Give feedback.
-
|
I ran into exactly this issue when I forked |
Beta Was this translation helpful? Give feedback.
-
|
Yes, this is a rather silly limitation of GitHub. Nods. There's another very silly restriction/limitation on GitHub I discovered while I attempted to work around this. If you start a new depository and choose to upload the files, you can only upload up to 100 files at a time -- which is quite a ridiculous limit to set for uploading a Git repository! 😠 And it gets even wierder: to create a new folder, you need to also create a new file, and the process is not at all straightforward -- you need to add the new folder to the filename, using a trailing slash. Talk about neddlessly complicated and unintuitive. 🙄 Uploading the repository via Git is also needlessly complicated, now, on GitHub with the use of extra security measures/signatures required to upload to the site. 😥 But then again, GitHub is owned and run by Microsoft (since 2018), so what are we expecting? 🤷 😅 |
Beta Was this translation helpful? Give feedback.
-
Sorry, chipping in late on this one, but hopefully not too late: I suggest that these emulator/software forks be placed under a directory within the MiyooCFW org source. So, for example, "emulators/snes9x4d", "emulators/picodrive", etc. If this is possible to do. This way we'll keep it clean: emulator sources under "emulators", game sources under "games", etc. (just like on the system). Only the system related sources should be at the top/root level. |
Beta Was this translation helpful? Give feedback.
-
|
I haven't managed to track down the FBA source. Does anyone know from which source the current release of FBA on Miyoo was compiled from? The documentation says it's this one: https://github.com/retrofw/fba-a320 But I haven't managed to successfully compile this source for Miyoo. |
Beta Was this translation helpful? Give feedback.
-
I was able to get the emulator to show up on the display once I disabled double and triple-buffering, and switched the hardware surface to a software surface (the usual workaround). But it still crashes after displaying the loading progress bar, right at the start. So there's something else critical that is amiss, too. Something that's FBA-specific here, it seems. :/ |
Beta Was this translation helpful? Give feedback.
-
|
The upstream version won't run after compilation with either toolchain (it crashes during the loading process). The fba-miyoo-playable version compiles and runs successfully with the old (uclibcgnueabi) toolchain, but it has a sound emulation issue, which I'm currently trying to figure out. The sound is completely distorted -- like it's played/spoken loudly through a megaphone... :/ |
Beta Was this translation helpful? Give feedback.
-
|
Okay, it turns out that the sound problem with fba-miyoo-playable is isolated to CPS (Capcom) machines only. With other machines the sound works fine. Now I just need to figure out what changes were made to the Capcom machines' sound emulation. Edit: More specifically, it's isolated to CPS 2 (and CPS Dash) (QSound) machines. The sound in the original CPS 1 Capcom machines plays just fine. |
Beta Was this translation helpful? Give feedback.
-
|
I dug more into this, and it seems to be a long-standing issue with FBA in general, not this release of FBA. I'm not sure what was done with the bundled binary to fix this sound issue, but upstream doesn't have that update, those changes. I've tried patching the "miyoo-playable" source with the latest FBA source (0.2.97.43), with success, but even in there the QSound emulation seems to be lacking. I have one more idea: I'm going to try and patch the new QSound emulation from FBNeo into the "miyoo-playable" source. I have a feeling that that's what the person who compiled the currently bundled release of FBA for Miyoo did. |
Beta Was this translation helpful? Give feedback.
-
|
SUCCESS!! 😃 🎉 Yep, this is what the person did! Nods firmly. I've managed to patch it in, and QSound emulation works wonderfully now. 🥂 An updated FBA with a working source will be available for download from tomorrow. 👍 (Just need to upload it to GitHub. 😅 ) It has smoother visuals/screen-scaling than the stock/bundled version (thanks to Littlehui's work). I've fixed the buttons/controls to fully conform to current Miyoo standards, and I've fixed CFG file saving and loading -- so now the custom changes you make to the controls for each game in the UI are actually saved, and whatever manual changes you make to the values/settings in the config files will be respected and loaded by the emulator when you load the game. FBA no longer overwrites the tweaks you've manually made to a game config file. Saving and loading save states is still unreliable/botchy, like in the stock/bundled version. But now we have the source code to fix that and do a proper save state implementation. |
Beta Was this translation helpful? Give feedback.
-
|
Huzzah! We now have a fully working, updated FinalBurn Alpha for Miyoo, with source: FBA: https://github.com/Rezzy-dev/fba-miyoo-playable Binary download/build for convenience provided. (Note that this build/download is an update, so you'll need the emulator's original files to install this over them.) Based on @littlehui's work, the new build/release successfully runs on the system and features smoother graphics when screen scaling. I've also fixed/added customisable button mapping per game in the menu (that is actually saved), manually tweakable CFG settings, and updated controls that match the current Miyoo standards (correct A and B button behaviour, Reset button to call the menu). I've patched in full QSound support using excellent emulation for it from the FBNeo project, programmed by Ian Karlsson (with Valley Bell's help). Deep thanks to @Apaczer and @jSTE0 for your help, for our sharing and idea-bouncing -- it meant heaps ❤️ -- and everyone for the support. Looking forward to seeing what we can do with this source, where we can take FBA and its emulation on Miyoo! 🎉 There's lots of potential here, especially if we take into account the hard work of Team FBNeo and the huge resource that is the FBNeo project. So much outstanding work done there to build upon and improve FinalBurn -- much that can serve as fertile ground and inspiration for improving FB(A) and its emulation support on Miyoo. |
Beta Was this translation helpful? Give feedback.
-
Well, Miyoo devices have a fixed resolution screen of 320 x 240 px. The arcade machines that FBA emulates had a wide range of different resolutions, usually higher than this -- some a little higher, some up to double. So the result will vary between different games. Cadillacs and Dinosaurs shows quite a difference, for example, between the stock bundled FBA and this improved version. But you do have to keep in mind that we are working with downscaling to a lower resolution screen -- so it's not a super-fantastic difference. It just makes certain texts actually readable, and the graphics a little smoother -- showing more detail. It's a very small difference to see with the naked eye. Your best bet is to take screenshots and compare by overlaying the two images. But yeah, the new scaling method does make details easier to see and text more readable.
I wasn't aware there was such a menu in FBA. How do you access it? 😕 These changes can be made manually in the game's config file, now, too. |
Beta Was this translation helpful? Give feedback.
-
Metal Slug is a Neo Geo game, so it will have the native resolution of the screen (320 x 240 px, actually 320 x 224 px to be precise). Like Sega Mega Drive games, Neo Geo games match the Miyoo screen perfectly. With The Punisher you should see a little difference -- although it's not very noticeable in that game. The Punisher has a resolution of 336 x 240 px -- so 16 more pixels horizontally than the Miyoo screen has. (Which is not much space to work with in terms of antialiasing.) |
Beta Was this translation helpful? Give feedback.
-
I believe you can see it only when launching FBA without gmenu2x ROM selector (directly to app).
Yup , I though it may be the case here 👍 , but strangely I tried now with Cadillacs and Dinosaurs and still see no difference in output image (I did two screenshots to be sure and they're identical). Sorry for drilling this thing down, but I find it interesting to have new filtering method on FBA emu. Could you check again back&forth if you see any image mismatches between two releases (image comparison will be appreciated 🙏)? |
Beta Was this translation helpful? Give feedback.
-
Ah! That explains why I never saw it. 😅 (I consider that internal UI unusable. 😜) Is the button mapping still switched there? I thought I had done a thorough job covering all map-cases, but it's possible I missed this instance in the source. Will have a second look. If you find it and fix it, send the changes back upstream and I will pull them in.
It's okay, you're not drilling -- it's a sensible question. Will do. And I'll try to find the section in the code where I saw this specifically implemented. I remember seeing different scaling/rendering methods used for different arcade machines to optimise the scaling/graphics. I wish I had made a closer note of it then, but I was focused on fixing the QSound. I remember that as soon as I launched Litthehui's version, I imediately saw the visual difference, and I confirmed that when I switched back to the old build to check if the two builds were in sync in terms of their visual features/UI. When I switched back to the old build, I remember noticing the sharp pixel distortions again in the scaling, and loss of detail. It's possible that it applies only to certain arcade machines. I'll have a deeper look into this and let you know. And I'll see if I can give us a direct visual comparison. |
Beta Was this translation helpful? Give feedback.
-
|
Another interesting thing to note here is that @littlehui has implemented volume level control/adjustments for the machines to bring them in sync in terms of their audio volume level, too. I haven't managed to hook this up to the new QSound implementation yet, but it's certainly something that can be patched in in the near-future, and the volume levels can be aligned across machines. |
Beta Was this translation helpful? Give feedback.
-
|
I'll just make a mention of this here: I've found an updated/revised version of the MAME4All source here: https://github.com/goldmojo/mame4all This version has the annoying startup "OK" and other MAME message dialogs disabled, and, more importantly, has a command line running implementation added to the software -- meaning that MAME4All can also run like any other emulator on the system, loading ROMs directly from the system's main menu. I think it will need the Makefile from the original source code to compile it for Miyoo (as it's missing it): https://github.com/steward-fu/miyoo/releases/download/v1.2/mame4all.7z I haven't given it a whirl yet, but I thought I'd mention this here, just in case I don't get around to building and testing it. Unfortunately it's still MAME4All, so it's still based on the old MAME 0.37b5 source -- which means that it only runs classic arcade machines (such as Pac-Man, Galaxian, Frogger, etc.) from the 0.37b5 ROMset (year 2000) well. But that is a good purpose (use-case/application) for this emulator -- we do need a classic arcade game/machine emulator on the system. |
Beta Was this translation helpful? Give feedback.
-
|
For anyone having trouble getting the sound working in MAME4All for some of the classic arcade games, it's because this early version of MAME -- and, for some games (like Space Invaders), even later versions of MAME -- can't produce those sounds via emulation, so it needs these sound file packages for the sound to work: https://samples.mameworld.info/ (Check both the "Older Samples" and "Current Samples" list/archive.) These ZIP files need to be placed in "/mnt/emus/mame4all/samples/". After that the full audio for these games works. I don't think there's any reason why we can't bundle all these soundpacks with MAME4All (so that the user doesn't need to download them and set it up). To my best knowledge, they are public domain. It may increase MAME4All's size by a bit, but I don't think that's such a huge issue on an 8 to 64 GB SD card, and it greatly enhances MAME4All's reliability/usefulness. At least the main gaming classics should be included: Space Invaders, Asteroids, Donkey Kong, Donkey Kong Jr., Mario Bros., etc. That won't bloat the size much. |
Beta Was this translation helpful? Give feedback.
-
|
Pico-8 (Fake-08): https://github.com/jtothebell/fake-08 Latest binary builds/downloads (experimental): https://github.com/jtothebell/fake-08/actions |
Beta Was this translation helpful? Give feedback.
-
The links to the source code for the FCEUX and PokeMini emulators are missing from this main landing page and repository. Where can the Miyoo sources for these emulators be found? Searching for them online bring up a number of different repositories, with no clear match to the builds/binaries used in this distribution.
Beta Was this translation helpful? Give feedback.
All reactions