Dingoonity.org

Hello Gamablabla, wow, this is a major update ! Your post is much technical, as firmware porting is still an obscure subject for me. It seems you have done a real amount of work, many thanks for doing it. Not sure everyone will understand what you've done ! I have a few questions not directly related, but it is still about software development for RS97. First, is the SDL2 library supported ? I can only see source codes based on old SDL 1.2. Then, do you know if OpenGL is supported ? I had no success trying to compile with these two libraries. Thank you !

Hi Gameblabla, nice work on that one.

I hope there will be more improvement with the firmware, like adding ipu support, as well as scanline option if possible.

Regarding FBA, I guess you could look at porting NJEMU from PSP https://github.com/phoe-nix/NJEMU
There's support for CPS1, CPS2, NeoGeo and NeoGeoCD and the speed is really good on PSP as long as the game doesn't use rasters.

Those emus where the one that were used on the original dingoo A320.

I hope FBA could be readded at some point since there are some nice cave shooters for it.

Thanks for everyone involved in that project !

First, is the SDL2 library supported ? I can only see source codes based on old SDL 1.2. Then, do you know if OpenGL is supported ? I had no success trying to compile with these two libraries. Thank you !

SDL2 has no software renderer and is impossible to be supported. The RS-97 has no 3D hardware and the 2D hardware is not supported, only a framebuffer is. SDL2 requires to be able to set up an EGL context and that requires hardware acceleration.
It is possible to compile it with DirectFB but you'll get a black screen no matter what.
OpenGL is also not supported. In theory, a Mesa3D software renderer is possible, however that is undesirable, will be ultra slow and thus useless. It will also severely increase the rootfs size for something that is ultimately useless.
Closest thing we have to 3D is TinyGL and unfortunately, it's pretty primitive. (take the one from my blockout source)

I hope there will be more improvement with the firmware, like adding ipu support, as well as scanline option if possible.

Steward is working IPU support, at least he was... I got no words from him since a week or so. I must note that i am unable to compile a working linux kernel due to missing LCD drivers.

Regarding FBA, I guess you could look at porting NJEMU from PSP https://github.com/phoe-nix/NJEMU
There's support for CPS1, CPS2, NeoGeo and NeoGeoCD and the speed is really good on PSP as long as the game doesn't use rasters.
Those emus where the one that were used on the original dingoo A320.Would it be possible to have the port to the Dingoo ? I couldn't find it and porting the PSP work would be a huge amount of work. (not to mention its CPU is not directly compatible with mips32)
I found this old CPS2 emulator for the GP2X with the released source code : https://github.com/gameblabla/cps2emu
Unfortunately, even that won't properly work on the RS-97 due to issues with broken code being used for loading cache files...

This is going to be a lot painful.

Great! As soon as this cfw will support also 1.0 and 2.0 revs I will add it to the "Ultimate" RS-97 Guide

Sure, it's among my plans.

Thanks guys, i lost many nights trying to fix FBA SDL & GCW0, to no avail... If slaneesh could release his source code for the Dingoo port of FBA, that would also help because he never released it...

Unfortunatly njemu port were released on original firmware for dingoo A320 by the dingoo manufacturer so no sources were ever released. Plus I guess it was compiled for ucos. The port was also a bit different from the original since cache files were embedded into a file (.mvs or .cp2) rather than being in a folder.

I thought PSP and RS-97 were closer on an hardware side in fact.

It turns out the CPS2Emu is actually based on an older version of NJEMU !
NJEMU has also no assembly lines of code, making it much more useful. However, it still uses too much PSP specific code so i used it as a reference to fix the cache code. Doing so led to CPS2 games now booting up and running just like it does on PC.
I'll work more on CPS2EMU and hopefully release it.
Sadly, it has currently no sound and i completely suck when it comes to this. Hopefully it's an easy fix... (i don't have sound with the SDL version either)

I'm pretty sure you will end up figuring it out

And i did figure out the issue :' ) Turns out sound was not enabled by default... Stupid right ?

I have a released a new firmware version with a newer partition layout and the CPS2 Emulator.
I also have added a firmware image for revision 2.0/1.0. Be warned that it might not work, since i don't own that revision.

Other than that, no changes. if you don't care for the newer partition layout, then grab the update pack which adds the CPS2emulator to GMenu2x. Reboot after applying the changes.

