RetroFW - Developer Support Thread

[alfredobonzo]

Chaps, do the dge apps log somewhere by default?

I'm trying to get OpenTitus to work on RS97 Plus v2 - I now got to the stage where it launches, but stays on black screen (I get this far only if executed from the terminal - when launched from Explorer or Commander, it immediately "crashes to desktop"). I think I compiled it alright, cuz if I manipulate the names of game files (you have to be a happy owner of those) and exec the dge, I get correct error messages in the terminal...

Thanks in advance!

[d0rk]

Ok, so i've got a build environment setup, built a test app (sdl tile engine i started on), can draw to the screen, got a keymap of all the buttons.

Now i'm trying to get a native build of powder up and running.

I managed to modify the makefiles, and have a working executable.
The game runs, but the screen is corrupt. 
looking at the pc version pressing down 4x and then enter to exit DOES work on my executable just like it would on the pc.

It almost looks like the game is trying to run a higher resolution than the display supports, but sdl *should* be able to detect the screen resolution correctly and prevent this, but idk. 

any ideas? 


Before running


powder running


after running

[bopbopbop]

I'm not sure but I did a port of powder that works if you want to compare code. The screen changes were quite minimal from what I remember.

It's here:

https://gitlab.com/bopbopbopbop/powder-rs97

edit: sorry, just re-read your post. By default the current release of retrofw upscales from 320x240 to 320x480, it doesn't change scale arbitrarily, so it depends what the port was originally set to. Powder uses that weird HAM config file, so I believe you have to set the screen resolution in tiles. Anyway, check out my code if you're interested, I'm pretty sure it was just a few line fix.

Also, by default the controls in powder are not SDL, they're mapped to hardware inputs from the dingoo, which don't correlate to these devices. If you haven't changed them already, you'll need to write a replacement input routine. Again, check my code if you would like an example.

Ok, so i've got a build environment setup, built a test app (sdl tile engine i started on), can draw to the screen, got a keymap of all the buttons.

Now i'm trying to get a native build of powder up and running.

I managed to modify the makefiles, and have a working executable.
The game runs, but the screen is corrupt. 
looking at the pc version pressing down 4x and then enter to exit DOES work on my executable just like it would on the pc.

It almost looks like the game is trying to run a higher resolution than the display supports, but sdl *should* be able to detect the screen resolution correctly and prevent this, but idk. 

any ideas? 

[d0rk]

Oh, I see where i went wrong.

I modified the makefile for linux (retrofw is linux after all), and built it that way.
I tinkered around with the code and worked out how to change the resolution by fiddling with the code and doing a desktop linux build of powder, got it down to 320x240 (native for the LDK i'm working with as far as i've read)
it runs, but it still looks weird. I also realized doing a standard linux build its expecting keyboard and mouse instead of just the few keyboard keys the buttons register as, so i would have to work out an input routine like you have already done.

I'm assuming you modified an existing dingoo port to work on the rs97.
i'll have to try to get yours up and running.
I'm new to porting things, I've took a few x86 linux games and tweaked  them to get them running on the  raspberry pi (powder, cataclysm:dda, brogue)  but never anything this deep down the rabbit hole.

by the way,  I never found any one mention the developer backdoor on the retrofw firmware, so i figured i'd mention it here:
no clue if it works on windows/osx due to drivers, but if you plug a usb cable in, boot to the Ui and press b to not do file transfer but charge only...  On a linux desktop about 30 seconds later a usb ethernet adapter shows up and automatically assigns an ip address to your pc of 169.254.1.2 (the rs97 device itself is 169.254.1.1)

port scanning it i found that ftp and telnet are open login for telnet appears to be root, no password. ftp works anonymous, very handy for remote testing/debugging.


I'm assuming it work just as well on a linux vm as long as you handed the usb port off to the VM.


I'm currently in the process of getting buildroot back up and running with sdl2, going to see if i can get blake stone up and running, but i'll have to try your build and see exactly whats different from what i was trying to do.

edit- forgot to ask/add
the specs for the cpu/SOC should support USB OTG, i'm not sure if the hardware exists to enable it, but just curious if anyone knows if that is something that could be made use of?   plugging in a keyboard, second gamepad, or even something like a wifi adapter via USB OTG would be cool.

UPDATE:
POWDER runs!
had to modify /rs97_dev/powder-rs97/port/dingoo/hamfake.cpp:147 changed SDL_TRIPLEBUF (errored during build as if it were nonexistant) to SDL_DOUBLEBUF to get it to build, maybe i need to update buildroot?

running a quick feature test, i noticed a couple tilesets cause the screen to go blank  (akoi meexx 12, ibson the gray), i'm assuming they're different size tiles compared to the others.

nice work @bopbopbop

[bopbopbop]

///telnet

Ah that's really useful. I'd heard about the telnet link but never tried it - it doesn't seem to turn up on my linux mint system. I'm probably not waiting long enough!

///sdl triplebuf

You're correct, if you can't compile to SDL_triplebuf it means you're missing the SDL patches. You can find the patches here:

https://github.com/retrofw/buildroot/tree/master/package/sdl

