Some observations from a UNIX sysadmin

Present yourself, make suggestions, tell what you think of the project, ask your general questions
Post Reply
Posts: 3
Joined: Fri 26 Apr 2019 07:20

Some observations from a UNIX sysadmin

Post by Atari_Datacenter » 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:,9002
mapping register with mmap in C (gpio in this example): ... on_lubuntu
Working with multiple frame buffers:
Informing the OS of the new resolutions with fbset:

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 ./

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

Posts: 6
Joined: Mon 8 Apr 2019 23:47

Re: Some observations from a UNIX sysadmin

Post by deerwings » Sat 27 Apr 2019 02:31

Heat is definitely an issue. I haven't looked at it yet to see what it could take to improve the cooling, but near as I can figure the best solution would be a larger heat spreader with an active cooling solution to encourage airflow out of the case. That would probably resolve the heat issue, though I'm not certain the efficiency versus the payoff. Worth exploring.

Regarding the screen: If running both internal and external screens at the same time drives the heat up that significantly, then it might be something that would only be practical with a sufficiently efficient cooling system but I don't know many other practical applications for it, though I can see where you're going with that.

Regarding the Themes: I've had this issue myself, and the best solution I have come up with is backing up your themes to the rom folder, and then if you make a mistake, you can simply copy it back. Otherwise, you'd probably be best off manually selecting a theme in the .emulationstation/es_settings.cfg to something else and then performing a system reboot. I've been personally using the Pixel-TFT with sufficient font settings to make it practical on the internal display.

I would like to see a better method to switch internal and external screens, though!

Posts: 3
Joined: Fri 26 Apr 2019 07:20

Re: Some observations from a UNIX sysadmin

Post by Atari_Datacenter » Sun 28 Apr 2019 08:17

Good news?

I worked on some of the performance problems with a game in MAME that I was quite familiar with: Tokimeki Memorial Taisen Puzzle-Dama. Sure, that's a pretty strange title forr an American to be familiar with, but I've got the game in my PCB closet as part of my Konami GX motherboard collection. On the RetroStone (with RetrOrangePi) the game had some problems. The graphics were faithful, but the the sound was scratchy at times, there were some subtle slowdowns from time to time for no apparent reason, and a regular audio click every two seconds or so. Playable, but annoying, right?

I think I've made some significant improvements in performance tuning the platform. I've been writing a detailed explanation of what I tried, what I found, and how I addressed it. At this point, it is 1am and I'm going to call it a night. I'll post what I found (and I guess probably sign up to the RetrOrangePi forum and lelt them know over there -- these are all OS changes, no hardware hacks).

Are there going to be any volunteers with shell access to their RetroStone to try a few commands and evaluate the change in performance?

Atari Datacenter

Posts: 3
Joined: Fri 26 Apr 2019 07:20

Re: Some observations from a UNIX sysadmin

Post by Atari_Datacenter » Mon 29 Apr 2019 00:50

Performance tuning UNIX servers is something I do in my day job, so even though I'm just now getting up-to-speed with Linux, I thought I'd try my hand with some tuning of the RetrOrangePi distribution on my newly acquired RetroStone. At a high level, my findings (if accurate) seem to suggest that the RetrOrangePi should be customized to match the intended form factor (laptop, gameboy form-factor handheld), hardware (desktop, RetroStone), and intended use (entertainment/emulation, or desktop). Those customizations could be a one-time adjustment, or settings that dynamically changed based on which function the user has launched. But I'm getting ahead of things.


I think we'd all benefit if some others would replicate the change with the steps listed below. Then let us know if you think the benefits are real, and perhaps you could report back with your own before/after story. No permanent changes will be made to your OS image or your hardware settings. This requires root access to the device while a game is actively running on the screen (ssh would make a fine choice).


STEP 0 (BASELINE): Use only the internal LCD display. Reboot your RetroStone. If you can report what frequency scaling governor your CPUs are set to, that's appreciated. (I used "cpufreq-info" as part of the "cpufrequtils" package.) And if you can report your CPU and DRAM frequencies ("h3consumption -p"), that too is helpful. I've been using the arcade game "Tokimeki Memorial Taizen Puzzledama" because I have it in my arcade pcb collection and I know exactly how it behaves. If you can do that game, great. If you have another game that gives you some mild performance issues, you can try and report on that instead. Whatever game you've selected, please launch it before proceeding to the next step.

