3 ms·

DotnetSnes: Library allowing to use C# to create SNES ROMs

68 points by ingve 2y ago

SideburnsOfDoom 2y ago
> No dynamic allocations are supported (thus no reference type support) No class instances. This is a severe limitation, to the point where it will change the character of the language entirely.
- KallDrexx 2y ago
  In theory, allocation could be hacked in with an arena allocator. I just need to add in reference type support and custom allocation strategies into the transpiler. Then again, that's only viable if you don't use enough memory to require rom bank switching, or have better control over which class gets placed in which rom bank.
  - SideburnsOfDoom 2y ago
    Does "no reference type support" also imply "no strings" ? i.e. no instances of the common reference type System.String ?
    - KallDrexx 2y ago
      Strings become `char*` so they are supported as long as they are not dynamically generated (no concatenation for example, but some things like `printf()` templates do work. e.g. https://github.com/KallDrexx/DotnetSnes/blob/master/src/DotnetSnes.Example.Breakout/Game.cs#L185 https://github.com/KallDrexx/DotnetSnes/blob/master/src/Dotn...
- KallDrexx 2y ago
  Also, I would point out that there are cases where it doesn't change significant amount of the language or hamper things. The transpiler also works for Linux eBPF kernel side applications without unsafe pointers and other odd things I need to do for SNES. Since you can have methods on c# struct instances, things can still work pretty idiomatically. You also do have statically sized arrays, or heap allocated arrays (the latter is only supported if host C application passes it in before hand, and is responsible for free ing it).
rawling 2y ago
https://news.ycombinator.com/item?id=43673011 https://news.ycombinator.com/item?id=43673011 Some discussion 3 weeks ago
- chongli 2y ago
  Someone asked on the previous discussion why there's no heap but no one answered and replies are locked out, so I'll answer here: There's no heap on the SNES because the system has only one program running at all times (the game). There's no point using dynamic memory allocation when all of the memory on the system is available to the program, so you can just start writing to any valid, writeable address you want. Some addresses are, of course, not writeable (such as ROM space), and some addresses are not memory (memory-mapped IO) but that's not a problem. The really nice thing about the SNES is that it uses a 24-bit address space instead of the 16-bit address space of the NES. Most NES games needed to use mapper chips to swap between different ROM banks since with 16 bits you can only address 64KB of memory at a time and many NES games were larger than that. Having 24 bits allows you to fit your game into far fewer ROM banks, greatly simplifying the programming model and making it much more realistic to use a high-level language like C#.
  - kfuse 2y ago
    Frankly, that doesn't explain much, because that sounds like how modern computing works: every program has its own continuos 32/64 bit address space. With 24 bits you can address 16MB which seems enough to be useful if you throw away reflection and such.
    - chongli 2y ago
      16MB is larger than every single SNES game ever released. Modern programs have dynamic memory allocation. You can't just start writing to any address you want. You have to request memory from the operating system with malloc() and then free() it when you're done. Memory-managed programming languages handle this for you but it's still there under the covers. On the SNES, you simply have all memory available from the beginning. No malloc/free, just start reading and writing.
reverseblade2 2y ago
Just use F# to Rust via fable. https://github.com/ncave/fable-raytracer https://github.com/ncave/fable-raytracer
- KallDrexx 2y ago
  It's not clear that Fable would fit the constraints, especially since F# heavily relies on reference types for discriminated unions and lots of other features. It's possible that Fable wouldn't be able to compile down to lower end embedded platforms, or even things like Linux eBPF applications (like my transpiler can do).
  - throw234234234 2y ago
    You can for some features tag the type with a [<Struct>] attribute and it will compile down to a struct/value type representation. That includes records, DUs, active patterns, etc.
- no-marxism-thx 2y ago
  [flagged]
  - uh-oh-oh-no 2y ago
    [flagged]

68 points by ingve 2y ago

> No dynamic allocations are supported (thus no reference type support) No class instances. This is a severe limitation, to the point where it will change the character of the language entirely.

KallDrexx 2y ago
In theory, allocation could be hacked in with an arena allocator. I just need to add in reference type support and custom allocation strategies into the transpiler. Then again, that's only viable if you don't use enough memory to require rom bank switching, or have better control over which class gets placed in which rom bank.
- SideburnsOfDoom 2y ago
  Does "no reference type support" also imply "no strings" ? i.e. no instances of the common reference type System.String ?
  - KallDrexx 2y ago
    Strings become `char*` so they are supported as long as they are not dynamically generated (no concatenation for example, but some things like `printf()` templates do work. e.g. https://github.com/KallDrexx/DotnetSnes/blob/master/src/DotnetSnes.Example.Breakout/Game.cs#L185 https://github.com/KallDrexx/DotnetSnes/blob/master/src/Dotn...
KallDrexx 2y ago
Also, I would point out that there are cases where it doesn't change significant amount of the language or hamper things. The transpiler also works for Linux eBPF kernel side applications without unsafe pointers and other odd things I need to do for SNES. Since you can have methods on c# struct instances, things can still work pretty idiomatically. You also do have statically sized arrays, or heap allocated arrays (the latter is only supported if host C application passes it in before hand, and is responsible for free ing it).

rawling 2y ago

https://news.ycombinator.com/item?id=43673011 https://news.ycombinator.com/item?id=43673011 Some discussion 3 weeks ago

chongli 2y ago
Someone asked on the previous discussion why there's no heap but no one answered and replies are locked out, so I'll answer here: There's no heap on the SNES because the system has only one program running at all times (the game). There's no point using dynamic memory allocation when all of the memory on the system is available to the program, so you can just start writing to any valid, writeable address you want. Some addresses are, of course, not writeable (such as ROM space), and some addresses are not memory (memory-mapped IO) but that's not a problem. The really nice thing about the SNES is that it uses a 24-bit address space instead of the 16-bit address space of the NES. Most NES games needed to use mapper chips to swap between different ROM banks since with 16 bits you can only address 64KB of memory at a time and many NES games were larger than that. Having 24 bits allows you to fit your game into far fewer ROM banks, greatly simplifying the programming model and making it much more realistic to use a high-level language like C#.
- kfuse 2y ago
  Frankly, that doesn't explain much, because that sounds like how modern computing works: every program has its own continuos 32/64 bit address space. With 24 bits you can address 16MB which seems enough to be useful if you throw away reflection and such.
  - chongli 2y ago
    16MB is larger than every single SNES game ever released. Modern programs have dynamic memory allocation. You can't just start writing to any address you want. You have to request memory from the operating system with malloc() and then free() it when you're done. Memory-managed programming languages handle this for you but it's still there under the covers. On the SNES, you simply have all memory available from the beginning. No malloc/free, just start reading and writing.

reverseblade2 2y ago

Just use F# to Rust via fable. https://github.com/ncave/fable-raytracer https://github.com/ncave/fable-raytracer

KallDrexx 2y ago
It's not clear that Fable would fit the constraints, especially since F# heavily relies on reference types for discriminated unions and lots of other features. It's possible that Fable wouldn't be able to compile down to lower end embedded platforms, or even things like Linux eBPF applications (like my transpiler can do).
- throw234234234 2y ago
  You can for some features tag the type with a [<Struct>] attribute and it will compile down to a struct/value type representation. That includes records, DUs, active patterns, etc.
no-marxism-thx 2y ago
[flagged]
- uh-oh-oh-no 2y ago
  [flagged]