You probably know this, but if you want to recompile, you can drop the patch files in your buildroot sourcetree in the same place, recompile just the SDL package, and it should all just work.  Instructions are here:

https://buildroot.org/downloads/manual/manual.html#rebuild-pkg

It's basically make <packagename>-rebuild followed by make, and it's quick. You might want to back up your buildroot before you do it though, just in case!

///ldk

The default resolution for the LDK is actually 320x480, weird as that is, it's just that the kernel is automatically using the ppu chip to resize the 320x240 you are giving it to 320x480.

///ports

Blake Stone would be awesome. There's also aleph one (marathon) which has a dingoo build I've got to compile but haven't managed to get to recognize the files on, if you (or anyone else reading this) fancy giving it a crack. Fair warning, the code is a bit of nightmare:

https://github.com/Aleph-One-Marathon/alephone-dingoo

///sdl2

Some people have got SDL2 running with a framebuffer (@cpasjuste, @pingflood) but I don't think the performance was great. Definitely let me know how far you get.

///but never anything this deep down the rabbit hole.

It only goes deeper.

Oh, I see where i went wrong.

I modified the makefile for linux (retrofw is linux after all), and built it that way.
I tinkered around with the code and worked out how to change the resolution by fiddling with the code and doing a desktop linux build of powder, got it down to 320x240 (native for the LDK i'm working with as far as i've read)
it runs, but it still looks weird. I also realized doing a standard linux build its expecting keyboard and mouse instead of just the few keyboard keys the buttons register as, so i would have to work out an input routine like you have already done.

I'm assuming you modified an existing dingoo port to work on the rs97.
i'll have to try to get yours up and running.
I'm new to porting things, I've took a few x86 linux games and tweaked  them to get them running on the  raspberry pi (powder, cataclysm:dda, brogue)  but never anything this deep down the rabbit hole.

by the way,  I never found any one mention the developer backdoor on the retrofw firmware, so i figured i'd mention it here:
no clue if it works on windows/osx due to drivers, but if you plug a usb cable in, boot to the Ui and press b to not do file transfer but charge only...  On a linux desktop about 30 seconds later a usb ethernet adapter shows up and automatically assigns an ip address to your pc of 169.254.1.2 (the rs97 device itself is 169.254.1.1)

port scanning it i found that ftp and telnet are open login for telnet appears to be root, no password. ftp works anonymous, very handy for remote testing/debugging.


I'm assuming it work just as well on a linux vm as long as you handed the usb port off to the VM.


I'm currently in the process of getting buildroot back up and running with sdl2, going to see if i can get blake stone up and running, but i'll have to try your build and see exactly whats different from what i was trying to do.

edit- forgot to ask/add
the specs for the cpu/SOC should support USB OTG, i'm not sure if the hardware exists to enable it, but just curious if anyone knows if that is something that could be made use of?   plugging in a keyboard, second gamepad, or even something like a wifi adapter via USB OTG would be cool.

UPDATE:
POWDER runs!
had to modify /rs97_dev/powder-rs97/port/dingoo/hamfake.cpp:147 changed SDL_TRIPLEBUF (errored during build as if it were nonexistant) to SDL_DOUBLEBUF to get it to build, maybe i need to update buildroot?

running a quick feature test, i noticed a couple tilesets cause the screen to go blank  (akoi meexx 12, ibson the gray), i'm assuming they're different size tiles compared to the others.

nice work @bopbopbop

[yochy4671]

Hello,

Can I see U-Boot config and Linux kernel config of RetroFW?
I want to build that locally.

Thank you.

[ogami]

Hello,
I have a LDK GAME V1 with RETROFW 1.2.
The RetroFW time clock does not work when the console is "on", "in sleep" or "off".

Could you activate the RTC/"real time clock" of jz4760/jz4760B in the RetroFW kernel, please ?!

[gameblabla]

Can I see U-Boot config and Linux kernel config of RetroFW?
I want to build that locally.

I have leaked the kernel here :
https://github.com/rs-97-cfw/rs97-linux-kernel-NoNDA

If you are asking for the uboot source code, i don't have it. In fact, i have been asking for it
for quite a while and all i got was being cancelled.
It's never going to happen. you are better off porting uboot or another bootloader from scratch.

Hello,
I have a LDK GAME V1 with RETROFW 1.2.
The RetroFW time clock does not work when the console is "on", "in sleep" or "off".
Could you activate the RTC/"real time clock" of jz4760/jz4760B in the RetroFW kernel, please ?!

The handled has no working RTC. And the power off trick for the RS-90 doesn't work there either.
So even if it is enabled, then it won't retain it after you power it off.

But if you think you can get it working then see the kernel source code above.

[ogami]

Thank you Gameblabla for your answer and your previous work.
It's sad not to have the RTC activate to have the clock when the console is turned on.

I do not know the power off trick for the RS-90 but I find a manipulation/trick on my LDK.
-Console turn on-> press START in GmenuNX-> Select Power Off = Console off without touching the switch Off
-To turn on the console, press the sleep button = Console turn on.
The console is always powering and listening to the buttons with this method of extinction.

It is surely not impossible to keep the time with the console off.