STEP 1 (ENFORCED CPU SETS): We're going to specifically require that certain items run on pre-designated CPUs, and at very specific priority levels. With the game still running, as root, cut and paste the following commands into your RetroStone (and in the order they're listed). The first line binds everything (that can be reassigned) to run only on CPU 0. The for loop which follows will bind all retroarch threads to the scheduler's choice of either CPU 0 or CPU 1, and with a extremely high priority level that beats almost anything else. The next two lines will re-bind the main retroarch thread (the one that consumes an entire CPU) to CPU 2 where it will run all by itself. The final two lines will re-bind the SDLAudio thread (presumably responsible for audio) to CPU 3 where it will run all by itself. This probably isn't the ideal set of bindings, but in the absence of certain details, it still makes for a good improvement. NOTE: If you exit a game and start another, run these commands again after the emulator has loaded the new game. When you are done testing, reboot your RetroStone to remove the bindings, or everything may actually run slower until rebooted.

Code: Select all

for i in `ps -eao pid`; do echo $i; taskset -pc 0 $i; done
for i in `ps -eLo tid,args | grep retroarch | grep -v grep | cut -c1-6`
chrt -r -v -p 90 $i
taskset -pc 0,1 $i
/usr/bin/renice -n -1 -p $1
taskset -pc 2 `ps -eao pid,args | grep bin/retroarch | grep -v grep | cut -c1-6`
chrt -f -p 10 `ps -eao pid,args | grep bin/retroarch | grep -v grep | cut -c1-6`
taskset -pc 3 `ps -eLo tid,fname,args | grep retroarch | grep SDLAudio | cut -c1-6`
chrt -f -p 10 `ps -eLo tid,fname,args | grep retroarch | grep SDLAudio | cut -c1-6`
STEP 2 (DISABLING UNNEEDED SERVICES): I thought the above tuning helped, but I was still getting regular clicks or semi-slowdowns every couple of seconds. I looked for the potential reasons and started to install strace when I found two Linux processes which were regularly popping up. (Neither one is necessary for a RetroStone.) The following commands will disable the services. Unless you've rebooted, you only need to run this once. These settings revert back to normal on the next reboot.

Code: Select all

systemctl stop acpid.path acpid.service acpid.socket
systemctl stop systemd-journald.service systemd-journald.socket systemd-journald-dev-log.socket
STEP 3 (TESTING): To make my own judgment on performance quality with my own choice of Tokimeki Memorial, I used the attract screen (which had sound) and then gameplay. The sound was significantly better and those slight slowdowns that were happening at regular intervals were no longer a problem. If you choose a different game, that's fine. I've targeted these tunings for the Arcade game selections (using MAME) but I *believe* they'll also work on some of the other emulators.

STEP 4 (REPORTING BACK): All done? Report back and let everyone know how it went with a reply to this topic. Any time someone can run a performance test on real machines, we all benefit. Thank you!

So, reboot your RetroStone, run the tests, and let us know how things go, willyah?

Atari Datacenter

User avatar
Administrateur du site
Posts: 393
Joined: Sat 10 Dec 2016 13:12

Re: Some observations from a UNIX sysadmin

Post by Admin » Fri 3 May 2019 15:48

Hi! Sorry I missed your message!

About HDMI switch I tried for a long time to find a way to make automatic switch between LCD and HDMI rather than using the bashfile but with no luck.
You can see discussion here on armbian forum : ... ment-64676

In the end I could read HDMI detect (HPD) but after impossible to change the display. Turning OFF LCD is OK, turning HDMI ON is another matter. If you want to give it a shot :)

From what I read on armbian forum, for H3 dual output of composite and HDMI with 2 different framebuffer is not working currently. I made some tests without success. Maybe clone '2 screen one framebuffer) could work but I could not get it to work.

SSHing is working.

Software-based LCD backlight power switch: The backlight itself is driven by AMT630A which is the RGB-CVBS converter. You can't enable/disable the power supply of the backlight directly from software. In fact it should be possible as when you turn OFF the device from software the LCD ends up being turned off. I think there's probably a signal to send through CVBS that tells AMT630A to power off. Maybe it's just when CVBS is flat 0V?

Video conversion chip is AMT630A it converts composite into RGB24. I can send you datasheet if you want.

Post Reply