2.0 Beta Dev Status

[TriForceX]

Many people wonder when the next release will take place, if the project is abandoned, etc ... So i will leave here a list of the current status of the project, and in which progress is being made.

Note: Difficult level is based on how much time is required to be changed or applied.

Next release

Status	Difficult	Task
✅	High	Make fully working & clean source code (This means more frecuently updates)
✅	High	Fix screen-tearing (Experimental)
✅	Low	Update boot stock logo (NXHope) to MiyooCFW logo
✅	Low	Add current version to boot logo
✅	Low	Add SD card custom icon for PC drive
✅	Low	Add version info on GMenu2x settings info
✅	Medium	Fix text overflow on file explorer when screenshot preview is enabled
✅	Medium	Add L2 and R2 support for Powkiddy V90
✅	Medium	Add Plus-Sign/Secondary button support for Powkiddy Q20 and Q90
✅	Medium	Configurable internal clock (useful for time-based games)
✅	High	Create an universal image with auto-detection for all devices
✅	High	Add auto-expand storage for Main partition on first boot
✅	High	Update battery driver to allow more parameters (like the charge status)
✅	Medium	Add option to disable battery warning
✅	High	Add XYC Q8 / SUP M3 console support (Experimental)
✅	High	Allow CFW install on 1bit consoles (No hardware mods required)
✅	High	Add TV Out feature
✅	High	Updated GMenu2x main front-end
✅	High	Add data sharing & communication through USB (OTG)
❌	High	Create a proper website for all homebrews, emulators and apps (DELAYED)

Futher releases

Difficult	Task
High	Add IPK/OPK support (maybe?)
High	Add an auto-update script for CFW
Medium	Change low battery warning method
Medium	Update battery driver to allow more parameters (like the charge status)
Medium	Add text-to-speech feature
Low	Add sound effects on GMenu2x interactions
Low	Add background music on GMenu2x

Theres another thread to discuss more futher updates/improvements here

[nfriedly]

I feel like this is an awful lot to try and do all at once. What do you think about working on a series of smaller, more incremental releases?

[TriForceX]

You are right, ive update it now. Thanks!

[nfriedly]

What about the "create a proper website" one - I like it, but does it really need to block shipping 1.4? I feel like they're a bit orthogonal.

[Rezzy-dev]

I can help with creating the website -- I have professional web design and development experience -- and I agree, the website shouldn't delay the release schedule for the firmware. Having clearer access to all the software is great and desired, but it does not need to delay the progress of the firmware development itself. In fact, future releases of (or updates to) the firmware should better aid faster and easier software development for the platform -- such as device type identification.

[SDGames94]

I'd be happy with just the extra 2 triggers on the v90 pretty please!! ^_^ When will that update be released? thanks

[TriForceX]

You have 2 options, wait for the release or compile the source code youself (the kernel module in this case)

I cannot give you estimated time for release because i just work on this project on my free time. There is no development team behind this, is just me and some people who help me testing stuff...

[Rezzy-dev]

Top priority: gather and upload/bundle missing sources! #260

Make it a policy to bundle/release/preserve the source code for everything that is compiled for and released with this CFW.

There will be no long-term and fast progress if the source code remains missing/private/closed for key parts of this project. And the emulators are the very heart of it!

The future and progress/development of this project -- of any free and open source project -- depends on how we preserve and share our source code. If it's not shared, easy to find, and available, it's not open. And it won't make strides and won't survive long.

[TriForceX]

I agree with you, is an important task ive been working on (i dont want upload the next release without that), but putting it all together takes time, time i usually dont have because real-world job + family 😅

There are almost 30+ source codes im putting all together in one place that will be available for everyone for the next release, so it will happen 👍

Edit; You have to understand the priority will always be "the CFW", the "apps" are a secondary thing (i cannot handle everything myself), sadly the current mess wasnt my fault, and it's a mess that has been creeping up on since the project started.

[Rezzy-dev]

I understand, now. TriForce, if there's anything I can help with, let me know! I'm sure that I can help you gather, prepare, and upload the source, and I have more time on my hands currently. I'd love to see this project go forward.

I think it would be wise to take it step by step, and the most crucial software for this platform are the most widely used emulators that are currently missing their source: PicoDrive (Sega Mega Drive), FCEUX (NES), Ohboy (Game Boy & Color), MAME4All (arcade), FBA (arcade), GnGeo (Neo Geo), and Stella (Atari 2600). We should start with these, and then gradually expand to the rest. This way it's not 30 we're talking about, but a key 7-10 or so at first.

