Author Topic: Legacy Dingux to OpenDingux compatibility layer?  (Read 2205 times)

MightyJAK (OP)

  • **
  • Posts: 538
    • My tumblr
Legacy Dingux to OpenDingux compatibility layer?
« on: April 17, 2014, 05:51:09 pm »
I recently developed an interest in Game Park's handhelds (yeah I know, slowpoke.jpg) and after learning about GINGE (Ginge is Not GP2X Emulator), I got to wondering if something like this could be made for OpenDingux to increase compatibility with legacy dingux applications Ginge "operates by hooking certain system calls and using realtime patching of code that accesses memory mapped hardware directly". Since we're talking about the same hardware (or similar hardware for the other devices OpenDingux currently runs on), I'm guessing this program could be even simpler. It would have to patch use of the OSS audio driver, fixed-point calculations, and any other differences that commonly prevent legacy dingux programs from working properly on OpenDingux.

So tell me devs, would such a program be feasible, and is there any interest in developing it? As Zear said:
I should discourage anybody from running or hoping to run verbatim any A320 compiled binaries on GCW0. They were not designed to run on GCW0 and we take no responsibility for any misbehaviour of them.

.. you should stay away from the old A320 binaries and rather wait for us to properly port it to GCW0.
I'm making this request because I realize there are a limited number of active developers, with limited time and interest in updating old software. While I would also prefer to have updated releases with extra polishing and bugfixing, most legacy apps will probably never get the OpenDingux treatment. Having this program would instantly increase the amount of software available for the GCW-Zero, GameGadget, Neo-Geo X, and any other devices that get OpenDingux (I'd love to have OD running on my 2DS someday).

Another consideration: if this program becomes a reality, what would we call it? DINALDE - Dinalde Is Not A Legacy Dingux Emulator?  ::)
« Last Edit: April 17, 2014, 07:44:29 pm by MightyJAK »
My machines:
GBC,GBA,GBA SP,NDS,NGPC,Panasonic FZ-10 3DO,NES,Sega Nomad,Sega CDX w/Power Base Converter,PS1,PS2,PS3,Saturn,Dreamcast,PC (Win 98, XP, 7),Dingoo A320,Dingoo A330,Gemei A330,LetCool N350JP,PAP-GAMETA,GCW-Zero SE,Kyocera Rise,2DS,GP2X-F100,GPD G7,JXD 100,JXD A1000,JXD A3300,JXD F3000,JXD V5000,JXD S7300B,Hyperkin SupaBoy

Currently playing: Theatrhythm Final Fantasy Curtain Call (2DS)

mth

  • *
  • Posts: 294
Re: Legacy Dingux to OpenDingux compatibility layer?
« Reply #1 on: April 18, 2014, 04:24:46 am »
It helps to separate kernel incompatibilities from rootfs incompatibilities.

Kernel incompatibilities include:
  • OSS (legacy) vs ALSA (OD)
  • Direct hardware access through /dev/mem (possible on legacy, blocked on OD)
  • Ingenic specific kernel interfaces in /proc/jz (available on legacy, replaced by standard interfaces on OD)