I follow your different works and I already download on ingenic Kernel linux-2.6.31.3 with "Patch files" and also your "rs97-linux-kernel-NoNDA". But I am looking for the "jz4760_ipu" for the "2.6.31"!

It's sad to have no news of the development of RetroFW and Pingflood.
He should share the sources of RetroFW so that other developers resume are abandoned project.

Thanks again

Edit:

Can I see U-Boot config and Linux kernel config of RetroFW?
I want to build that locally.

I have leaked the kernel here :
https://github.com/rs-97-cfw/rs97-linux-kernel-NoNDA

If you are asking for the uboot source code, i don't have it. In fact, i have been asking for it
for quite a while and all i got was being cancelled.
It's never going to happen. you are better off porting uboot or another bootloader from scratch.

I am a beginner in the development, but it is not compatible with the source of Ingenic?
ftp://91.215.122.205/mirrors/Ingenic/legacy-ftp.ingenic.cn/3sw/01linux/01loader/u-boot/

[yochy4671]

Thank you so much.

I'll try to compile kernel.

I found U-Boot patch for jz4760(b) LEPUS board that named u-boot-1.1.6-jz-20120904-r1819.patch.gz,
and I can compile and link that. However, I have not confirmed that it works correctly. I'll check this too.

If it works, I am planning to port the U-Boot patch to a newer version of U-Boot.

Can I see U-Boot config and Linux kernel config of RetroFW?
I want to build that locally.

I have leaked the kernel here :
https://github.com/rs-97-cfw/rs97-linux-kernel-NoNDA

If you are asking for the uboot source code, i don't have it. In fact, i have been asking for it
for quite a while and all i got was being cancelled.
It's never going to happen. you are better off porting uboot or another bootloader from scratch.

[gameblabla]

-Console turn on-> press START in GmenuNX-> Select Power Off = Console off without touching the switch Off
-To turn on the console, press the sleep button = Console turn on.
The console is always powering and listening to the buttons with this method of extinction.

It is surely not impossible to keep the time with the console off.

It's funny because i had been told that it didn't work on other's consoles yet it does for you.
Good i guess but then as soon as you remove the battery, RTC's gone.
Now that podulator added OPK support to GMenuNx, you can port it back to the RS-97 if you feel like it.

I follow your different works and I already download on ingenic Kernel linux-2.6.31.3 with "Patch files" and also your "rs97-linux-kernel-NoNDA". But I am looking for the "jz4760_ipu" for the "2.6.31"!

That file, jz4760_ipu.c, was removed because it is covered under an NDA. Contact me if you need a copy of it.

Be warned that the kernel as is does not support IPS panels !

I found U-Boot patch for jz4760(b) LEPUS board that named u-boot-1.1.6-jz-20120904-r1819.patch.gz,
and I can compile and link that. However, I have not confirmed that it works correctly. I'll check this too.

If it works, I am planning to port the U-Boot patch to a newer version of U-Boot.

It could work, however keep in mind that the LCD display will not work unless you support it of course.
Not that it's needed for the bootloader thankfully.

[ogami]

Oh ! Thank you for the warning of the IPS.

It's funny because i had been told that it didn't work on other's consoles yet it does for you.
Good i guess but then as soon as you remove the battery, RTC's gone.
Now that podulator added OPK support to GMenuNx, you can port it back to the RS-97 if you feel like it.

I made you a quick video:
<a href="https://web.archive.org/web/20210724183018/https://www.youtube.com/watch?v=JNgKQGIYS-4" target="_blank">https://www.youtube.com/watch?v=JNgKQGIYS-4</a>

That file, jz4760_ipu.c, was removed because it is covered under an NDA. Contact me if you need a copy of it.

Be warned that the kernel as is does not support IPS panels !

And I unfortunately do not find the "jz4760_ipu.c".
So if you can help me, please, thank you

I want to make a Kernel RTC and 3D print a cache to replace the power switch.
The RTC on the LDK Game is really a big lack...

EDIT:
Good news ! On LDK game the RTC of the JZ4760B works with the PowerOff button "Start" and the waking with the button "sleep".
Screen Telnet=


But of course the switch "PowerOff" reinitializes at "12:00 AM 2010-10-01".

Unfortunately Retrofw 1.2 uses the virtual clock "rtc0" 
Now, how to change the RTC source without recompile the kernel?
Personally I think it is necessary to reconfigure the kernel and recompile ...

[JOCO_MKNZ]

Hi all

I wanted to ask for help in porting a more recent version of openbor to retrofw, as retrofw only has build 3434 which is way too old to play some of the more recent pak's. Hopefully this issue should be remedied with a newer openbor version.

I managed to successfully cross compile both rs97commander and pong for my RG300, so I am sure buildtools works correctly.

However, when I then tried to cross compile openbor from gameblablas repo at https://github.com/gameblabla/rs97-fixesgames/tree/master/openbor I am getting abicalls linked to nonabicalls error and I am getting a segfault error when I try to run the compiled dge file on the device.

I even tried to hardcode links and yet I am still having no luck with cross compiling.

Makefile, environ and errors all attached