After testing all the emulators on the system on the fastest hardware that it runs on, currently, it's clear to me that this system emulates the Sega Mega Drive (Genesis), the Game Boy (Color), the Neo Geo, and the Atari console line best, with the highest accuracy and smoothest performance. It also emulates arcade machines quite well (using a combination of MAME4All and FBA). This, along with the popularity of the retro games for these systems is my reasoning for the above prioritisation. Let's handle the mainstream, most widely used emulators on the platform first. This way we can take things step by step, in smaller bites, and not try to do everything at once.

[salvacam]

@Rezzy-dev, It will be impossible for all applications or emulators to have available source code, there are developers who do not want to provide the source code, especially in games.

Also, if later there are no developers who use the source code, then I do not think it is the highest priority, although it is necessary to try to have all the source codes available, but I do not think that an application should not be added to the cfw because it does not have the source code available.

He did not say it for me, everything I have done, for Miyoo and for microcomputers and for the web I have published on github or gitlab

[Rezzy-dev]

This especially applies to GPL licensed code/applications. The General Public License legally requires you to share what you've built upon that work the same way as you've obtained it:

https://en.wikipedia.org/wiki/GNU_General_Public_License

[Rezzy-dev]

So if we're using emulators/applications built upon GPL-licensed code, and we don't have the source code for them available, our distribution is actually illegal/pirated.

[Rezzy-dev]

DOSBox, PicoDrive, FCEUX, Gambatte, GnGeo, GPSP, MAME4All, OhBoy, PCSX-ReARMed, GMenuNX -- these are all copyrighted and copyleft/GPL licensed software. If you make modifications to these, and build a new binary from them, by law you have to distribute the source code for that binary as well.

Free and open source (GPL licensed) is not public domain (do what you want with it). There's a big difference. These software still have copyright on them, and the copyright holder has decided to use their rights over the software to protect the free use and sharing of their work. (Copyleft, protecting free use and sharing, instead of copyright, protecting private ownership.) So these software are free to create derivative works of provided you share your source code just as openly!

You cannot build upon these software, this code, and claim is as your own private property. Whatever you build upon it has to be shared the same way you received this code.

[Rezzy-dev]

The only exception to this is MIT licensed software -- which require you to officially acknowledge the original author of the software, and their copyright over the code/software, but permit you to create derivative works of the software and call it your own property, to do with as you will. But none of the above software are MIT licensed! Not even the operating system (OpenDingux) itself! They're all GPL -- legally required to be openly shared.

[Rezzy-dev]

You can think of it this way:

With regular, proprietary, copyrighted work, if you use the work without the author's permission and share it, you're breaching the law, you're pirating.

With GPL licensed work it's the total opposite -- you can use the work any way you like, without asking for explicit permission, but if you don't share what you create based on that work and instead hang onto your source, and only distribute the compiled/finished product, you're breaching the law, you're pirating. Because the author released the work with the legal license and intention that it will continue to be built upon and freely shared. So not sharing the source to your modifications (derivative work) goes against the legal permissions the author gave you to use their work.

[salvacam]

@gameblabla made many ports for Miyoo, maybe one of them is here https://gitlab.com/users/gameblabla/projects

[Rezzy-dev]

Yess! It looks like this is where the PokeMini for Miyoo came from. I think some of the ones we're missing from @steward-fu source are here -- as well as many of the game ports. (Thank you!)

[MiyanoOsu]

[Rezzy-dev]

Could you add an option custom keymap for menu of emulator like picodrive? bc some emulator in powkiddy Q90 using cfw miyoo are wrong menu keymaps (keymaps in game is available to change).

I'm already addressing this issue separately here:
#260

This is out of the scope of the Miyoo CFW, and up to the individual emulators, as each handles this in-menu key binding differently. I'm calling it the "A-B button fix", or "switched buttons" update.

All the current sources for the emulators need to be found and updated, so that instead of using the old BittBoy button layout, they use the new, PocketGo/PowKiddy layout.

I've found and fixed PokeMini, PicoDrive, OhBoy, and Handy so far. I'm having trouble compiling the FCEUX source. Any help is welcome and appreciated.

[Rezzy-dev]

Figured out FCEUX on my own. Current source and update/fix coming shortly. ^_^

