Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
60 Frames Per Second?
#1
Hello, all, 

Apologies in advance if this has already been answered... 

I finally got my kit put together am so happy with it - initially I was a little underwhelmed due to issues with the display.  Frame rates were not good and it was introducing latency that made playing action games link Ninja Gaiden a chore.  I had been playing the damn think pretty much nonstop since I finished the build on whatever charged the battery shipped with.  So after charging for a few hours, I came back to the device and then started fiddling with the driver settings. I switched to "full screen" and then promptly switched back to the "gameboy crop" setting.  After charging and the switching back and forth of the driver settings, I notice my frame rates were rock solid - had to be 60 FPS and all latency was gone (that I could perceive).  I just don't know what change resulted in the improvement, so my questions are:

Does the freeplay retropie build throttle down CPU/GPU usages when the battery is low?  

Does anyone in the know suspect that changing the driver settings back and forth may have tripped some setting that resulted in the improved frame rates I am seeing?  

And finally, can anyone guide me on what the optimal configuration settings would be to ensure that I keep getting this silky smooth frame rates I am seeing?  


Truly, after the change, the device went from "oh, that's neat", to "Wow that's ****IN Amazing!!!".  

60 FPS made this my favorite retro toy.  Can not wait to buy a couple more to build for family and friends.  Thanks for any info you all have!!! 

- John
Reply
#2
Thanks John!

We at Freeplay actually had a somewhat quiet release of a new display driver, but decided to leave it disabled by default since it can impact battery life. To what extent, we are currently unaware, but it shouldn't be anything terrible, and are aware of no low battery throttling that happens (though more strenuous games could very easily cause the framerate to stutter due to the CPU downclocking to compensate for that heat).

I will say that all thanks go to juj's REPO (LINK) which he is continuously updating. We found the version we compiled was good enough that rather than ask users to compile it from source (which could be a bit much for some of the not-so-*nix-savvy), we just bundled a bunch of precompiled binaries and installed them by default in the newer images. If you don't have the ability to update via one of our images (savegames, scraped data), then we have a repo HERE with everything so you can install it on an already setup image.

To do so, just SSH in with a terminal or TTY client of your choice (or plug a keyboard in and exit to terminal by quitting emulationstation from the menu) and run the following:
Code:
git clone https://github.com/mootikins/freeplayili9341
cd freeplayili9341
Then depending on your Freeplay unit, run the corresponding setup script with either:
Code:
./setupCM3.sh
OR
./setupZero.sh

You may need to run whichever you need as sudo since some super user stuff needs to be done, but we didn't encounter any issues with this during our testing. A simple reboot of the system with the power switch at this point, and you should now have the wonderful high speed driver available to be switched to in your RetroPie Menu under Freeplay Display Driver!
If anyone runs into any issues with this, please contact me or TheFlav and we'll do our best to help you TS and get any errors in the repo fixed right away, and if you see any features you want that are in the repo I linked above we'll do our best to update the binaries with those newer versions.

As far as I am aware, there are no other options needed to keep that silky smooth framerate, but if you are savvy a flip through that repo and user compile could improve battery life and performance, though I only recommend doing so at your own risk. If your SD gets a little messed up by something, I recommend looking at the install script and finding the location and filename needed for the replacement of the old driver.

Thanks for enjoying our hard work!
Matthew
Reply
#3
(07-30-2018, 11:26 AM)Mootikins Wrote: Thanks John!

We at Freeplay actually had a somewhat quiet release of a new display driver, but decided to leave it disabled by default since it can impact battery life. To what extent, we are currently unaware, but it shouldn't be anything terrible, and are aware of no low battery throttling that happens (though more strenuous games could very easily cause the framerate to stutter due to the CPU downclocking to compensate for that heat).

I will say that all thanks go to juj's REPO (LINK) which he is continuously updating. We found the version we compiled was good enough that rather than ask users to compile it from source (which could be a bit much for some of the not-so-*nix-savvy), we just bundled a bunch of precompiled binaries and installed them by default in the newer images. If you don't have the ability to update via one of our images (savegames, scraped data), then we have a repo HERE with everything so you can install it on an already setup image.

To do so, just SSH in with a terminal or TTY client of your choice (or plug a keyboard in and exit to terminal by quitting emulationstation from the menu) and run the following:
Code:
git clone https://github.com/mootikins/freeplayili9341
cd freeplayili9341
Then depending on your Freeplay unit, run the corresponding setup script with either:
Code:
./setupCM3.sh
OR
./setupZero.sh

You may need to run whichever you need as sudo since some super user stuff needs to be done, but we didn't encounter any issues with this during our testing. A simple reboot of the system with the power switch at this point, and you should now have the wonderful high speed driver available to be switched to in your RetroPie Menu under Freeplay Display Driver!
If anyone runs into any issues with this, please contact me or TheFlav and we'll do our best to help you TS and get any errors in the repo fixed right away, and if you see any features you want that are in the repo I linked above we'll do our best to update the binaries with those newer versions.

As far as I am aware, there are no other options needed to keep that silky smooth framerate, but if you are savvy a flip through that repo and user compile could improve battery life and performance, though I only recommend doing so at your own risk. If your SD gets a little messed up by something, I recommend looking at the install script and finding the location and filename needed for the replacement of the old driver.

Thanks for enjoying our hard work!
Matthew

I'm trying to get this driver working on my FPZ. It works as I boot up and navigate around emulationstation, but the instant I launch any game the display stops updating. If I have HDMI attached the HDMI screen continues to work.

