Developing for DietPi

Hi there!

Just discovered this gem.
I am the author of a retro computer emulator called Continuum 93 (Continuum 93 by Enthusiast Guy) and would very much like to make it available for Raspberry Pi, and your excellent OS seems to be perfect for that.
I wrote my emulator with Monogame in C# and Monogame allows me to compile for Linux. Is that sufficient for me to deploy it on DietPi?
If not, what can I use to develop for Diet? (Preferably with C#).



let me ping our developer @MichaIng

In general, DietPi is not an own OS, it’s a set of bash script on top of a Debian image. Mainly we use Armbian, Raspberry OS or plain Debian. Next to this we support various SBC and best would be if your app would be fully able to run on ARMv7, ARMv8 and AMD64. :smiley:

1 Like

Hey Joulinar!

Thanks for your reply. As far as I remember some discussions on the Monogame forum, I ‘think’ it is possible to build for arm64 as long as I remove some references from the project. But I have to dig a bit to confirm. Could use a bit of insight first from you guys, so your ping is welcome. Right now I’m on a different kind of forest than what I’m used to. :slight_smile:


ARM64 is the main platform for DietPi.

  • 50% aarch64
  • 20% x86_64
  • 20% armv7l
  • 10% armv6l
  • brand new riscv64
1 Like

How does it access the GPU? Does it use/support some framework or specific API for that? Generally if it can use KMS/DRM and in case some OpenGL flavour, it should work fine on most platforms with Linux.

If you develop it/add support for Debian, it should work on DietPi and Raspberry Pi OS similarly. But I guess it can be made more generic to support all Linux distros, unless one finds/installs the needed framework(s) or shared libraries. Wrapping some autostart service around the executable binary and build a DEB package from it is something we could take care of for a dietpi-software integration.

For different ARM/RISC-V platforms, I guess the individual builds can be optimised to make use of all available CPU features. Generally your project sounds similar to Amiberry (Amiga emulator), which we build and provide packages for on DietPi. It is written in C++, but maybe you are still able to pick some ideas about Linux integration from it. It uses build targets to set compiler flags for the different ARM SoCs/CPUs: GitHub - BlitterStudio/amiberry: Optimized Amiga emulator for the Raspberry Pi and other ARM boards

1 Like

Hey Michalng,

Thanks for picking this up.
I am developing with the Monogame framework. I can’t say I had much brush with Linux, but this framework I am using promises that it can build for that. My worry is in “flavor”. I researched since yesterday and found out that if you install monogame on a linux platform you could simply run the .exe with ‘mono YourProject.exe’ if you install the monogame prior. I am still working on figuring things out there. There’s no notion of Debian in monogame, at least none that I could find so far. But I am confident I can eventually click with your OS.
I don’t know how much about how monogame accesses the GPU, but I figure it should be openGL since it’s cross platform. I’ve started taking some steps to test how I can interface. Will get back on this.
Again, thanks a lot for your reply, It’s useful!

Ah got it: MonoGame => Mono => .NET => C#

I using Mono on Linux still a necessity when using MonoGame or does it work with a recent .NET core as well? As Mono is basically a dying end since .NET core supports Linux natively. All Mono projects I know did or do migrate to .NET core, which serves much better performance compared to running things with the Mono runtime system.

I see OpenGL referenced, but not OpenGLES. The latter is supported on most ARM systems, the first not. However, if GPU hardware acceleration via OpenGLES really does not work, we can ship it with gl4es, an OpenGL API wrapper for OpenGLES.

Hi again!

Sorry if my answer might be a bit off, your particular english inflexion is rather difficult for me. I will improve on that, english is not my native language, so I assume a double language abstraction here. :slight_smile:

My Continuum project started on NET core 3.1 but I migrated it onto NET core 6.0 and that happened 2 months ago.
I am not sure how much of the GPU accelleration I am using. I am using a texure2D to assemble data from my video memory layers and scaling that to the screen. That I can change if needed, but I consider it a minor component.
However, I have not exausthed all means of testing my release on DietPi. I barely started. I will get back to you after some thorough testing.


1 Like

Ah okay, so “MonoGame” does not mean that “Mono” is needed. I thought so because you mentioned mono YourProject.exe. With .NET core embedded it should then work OOTB. Projects like Prowlarr do it like this.

1 Like

Yes, that also had me confused when you mentioned it.

mono Your.exe is actually a console command that alegedly can run the same executable produced for windows when on a linux environment with MonoGame installed. Haven’t tested that path yet. For now I can’t test much since I’m traveling for a couple of weeks, but probably I can build natively too with only the NET core embedded as you mentioned because I don’t like having too large dependencies to run this.

MonoGame is actually an implementation of the XNA framework made initially by Microsoft. It’s open source as well and has been my preference for a few years.

1 Like