Closed anzz1 closed 1 year ago
irixxxx
commented
1 year ago Looks like the zlib detection isn't working correctly. Post me the config.mak and config.log files after configure.
Additionally, to support this, please try adding "--with-zlib=yes" to your configure command.
anzz1
commented
1 year ago Thanks for a quick reply!
The build script isn't using configure, as the autoconf/automake tools can be very bad especially in a cross-compile environment. It uses the Makefile.libretro directly instead.
This is the Makefile build script and this is the 1001-miyoomini-build.patch applied to the Makefile.libretro to add the miyoomini platform. I suppose the DONT_COMPILE_IN_ZLIB flag doesn't work anymore?
It's strange, as the Makefile.libretro didn't change. By all accounts it shouldn't have broken, but somehow it did.
irixxxx
commented
1 year ago The picodrive configure script is rather baroque. It's not using autoconf et al.
And no, DONT_COMPILE_IN_ZLIB indeed isn't working anymore. It's a leftover from old times.
The libretro frontend apparently always uses the embedded zlib. Sorry, I wasn't aware of that.
Try adding PLATFORM_ZLIB = 1 at line 707 of Makefile.libretro, before the include line
irixxxx
commented
1 year ago Please check if the current master fixes your problem.
anzz1
commented
1 year ago It does indeed! Thank you very much for your quick responses and fix! :+1:
I commend you and the other authors on your great work on this core! After getting my hands on a Miyoo Mini+ handheld console, I instantly got around to tinkering with it and found out that from all the libretro cores, picodrive and pcsx-rearmed stood as best among the rest. Was quite amused to find out that many of the same developers worked on those, and also with picoarch and libpicofe projects which the current frontend I'm using, MiniUI / DotUI, heavily relies on. So kudos for making all this possible :smile:
The core is really well optimized and I recognize that it is really well made under the hood. It not only runs at full-speed on this rather low-powered device, but it runs at 200%+ speed. This is a great achievement, and not many people understand or appreciate that running at full speed is not the end-all-be-all, that being able to run at 200% is very different than 100%. Even if you don't care about fast forward, using half the CPU power to run at 100% means using less than half the energy, which directly translates to greatly increased battery life.
The current core is very stable and pretty much feature-complete from what I can tell, it has had zero problems running anything I've thrown at it, be it MegaCD/32X/Megadrive, no crashes and savestates work 100%, even the RAM cart for MegaCD works and some random prototypes I tested. The only exception was some random 32X test cart ROM, which I can't be sure is even real or properly dumped nor if it even runs on original hardware and it's definitely something that does not carry any significance.
As an added bonus, the latest master (3a77090514c3ba3c1a0286a046bc9fe323e07f27), based on quick and very much non-scientific comparison runs ~5% faster than the earlier build (ae9a76c90d8405623b433dfaa20959d23cc46ac8) I had on my device to compare against. :partying_face: All while compiling to a binary of < 2MB.
I'd like to bend your ear about something though, as I've been thinking about the current build process of the DotUI frontend I'm working on. The way it currently works is that it pulls and has patches for the picoarch repo which in turn pull and has patches for the different cores, including this one. It works pretty well as-is but it's a bit more complicated than I'd like.
I understand the original idea behind it, to not burden the core maintainers with an additional platform to maintain and while having a good mix of platform compatibility in the makefile of the base repo is a nice thing to have, I also have seen on many cores how adding a thousand different platforms to the base repo can quickly devolve into an unmaintainable mess where no one has known for years if the compiler flags are actually correct or even if it builds at all. Especially hard when the platform was initially added in some random commit way back when with zero documentation on how to actually build it and the toolchain required, so no one can even check.
That being said, as this repo is very well suited specifically for ARM devices and already has support for many similar low-power ARM handhelds already, do you think that in this case it would make sense to add the miyoomini support from this patch to this base repo? With you being the ARM wizard, you'd be better equipped to understand if the compiler flags are correct, or if some new optimizations would need changing them. I understand this would be a added burden and it's completely your call. I already noticed that the patch uses -march=armv7ve and not -march=armv7ve+simd to enable the additional SIMD instructions the chip supports, and not sure whether it's a conscious call or an error.
The target platform is a SigmaStar SSD202D SoC with an ARM Cortex-A7 and 128MB of DDR3 RAM. There are two iterations of the device, the Miyoo Mini and the Miyoo Mini+, but for all intents and purposes they are the same device.
anzz1
commented
1 year ago Offtopic warning, lengthy post ahead, not directly related to this issue
By the way, if your interests in writing optimized ARM code aligns with retro handhelds too, I highly suggest picking up the Miyoo Mini+. At 70 US$ it's a steal for what it is, and it's a great platform to work on. It's still early days regarding the development on it, but the addition of the wifi module to the new iteration of it vastly improves the development workflow. By replacing the stock OS you can run it with 100% open-source code, and even completely replacing the firmware/bootloader/kernel is possible without any hardware modification if you wish to do so.
If you are interested, one such open-source OS for it is the DotUI , (or my current development fork of it).
I've only had the thing for a couple of weeks and have yet to see if debugging with gdb thru wifi would be viable, but it certainly could be.
Particularly I'm currently interested in porting the CPS-1/CPS-2/CPS-3 and NeoGeo cores with ARM optimization. They are all based on very similar architecture to the Megadrive/Genesis, using the M68K, Z80, SH2 and YM2610 chips, for which the optimized arm asm drc's already exist. So all the pieces are there, and all the hard legwork is already done, it's just that no one has put them together. There have been attempts to add the Cyclone68000 cpu at various times on the various FBA/FBNeo lineages, but after doing a pretty exhaustive search it hasn't been done properly at any point (to my knowledge).
I tried to piece together something working using an older FBA build as base, adding various patches/fixes from different lineages/revisions and replacing the C "Musashi" 68K and C Z80 cores with Cyclone and DrZ80, to no avail. I got it working somehow, but CPS titles were hit-n-miss and NeoGeo worked pretty well unless savestates were involved, and it still had intermittent crashes. The various issues posted pointed to the Cyclone core as being the culprit, but as that works well in other contexts (like this one), that is probably not the case. I think instead the bugs stem from FBA itself but the Musashi cpu just happens to mask them, so it works. I eventually gave up trying to pinpoint the issue since the FBA codebase with a development spanning over two decades tracing all the way back to the first MAME release, with hundreds of developers working on it, fractured lineages and the monolithic design has lead to a very messy codebase which is hard to work with and most of it would need to be rewritten to achieve any kind of optimized code anyway.
So my conclusion was that it would probably be easier just starting over. If you have any pointers for a slimmer codebase to start on or any other helpful knowledge on this path, that'd be greatly appreciated. I am pretty well versed in C and x86 assembly, but not at all on ARM assembly. But as the hard parts of creating the cpu dynarec cores is already done, I figured I could be able to put this together, as I surmise that C knowledge is enough to put the parts together, deep knowledge of ARM assembly not required. And for debugging, at least some of the x86 assembly experience carries over so fixing a bug or two could be possible with a shallower understanding of the ARM architecture.
And sorry for the off-topic wall-of-text :sweat_smile:
irixxxx
commented
1 year ago Fixed with 3a77090...
irixxxx
commented
1 year ago I commend you and the other authors on your great work on this core! After getting my hands on a Miyoo Mini+ handheld console, I instantly got around to tinkering with it and found out that from all the libretro cores, picodrive and pcsx-rearmed stood as best among the rest. Was quite amused to find out that many of the same developers worked on those, and also with picoarch and libpicofe projects which the current frontend I'm using, MiniUI / DotUI, heavily relies on. So kudos for making all this possible 😄
Thanks for that... I stand on the shoulders of giants as well, though!
The core is really well optimized and I recognize that it is really well made under the hood. It not only runs at full-speed on this rather low-powered device, but it runs at 200%+ speed. This is a great achievement, and not many people understand or appreciate that running at full speed is not the end-all-be-all, that being able to run at 200% is very different than 100%. Even if you don't care about fast forward, using half the CPU power to run at 100% means using less than half the energy, which directly translates to greatly increased battery life.
I took great care to not make picodrive slower with all those fixes and extensions. Nonetheless, more accuracy has a price... it has gotten very slightly slower since notaz' latest 1.93 release for megadrive and megacd. You won't notice any of that on modern devices though, on those it's in the sub-1% range.
OTOH, 32x has improved greatly. It's much faster than previoulsy, and much more correct as well as I conducted thorough testing. I think in term of quality there isn't much difference between the SH2 drc and the interpreter anymore.
The current core is very stable and pretty much feature-complete from what I can tell, it has had zero problems running anything I've thrown at it, be it MegaCD/32X/Megadrive, no crashes and savestates work 100%, even the RAM cart for MegaCD works and some random prototypes I tested. The only exception was some random 32X test cart ROM, which I can't be sure is even real or properly dumped nor if it even runs on original hardware and it's definitely something that does not carry any significance.
Well, it's not flawless. I know of a few having graphics glitches... sometimes they are so minor you wouldn't probably notice, though.
As an added bonus, the latest master (3a77090), based on quick and very much non-scientific comparison runs ~5% faster than the earlier build (ae9a76c) I had on my device to compare against. 🥳 All while compiling to a binary of < 2MB.
I changed the set of optimization flags for the C compiler to a more modern one if the gcc version is recent enough. Especially LTO optimization is quite effective on newer versions.
[...] That being said, as this repo is very well suited specifically for ARM devices and already has support for many similar low-power ARM handhelds already, do you think that in this case it would make sense to add the miyoomini support from this patch to this base repo? With you being the ARM wizard, you'd be better equipped to understand if the compiler flags are correct, or if some new optimizations would need changing them. I understand this would be a added burden and it's completely your call. I already noticed that the patch uses
-march=armv7veand not-march=armv7ve+simdto enable the additional SIMD instructions the chip supports, and not sure whether it's a conscious call or an error.
I'll have a look at that. The patch needs some revisiting though, there are duplicate flags in it, and I doubt some of them actually do anything positive for performance.
By the way, if your interests in writing optimized ARM code aligns with retro handhelds too, I highly suggest picking up the Miyoo Mini+. At 70 US$ it's a steal for what it is, and it's a great platform to work on. It's still early days regarding the development on it, but the addition of the wifi module to the new iteration of it vastly improves the development workflow. By replacing the stock OS you can run it with 100% open-source code, and even completely replacing the firmware/bootloader/kernel is possible without any hardware modification if you wish to do so.
I already have a large load of handheld devices to test releases on, ranging back about 15 yrs - just look at the list on the releases page. Hence, I rarely acquire devices, most of the newer devices in my possession have been donated directly by the manufacturers. So, if you happen to have a contact to them, drop them, or me, a note.
Commit 110a49ed2a4941bda1b75beacd73ec4df66391c2 breaks build on picoarch, the one before works fine. This is when cross-compiling for ARMv7 (-march=armv7ve+simd) on a x86_64 host.
As I know it can be very painful to set up different build environments, here's the whole process containerized. Nothing external required other than Docker or Vagrant/VirtualBox.
A) Using Docker (Linux, MacOS, x86_64, ARM64)
B) Using Vagrant / VirtualBox (Windows, x86_64)
GCC
GCC Version:
arm-linux-gnueabihf-gcc (GNU Toolchain for the A-profile Architecture 8.3-2019.03 (arm-rel-8.36)) 8.3.0GCC Error Log:Picoarch repo https://github.com/shauninman/picoarch/tree/ab7f0294377178a2db77d4adf44e7691f532f1a1