[Rezzy-dev]

FCEUX and its code has been updated/fixed, too: https://github.com/Rezzy-dev/fceux ;) ^_^

Correct A and B buttons are working now, updated binary download provided, and the source is easy to compile. :)

[Rezzy-dev]

Create an universal image for all devices

How is the different button layout between BittBoy and the other devices going to be handled in software that is released for all devices? Is the PocketGo (post-BittBoy) layout going to take prefence now (since there are more devices that use this layout), or will software need to be rewritten to support both button layouts?

What wll be the approach/policy/guidance here?

How will software know what device it is running on?

[nfriedly]

I may take a stab at one of the "display the version" items on the checklist - how do we want to handle the nuts-and-bolts of that?

I'm thinking that maybe https://github.com/MiyooCFW/mainboot/blob/master/generate_image_file.sh should use the current git tag or hash as the version, and stick that in a text file, then gmenunx can read it to know the version of the CFW.

I'm not sure about uboot, though - perhaps it can read the same text file, but maybe we need to just bake it in at compile time. What do you think?

[Rezzy-dev]

Agreed! Nods firmly. I'm not sure why the changes were made. I tend to go by the philosophy: "If it ain't broke, don't fix it!" ;)

There's no point in making compatibility-breaking changes unless it is absolutely necessary in order to make significant progress forward (and even then, backwards compatibility should still be considered). I'm not sure that here qualifies as such. :/

[nfriedly]

Ok, this fixes the layout default layout issues: MiyooCFW/gmenu2x#16

I'm now pretty confident that our copy of GmenuNX is also missing some modifications that were shipped in v1.3.3 - in particular, there doesn't seem to be any code to render the bottom status bar. Instead the icons are in the top and it just doesn't show the long description anywhere when there are multiple columns. (The 1.3.3 gmenunx shows the long description in the bottom bar for a second or two.)

Regardless, with my layout fix, I'd consider it to at lease be shipable now.

[Rezzy-dev]

Have you tried using the different layouts? Because some layouts in GMenuNX will force certain UI features to behave a certain way (for example force all indicator icons to be at the top, and/or remove the status bar). Make sure that you try using the "Classic", horizontal layout as well for the currently selected skin.

Skins don't have power over the GMenuNX layout modes/functioning in GMenuNX's layout engine. In fact they rely on the layout engine's positioning/display of its UI elements, they work on top of it. They're dependent on the currently selected layout mode.

[nfriedly]

Yeah, I dug into it a bit and realized that there is a separate rendering mode when there is only a single column of shortcuts vs multiple columns. And, that mode had a couple of issues:

1. The first was that it didn't account for the width of icons when writing out the name, so it always drew the icon on top of the text. That required a code change to correct.
2. The second issue was that it defaulted to 6 rows and showing the extended description, but there just wasn't room for that on the screen. However, reducing it to 5 rows did allow enough room, so I just changed the default. You can still recreate that part of the issue if you change it back to 6 in the settings.

(Section bar on top vs left doesn't have any effect, the bugs were still there regardless. There isn't a "classic" option when built from source.)

I also compared this to the GmenuNX binary from 1.3.3 and it doesn't have the first issue - it correctly moves the text over to make room for the icon, and it doesn't have the second issue with 6 rows, but it does start to show up at 7-8 rows, so maybe it's using a slightly smaller font size or something?

It's kind of frustrating not having the source code for the previous release. Instead of improving it, we're wasting time fixing bugs that have already been fixed.

[Rezzy-dev]

Agreed. Nods firmly. That's why we're trying to gather and consolidate all the source code, now, and bring everything up-do-date and make it easy to use and accessible to everyone going forward. (At least that's what I've been trying to do with the main emulators for the system.)

[DoctorOey]

Hi,,,i have advice , Waitting time for all update is very long. Could you release the existing update now as bug fix, i mean it would be fix user problem sooner than waitting the version is completed take much time
Miyoo 1.3.7 maybe and for the complete version is 1.4.0.

[nfriedly]

I feel you. It's coming along as fast as possible. We've already pared back what we want to include in the next release in order to ship it faster, but there are some gotchas that mean we can't just update one or two components, we basically have to rebuild the entire thing.

[Rezzy-dev]

This is being worked on with passion in people's spare time, and while we ought to aim for certain targets/deadlines to keep moving forward efficiently, we should all be flexible and patient. Nods.

