5 ms·

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 painstakin

by bmn__ 11mo ago

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 11mo ago
> You couldn't even attempt to port a dotnet subset. Because of the lack of a multiplication op code? Hmm.
chillingeffect 11mo ago
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 11mo ago
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 11mo ago
  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 11mo ago
  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.

by bmn__ 11mo ago

lysace 11mo ago

> You couldn't even attempt to port a dotnet subset. Because of the lack of a multiplication op code? Hmm.

chillingeffect 11mo ago

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 11mo ago

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 11mo ago
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 11mo ago
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.