07-16-2022, 01:53 AM
Thanks for cleaning up the config.txt file!
When using this new config file I'm able to run the FreeplayILI9341 options without them throwing the DMA collision error, the program even outputs that it is resetting DMA channels for use`. I'm sometimes getting random issues with these options where only random lines are drawn on all over the screen and the images are rotated 90 degrees, it seems to be swapping the widht/height as per the initial output:
The one I had compiled a while back had a line commented out where `DISPLAY_FLIP_ORIENTATION_IN_SOFTWARE` was set, as per the instructions in this thread: https://forum.freeplaytech.com/showthread.php?tid=4989.
This custom version sets the drawable area to 320x240 instead of 240x320 like the FreeplayILI9341 but there's still a lot of artifacts on the screen.
Its output is this:
It seems as if they were trying to draw additional empty lines of pixels on the screen. I noticed both display different BCM core speeds, perhaps the timing to read the pixel lines is incorrect?
When using this new config file I'm able to run the FreeplayILI9341 options without them throwing the DMA collision error, the program even outputs that it is resetting DMA channels for use`. I'm sometimes getting random issues with these options where only random lines are drawn on all over the screen and the images are rotated 90 degrees, it seems to be swapping the widht/height as per the initial output:
Code:
pi@retropie:~/Freeplay/FreeplayILI9341 $ sudo ./fbcpFilled
bcm_host_get_peripheral_address: 0xfe000000, bcm_host_get_peripheral_size: 25165824, bcm_host_get_sdram_address: 0xc0000000
BCM core speed: current: 233333333hz, max turbo: 500000000hz. SPI CDIV: 6, SPI max frequency: 83333333hz
Allocated DMA channel 5
Allocated DMA channel 1
Enabling DMA channels Tx:5 and Rx:1
DMA hardware register file is at ptr: 0xb5349000, using DMA TX channel: 5 and DMA RX channel: 1
DMA hardware TX channel register file is at ptr: 0xb5349500, DMA RX channel register file is at ptr: 0xb5349100
Resetting DMA channels for use
DMA all set up
Initializing display
Resetting display at reset GPIO pin 27
Creating SPI task thread
InitSPI done
DISPLAY_FLIP_ORIENTATION_IN_SOFTWARE: Swapping width/height to update display in portrait mode to minimize tearing.
Relevant source display area size with overscan cropped away: 768x1024.
Source GPU display is 768x1024. Output SPI display is 240x320 with a drawable area of 240x320. Applying scaling factor horiz=0.31x & vert=0.31x, xOffset: 0, yOffset: 0, scaledWidth: 240, scaledHeight: 320
Creating dispmanX resource of size 240x320 (aspect ratio=0.750000).
GPU grab rectangle is offset x=0,y=0, size w=240xh=320, aspect ratio=0.750000
All initialized, now running main loop...
^CSignal SIGINT(2) received, quitting
Quit.
The one I had compiled a while back had a line commented out where `DISPLAY_FLIP_ORIENTATION_IN_SOFTWARE` was set, as per the instructions in this thread: https://forum.freeplaytech.com/showthread.php?tid=4989.
This custom version sets the drawable area to 320x240 instead of 240x320 like the FreeplayILI9341 but there's still a lot of artifacts on the screen.
Its output is this:
Code:
pi@retropie:~ $ sudo ./fbcpFilledN64
bcm_host_get_peripheral_address: 0xfe000000, bcm_host_get_peripheral_size: 25165824, bcm_host_get_sdram_address: 0xc0000000
BCM core speed: current: 300000000hz, max turbo: 500000000hz. SPI CDIV: 6, SPI max frequency: 83333333hz
Initializing display
Resetting display at reset GPIO pin 27
Creating SPI task thread
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 320x240. Applying scaling factor horiz=0.31x & vert=0.31x, xOffset: 0, yOffset: 0, scaledWidth: 320, scaledHeight: 240
Creating dispmanX resource of size 320x240 (aspect ratio=1.333333).
GPU grab rectangle is offset x=0,y=0, size w=320xh=240, aspect ratio=1.333333
All initialized, now running main loop...
^CSignal SIGINT(2) received, quitting
It seems as if they were trying to draw additional empty lines of pixels on the screen. I noticed both display different BCM core speeds, perhaps the timing to read the pixel lines is incorrect?