Making SNES ROMs using C# • Hacker News Board

Re: Making SNES ROMs using C#

#11

Post by KallDrexx » Sun, Apr 13, 2025, 7:04 PM UTC

DobarDabar wrote: post #4

valiant55 wrote: post #3

Neat, but with restrictions like no reference types and looking at the examples, they are far from idiomatic C# as to be almost indistinguishable from C I'm trying to figure out the motivation. Maybe it's "because you can" which is fine, but are there any advantages to this approach over using C directly? EDIT: I overlooked the reddit post and comments and jumped straight into the repo, it looks like the creator is o…

How about il2cpp? Then you could just use LLVM to compile it to just about anything

Author here.

When I started this journey I had a hard time figuring out how open source il2cpp actually was, and it seemed to be heavily tied to unity. All the docs seemed heavily geared towards unity usage as well.

Likewise, some of my long term goals with the project involve writing code that can run on low end embedded platforms that may not have the C++ standard library available to it. So I had two main goals:

1. Create a system where C# could be run on very low end systems (esp32, arduino, etc...) 2. Allow the C# code to be easily referenced in a non-C# project for platforms that don't allow it.

So I ended up making my own system, as il2cpp and others didn't quite fit some of these bills. I targetted C to make sure that any C compiler could be used, so if an embedded platform has a custom gcc based compiler it could still be used (I think that's the case with the compiler that PVSnesLib uses for its `tcc` compiler).

Re: Making SNES ROMs using C#

#12

Post by KallDrexx » Sun, Apr 13, 2025, 7:33 PM UTC

tombert wrote: post #6

This is genuinely pretty cool. Without dynamic allocations and garbage collection, I'm not sure how much C# buys you, but it's still neat and I think further updates might end up making this much neater.

Author here.

One thing it potentially buys you (besides things mentioned in other posts) is faster iteration cycles.

The C stubbed methods can potentially be populated with logic that sets up a fake SNES logic in it, and makes calls to a custom rendering and input handling (monogame calls for example).

This means you can test a bunch of your logic in a monogame app for easier logic debugging, then use the transpiler to test it on a real system.

Re: Making SNES ROMs using C#

#13

Post by neonsunset » Sun, Apr 13, 2025, 9:01 PM UTC

KallDrexx wrote: post #10

valiant55 wrote: post #3

Neat, but with restrictions like no reference types and looking at the examples, they are far from idiomatic C# as to be almost indistinguishable from C I'm trying to figure out the motivation. Maybe it's "because you can" which is fine, but are there any advantages to this approach over using C directly? EDIT: I overlooked the reddit post and comments and jumped straight into the repo, it looks like the creator is o…

Author here, yes I am on an insane quest to get C# to run anywhere and SNES was just a random side tangent to that :D. So the code in the game example is very much a "port directly from the example C code to make sure it's possible and it works". The next step was to start looking at where things can be made more idiomatic. For example, C# supports static methods in interfaces now. This means instead of passing funct…

> I think I can do that in a no overhead way.

If 'T' is a struct, yup, although that's specific to the way it is compiled by CoreCLR's JIT or ILC.

For constructor semantics it's best to expose a static abstract interface method Create and have the interface be SomeInterface where Self : ISomeInterface.

For example, that's how `INumber` interface works so you can further down the line write `T.Zero`.

Re: Making SNES ROMs using C#

#14

Post by DobarDabar » Sun, Apr 13, 2025, 9:44 PM UTC

KallDrexx wrote: post #11

DobarDabar wrote: post #4

Earlier quoted context omitted.

How about il2cpp? Then you could just use LLVM to compile it to just about anything

Author here. When I started this journey I had a hard time figuring out how open source il2cpp actually was, and it seemed to be heavily tied to unity. All the docs seemed heavily geared towards unity usage as well. Likewise, some of my long term goals with the project involve writing code that can run on low end embedded platforms that may not have the C++ standard library available to it. So I had two main goals: 1…

Interesting, thank you for the insight.

Re: Making SNES ROMs using C#

#15

Post by [deleted] » Sun, Apr 13, 2025, 10:30 PM UTC

DobarDabar wrote: post #4

valiant55 wrote: post #3

