[HN Gopher] .NET for NES Game Console on 6502 Microprocessors
___________________________________________________________________
.NET for NES Game Console on 6502 Microprocessors
Author : mtmk
Score : 120 points
Date : 2024-05-24 09:35 UTC (1 days ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| codespin wrote:
| I love seeing fun little projects like this
| nurettin wrote:
| then you will love this
| https://www.reddit.com/r/csharp/comments/1c23y53/youtuber_ma...
| CodeCompost wrote:
| Didn't see the video but doesn't that effectively mean that
| .NET was ported to DOS?
| KETHERCORTEX wrote:
| No. It relies on Windows 95 infrastructure. And it's not a
| modern .NET, but .NET Framework 2.0.
| nurettin wrote:
| It is still maintained. You can use .net 2.0 on the
| latest visual studio if you choose to.
| nurettin wrote:
| .net 2.0 and later are highly dependent on windows and
| winapi. Parts of .net core might stand a better chance at
| being ported to DOS.
| LeFantome wrote:
| .NET 2.0 was fully implemented as Open Source by the Mono
| Project.
|
| The most recent version includes quite a bit of Microsoft
| code and offers .NET 1.0 through 4.x
| le-mark wrote:
| No runtime No BCL No objects or GC No
| debugger Strings are ASCII
|
| I did not see the readme mention anything about
| bool/byte/char/short/int/long sizes or signed and unsigned. It
| can be quite a surprise to find yourself with 8 bit long longs!
| As some found with sdcc for gameboy.
| noobermin wrote:
| The NES has 2K ram, where you can get carts with mappers that
| allow you to use prg as ram as well though, this is still
| limited. Also, the "stack" as it exists must fit on a page (256
| bytes). Putting a runtime or sorts onto an NES itself is a big
| feat given this and requires a lot of manual twiddling.
| bagful wrote:
| The hardware stack pointer is restricted to indexing within
| [$0100, $01ff] but, lacking a stack-pointer-relative
| addressing mode, it is more preferable to realize a parameter
| stack using a zero-page pointer indexed with the (zp),Y
| addressing mode, as cc65 does.
| userbinator wrote:
| _This looks very much like "Hello World" in C, taking advantage
| of the latest C# features in 2023._
|
| If you admit that it looks like C(99), what's "C#" about it then?
| This can probably be done with just about every C-syntax-derived
| language, which is why I think the title is a bit clickbaity; I
| was expecting some sort of highly-stripped-down CLR.
| whaleofatw2022 wrote:
| When I saw it only seems to support a 'main' I got
| disappointed.
|
| If it could even get to 'method calls with ref structs' you
| would start getting into where I'd want to YOLO with it, maybe
| even use Nesticle to test for the irony.
| pjmlp wrote:
| The same way C23 on NES, isn't C proper, rather the macro
| assembler K&R C used to be.
| DeathArrow wrote:
| So K&R C wasn't proper C?
| shzhdbi09gv8ioi wrote:
| It predates the first standardized C versions:
| * ANSI C by 11 years (C89) * ISO C by 12 years (C90)
|
| https://en.wikipedia.org/wiki/C_(programming_language)#K&R_
| C
| ngcc_hk wrote:
| So strange. Someone invented a computer language called C
| and is not proper C until it is stabdardised by a
| committee. I would say the original C is proper C. Got a
| whole operating system to run with it.
|
| Organisation is nothing if we do not accept individual's
| role.
| pjmlp wrote:
| The C language as invented for porting UNIX does not fit
| into a NES, nor does it expose its hardware capabilities.
| pjmlp wrote:
| Not the subset you can fit onto a 6502, thus that subset
| fits the same purpose as K&R C, a portable macro assembler,
| calling into functions that are written in raw Assembly,
| compiled by an external macro Assembler.
|
| And good luck making good use of 6502 registers for C code.
| noobermin wrote:
| Saw this make the runs on twitter a few weeks ago and was
| confused, I had assumed they had ported a limited run time by
| making a custom cart with a large prg rom, which seems like an
| amazing feat actually...whereas this is a 6502 compiler
| essentially with some limited functionality.
|
| No shade btw, just seeing the title made me perhaps expect quite
| the effort while this is still a fun project of sorts.
| richardfey wrote:
| I'd love something like this for the SNES
| ladyanita22 wrote:
| There's also this
| https://gergo.erdi.hu/blog/2021-09-18-rust_on_the_mos_6502__...
| for rust on the 6502.
|
| I wonder how's the performance vs. C (for both, C# and Rust).
|
| Edit: It's my understanding that the 6502 is extremely stack-
| limited, so a well-versed assembler would use the stack very
| little and allocate mostly on the heap. In C, you can replicate
| this with global variables, and I _believe_ (and I would be very
| happy if someone related to the 6502 rust port could chime in
| here) on Rust you can do the same with `static mut` on Rust 2021
| and `Unsafecell` on Rust 2024.
| DeathArrow wrote:
| >For lack of a better word, .NES is a "transpiler" that takes
| MSIL and transforms it directly into a working 6502
| microprocessor binary that can run in your favorite NES emulator.
|
| >Building a project should produce a *.nes binary, that is byte-
| for-byte identical to a program written in C.
|
| What about memory management? Is the garbage collector included
| in the generated code? If not, any idea on how memory management
| is done?
| DeathArrow wrote:
| How hard would be to add a 6502 backend to the C# AOT compiler?
___________________________________________________________________
(page generated 2024-05-25 23:02 UTC)