If anyone wants to join in and work on aspects of the project to help it along quicker, they're welcome to. That's what free and open source is about, and that is its strength: open and shared community effort/progress. We all play an active part in when the next official version is ready for release. In the meantime, the current code and state of the project is always available.

[TriForceX]

Ive rejected any cfw update that came after 1.3.3 due the "old process" to make the cfw packages was a complete mess, so making a new 1.3.4, 5, 6, 7 etc... using the same "old process" will cause the cfw stability more worsen than it already is.

Many people doesnt know about that, but 1.3.3 and previous releases had mixed system files carried from the previous releases, some of them with unknown sources, so there are some bugs (and there can be more) that we cant recognize due the mess.

I know how it feels waiting long time without updates, but i also know that doing the things using the wrong methods can cause any project its extintion, thats why i wanted to get some support to improve the methods and make a new stable release... the big problem is everyone wants a release, but no one helps to get it, just wanting something and giving advice from current issues is not a big help in the end. Theres no a team behind this, is just a couple of people who is trying to do something on their free-limited time.

I hope you can understand the current situation.

[CricioZ45]

Hello, I saw that the status of the new version is at 90%, is there any prediction of when it will be completed?

[akg83]

@TriForceX not being a firmware developer, but just asking.. what is currently missing in order to complete what's needed for release 2.0 ? I know that I can also compile the nightly, but I think only once this version is officially complete and released, that it will be stable enough to replace my current CFW with. I wish I could help (maybe I could? I have software development experience in general, just not in FW development)

[RUANRUI1995]

Thanks a lot!

[RUANRUI1995]

What is pocketgo-te means by the way?

[RUANRUI1995]

This is a build for PocketGo with support of TE (screen synchronization) pin. Effectively you have no screen tearing with it. It cannot be used with other devices because of different PCB layout.

I select this device and it runs well.It's that means my poketgo supprt TE pin?

[szymor]

If it runs well and you see no screen tearing, then yeah.

[Apaczer]

@szymor said it - your HW should support it, otherwise you will get blank image.

It's the Tearing Effect output line (O) pin of the ST7789S display. It modifies and ensures that the microprocessor's Frame Memory write is synchronized with LCD Panel read or you will have overlapping frames.

There are other ways to eliminate screen-tearing (see TEfix setting in gmenu2x), but if possible you should use PocketGo-TE instead (mostly for performance reasons). We were not sure if all PocketGO revisions support it, thus left that optional to enduser. Big thanks to @tiopex 👍 and others for making it a reality.

[RUANRUI1995]

TEfix setting in gmenu2x should set to 0 if use the pocketgo-te device?I guess 0 means off.

[RUANRUI1995]

I am wondering if we can show device type somewhere?Like gmenu2x about text

[Apaczer]

TEfix setting in gmenu2x should set to 0 if use the pocketgo-te device?I guess 0 means off.

Yes, however if you use pocketgo_TE variant, then this setting have no effect.

I am wondering if we can show device type somewhere?Like gmenu2x about text

We could! For now, the device type in use can be read from /boot/console.cfg or /mnt/log.txt

[thogi99]

Can someone point me to info on what is needed regarding "Create a proper website for all homebrews, emulators and apps"? This is one area that I do have some expertise on and would be glad to assist.

[havhav31]

Will v2.0 ever be released? I've grown old waiting

[ash2822]

you can just download a build from the actions tab, i'm already using it. But yeah i dont see why we need a website for the new version to be launched XD

[Carlos1Costa]

Hi @TriForceX :) I was wondering if there was anything I could help you with for the release of version 2.0 (I have experience with embedded Linux), and I found this list saying that just a website is missing. Is there any beta image available? Do you guys need any help?

[Lambku]

cfw 2.0 release date?

[oliveruh]

Hey, do you guys need help with the website? I have experience in web development. Is there a repo for it yet?

[TriForceX]

Website was delayed due personal reasons (basically no time to upload yet) but is going to be uploaded here: https://github.com/MiyooCFW/miyoocfw.github.io

The website is made in Angular 12+ (Basically HTML, CSS and JS) and content will be shown from official Wiki guides (markdown format)
For the moment follow the repo to get notified when is uploaded. Thanks!

[TriForceX]

Since Version 2.0.0 Beta Pre-release is out this topic is being closed. Many thanks to all people who contributed!

Any futher conversation will be on the Version 2.0.0 Beta topic here