Neat, but with restrictions like no reference types and looking at the examples, they are far from idiomatic C# as to be almost indistinguishable from C I'm trying to figure out the motivation. Maybe it's "because you can" which is fine, but are there any advantages to this approach over using C directly? EDIT: I overlooked the reddit post and comments and jumped straight into the repo, it looks like the creator is o…

How about il2cpp? Then you could just use LLVM to compile it to just about anything

[deleted]

Re: Making SNES ROMs using C#

#16

Post by KallDrexx » Mon, Apr 14, 2025, 12:21 AM UTC

neonsunset wrote: post #13

KallDrexx wrote: post #10

Earlier quoted context omitted.

Author here, yes I am on an insane quest to get C# to run anywhere and SNES was just a random side tangent to that :D. So the code in the game example is very much a "port directly from the example C code to make sure it's possible and it works". The next step was to start looking at where things can be made more idiomatic. For example, C# supports static methods in interfaces now. This means instead of passing funct…

> I think I can do that in a no overhead way. If 'T' is a struct, yup, although that's specific to the way it is compiled by CoreCLR's JIT or ILC. For constructor semantics it's best to expose a static abstract interface method Create and have the interface be SomeInterface where Self : ISomeInterface . For example, that's how `INumber ` interface works so you can further down the line write `T.Zero`.

Yep, in the current restrictions `T` has to be a struct (no heap allocations means no reference types are supported).

Huh, interesting idea with the `Self` generic dependency for the `Create`. That's an interesting angle I hadn't thought of, thanks.

Re: Making SNES ROMs using C#

#17

Post by tombert » Mon, Apr 14, 2025, 12:56 AM UTC

KallDrexx wrote: post #12

tombert wrote: post #6

This is genuinely pretty cool. Without dynamic allocations and garbage collection, I'm not sure how much C# buys you, but it's still neat and I think further updates might end up making this much neater.

Author here. One thing it potentially buys you (besides things mentioned in other posts) is faster iteration cycles. The C stubbed methods can potentially be populated with logic that sets up a fake SNES logic in it, and makes calls to a custom rendering and input handling (monogame calls for example). This means you can test a bunch of your logic in a monogame app for easier logic debugging, then use the transpiler…

Very cool.

I might need to play with this; I have been looking for an excuse to play with the retro console homebrew scene, this seems like as good an excuse as any.

Re: Making SNES ROMs using C#

#18

Post by KallDrexx » Mon, Apr 14, 2025, 3:47 AM UTC

tombert wrote: post #17

KallDrexx wrote: post #12

Earlier quoted context omitted.

Author here. One thing it potentially buys you (besides things mentioned in other posts) is faster iteration cycles. The C stubbed methods can potentially be populated with logic that sets up a fake SNES logic in it, and makes calls to a custom rendering and input handling (monogame calls for example). This means you can test a bunch of your logic in a monogame app for easier logic debugging, then use the transpiler…

Very cool. I might need to play with this; I have been looking for an excuse to play with the retro console homebrew scene, this seems like as good an excuse as any.

Feel free to write up any issues in the repo if you encounter them. It's likely to encounter MSIL opcodes that my transpiler is missing support for.

Also the pvsneslib docs will probably be crucial for working with the SNES in general.

The Maven 2 SNES emulator was pretty useful for debugging. If you are on windows there's also a no$sns emulator that pvsnseslib has console message support for debugging.

I'm not going to promise it's a super polished effort in its current state :)

Re: Making SNES ROMs using C#

#19

Post by mystified5016 » Mon, Apr 14, 2025, 1:33 PM UTC

Why exactly is there no heap? I can understand stack size being limited, that's largely hardware dependent, but the heap?

Does the SNES not have enough RAM to be worth it or did you just not port the heap allocator? Or is there some other reason?

Re: Making SNES ROMs using C#

#20

Post by CodeCube » Tue, Apr 15, 2025, 1:59 PM UTC

This is so friggin' cool!! I was wondering recently why Nintendo doesn't use it's already-existing channels of the on-Switch emulators, to let gamedevs make _new_ games for those platforms. That would be such a cool, nostalgic, and potentially lucrative market!