Rootfs incompatibilities include:
  • Incompatible library versions (different SONAME) for some libraries
  • Hardware vs software floating point ABI (OD on the GCW Zero uses hardware float; both legacy and OD on the A320 use software float since the JZ4740 doesn't have an FPU)

Working around rootfs incompatibilities is easy: you can just mount the rootfs of the system you're trying to mimic and then use chroot to make it appear as the main rootfs to an application. Well, you'd have to bind-mount /dev and /tmp and add second mounts of /sys and /proc in the compatibility rootfs, so it's a bit more involved than that, but it's not beyond what a shell script of a dozen or so lines could do.

Working around kernel incompatibilities is hard:
  • We tried the OSS emulation that exists for ALSA, but performance was poor and on A320 we lost software volume control, so it was always playing at maximum volume. In the end, we decided it was not worth enabling it in a release.
  • Having applications access hardware registers directly that are also accessed by the kernel is waiting for an accident to happen. It would also break suspend, since the driver would not be able to restore the hardware to the right state when resuming. We think applications poking into hardware registers is a very bad idea and we also don't want the support nightmare of having this feature enabled, so it is removed in OD. You'd either have to write some kind of simulator for /dev/mem or accept that some apps won't run.
  • Regarding /proc/jz, most of the things that happen there are not very critical (such as changing screen brightness), so you could probably put a ramdisk (tmpfs) there to make it appear to the application that writes succeeded but let nothing happen.

I don't think there are all that many applications using /dev/mem fortunately. But reliable and well-performing OSS emulation would be crucial to make a compatibility layer like this usable.

I doubt though whether a compatibility layer is the right approach in making more applications available. Most software for the Dingoo and Zero is open source, so let's take advantage of that by modernizing and standardizing the applications. OpenDingux uses standard interfaces as much as possible, so if you make an application run on OpenDingux it will also be much easier to run it on other Linux systems. It's an investment in keeping the application usable on current and future devices, while a compatibility layer is far less future proof.

Also porting applications is a great way for beginning developers to learn, while creating the kernel parts of a compatibility layer requires an expert developer. So the porting approach will also help towards decreasing the developer shortage, while the compatibility layer approach would just use up development time that could be used better in my opinion (we still need SDL2 support on the Zero, for example).

What would help a lot is if porters would adopt a workflow where they publish their changes as commits instead of as ZIP files / tarballs. What I mean is something like this:
  • commit 1: Import upstream application release.
  • commit 2: Add/change Makefile for compiling for OpenDingux.
  • commit 3: Work around function missing in uClibc.
  • commit 4: Add button mapping for OpenDingux.
  • commit 5: Render using double buffering.
  • commit 6: Save in home dir instead of installation dir.
  • commit 7: Add Makefile rule to package as OPK.
And publish those commits on GitHub (or BitBucket or SourceForge etc). Although I didn't finish it, I did start on this process for Mr Drillux. Please look through the commits list there and compare that to getting a ZIP file with sources.

This approach solves a number of issues:
  • Future porters have an easier time finding the latest version of the source: there is a single repository that contains everything, instead of having to dig through old forum posts and hope that the source download link still works.
  • It is much easier for another developer who wants to make improvements to see what the first porter did.
  • It is much easier for another porter to port to a new device: they can cherry-pick the commits that are appropriate to the new device and for commits that don't match the new device they can still see what part of the code needs modification, saving them a lot of time digging through the code.
  • If the upstream (parent project) is still active, you can import newer releases and easily re-apply the customizations on top of that.
  • If the upstream is still active, they might include some of your customizations into the parent project, making it easier to port in the future.

To summarize: making a compatibility layer is not easy and in my opinion the effort is better spent in cleaning up and modernizing application source code, since that will have more long term benefits.
« Last Edit: April 18, 2014, 04:30:37 am by mth »

MightyJAK (OP)

  • **
  • Posts: 538
    • My tumblr
Re: Legacy Dingux to OpenDingux compatibility layer?
« Reply #2 on: April 23, 2014, 07:50:15 pm »
making a compatibility layer is not easy and in my opinion the effort is better spent in cleaning up and modernizing application source code, since that will have more long term benefits.

Although I had suspected this would be the answer, I appreciate the detailed reply.

Looks like I'm at the mercy of the developers' whims as to what gets updated to OD and when (or my own whims, if I can find the time in my busy game-playing schedule to learn how to make games myself  :P).
My machines:
GBC,GBA,GBA SP,NDS,NGPC,Panasonic FZ-10 3DO,NES,Sega Nomad,Sega CDX w/Power Base Converter,PS1,PS2,PS3,Saturn,Dreamcast,PC (Win 98, XP, 7),Dingoo A320,Dingoo A330,Gemei A330,LetCool N350JP,PAP-GAMETA,GCW-Zero SE,Kyocera Rise,2DS,GP2X-F100,GPD G7,JXD 100,JXD A1000,JXD A3300,JXD F3000,JXD V5000,JXD S7300B,Hyperkin SupaBoy

Currently playing: Theatrhythm Final Fantasy Curtain Call (2DS)

 

Post a new topic
Post a new topic