[HN Gopher] Building a bare-metal bootable game for Raspberry Pi...
___________________________________________________________________
Building a bare-metal bootable game for Raspberry Pi in C#
Author : pjmlp
Score : 166 points
Date : 2023-12-11 09:35 UTC (13 hours ago)
(HTM) web link (migeel.sk)
(TXT) w3m dump (migeel.sk)
| DeathArrow wrote:
| Now all C# needs is a way to manually allocate/deallocate memory
| to ditch the GC if needed.
| nurettin wrote:
| That's a great idea, something like
|
| /memorymodel:scoped_refcounted
| kevingadd wrote:
| The problem with doing memory model stuff as a compile time
| flag is it's all-or-nothing, it becomes very hard to
| transition a whole app to it or even dream of making
| something like the whole standard library support it.
|
| Typically you'd see a model that allows file-by-file
| transitions so that you can slowly clean up a codebase to
| make it 'safe' for a given model. This is (afaik) roughly how
| non-nullable references were added to C#.
|
| If you look at it from that perspective, I don't think you
| would end up wanting the compiler to help you with this.
| You'd introduce some sort of 'refcounted pointer' type, maybe
| called Rc<T>, which wraps a T* + a deallocator. I can't
| imagine C# ever letting you overload the -> operator though
| so the ergonomics would be bad.
| pjmlp wrote:
| Manually memory allocation has been there since the begining in
| interop APIs, and improved later on.
|
| https://learn.microsoft.com/en-us/dotnet/api/system.runtime....
|
| There is always C++ for those that don't want a tracing GC.
| chrismsimpson wrote:
| Mojo's model looks interesting here. No GC and no ref counts,
| something akin to a reference count mechanism at compile time.
| Not sure how it works exactly and the documentation (as is the
| whole project) very alpha.
| lambda_garden wrote:
| The only way this can work in practice is restricting the
| memory patterns that the developer can use, which is what we
| see in Rust.
|
| Is it impossible to prove memory safety in the general case
| due to the halting problem?
| naasking wrote:
| It's possible to permit arbitrary memory patterns by adding
| ref counts in specific ways:
|
| https://www.microsoft.com/en-
| us/research/publication/perceus...
|
| It's interesting how much there still is to discover in
| this space, despite decades of research.
| bob1029 wrote:
| All I want for Christmas this year is for Java Epsilon GC [0]
| to be made available in .NET.
|
| Maybe I am missing something, but this doesn't seem like a very
| complicated ask. Granted, some developers would absolutely blow
| their feet off with this, but that's why you don't make it a
| default thing. Hide it behind a csproj flag and throw a runtime
| exception if the developer presses the GC.NapTime() red button
| without configuring the runtime appropriately.
|
| There are a _lot_ of use cases where you can strategically
| reorganize the problem and sidestep the need to meticulously
| clean your heaps. Running a supervisory process (which _is_
| allowed to GC itself) that periodically resets the principal
| ZGC process via business events or other heuristics is a pretty
| obvious path to me. Round-based multiplayer gaming seems well-
| aligned if you can keep allocations to a dull roar.
|
| [0]: https://openjdk.org/jeps/318
| neonsunset wrote:
| Given that GC exists as a standalone .dll / .so when
| targeting JIT, you could theoretically replace it with your
| own implementation that only supports allocation. But
| realistically this may not be desirable since the allocation
| traffic in applications can be pretty high and require a lot
| of RAM to not quickly go OOM without reclaiming the memory.
|
| There is also API to temporarily suppress GC:
| https://learn.microsoft.com/en-
| us/dotnet/api/system.gc.tryst...
| bob1029 wrote:
| > the allocation traffic in applications can be pretty high
|
| My use case is such that I have already done everything in
| my power to minimize allocations, but I have to use some
| parts of the framework which generate a small amount of
| ambient trash as a consequence of their operation. My
| desire to suppress GC is not so much about my own
| allocation story as it is keeping the gentle, gradual
| allocations from auxiliary framework items from triggering
| a nasty GC pause.
|
| My biggest pain point - every time an HttpContext is used
| there is some degree of trash that accumulates. I have zero
| control over this unless I want to write my own HTTP+web
| socket implementation from zero.
|
| The current solution for me is to GC as often as possible
| in workstation mode, but I would find a zero GC solution
| even better for this specific scenario. I suspect "rapid
| GC" is only sustainable while total working set remains
| small-ish. In the future, I may want to operate with
| working sets measured upwards of 10 gigabytes.
| evntdrvn wrote:
| If you raise issues on the asp.net repo and tag David
| Fowler, he's pretty passionate about removing allocations
| whereever possible :)
| superfist wrote:
| Something like this: https://github.com/kkokosa/UpsilonGC ?
| thomasz wrote:
| Huh. That's interesting.
|
| I can see something like this be useful in certain
| circumstances. But I would intuitively assume that gen0
| collection is probably a better compromise.
| kevingadd wrote:
| It's been pretty straightforward to do this since the start,
| since C# has had structs and pointers the whole time. It's
| gotten a lot easier now that there are safe bounds-checked
| pointer abstractions (Span and Memory) so that you can work
| with raw memory anywhere you want without constantly having to
| manually do safety checks to avoid heap corruption. 'where T :
| unmanaged' means you can finally write generics around pointers
| too.
|
| now that you can return refs instead of just passing them
| around, that's also really nice for cases where you want to
| pass around an interior pointer into some sort of data
| structure - you can use refs whether a value is allocated via
| the GC or malloc or stackalloc.
| fulafel wrote:
| UEFI app using the graphics API there, not really bare metal.
| Interesting hack nonetheless.
| shortrounddev2 wrote:
| What would be more bare metal than UEFI?
| nurettin wrote:
| I guess something like an OS that boots and then only plays
| the game using a raw memory page for vga and interrupts for
| keyboard input, not something that is hosted on UEFI.
| plagiarist wrote:
| This is also what I was expecting. Flashing the device with
| some bootloader at the very least. It's a cool project but
| I'm not as interested in UEFI.
| galangalalgol wrote:
| Or controlling a DAC hat to drive s video, or using lvds.
| Microcontroller techniques make more sense than trying to
| use the gpu in a pi, at least it seems that way to me. Is
| there is enough known about the gpu in any of the
| versions of the pi to forgo the blob when making a video
| buffer?
| shortrounddev2 wrote:
| Like FreeDOS?
| nurettin wrote:
| Like freedos, much less sophisticated, without a
| filesystem or extended memory driver
| bluescrn wrote:
| Generating a video signal from GPIO pins?:
| https://www.hackster.io/news/outputting-a-video-signal-
| from-...
| woodrowbarlow wrote:
| or maybe directly from a floppy drive?
| https://hackaday.com/2021/07/08/c64-demo-no-c64/
| fulafel wrote:
| Programming the hardware ("metal") natively would be more
| bare-metal than imp!ementing a hosted UEFI app that does
| stuff through UEFI APIs. In this case eg programming the
| VideoCore hw in the Pi.
| not_the_fda wrote:
| https://www.st.com/en/evaluation-tools/32f469idiscovery.html
| nazgulsenpai wrote:
| https://github.com/nifanfa/MOOS
|
| I ran across this link-hopping through GitHub repos after
| reading the article. Its x64 but might be closer to what you
| were hoping for.
| andsoitis wrote:
| I haven't programmed against .net in almost 15 years so it was
| cool to see where the ecosystem is today:
|
| * latest version is 8.0, released Nov 2023
|
| * cross-platform: Windows, macOS (incl. ARM64), and Linux
|
| * can not only target desktop (Windows & macOS) and server, but
| also WASM, Android, iOS
|
| * used in game development (Unity, Godot, MonoGame, Stride,
| FlatRedBall, Everyone, CryEngine, Unigine)
|
| * can target embedded development ("IoT")
|
| * developer tools (Visual Studio) that works across Windows,
| macOS, and Linux
|
| (source: https://dotnet.microsoft.com/en-us/)
| Zambyte wrote:
| > developer tools (Visual Studio) that works across Windows,
| macOS, and Linux
|
| Dang I was really excited when I saw this because I thought I
| missed something, but still only support for Windows :(
| andyjohnson0 wrote:
| Visual Studio for Mac is a thing and I find it pretty good.
| It doesn't feel as feature complete as the Windows version,
| but I've never found anything I couldn't work around.
|
| Unfortunately it's being retired at the end of August next
| year. Thanks a bunch Microsoft.
| hu3 wrote:
| https://www.jetbrains.com/rider/
|
| is amazing and cross-platform. From the same authors of
| ReSharper plugin for Visual Studio.
| cptskippy wrote:
| Rider and VS Code are slowly killing Visual Studio for
| .NET development. Unless you're using .NET Framework
| (legacy framework with confusing name), you're likely
| better served using anything else.
| calamari4065 wrote:
| For a long time, the only reason I ever needed to open VS
| was for WinForms and WPF visual editing. Earlier this
| year, Rider implemented a WYSIWYG editor for those
| frameworks. I think based on Avalonia.
|
| Now I have no reason to use VS at all, and my life is
| better for it
| andyjohnson0 wrote:
| > Rider and VS Code are slowly killing Visual Studio for
| .NET development.
|
| You're probably right, but I never understand the dislike
| for VS on HN. For me it's s a reliable, capable tool.
| cptskippy wrote:
| My only complaint with VS is that it's optimal resource
| requirements always seem to be just beyond the limits of
| my work issued machine. Functionally I have no issues
| with it and it's worlds better than a lot of other IDEs
| that I've used.
| pjmlp wrote:
| Except VS is the first party IDE, and Microsoft already
| acknowledged VS Code will never provide feature parity
| with VS.
|
| Rider, being a 3rd party IDE, will always be playing
| catchup with VS and .NET tooling from Microsoft.
| cptskippy wrote:
| > Microsoft already acknowledged VS Code will never
| provide feature parity with VS.
|
| That's correct and misleading. The features that VS
| supports that aren't present in VS Code are mostly legacy
| features that need to exist for legacy support reasons
| and are not being utilized in modern development.
| pjmlp wrote:
| Like native desktop Windows applications, and server
| profiling tooling?
|
| This has been asserted by Microsoft employees in .NET
| podcasts, and on twitter, maybe start paying attention?
| all2 wrote:
| I'll second Rider. Well worth the money, in my
| experience. I use Rider products exclusively on Linux,
| and they tend to work well.
| znite wrote:
| There's also Jetbrains Rider for .net on mac & Linux (google
| it)
| pjerem wrote:
| & Windows
|
| Because it's better than VS anyway ;)
| Zambyte wrote:
| I'm familiar. I was looking for Visual Studio, which is not
| Rider.
| Mountain_Skies wrote:
| They might have meant Visual Studio Code, which due to
| Microsoft's continued commitment to naming things poorly,
| causes a good deal of confusion. VS Code doesn't have all the
| features of Visual Studio but it's turning into its own
| impressive ecosystem that even diehard Microsoft haters love.
| donny2018 wrote:
| You almost can't even escape it at this point. VS Code
| ecosystem is a beast.
| pjmlp wrote:
| The only reason why I tolerate that Electron app, is
| exactly some tooling only supporting it, e.g. VS Code is
| now the official IDE for Powershell.
| bad_user wrote:
| WASM, Android, and iOS targeting is subpar, though. For multi-
| platform client-side targeting, Kotlin is actually more
| interesting.
|
| .NET was always built for showmanship, with somewhat
| disappointing results when actually tried.
| jayd16 wrote:
| What makes kotlin more interesting besides the first class
| Android support?
| bad_user wrote:
| The latest Kotlin can target WasmGC. WasmGC became enabled
| by default, quite recently, in both Chrome and Firefox:
|
| https://developer.chrome.com/blog/wasmgc/
|
| Kotlin's support is in Alpha right now, but works well, and
| it's one of the first language implementations that can
| target WasmGC:
|
| https://blog.jetbrains.com/kotlin/2023/12/kotlin-for-
| webasse...
|
| By comparison, .NET's Blazor targets LLVM, and they either
| AOT or JIT, however the client has to download a heavier
| runtime that has at least a garbage collector (nevermind
| the JIT), and is less than ideal. Basically, the original
| Wasm was designed for languages with linear memory and
| still makes a great target for C++ or Rust, but not for
| managed languages like Kotlin/Java. dotNET's WASM is there
| only to support Blazor, which is a web framework, a sort of
| successor to Web Forms and whose future is uncertain.
| Speaking of which, you're better off with MVC + HTMX, but I
| digress. So for more interesting use cases, Kotlin is
| actually ahead in their Wasm support.
|
| For multi-platform support, the company behind it has a
| vested interest in targeting multiple platforms, and Kotlin
| Multi-platform support also has Google backing. So, for
| one, you can share business logic on iOS, as you can
| integrate Kotlin libraries into Swift applications:
|
| https://kotlinlang.org/docs/multiplatform.html
|
| And they have been porting Jetpack Compose to the desktop
| and to iOS (and can be used with Wasm in the browser, too):
|
| https://github.com/JetBrains/compose-multiplatform
|
| Also, see this year's keynote at KotlinConf:
|
| https://www.youtube.com/watch?v=c4f4SCEYA5Q&t=2903s
|
| Over on dotNET side, the blessed solution by Microsoft, for
| targeting iOS, Android, or the desktop, is right now .NET
| MAUI. So, where's Xamarin? Where's Silverlight for that
| matter? That's right, Microsoft changes multi-platform
| solutions like they change socks, and I don't understand
| how anyone could trust them for a multi-platform solution.
| neonsunset wrote:
| WasmGC is a prototype that only supports the bare minimum
| that is enough for languages with high level constructs
| only but not for something like C# which has interior
| object pointers (ref) and uses them heavily for
| performance (spans are built on top of them).
|
| The API of WasmGC is really rudimentary.
|
| With that said, you can track support of various WASM
| features by .NET here:
| https://github.com/dotnet/runtime/issues/94351
|
| I don't understand how the logic of your post works
| however, WASM in .NET is already used in production
| versus something that is an early alpha? Also, on Kotlin
| and targeting something that is not Android - "Java
| Interop" that's all I need to say.
| wiseowise wrote:
| What's wrong with Java interop?
| mihular wrote:
| MAUI is rebranded Forms and while MS is pushing it, it's
| by far the only way to build an Android UI. You can build
| it natively, sort of like since the beginning. While
| still supported, Xamarin transitioned quite nicely into
| .NET where can take all of the advantages. And you get a
| good reply about WasmGC in the other post. Also .NET is
| ahead when it comes to cross platform UI compared to
| Kotlin - there are libraries such as Avalonia, Uno and
| others. And so on and so forth.
| naavis wrote:
| How have I missed Uno! I was familiar with Avalonia, but
| first time hearing about Uno. I'd love to see more UI
| frameworks for .NET that also work on Linux.
| WillPostForFood wrote:
| _it 's by far the only way to build an Android UI_
|
| far from the only way! (as you explain).
| unusualmonkey wrote:
| Seems strong to say .net is mostly showmanship... when
| your main contention is another framework has _alpha_
| support for a different GC.
| pjmlp wrote:
| Kotlin is really only relevant for Android, and because
| Google says so.
|
| And even in spite of that, they had to backtrack on
| leaving Java behind, as Android was slowly not able to
| consume modern Java libraries.
|
| Kotlin on the browser lags behind Blazor, and
| Kotlin/Native was so badly implemented they had to redo
| the whole memory management concept, originally
| incompatible with JVM semantics.
| superfist wrote:
| You have either outdated info or outdated experience
| gregmac wrote:
| > WASM, Android, and iOS targeting is subpar
|
| How so?
| tuwtuwtuwtuw wrote:
| > showmanship
|
| What do you mean by that? I know what the term means but
| considering it's one of the most used programming stacks I
| don't understand what you mean when you use it.
| jeswin wrote:
| The only missing thing in NativeAOT (for my use cases) is EF
| Core. It's getting there. Once EF Core works well on NativeAOT,
| C# would be a fantastic alternative to Go.
| neonsunset wrote:
| Amazon has sponsored the author of Dapper to work on Dapper AOT
| for this exact reason since it's an important target for AWS
| Lambdas.
|
| https://aot.dapperlib.dev/
| hypeatei wrote:
| Is there a blog post on the Amazon sponsorship? Couldn't find
| anything on a quick search.
| neonsunset wrote:
| https://twitter.com/marcgravell/status/1713308311993372959
| leosanchez wrote:
| Marc Gravell himself works in Microsoft, doesn't he ?
| evntdrvn wrote:
| yup, unless that's changed recently. he and Nick Craver
| have been making some great impacts there.
| cardanome wrote:
| Can it compete with golang on compilation speed?
|
| It doesn't need to be exactly as fast but similar ball-park
| would help. If it could, then it would indeed be a fantastic
| alternative.
| pjmlp wrote:
| Yeah, because specially you can do everything with JIT and
| only AOT when publishing, and it is still reasonable anyway.
|
| Go isn't special, the world just happened to forget how fast
| AOT compiled languages with modules used to be, before C and
| C++ took over with their text file inclusion model.
| leosanchez wrote:
| > Can it compete with golang on compilation speed?
|
| No.
| jacquesm wrote:
| I've been looking at the various very small microcontroller/SBC
| alternatives out there and it is extremely impressive what you
| can get for $50, $10, $5 or even $3 in some cases. Arduino's,
| Esp32's, The Raspberry Pi's (including the Pico!) and the
| Teensy's (a bit more expensive but very capable) all offer an
| amazing amount of computer for very little money.
|
| Between those four there isn't a whole lot that you couldn't
| make. I'm interested in these because my kids are of an age where
| toying around with hardware is something they fancy and this
| makes it all very much real-world, seeing an LED blink or a
| computer respond to a button press and move a servo is a
| completely different experience from what's happening on their
| screens of mobile computers and laptops and that half-way house
| between hard core electronics and software is a nice step for
| them to get more familiar with what computers really are (besides
| entertainment and homework).
|
| Definitely going to try this game!
| Decabytes wrote:
| What does one need to learn to begin to attempt something like
| this? Seems like the author works on .NET for Microsoft so that
| certainly helps!
| alexb_ wrote:
| Whenever I see "bare-metal" thrown around, I think about how
| Atari Pong was _literally all hardware_ , as in the entire game
| was printed on the circuit board as actual physical logic gates.
| With the advancements of modern technology, I wonder if it's
| possible to put something much more complex yet completely
| functional as a standalone program on a circuit board.
|
| https://i.redd.it/kxks306cu9y81.jpg
| Frenchgeek wrote:
| https://twitter.com/sylefeb/status/1258808333265514497 ?
| darknavi wrote:
| Minecraft redstone is what you're describing at a certain
| level.
| evntdrvn wrote:
| Michal Strehovsky rocks. I appreciate that he pushes the edge
| from within Microsoft :)
| mtnygard wrote:
| Did I miss a step in the article? The headline is about Raspberry
| Pi, but the example says x64 and uses UEFI. AFAIK the Pi doesn't
| use UEFI.
| not_the_fda wrote:
| It looks like the article was intended for x84 UEFI and then
| they changed the title to Raspberry Pi for the clicks. Nothing
| in the article applies to the RPI, nor mentions it.
| mtnygard wrote:
| The only RPi "thing" I could see was the tricolor triangle at
| the start of one of the videos.
| neonsunset wrote:
| Raspberry Pi (assuming 4?) supports UEFI externally. bflat can
| target Aarch64 ISA and UEFI as a platform producing compatible
| binaries that can be booted up without any further post-
| processing.
| MStrehovsky wrote:
| The repo does mention the Pi. I just forgot to talk about the
| Pi specifically in the article, sorry.
| https://github.com/MichalStrehovsky/uefimaze
___________________________________________________________________
(page generated 2023-12-11 23:00 UTC)