4k screen issues

[NotFred]

I've been trying to to get ADFFS working on a pi zero 2W for a while now, and kept running into errors with both ADFFS itself and then with trying to launch games when I could get it to work. I've narrowed the issue down to the screen I was using.

By default I had been using a 4k 144Hz screen. This was producing errors when trying to launch ADFFS. Riscos was defaulting to using 640x480 75hz resolution, and changing this to 60Hz and other resolutions would change the error codes. When I tried this towards the end of last year I could get ADFFS to launch with some resolutions, however games themselves would crash. When I tried again with the most recent version I couldn't not find any settings that would get ADFFS to work.

I then moved to using a 1080p (I think actually 1920x1200) 60Hz screen, and suddenly everything worked. I connected to this screen via a HDMI to DVI converter, but I don't believe this should make a difference? Everything was being installed via pacman.

I don't know if this is a known issue or not, or whether this is related to ADFFS, Riscos or the pi itself. I couldn't find any discussion of high resolution screens elsewhere on this forum. If this is a known issue, are there any workaround to getting this to work on a high resolution screen? If this is not a known issue I would be happy to help debug it and record what errors were being thrown.

[JonAbbott]

You're the first to report it.

What were the errors?
What resolution and bpp was the desktop in?
How much RAM do you have allocated to the GPU?
What build of ADFFS is it loading on the 4K and 1080p monitors and is it the same build? Let me know what *HELP ADFFS says.

It could be any number of things, but GPU RAM exhaustion sounds the most likely.

[NotFred]

Thank you for your reply, I've been doing some additional testing which has some interesting results.

HELP ADFFS reports: ADFFS 2.88 (28 Mar 2026) ARMv7 32bit overlay high vector.
Both screens were tested using the same build (in fact the same pi entirely moved between the screens).

Initial testing was done with gpu_mem=64. The 4k screen defaults to 640x480, 75Hz, 256 colours. This fails with the message:
"Internal error on data transfer at 202DD690". I also tested the same resolution at 60hz, and 800x600 at both refresh rates, and these all failed with the number 202DD630.

However it appears in my initial testing I did not try enough resolutions, because as I went higher I found that 1024x768@60hz, 1024x768@75hz, and 1920x1080@60hz all work. All still at 256 colours.

I tried changing to gpu_mem=128 in the pi config. Failing resolutions still failed, however the errors changed to 202DD5F0 for the default and 202DD650 for the others. I reverted this to 64 for the next tests.

I then tried these four resolutions on the 1080p native monitor, and all worked. However I realised this monitor was defaulting to 16 million colours. Testing this monitor at 640x480 with 256 colours produced an error at 202DB550. I then re-tested the 4k monitor at 16 million colours and the four test resolutions now worked.

So my conclusions from this are:
* The actual screen does not matter, except that with my 4k screen RiscOS picks a very low default resolution (this is actually mentioned in the RiscOS FAQ)
* I have only found errors to occur in a narrow band of low resolutions at 256 colours. It just happens my screen was defaulting to one of them.

So I have a way forward and suspect this is only of academic interest. But might be useful for anyone else running into the same issue

[JonAbbott]

HELP ADFFS reports: ADFFS 2.88 (28 Mar 2026) ARMv7 32bit overlay high vector.
… The 4k screen defaults to 640x480, 75Hz, 256 colours.

That will be the issue - the overlay build requires an 24bpp desktop mode. It should have reported an error when the GPU driver failed to create the overlay ADFFS requires. It may have report an error, but in a way that didn’t stop the game from running further.

I’ll have to see what changing to ”MODE 13” does when the desktop is in an 8bpp mode, I suspect it’s going to report an error but with no display to see it! I’ll change the JIT so it does a full abort and reports a suitable error if it’s running when the overlay fails to get created. I’ll also revise the requirements section on the download page, it should list a 24bpp desktop mode from when overlays were first introduced.

Thank you for reporting the issue, I probably would never have found it as the Pi normally defaults to a 24bpp mode.

I had originally planned to fall-back to a non-overlay build if ADFFS is loaded in a mode that wasn’t 24bit or EDID is enabled, but I seem to recall I couldn’t determine if EDID is active as the OS doesn’t expose it.

