Raspberry Pi (64 bit Bullseye) support

[Elias Lopez]

Hello! I was hoping to see how denise would perform on a standard Raspberry pi installation, but I can’t get it to run.

I get:

pi@pi64:~ $ ~/.local/bin/denise 

(denise:2692): Gdk-ERROR **: 20:49:12.817: The program 'denise' received an X Window System error.
This probably reflects a bug in the program.
The error was 'GLXBadFBConfig'.
  (Details: serial 289 error_code 167 request_code 152 (GLX) minor_code 34)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the GDK_SYNCHRONIZE environment
   variable to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)
Trace/breakpoint trap

I am happy to help debug this as I am a software developer, I just don’t know C/C++ let alone OpenGL

I’ve attached the output of glxinfo

I’ve tried this on a Debian 64 bit Bullseye ARM VM and it seems to be fine.

[PiCiJi]

Hi,

The problem arises in the file "driver/video/glx.cpp" within the "init" method. In the past, this error already existed for another Linux distribution. I assume that other software, which also use GLX (openGL for Linux), run on your Raspberry.

Unfortunately, I can't debug the error myself without a Raspberry.
You could try some changes in the "init" method. For example, comment out lines 44 - 47.
Alternatively, you could use an old GIT checkout (a year back) and see if it works with it. Then I can draw conclusions about which changes in "glx.cpp" are the cause of this.

[Elias Lopez]

Hi Thanks for the response.

Commenting out those lines had no effect but I made some progress.

• I checked out tag v1.1.1, it doesn’t crash but I get a black screen with nothing but the UI menus etc are fine.

• I changed back to v1.1.3.1:

  • I changed lines 108-109 to the following based on what VICE was doing:
  • GLX_CONTEXT_MAJOR_VERSION_ARB, 1, GLX_CONTEXT_MINOR_VERSION_ARB, 2,
  • The reason I thought to try this was because VICE logs:

GLX version: 1.4
Getting matching framebuffer configs
Found 64 matching FB configs.
Error - Failed to obtain an OpenGL 3.2 context, requesting a legacy context

Obtained OpenGL 2.1 context
      Vendor: Broadcom
    Renderer: V3D 4.2
     Version: 2.1 Mesa 20.3.5
      Legacy: yes

‌

• With these changes in Denise, I don’t get the error on startup but I get just a black screen.

‌

[PiCiJi]

VICE seems to use a "legacy" driver if the openGL version is less than 3.2. Your glxinfo says:
OpenGL ES profile version string: OpenGL ES 3.1 Mesa 20.3.5

That will be the reason why it works there.

OpenGL 3.2 is from 2009. Can a driver update solve the problem?

[Elias Lopez]

I changed to Ubuntu Jammy for raspberry pi and used the oibaf PPA to get the latest mesa drivers, no difference.

I’ve been doing a lot of googling about opengl and cross referencing with what vice is doing and I think I understand the situation.

This is a limitation of the VC4 GPU and Mesa V3D drivers available for the RPI4 which only has OpenGL 2.1, but does conform to OpenGL ES 3.1 which is obviously not the same thing being a subset api.

VICE works on the RPI because it falls back to different rendering implementation which I guess is compatible with 2.1

Probably ok to close this issue as its seems like its going to be a fair bit more work than I hoped.

Thanks for your help and writing such a great emulator :)

[PiCiJi]

I don't know if it's worth the effort to support this old rendering engine. Do emulators, such as VICE, run fast enough on the system?

[Elias Lopez]

The hardware is certainly capable otherwise projects like Retropie wouldn’t be viable, a Raspberry pi 4 can handle things like a Nintendo 64, or Dreamcast for example with Retroarch/libretro. Even with a basic CRT shader (zfast)

They’ve got some kind of abstraction over how they use OpenGL/ES though so it works with either.

That aside, VICE Runs perfectly on a raspberry pi 4 - but not if CRT emulation is enabled and it can’t keep up. Vice implements this in CPU not GPU

My motivation for testing Denise on the PI4 is because of the Integer Scaling and CRT Shader features. If using an old rendering engine means losing the shader support, it feels like it wouldn’t be worth spending the effort on the old engine.

FWIW Putting a raspberry pi into a c64 case seems to be a popular project in the retro community :) eg https://www.thegeekpub.com/13651/raspberry-pi-commodore-64/

‌