Dingoonity.org

For those who like to live on the edge, we now have nighty OpenDingux builds for the GCW-Zero, RS-90, RG-350 and RG-350M.

More info here: https://zcrc.me/opendingux/2020/10/13/we-have-nighties.html

Very cool indeed!
i installed the latest (10/15/2020) on my kickstarter gcw0. Everything seemed to have installed properly, but when i boot 'er up, it hangs/freezes at the "OpenDingux Loading..." screen.

Looks like GMenu2X is not starting. Try to remove your .gmenu2x folder.

Just an update. I was able to replace my internal sd (really hated to crack open my gcw0 again, lol) with a new one, and updated to the latest opendingux beta succesfully.
Now to get all my opks updated that need it.

Noticing that gmenu2x charging icon is always present whether plugged or not.

I updated my GCW0 to 03-01-2021 and some things would not run any more: dingux-colem, dingux-ti99, nethack.  (All were working fine on 2014 fw.)

I tried recompiling dingux-ti99 with the latest toolchain after it failed to start, complaining about some lib or other being the wrong version. (libpng, I think) So now it starts, but none of the buttons work.

Have the SDL button mappings changed?

Is there a log someplace? USB networking will not work for me so I can't just telnet/ssh in to get to a prompt. If it is supposed to work, it might be my hardware: I have never been able to do anything but charge the GCW0 with USB; I got my GCW0 "for parts" cheap, and the only way to get it working was to  use dd to write an image to the internal card.

ST-SDL (Terminal.opk, I think frm RG350 Rogue) does not work either; the help startup dialog splash  flashes by and st-sdl just dies without any error. I lot of things fail this way. Recompiling with the latest toolchain usually makes them hang. (ti99-sim was hanging, not a problem with buttons.)

I've tested a bunch of old stuff and most everything worked perfectly once recompiled --static with the RS97 toochain: dingux-ti99, fba-sd, dingux-cap32, dingux-atari, beebem, dingux-colem all working. (I didn't rebuild all this, but already had the binaries laying around in a backup of my RG300.)

Vice (GCW0 version floating around on these forums) does not run, but says it can't find libungif.so.4. Static RS97 version from my RG300 works without sound. Maybe I'll try to LD_PRELOAD it, assuming I can build it.

gmenu2x SELECT menu seems to be missing almost everything.

Nethack (compiled with latest tools) hangs a with a distorted screen. Compiled with the old gcw0 toochain, it hangs with a black screen.. Old RG300 Nethack (static) runs but the screen is still, err, sort of doubled up.


UPDATE: I managed to get ST-SDL (from https://github.com/benob/rs97_st-sdl ) to run by rebuilding it (using gcw0-toolchain) with the only the flag SDL_SWSURFACE in the arguments  to SDL_SetVideoMode. It would not run with SDL_HWSURFACE | SDL_DOUBLEBUF.

The log viewer is a great idea, thanks for this! It has always been too much logging or not enough, but this is just right: show the output of the last thing that ran.

Turns out nethack was only using SDL to set the video mode and then doing something else (a bunch of wacky functions dzzFlip(), dzzInit(), etc.) in dingoo.c to actually put things on the screen.  Funnily, there was already SDL support there in sdl.c, but it was not being built. Removing dingoo.c and building sdl.c has got it working!

I'm curious why you say it is bad to link statically, that things break with updates; in my experience it is the opposite: dynamic linking results in libthisorthat.so not found at runtime, or just flakey behaviour if the balky old program runs at all. But, then again, I'm trying to move stuff across platforms, not updating one platform; up until recently, there were not so many updates to Dingoo, GCW0, RS97....

Anyway, thank you for this great work on the GCW0...mine probably would still be collecting dust if not for your efforts.

It looks like a problem with a few programs is with having both libpng.so.3 and libpng.so.4 in the lib directory. If you recompile (-lpng) with the new toolchain it links to libpng.so.4. Running the program, you get a seg fault with error "compiled with libpng.so.4, found libpng.so.3" I guess because libpng.so.3 is found first?

In the short term, I just recompile static with the old gcw0 tools. This affected a couple old games. openggs is one.

Will there ever be some kind of fake RTC? It would be nice to be able to set the system time at startup or at least save the time in a file at shutdown and then increment it a wee bit at startup. The important thing is that time never go backwards: for example, in gpsp with GBA Pokemon games (orginal and hacked) : if your save file stores a time in the future, berries stop growing and day/night cycle can get stuck.  Fixing requires a save editor or just starting the game over.  (This isn't an emulator problem; a real Pokemon Emerald cart will behave this way when the clock gets reset when the battery is replaced.)

This is just wishlist stuff now, but if there ever is a good MIPS NDS or N64 emulator, not having the clock behave reasonably will also ruin your day playing Animal Crossing (Dobutsu no Mori) games.