I did code an EDID build of ADFFS, that I’ve never released, which essentially blits directly to the current display, without changing mode or using overlays. It was primarily created for the Pinebook Pro as its video driver is about as bare-bones as you can get. I didn’t get far with it though as there’s a bug in the PBP video driver that prevents ADFFS from installing its video driver. That was reported to R-Comp at the time and various changes were made to the OS, but the issue wasn’t resolved…as it’s closed source I’m reliant on R-Comp finding and fixing the bug.

Anyhow, I digress, but the EDID may have worked here so I’ll look at resurrecting it.

[NotFred]

Thanks for the extremely informative reply!

[JonAbbott]

I tested both MODE 13 and some games from an 8bpp desktop mode and they all worked, so I’m now unsure why it didn’t work in your case. I was using 1280x1024x8bpp, which is as high as my screen would go.

I probably did test this scenario when I originally developed overlay support and have just forgotten, which would explain why I didn’t put 24bpp in the Pi requirements.

If you’re in a position to recreate the issue, could you run a game from the Supervisor prompt as follows:

Code: Select all

Press F12
GOS
DIR $.Apps.Games (or whatever you have them installed)
!Lemmings (any game that you could see the abort will do)

When it Aborts:

Code: Select all

Where
ShowRegs
(grab screenshot)
BASIC
PRINT MODE
(note the mode)
QUIT
JITShowRegs
(grab screenshot)

[NotFred]

I think I might have conflated two issues in my original post. I can no longer reproduce the game aborts, I can only see aborts when launching ADFFS itself in either 640x480x8bpp or 800x600x8bpp. Resolutions higher than that work, even in 8bpp.

I was originally trying to get this to work in November of last year. At that time, I would see ADFFS aborts in some resolutions, and game aborts even in resolutions when ADFFS itself worked. Reading the around the forum, I suspect I had been running the 2.87 release that was actually an unstable test build mentioned in the 2.87 release thread. Even if some of my ADFFS aborts were resolution related, I suspect the game aborts I was seeing were related to the test build.

When I returned to trying to get this to work using 2.88, I initially saw ADFFS aborts as my screen had defaulted to 640x480x8bpp. As I thought I was seeing the same errors again, I may not have searched as thoroughly as I could have for a working resolution. It turns out I only see issues at those two low resolutions mentioned, and no longer see game aborts.

All of that said.. I'm assuming those commands will work to get details for the ADFFS aborts as well, just replacing the game launch command with launching ADFFS itself. I'll investigate this and post what I find

[NotFred]

I've attempted launching ADFFS (not a game) following the above commands, and unfortunately I don't think the error I get is useful.
I.e.

Code: Select all

Press F12
GOS
DIR $.Apps.Games
!ADFFS

I get an error "Error: Window Manager is in use (Error number &104)". However I get this error even in resolutions I know were working when launched normally (e.g. 1920x1080x24bpp), so I suspect this is related to how I'm trying to launch it and not the same issue as previously.

I did try some additional modes.
Mode 28 gave me 640x480x256 colour, and produced the error below:

scrn1.png (44.77 KiB) Viewed 2007 times

ADFFS abort.jpeg (164.39 KiB) Viewed 2007 times

(Excuse the improvised phone camera screen shot, I'm not sure how to take a screen capture when it is in this state and once I press cancel the desktop is corrupted and unusable)

Mode 13 gave me 720x400x256 colour and produced I think the same error (my screen is extremely blurred in this resolution but I think the number was the same).

Manually setting 1280x1024x256 colour, ADFFS worked as expected.

[JonAbbott]

None of that is useful I’m afraid. You need to follow my instructions above to get meaningful information.

You can’t run !ADFFS from the Supervisor as it will fail when it tries to load the Filer…which is the “Window Manager in use” error. You need ADFFS to be already loaded before you run through my test above.

Running a game from Supervisor however should leave you at the Supervisor prompt when it Aborts, allowing further checks to be performed to narrow down where the Abort occurred.

A Phone is the only way to capture this info on real hardware, so that’s fine.

[JonAbbott]

In response to your PM, yes I’ve read both of your replies above. The 2.87 build that was initially released contained code from 3.00 which would have crashed all over the place.

2.88 resolved those issues, but your desktop resolution issue is something else that I’ve not managed to reproduce.