[HN Gopher] Programming the Commodore 64 with .NET
___________________________________________________________________
Programming the Commodore 64 with .NET
Author : mariuz
Score : 105 points
Date : 2025-11-13 21:02 UTC (6 days ago)
(HTM) web link (retroc64.github.io)
(TXT) w3m dump (retroc64.github.io)
| metadata wrote:
| Such a cool side project. And with LiveReload!
| indigodaddy wrote:
| Super cool, this is what HN is all about for me.
| lysace wrote:
| It would have been cool to get some subset of the dotnet runtime
| running on the C64.
|
| This is not it. It's a desktop IDE built using dotnet that just
| assembles 6502 instructions with some extra awkward syntax.
|
| Many more elaborate projects exist. My favorite is the one that
| compiles something similar to Turbo Pascal to C64 6502. It's
| implemented in C++/Qt, but noone ever tried to market it that
| way, because why would they?
|
| https://github.com/leuat/TRSE
|
| _Turbo Rascal Syntax Error_
| indigodaddy wrote:
| Imo, this is actually way more interesting.
| bmn__ wrote:
| Programming for the C64 CPU is terrible. You couldn't even
| attempt to port a dotnet subset.
|
| There isn't a multiplication instruction, so you have to
| painstakingly reinvent all useful algorithms from the last 40
| years from nearly scratch and by the time you want to implement
| a hash you notice you're running out of RAM.
| lysace wrote:
| > You couldn't even attempt to port a dotnet subset.
|
| Because of the lack of a multiplication op code? Hmm.
| chillingeffect wrote:
| Yeah it pays to have a huge library of routines...e.g.
| multiplication for every size combo of number sizes,
| signedness. Also sorts...everything, but if you scour youll
| find many :)
| emptybits wrote:
| A generation of programmers might disagree with you.
|
| Multiplication instructions and hash tables (!) are easily
| worked around, as evidenced by decades of art and innovation
| programmed on that "terrible" CPU. There are still 6502
| programmers today delivering games, art, demoscene, etc.
|
| That CPU was a foundation of the home computer and console
| revolution: BBC, Commodore, Atari (consoles and computers),
| Apple, and Nintendo (NES).
| moring wrote:
| I don't think that games, art and the demoscene can be used
| as evidence here. Implementing something like C# means you
| have a spec to implement. You have to be creative with the
| implementation without violating that spec.
|
| All the three of games/art/demoscene on something like the
| C64 have a rough idea as the spec, but then you'll get
| creative about how much of that "spec" you can bend and
| violate to meet the technical limitations of the C64, while
| still being fun.
| zozbot234 wrote:
| It's just not the same class of devices. The tiniest IoT-
| focused subsets of .NET will still require more than 64KB
| of RAM and 192KB or so of mass storage. You _could_ try and
| implement some minimum viable WASM subset (I think the
| issues that made WASM non-viable on microcontrollers and
| the like have been addressed by now) since the overall
| architecture is likely simpler, but even that is rather
| dubious and more like something that could be appropriate
| on slightly newer 16-bit machines.
| pizza234 wrote:
| > Many more elaborate projects exist. My favorite is the one
| that compiles something similar to Turbo Pascal to C64 6502
|
| It depends on the purpose. The reference IDE is intended to
| produce real-world programs (it includes tools for sprites,
| music etc.), while high level language compilers are mostly
| academic, as they're not performant enough.
| zozbot234 wrote:
| llvm-mos https://github.com/llvm-mos/llvm-mos seems to
| generate good enough code - more than competitive with other
| high-level languages for the 6502, though perhaps not so much
| with manual assembly coders.
| bnchrch wrote:
| Question to HN .NET Devs
|
| Its been a long time since I was in the MSFT ecosystem (left just
| as wsl was getting popular).
|
| I remember thinking C#, F#, .NET and LINQ was a pretty robust set
| of tooling that was ahead of its time and certainly ahead of
| Java.
|
| At the time, the things that were holding it back was:
|
| - Poor to non existant linux support
|
| - A confusing labyrinth of MSFT web frameworks that were
| nonsensically named and often deprecated
|
| - A very GUI heavy dev and production setup
|
| I know a lot has changed since then. So how is it in 2025?
| vips7L wrote:
| Everybody's gotta bring Java into it.
| bnchrch wrote:
| Kind of like if im talking about VRBO, I should mention
| Airbnb.
|
| Similar in the heavy weight enterprise programming language
| space. If im talking about .NET I should mention Java.
| vips7L wrote:
| Not really. They're independent languages with different
| design goals. You're exact questions in this thread would
| have been just as relevant without bringing it up.
| bnchrch wrote:
| Open to you educating me here! I (maybe naively) see
| their design goals being very similar:
|
| - Enterprise Devs as the core user (Type safety, great
| stdlib)
|
| - High level OO based interfaces
|
| - Allows for low enough level programming that you can
| reasonably use in place of C/C++
|
| The differences seem to be more minor:
|
| - opinionated (C#) vs unopinionated (Java) when it comes
| to what tools / libraries you reach for.
|
| - Conservative (Java) vs Experimental (C#) when it comes
| to releasing new language features
|
| - Execution model: Java seems like a better choice for
| "run anywhere" but C# has been indexing more in this
| direction
| vips7L wrote:
| > - Enterprise Devs as the core user (Type safety, great
| stdlib)
|
| > - High level OO based interfaces
|
| > - Allows for low enough level programming that you can
| reasonably use in place of C/C++
|
| This can reasonably said about any programming language
| that is popular. These points could also reasonably match
| Go.
|
| C# and Java have had completely opposite design goals.
| C#'s design goals are to have a more powerful/complex
| language with a not as advanced runtime. Java is the
| exact opposite. They favor having a slower moving
| language while pushing the edge on having a very advanced
| runtime. They're only similar on the surface level being
| C-Like languages with a GC. The design philosophies have
| created very different languages with different
| implementations, for example async/await in C# vs virtual
| threads in Java.
| bnchrch wrote:
| To be fair. I'd be fine lumping Golang in this camp as
| well.
|
| Theyre all different languages and ecosystems.
|
| But in terms of what use cases they fill? Theyre more
| similar that not.
|
| In otherwords if I'm evaluating Java for a use case, in
| many situations, I'd also be evaluating C# and/or Golang
| along side it.
|
| Where as it would be less common for me to compare Java
| against Python, Javascript, Elixir, Erlang, Rust etc..
| tester756 wrote:
| >This can reasonably said about any programming language
| that is popular
|
| C++ does not have great stdlib, lol. Maybe "recently" it
| improved, but still.
| SeasonalEnnui wrote:
| It's a huge leap forwards from those days.
|
| - Works on linux/macos, x86/ARM64.
|
| - The mature frameworks (e.g. ASP.NET with razor pages) are
| great. Microsoft still have the same issue of pushing new and
| different ways of doing web things, but you do see a lot of
| that on the web platform in general.
|
| - CLI workflow for compilation/build/deployment is now there
| and works smoothly. VS Code extensions for a bit of
| intellisense without requiring a full IDE (if that's the way
| you work).
|
| The thing I enjoy most about modern C# is the depth/levels of
| progressive enhancement you can do. Let's say in the first
| instance, you write a proof of concept algorithm using basic
| concepts like List<T>, foreach, stream writing. Accessible to a
| beginner, safe code, but it'll churn memory (which is GC'd) and
| run using scalar CPU instructions.
|
| Depending on your requirements you can then progressively
| enhance the memory churn, or the processing speed:
|
| for(;;), async, LINQ, T[], ArrayPool<T>, Span<T>,
| NativeMemory.Alloc, Parallel.For, Vector<T>, Vector256<T>,
| System.Runtime.Intrinsics.
|
| Eventually getting to a point where it's nearly the same as the
| best C code you could write, with no memory churn (or stop-the-
| world GC), and SIMD over all CPU cores for blisteringly fast
| performance, whilst keeping the all/most of the safety.
| pmbanugo wrote:
| this performance aspects is interesting. So time to try C#
| again. I;m learning Zig for some of those reasons, but also
| because the language has a small scope and the language
| features will be smaller
| bhubert wrote:
| I use .NET at $job, and have been running arch for the last few
| years, without any problems. I also have two collegues using
| Apple silicon, also no problems there.
|
| The official aspnet core web framework is (in my opinion) good
| enough that you don't need anything 3rd party.
|
| The GUI story is not a good one though, and if I were to write
| a GUI program I'd reach for Avalonia (3rd party, free).
|
| I use Rider as IDE, but there are multiple other options.
|
| With the recent performance improvements (Span, Memory,
| Intrinsics, etc) it's possible to write quite performant C#
| these days, and with low GC pressure.
|
| You can read an overview of what's new with the language
| (although missing C#14 which was released days ago) here:
| https://learn.microsoft.com/en-us/dotnet/csharp/whats-new/cs...
| briHass wrote:
| Honestly, .NET should be the default choice for any non-trivial
| backend or non-GUI application. I assume the legacy
| (outdated/inaccurate) perception of MSFT's stewardship is the
| only reason anyone reaches for something else.
|
| AOT is a game changer for native binaries, but even with fw
| dependence, the cross platform support is excellent (we deploy
| to Linux servers frequently.)
| osigurdson wrote:
| >> .NET should be the default choice for any non-trivial
| backend or non-GUI application
|
| I personally wouldn't go that far. If you know well, it makes
| sense to use it, but you already know Java or Go, would the
| benefit delta isn't going to be that high.
|
| Somewhat famously, even Anders Hejlsberg decided to use Go vs
| .NET for the new Typescript compiler. .NET is fine (and I
| have personally used it a lot) but that doesn't mean it is
| net better than other options out there.
| celeries wrote:
| I am a full time .NET developer, experienced with both newer
| and older .NET versions.
|
| They are confusingly named, but this is the gist: - .NET
| Framework is the older version that is tied to Windows. - .NET
| is the newer version that is cross platform, and was renamed
| from .NET Core.
|
| Linux support is pretty good on .NET. I don't have as much
| experience with this personally since most of my company is
| still using .NET Framework, but I was able to get a simple .NET
| app running on Linux without any hassle.
|
| The main web frameworks I am aware of are Blazor and MVC.
| Blazor behaves more like a single-page application (without
| needing JavaScript!) and abstracts away most of the headache of
| making dynamic web pages, but generally doesn't scale as well
| from what I have seen. MVC is a little more traditional but you
| need to write some JavaScript for interactivity.
|
| I'm not fully sure what you mean by GUI heavy. Everything I am
| aware of can be accomplished with the CLI tooling.
| tester756 wrote:
| I've been running .NET web apps on Linux since 2018 (early .NET
| Core versions)
|
| ASP.NET is stable and really good web framework
| jcmontx wrote:
| Citing my own comment from another thread:
|
| I've worked with .NET for over 10 years and we built our
| startup on top of it. Here are my thoughts: Pros:
|
| * Stability
|
| * Very decent standard library
|
| * Good balance between productivity and robustness
|
| * Great package management
|
| * Extremely easy to upgrade, so essentially free goodies
| (performance) every year or so
|
| Cons:
|
| * Very MSFT dominated (obviously)
|
| * Subpar tooling outside of Windows (I'm looking at you C# Dev
| Kit)
|
| * C# has way to many features, it feels bloated
|
| * Culturally, it feels like .NET devs are less "passionate"
| about their work
|
| * The freaking stigma of being a .NET dev: you will never be as
| cool as the guys who work with Node/Python/whatever
|
| Edit: Also I'd like to add EFCore as one of the pros of the
| ecosystem. Hands down the best ORM. Others don't come close.
| keraf wrote:
| > Subpar tooling outside of Windows (I'm looking at you C#
| Dev Kit)
|
| JetBrains Rider is excellent and runs on Windows, Mac and
| Linux. It has a few Windows only features but nothing
| important for me, it's the best IDE for C#/.NET you can get
| on non-Windows platforms imo. And it's free for non
| commercial use.
| jcmontx wrote:
| You're probably right. I haven't tried it thoroughly
| vyrotek wrote:
| > you will never be as cool
|
| I quoted that on x a few days ago and got some fun replies :)
|
| https://x.com/vyrotek/status/1988737638682296388
| _zamorano_ wrote:
| At my daily job, our production servers are Linuxes, and we
| deploy our .NET code (fairly complex web app) just fine, using
| the same techniques you would with other technologies like CLI
| GitLab CI/CD, Docker, Kubernetes... Forget about GUI if you're
| not into it.
|
| The web framework craze is settling down. Microsoft seems to
| have consolidated into two web frameworks: Blazor
| (improved/extended Razor Pages) and ASP.NET for MVC, and APIs.
| I personaly don't expect another U-turn for the coming years.
|
| Blazor is really nice, and ready for production. The only
| downside I see is that Visual Studio (vanilla) struggles
| compared to another MSFT technologies. You don't need Visual
| Studio, though.
| fabian2k wrote:
| It runs perfectly fine on Linux since .NET Core.
|
| There is only one relevant web framework: ASP.NET Core.
| Microsoft is as bad at naming things as it has always been, so
| that hasn't changed. They're pretty good about not deprecating
| too much in the web area now, the big disruptive change was
| from .NET Framework to .NET Core. The Windows UI stuff seems to
| be a bit of a shitshow in terms of deprecations, but I've no
| direct experience with it.
| osigurdson wrote:
| The Linux story is much better now. Back end the day it was
| necessary to try to use Mono which wasn't fully compatible and
| the code had to have #if defs all over the place. That is
| thankfully all gone now.
|
| Most things can be done with the dotnet cli but for editing
| code, realistically you will want to use an editor like vscode,
| Rider or Visual Studio itself. I found the LSP support in vim
| quite bad for C#.
| radicalbyte wrote:
| It has been very good since around 2007/8 when ASP.NET MVC
| released. That was the first good MS web framework. You needed
| to avoid EntityFramework / WCF / Unity and anything coming from
| the Enterprise group. There were some amazing OSS frameworks
| and libraries.
|
| Then when .Net Core happened it was compelling and once that
| matured a no-brainer. On the MSFT the Alt.Net side won, MS
| hired many of the good people and the Alt.Net supporters inside
| Microsoft run the show nowadays. So now it's fine to run a
| largely MS stack on .Net.
| weinzierl wrote:
| It is only the .NET tooling. The software that runs on the C64 is
| still Commodore BASIC or 6502 assembly.
|
| Similarly a couple of years ago someone claimed to be able to
| play MP3 on the C64, but it was just a custom compression using
| some modern knowledge. Ultimately it had next to nothing in
| common with real MP3.
| zahlman wrote:
| > Ultimately it had next to nothing in common with real MP3.
|
| Designing a custom compression format that could be
| decompressed with C64 resources while still achieving good
| compression is still a very meaningful achievement.
|
| Which reminds me, maybe I should think more about that idea for
| a custom compression for GBA 4bpp graphics....
| weinzierl wrote:
| Absolutely and so is enabling people to program the C64 with
| modern tooling many are familiar with. The misleading is not
| only uncalled for but also completely unnecessary - and that
| is the saddest part.
| Razengan wrote:
| I've sworn to myself I will learn 6510/6502 assembly and make 1
| simple game for the C64 before I die.
|
| And the ZX Spectrum, and hopefully the SNES/GBA too.
|
| As an exercise to "catch up" with gaming/computing history if
| nothing else :')
___________________________________________________________________
(page generated 2025-11-19 23:01 UTC)