Dingoonity.org

Some people had asked (mostly curiously) what improvements that can still be made, even theoretically.
Here's a wish list :

• IPU dynamic resizing support

Obviously one of the most requested feature and the one that would be the most significant in terms of improvements.
If you have access to kernel source code, you can actually change the virtual screen resolution to anything (256x224 etc...) as it would be then upscaled to 320x480.
But we would need to do it on the fly (We request a certain resolution, RetroFW detects said size and then upscales it accordingly).

Looking at the code, it would require some changes, especially if we want to do it the proper way.
The GCW0 already does this and it's definitely useful for some emulators/games.

• BGR colorspace support

This one is a bit more specific to some emulators, mainly reGBA and PCSX4ALL.
There are some consoles like the GBA and PSX that natively work in the BGR colorspace.
Since the RS-97 (and other devices) work in the RGB colorspace, this requires some conversion.
Supporting this in the kernel would mean that the code for it can be greatly simplified :
https://github.com/gameblabla/pcsx4all/blob/master/src/gpu/gpulib/vout_port.c#L124
...which obviously results in greater speed.

GCW0 kernel has support for this in the upcoming kernel. There's also a patch for SDL to support this :
https://github.com/gcwnow/buildroot/commit/40685f89fa445b5f6db42ba67bbab3ead654d7a3

• Support for the 2D accelerator inside of the JZ4760 (Vivante GC200)

The Vivante GC200 is a 2D accelerator that can rotate, resize, and accelerate 2D content.
Definitely not as useful as a 3D accelerator (Vivante refers to it as a compositing accelerator) but given that software rendering is expensive, this could be useful to accelerate the framebuffer.
TonyJih also said that the accelerator could be used to support for LCD screens which are expected to be rotated for landscape. (phone screens)

Etnaviv in the upstream linux kernel has DRM support for it. Stock kernel also has the GPLv2 vivante code but it is currently unknown how to use it from userspace as it is poorly documented.

Supporting the 2D accelerator would mean either to use the upstream linux kernel (doesn't currently support JZ4760 board), or use it in the stock kernel. (would require Tony to support this in the JZ4760 code)

Btw, that's also where the OpenVG claim support comes from.
OpenVG in itself however is not very useful and support for it got removed in Mesa 10.1, it never resulted in wide adoption. (if any)

• VPU (also MXU related)

The VPU is a MIPS, general purpose cpu core that is intended for accelerating video content.
The only software to make use of it, Mplayer, is provided as part of the stock firmware. It can play back MPEG2 content.
However said Mplayer only targets the first generation of MXU (SIMD 1), not the second one. (SIMD 2)

Similarly related, the MXU is an instruction set that targets said VPU and is designed for video acceleration. This is what Mplayer uses to accelerate such content.

It was not possible to use mplayer on Useless because the rootfs was not compatible with it. (mplayer targets legacy dingux)
However, RetroFW now does have some compatibility with legacy dingux software so it's possible that mplayer works on it again.
(I need to test it and if it works, package it)

The GTE code(3D part of the PSX) in PCSX4ALL part5 also plans to make use of the MXU. This should result in greater speed on 3D games so stay tuned.

But what is BGR colorspace?

BGR and RGB are color formats for the screen. The difference is that they are ordered in a different way. There's also YUV, RGBA etc... Look up on Wikipedia if you want to know more.
The GBA uses BGR555 for the palette in the 8-bits mode and also in its BGR555 bitmap mode.

Is this the reason why the gba games so bright?

That's unrelated to BGR colorspace. The real reason why was due to the fact that earlier GBA games relied on the fact that the first GBA models had no backlight/frontlight so they oversatured the colors as to look correct on the GBA.


This issue can also happen on real GBAs with backlight mod and Nintendo DSes.

opk support inc firmware updates via opk?

In theory possible ? But the GCW0 actually mounts those files while compressed. You may have noticed this already but if you have a huge collection of games/emulators, it would actually become sluggish before it loads the list of games/emus.
Given that the RS-97 is even slower than that, i think that the IPK way is the better alternative.

EDIT: As for firmware updates, these won't be possible on OPKs, due how they work. (they are actually mounted, not decompressed)
We need to have a rootfs at to boot to the OS and GmenuNx and all.
Also kernel area is writed protected so even if the rootfs could be updated, we can't touch the kernel.

This issue can also happen on real GBAs with backlight mod and Nintendo DSes.

It is possible to add a color filter to ReGBA?

In my opinion 2D accelerator is very necessary for RS-97 Plus because there are so many screen-tearing effect. Hardware framebuffer in kernel is the best way to go. I saw this issue in the new Bittboy too. I hope you will succeed it in the near future.

Temper screen scaling doesn't seem to work at all, can this be looked into?

SNES emulation definitely need more polishing. Mode 7 and SuperFX games runs faster in Useless Firmware.

It's still slow in Useless, but less worse than in RetroFW.

This alone made me choose Useless Firmware, apart from the native games like KETM and Falling Time or the old school shooter ports.

I do miss some of the better feature on RetroFW (like USB connection).

But keep in mind I'm not complaining. Both RetroFW and Useless are wonderful works. I can use either anytime.

Thanks for the awesome project!

SNES emulation definitely need more polishing. Mode 7 and SuperFX games runs faster in Useless Firmware.

It's still slow in Useless, but less worse than in RetroFW.

This alone made me choose Useless Firmware, apart from the native games like KETM and Falling Time or the old school shooter ports.

I do miss some of the better feature on RetroFW (like USB connection).

But keep in mind I'm not complaining. Both RetroFW and Useless are wonderful works. I can use either anytime.

Thanks for the awesome project!

This is not my expirience. For example Super Mario Kart runs as well if not faster in retrofw for me. I agree with you I like them both as both are very viable, but i don't notice slower performance.

There's no dumbSNES in RetroFW, it's PocketSNES. Can't find any ipk too. I've collected all ipk from this forum.

At my device Mode 7 and Super FX games and are definitely faster on Useless, but still both don't run at full speed.

Yup, i haven't released any version of DumbSNES for RetroFW due to low compatibility. It's on Useless though.
I guess that they did not profile it properly. Maybe it's something i should look into but not right now...

Yeah it's fine. I don't play mode 7 and super FX games anyway.

Some games do combine pure 2D with mode 7 like Run Saber and Contra though.

that got me thinking, just a suggestion;
it's better to focus on supporting mode 7 than Super FX
Mode 7 have wider libraries than Super FX (only 8 of them) I think
Mode 7 : https://en.wikipedia.org/wiki/Mode_7
Super FX : https://en.wikipedia.org/wiki/Super_FX

Apart from those, every other games are running perfect and I already got shit tons of them in this tiny device. lol.

Just want to report about it.

Again, thanks for the project!