> Let me tell you the story so far; the process, obstacles, and solutions involved in making a roguelike dungeon crawler playable on systems like the Commodore 64, Commodore PET, and even more constrained machines.
Javascript is not running on a Commodore 64 with decent performance.
Interesting article, and it also shows why in the end, for most games we would mainly use Assembly directly.
What many are not aware is that after graduating from bedroom coders, having not much more than what one could acquire thanks to parents support, or small kids jobs, in proper studios cross-compiling with more powerful Assemblers, or indeed K&R C like languages were an improved developer experience.
I would think that rather than ifdefs, one could use separate port files. And regarding C89/99, a solution here is to use ANSI C, which is what Lua does.
Sometimes a source language can be an awkward fit for a target architecture. For one thing the 6502 is 8-bit and the C standard guarantees that the int type must be at least 16-bits. More generally, quirks of a hardware architecture can make it difficult for compilers to generate efficient code.
Back in the dim dark ages of the 80s, I persuaded one of the system programmers to print out the source for the curses library, which I the diligently typed in to my CPM/80 machine, I then got the source for rogue, which someone else had done a partial port for, using overlays. It was a bit big for the 48k you could reasonably expect a Z80 CPM machine to have. Mostly worked...
This post really resonated with me because it highlights the exact challenges I’ve been facing with portability, memory management, and UI adaptation. To streamline development, I’ve recently started using https://www.code-maestro.com/ , and it’s made a noticeable difference. It doesn’t just assist with generating or optimizing code—it also helps document and explain it, which is incredibly useful when juggling legacy logic or trying to restructure older modules without breaking things. I’ve found the ability to explore my own architecture interactively saves a lot of time during debugging or porting. For anyone juggling a multi-platform project in C, it’s worth exploring tools that genuinely help keep things manageable.
18 comments
[ 2.9 ms ] story [ 53.4 ms ] thread> Let me tell you the story so far; the process, obstacles, and solutions involved in making a roguelike dungeon crawler playable on systems like the Commodore 64, Commodore PET, and even more constrained machines.
Javascript is not running on a Commodore 64 with decent performance.
Lovely. However the poster of the original article would have trouble getting it to even parse on a C64?
[0] https://github.com/SuperIlu/DOjS
What many are not aware is that after graduating from bedroom coders, having not much more than what one could acquire thanks to parents support, or small kids jobs, in proper studios cross-compiling with more powerful Assemblers, or indeed K&R C like languages were an improved developer experience.
C89 and C99 are both standards that are endorsed by ANSI. [0] (At least, they were endorsed, as they're now both behind the times.)
The Lua interpreter is written in a subset of C that behaves identically when compiled as C++, they call this 'Clean C'. [1]
[0] https://en.wikipedia.org/wiki/ANSI_C
[1] https://www.lua.org/manual/5.4/manual.html
But I could imagine assumptions about it being a problem if you try to add a 6502 backend to an existing compiler for other platforms.