How I learned to program a Commodore 64 in BASIC and compiled C (2020) [video] | Hacker News Reader

How I learned to program a Commodore 64 in BASIC and compiled C (2020) [video]

youtube.com

55 pointsAlexeyBrin22 comments

Made me recall this article on why the 6502 isn't great as a C target, including a follow up with some pointers on avoiding some issues with it.

https://www.xtof.info/coding-c-8-bit-6502-cpu.html

There's a great talk [1] in which C++17 features are used to build an efficient Pong clone on C64. As I recall, the author wound up writing an (obviously limited) x86-to-6502 translator to get around the lack of 6502 support.

[1] https://www.youtube.com/watch?v=zBkNBP00wJE

Last year, the author tried a slightly different approach: use GCC to compile for AVR 8 bits, than translate the AVR assembly to 6502:

https://www.youtube.com/watch?v=EIKAqcLxtT0

Yeah, it’s better to use a “high-level” language designed for the architecture, such as this: https://github.com/dschmenk/PLASMA

FWIW: really the best example of that kind of thought was OSS's "Action!" language for the Atari computers. Unlike all the modern ideas in this space, this was actually a contemporary product (released in 1983). It's a little like K&R C in terms of semantics, with a bunch of concessions[1] to the limitations of the device.

Alas it came at a time in history where it couldn't make much impact. The Atari platform was being eclipsed by Commodore at the time, and the market for Serious Tool Development in the desktop world was swinging hard toward IBM (Turbo Pascal for MSDOS was arriving right about the same time).

[1] Like a more pascal-ish syntax. Atari didn't have curly braces on its keyboard! Also IIRC "POINTER" types were limited to being statically linked into the zero page, as that matched the operation of the hardware without requiring the runtime to move stuff around for you every time you wanted in do a load.

> Atari didn't have curly braces on its keyboard!

Isn't that why C also allows the <% and %> digraphs as alternatives?

Not the Atari itself, which never had a C compiler. But systems like that, yeah. Lots of 70's systems were designed for non-ASCII or ASCII-subset[1] character sets, whereas Unix had made very comfortable use of every funny symbol it could find.

[1] e.g. the original Apple II character ROM had only the 64 characters from 0x20 to 0x5f (no lower case, even) squished into 6 bits of addressing. The keyboard reflected that limitation, as did those from Atari and Commodore. This wasn't rectified by Apple itself until the IIe, though there were 80 column cards on the market from 1980 on that implemented the full

CC65 is just not a very good compiler by modern standards. There's an experimental 6502 backend for LLVM that outputs fairly good code. (A Z80 backend also exists, AIUI.)

Do you know if the 6502 LLVM backend has floating point support ? A big problem with CC65 is the lack of floating point support.

EDIT: The answer is no:

https://github.com/llvm-mos/llvm-mos-sdk#notably-missing-fea...

What kind of stuff do you want to do on a 6502 that requires emulated floating point support?

I wouldnt mind generating lookup tables at run time rather than my present system of exporting them via python etc... the algs could be more dynamic!

It is nice to have, most BASIC versions that run on 6502 micros have floating point support.

The "floating point" support that's in 6502 BASIC ROMs is not real IEEE 754 floating point though, see https://en.wikipedia.org/wiki/Microsoft_Binary_Format So it shouldn't be used to replace that, though of course one can use it for other purposes with some care. (It goes without saying that this is not hardware floating point, so the only potential gain from piggybacking on these ROM routines will be some saving in code size.)

So maybe someday we could do rust for the c64?

The people old enough to want to program on the c64 are not the same group of younger hipster who want to rustify the world. It would take someone to bridge these groups.

Yup, it's fun to think that the rust_embedded ecosystem could be repurposed with comparable ease to support bare-metal retro programming. Similar to how Rust itself bridges the "low-level C/C++" and "hipster high level language" worlds.

I guess I'm an old hipster that wants to rustify the world? I started on c64 basic as a tiny kid.

https://llvm-mos.org/wiki/Rust

Action! for the Atari 8 bit series was very well suited to the 6502.

https://en.m.wikipedia.org/wiki/Action!_(programming_languag...

Relevant: The Applesoft Compiler (TASC), an Apple II C compiler written in BASIC <https://news.ycombinator.com/item?id=31138214>

https://www.retrogamedev.com/

This guy's book on c64 game Dev is good. I bought it, but I never gave it the time required.

I think he is/was going to do a nes one too.

I hope there is one for more advanced ones such as PS (which already have great doc) and GBA (again good doc already) and such.

Sadly computing has advanced so much that making games on console is far from the older days when programmers need to be smart to think out of box to do stuffs. I guess maybe Switch is closer?

Reply on news.ycombinator.com