PERFORMANCE IMPROVEMENT: TESTERS NEEDED! (was: UNIX sysadmin observations)
Posted: Fri 26 Apr 2019 08:13
Hi, everyone. This is a great project, isn't it?
Me: I've been supporting Solaris servers for 20 years, but now I'm finally making the dive into Linux. The RetroStone is part of my at-home edutainment. I've only had it a full day, but I'm enjoying it and learning a ton about those Linux-specific quirks and also the H3 chipset. I'm complete inside AND outside of my comfort zone all at the same time.
Display devices: One of the things I've been playing with was the need to fully reboot the RetroStone to make a display change. I see that configuration changes are being done exclusively through the FEX script (converted into a binary) in the /boot folder. In Supreme RetroStone v1.3, those changes are facilitated by the video device selection script: /home/pi/RetrOrangePi/BashTool_ROPI_RCA/Tool/bashFiles/main.SH
That certainly works, but FEX was designed as boot-time hardware settings. The chipset wasn't designed to be locked into a single mode until the next time it is powered up. Has anyone tried changing display settings while the system was running by shifting the correct values into the H3's memory-mapped registers and reconfiguring/restarting any of the necessary demons? I've found a few web pages that won't solve the issue right out of the box, but they point to some of the components necessary to pull it off:
Dynamic video mode changer: https://forum.doozan.com/read.php?6,9002
mapping register with mmap in C (gpio in this example): http://docs.cubieboard.org/tutorials/co ... on_lubuntu
Working with multiple frame buffers: http://linux-sunxi.org/Dual_Monitor_Support
Informing the OS of the new resolutions with fbset: http://linux-sunxi.org/Display
Display options: Changing output devices and framebuffers might be a final goal. But a step along the way might be a video mode change, or working with a large virtual video buffer and seeing if the built-in scaler will give us better perceived resolution on the 320x240 display? But along the way, I've made a few attempts to far at video cloning (having the HDMI and the analog "CVBS" display the exact same output) but I haven't yet had a success. I am seeing that running two displays at the same time seems to significantly drive up the internal temperature of the RetroStone. It makes sense I guess. If you're taxing the CPU it is going to get hot, but if you start taxing the GPU it can quickly push the heat too high for the chipset.
One of the things I was really hoping to see is if we could get a game playing on the HDMI connection at the same time the local LCD has its own independent framebuffer that we can use to display some static text or graphics. But even two static screens and only moderate CPU use may end up tickle the heat issue and creating stability issues. Anyone have any experience playing with any of this?
SSH'ing into the RetroStone: I haven't heard many people talk about this, but it really is nice to be able to SSH into the RetroStone (via the "pi" account). And once you SSH into a server, the next step is to scp files back and forth with the RetroStone and a PC. It has been a really great way of loading ROMS onto the handheld and for backing up some configuration.
Deleting a theme can be dangerous: I had an experience where the RetroStone stopped working. It went to a text mode and display some assertion error about some sort of font texture cache. I looked in the forum and Googled and found that a number of people were running into similar problems now and then, but no great solutions I figured out how mine was happening, at least.
When you've got an author that is offering several themes, certain components (the fonts in particular) may end up being stored in the same place and shared among their different Themes. So while you've selected a Theme called "Mars" and you erase a totally different Theme that was installed earlier called "Venus", all of the sudden, emulationstation can't run and all you see is a font error that you can't get around! (And you probably didn't even realize those Themes had the same author, much less shared files.) The solution would be to log into the UNIX shell and remove/reinstall your active Theme, or to reinstall the Theme you just deleted. SSH is a good way to do it. When you log into as the "pi" user, these commands will start you down the road:
cd /home/pi/RetroPie-Setup
sudo ./retropie_setup.sh
So that's my experience as of day one.
Software-based LCD backlight power switch: Something I'd like to do is to tie into one of the GPIO pins and see if I can wire a simple circuit that would power on / power off the LCD backlight through some simple GPIO commands in the shell. I just find it annoying that the screen displays garbage while I'm playing games on the big screen, you know? Anyone have some thoughts on where I might want to focus my attention on the PCB?
The video conversion chip? Anyone have any details on how the CVBS (composite video) output from the A3 chipset is being massaged before sending it to the LCD? I'm wondering if it can be bent to deliver something close to full NTSC to a different LCD, or if the only real option is going to be to either tie into the composite video signal (or hijack the external HDMI) and convert and display it from there? I see that someone else here in the forum has gone the second route (internal HDMI display) but I'm hoping that there is some chance that the internal composite video may yet be salvaged?
Thank you for your time and interest,
Atari Datacenter
Me: I've been supporting Solaris servers for 20 years, but now I'm finally making the dive into Linux. The RetroStone is part of my at-home edutainment. I've only had it a full day, but I'm enjoying it and learning a ton about those Linux-specific quirks and also the H3 chipset. I'm complete inside AND outside of my comfort zone all at the same time.
Display devices: One of the things I've been playing with was the need to fully reboot the RetroStone to make a display change. I see that configuration changes are being done exclusively through the FEX script (converted into a binary) in the /boot folder. In Supreme RetroStone v1.3, those changes are facilitated by the video device selection script: /home/pi/RetrOrangePi/BashTool_ROPI_RCA/Tool/bashFiles/main.SH
That certainly works, but FEX was designed as boot-time hardware settings. The chipset wasn't designed to be locked into a single mode until the next time it is powered up. Has anyone tried changing display settings while the system was running by shifting the correct values into the H3's memory-mapped registers and reconfiguring/restarting any of the necessary demons? I've found a few web pages that won't solve the issue right out of the box, but they point to some of the components necessary to pull it off:
Dynamic video mode changer: https://forum.doozan.com/read.php?6,9002
mapping register with mmap in C (gpio in this example): http://docs.cubieboard.org/tutorials/co ... on_lubuntu
Working with multiple frame buffers: http://linux-sunxi.org/Dual_Monitor_Support
Informing the OS of the new resolutions with fbset: http://linux-sunxi.org/Display
Display options: Changing output devices and framebuffers might be a final goal. But a step along the way might be a video mode change, or working with a large virtual video buffer and seeing if the built-in scaler will give us better perceived resolution on the 320x240 display? But along the way, I've made a few attempts to far at video cloning (having the HDMI and the analog "CVBS" display the exact same output) but I haven't yet had a success. I am seeing that running two displays at the same time seems to significantly drive up the internal temperature of the RetroStone. It makes sense I guess. If you're taxing the CPU it is going to get hot, but if you start taxing the GPU it can quickly push the heat too high for the chipset.
One of the things I was really hoping to see is if we could get a game playing on the HDMI connection at the same time the local LCD has its own independent framebuffer that we can use to display some static text or graphics. But even two static screens and only moderate CPU use may end up tickle the heat issue and creating stability issues. Anyone have any experience playing with any of this?
SSH'ing into the RetroStone: I haven't heard many people talk about this, but it really is nice to be able to SSH into the RetroStone (via the "pi" account). And once you SSH into a server, the next step is to scp files back and forth with the RetroStone and a PC. It has been a really great way of loading ROMS onto the handheld and for backing up some configuration.
Deleting a theme can be dangerous: I had an experience where the RetroStone stopped working. It went to a text mode and display some assertion error about some sort of font texture cache. I looked in the forum and Googled and found that a number of people were running into similar problems now and then, but no great solutions I figured out how mine was happening, at least.
When you've got an author that is offering several themes, certain components (the fonts in particular) may end up being stored in the same place and shared among their different Themes. So while you've selected a Theme called "Mars" and you erase a totally different Theme that was installed earlier called "Venus", all of the sudden, emulationstation can't run and all you see is a font error that you can't get around! (And you probably didn't even realize those Themes had the same author, much less shared files.) The solution would be to log into the UNIX shell and remove/reinstall your active Theme, or to reinstall the Theme you just deleted. SSH is a good way to do it. When you log into as the "pi" user, these commands will start you down the road:
cd /home/pi/RetroPie-Setup
sudo ./retropie_setup.sh
So that's my experience as of day one.
Software-based LCD backlight power switch: Something I'd like to do is to tie into one of the GPIO pins and see if I can wire a simple circuit that would power on / power off the LCD backlight through some simple GPIO commands in the shell. I just find it annoying that the screen displays garbage while I'm playing games on the big screen, you know? Anyone have some thoughts on where I might want to focus my attention on the PCB?
The video conversion chip? Anyone have any details on how the CVBS (composite video) output from the A3 chipset is being massaged before sending it to the LCD? I'm wondering if it can be bent to deliver something close to full NTSC to a different LCD, or if the only real option is going to be to either tie into the composite video signal (or hijack the external HDMI) and convert and display it from there? I see that someone else here in the forum has gone the second route (internal HDMI display) but I'm hoping that there is some chance that the internal composite video may yet be salvaged?
Thank you for your time and interest,
Atari Datacenter