The easiest way for me to see what is happening was to stop the fbcpZero unit & run it in the foreground over ssh.

As I boot, here is the output:

Code:
root@vivgba:/home/pi# systemctl stop fbcpZero
root@vivgba:/home/pi# /usr/local/bin/fbcpZero
bcm_host_get_peripheral_address: 0x20000000, bcm_host_get_peripheral_size: 33554432, bcm_host_get_sdram_address: 0x40000000
BCM core speed: current: 250000000hz, max turbo: 400000000hz. SPI CDIV: 6, SPI max frequency: 66666667hz
Allocated DMA channel 3
Allocated DMA channel 1
Enabling DMA channels Tx:3 and Rx:1
DMA hardware register file is at ptr: 0xb4b50000, using DMA TX channel: 3 and DMA RX channel: 1
DMA hardware TX channel register file is at ptr: 0xb4b50300, DMA RX channel register file is at ptr: 0xb4b50100
Resetting DMA channels for use
DMA all set up
Initializing display
Resetting display at reset GPIO pin 27
InitSPI done
Relevant source display area size with overscan cropped away: 1024x768.
Source GPU display is 1024x768. Output SPI display is 320x240 with a drawable area of 302x202. Applying scaling factor horiz=0.29x & vert=0.26x, xOffset: 18, yOffset: 9, scaledWidth: 302, scaledHeight: 202
Creating dispmanX resource of size 302x202 (aspect ratio=1.495050).
GPU grab rectangle is offset x=0,y=0, size w=302xh=202, aspect ratio=1.495050

Then, I launch a game (for example, using lr-gambatte). The status of all the DMA channels is dumped and fbcpZero exits.

Code:
GPU grab rectangle is offset x=0,y=0, size w=302xh=202, aspect ratio=1.495050
DMA channel 0 has peripheral map 0 (is lite channel: 0, currently active: 0, current control block: (nil))
DMA channel 1 has peripheral map 7 (is lite channel: 0, currently active: 0, current control block: (nil))
DMA channel 2 has peripheral map 0 (is lite channel: 0, currently active: 0, current control block: (nil))
DMA channel 3 has peripheral map 17 (is lite channel: 0, currently active: 1, current control block: 0xdf4fe6a0)
DMA channel 4 has peripheral map 0 (is lite channel: 0, currently active: 0, current control block: (nil))
DMA channel 5 has peripheral map 11 (is lite channel: 0, currently active: 0, current control block: (nil))
DMA channel 6 has peripheral map 13 (is lite channel: 0, currently active: 1, current control block: (nil))
DMA channel 7 has peripheral map 0 (is lite channel: 1, currently active: 0, current control block: (nil))
DMA channel 8 has peripheral map 13 (is lite channel: 1, currently active: 0, current control block: (nil))
DMA channel 9 has peripheral map 0 (is lite channel: 1, currently active: 0, current control block: (nil))
DMA channel 10 has peripheral map 0 (is lite channel: 1, currently active: 0, current control block: (nil))
DMA channel 11 has peripheral map 0 (is lite channel: 1, currently active: 0, current control block: (nil))
DMA channel 12 has peripheral map 0 (is lite channel: 1, currently active: 0, current control block: (nil))
DMA channel 13 has peripheral map 0 (is lite channel: 1, currently active: 0, current control block: (nil))
DMA channel 14 has peripheral map 0 (is lite channel: 1, currently active: 0, current control block: (nil))
DMA channel collision! DMA channel 3 was expected to be assigned to our peripheral 6, but something else has assigned it to peripheral 17!
System is likely unstable now, rebooting is advised.
root@vivgba:/home/pi#


It seems something else is taking DMA channel 3 as soon as I launch a game. It's not clear to me what. Nothing interesting in dmesg or journalctl. I tried to use 'lsdev' but it's looking in /proc/dma which doesn't exist.

I haven't tried with a fresh image since I'd prefer to use this one; i've installed some extras and modified some scripts, and also don't want to open up my case.
As far as I know nothing I've done should impact this... let me know if you have any thoughts or want to see any config files.
Reply
#4
Hey viviridian, if you'd want to try the latest SD image we have linked at https://www.freeplaytech.com/build/ you would get the files directly that way.
In the main RetroPie menu, there should be an option for switching to the other fbcp drivers. You may need to reboot after selecting fbcpZero. In fact, I think we're going to auto-reboot after selecting a driver (in the next image).
It also has a new way of starting fbcp, so that if it dies (for whatever reason), then it will restart itself. As for the DMA stuff goes, I can ask Mootikins to jump back in here. I think he can tell you how to use a different channel (or a pre-built binary he probably has).
Card Fighters' Clash 2 English Translation ( http://cfc2english.blogspot.com/ )
Neo Geo Pocket Flash Cart and Linker Project ( http://www.flashmasta.com/ )
Avatar art thanks to Trev-Mun ( http://trevmun.deviantart.com/ )
Reply
#5
Hey Viridian, sorry to hear about the issues.
The first thing I'd try is our new update to systemd and see if the autorestart will just restart the service and get everything working as it should. To do this, go to ~/Freeplay/freeplayili9341 and pull from the repo with git pull. then if you ls, you should see some new .sh files. Run, in this order, uninstall.sh, fbcpSystemdConvert.sh, then setupZero.sh. This should convert everything, including the old fbcp driver, to systemd and could be the easiest fix for this issue since I suspect that your image is old enough that /boot/config.txt's HDMI mode is still set to 1024x768 and the resolution change can cause some problems for the new driver.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)