I must add that the CPS2Emu has some issues : First bootup will take some time (it needs to create a cache file on the console), it copies the rom file a second time and not all games were tested yet. I got it to work with Eco Fighters, complete with sound support.
If possible, overclock it beyond 600 Mhz for better results and less frame-skipping.

Do let me know if anything crash or does not work as expect. Thank you and enjoy

EDIT: It was reported that Minitool can corrupt the FAT32 partition if you attempt to expand it. Make sure to double check the FAT32 partition and also check if gmenu2x (apps/gmenu2x) is not corrupted.
Expanding it with Gparted works fine.

EDIT2: I have added a video that showcases my stuff on my UselessRS97 firmware. take a look if you're not sure.
https://www.youtube.com/watch?v=64Lwth6Ri9U

hi!

will try it soon, promising firmware!

2 small suggestion:

could you add this alternative gui?
https://boards.dingoonity.org/ingenic-jz4760-devices/help-wanted!-new-menu-written-in-python-for-k3p-(and-maybe-rs97)/
tagged as alpha, but seems working fine~

this tools too:
https://boards.dingoonity.org/ingenic-jz4760-devices/rs-97-here-is-my-(accurate)-battery-meter/


merci en tout cas pour le boulot

No, it's written in python, thus it's going to be atrociously slow on the device and would add yet another dependency to python. (which i have removed from the firmware)

I find this statement a little odd. PyMenu is running fine on the RS97 on the firmware based on stewards work. You don't need high end performance for a menu or possible other scripts with a small UI. Python 2.7 (which runs best on low end devices) and pygame adds only about 14mb of dependencies.

In the end, its your firmware and your choice

Quote from: gameblabla on July 15, 2018, 09:12:55 am

No, it's written in python, thus it's going to be atrociously slow on the device and would add yet another dependency to python. (which i have removed from the firmware)

I find this statement a little odd. PyMenu is running fine on the RS97 on the firmware based on stewards work. You don't need high end performance for a menu or possible other scripts with a small UI. Python 2.7 (which runs best on low end devices) and pygame adds only about 14mb of dependencies.

In the end, its your firmware and your choice

I agree. I tried the jutley/steward external firmware with PyMenu and it's very responsive. Also from all my time using Kodi/XBMC I'm sure people said it was written in Python to enable it to run better on low end devices. So my point is shouldn't a Python based menu run better on the RS97?

Full respect though to gameblabla and thanks for all your work.

Couple of observations from switching firmware and toolchain:

The precompiled toolchain didn't work on my setup (64 bit Ubuntu Mate 16.04) as 'ld' was linked to a version of glibc I didn't have. Everything else seemed to work - it just failed at the final step of linking. I managed to compile the toolchain - though this took a lot longer as some of the websites that were hosting files were on go slows.

I did have a couple of black screen hangs when exiting the Atari 2600 emulator. It never went back to the menu. The ability to soft reset by holding in the power button doesn't seem to work anymore so I had to reset via safety pin.

Couple of observations from switching firmware and toolchain:

The precompiled toolchain didn't work on my setup (64 bit Ubuntu Mate 16.04) as 'ld' was linked to a version of glibc I didn't have. Everything else seemed to work - it just failed at the final step of linking. I managed to compile the toolchain - though this took a lot longer as some of the websites that were hosting files were on go slows.

I did have a couple of black screen hangs when exiting the Atari 2600 emulator. It never went back to the menu. The ability to soft reset by holding in the power button doesn't seem to work anymore so I had to reset via safety pin.

As a noob i have zero idea what the differences between the hardware on the three machines is. Some seem to work better than others etc. The soft reset and the tv out functions never worked for me either but others say it works for them. On the plus side, most emulators worked for me fine. Picodrive would suffer lockups if i accidently hit the fast forward button and i never got gngeo to function at all. i'm gonna install this firmware on a v1 rs97 and see how it works  compared to the other firmware. Personally I think it's great more people are working on the rs-97 and improving it.

I have not tested everything yet. A few things stand out. Things that need work first: Mame4all loses its rom directory after closing a game.  It also suffers the occasional black screen when exiting a game as well.  Psx4all does not save global settings for games.  Dumbsnes runs slower than pocketsnes, is less accurate (as stated) and has worse sound.
Things that are better so far:  Psx4all feels much smoother. framerates don't appear different, but lag is noticeably better. The overal UI is vastly improved. Gmenu is much more responsive when transitioning windows and shutting down.

I need to do more testing i know. As stated before, these are results from a v1 device.