
A quick start guide to Commodore 64 assembly programming on Windows (2011) - Fjolsvith
https://digitalerr0r.wordpress.com/2011/03/19/commodore-64-programming-a-quick-start-guide-to-c-64-assembly-programming-on-windows/
======
Malic
And for the macOS folks out there: [http://dustlayer.com/c64-coding-
tutorials/2013/2/10/dust-c64...](http://dustlayer.com/c64-coding-
tutorials/2013/2/10/dust-c64-command-line-tool)

I might have to dust off the LADS assembly code of a decades old game I was
trying to make during the summer after I graduated from collage...

~~~
pryelluw
Thanks for the link. Ive been looking for something like this. Time to dust
off my demo skills :)

------
digitalerr0r
Hey, author here! Awesome to see this on Hacker News, and that so many still
care for this great computer! Happy to answer any questions/take feedback if
you got something on your mind.

~~~
pryelluw
Just want to high five you. Projects like this are what keep me up late at
night having fun.

------
cjauvin
I have "scratched a childhood itch" in a very satisfying way, by writing a
super minimal C=64 Tetris clone, using the Kickass assembler:

[https://github.com/cjauvin/tetris-464](https://github.com/cjauvin/tetris-464)

------
panic
There's something uniquely satisfying about writing code in a limited
environment like the C64. No libraries or operating systems -- just you and
the hardware!

~~~
ajross
You can still do this! The register interface for the peripherals on modern
microcontrollers is only a tiny bit more complicated (and in some ways
significantly easier) than what we had on 8 bit PCs.

You can absolutely grab a generic gcc/binutils cross toolchain for an ARM
Cortex-M, an AVR, or even an Intel Quark board and start writing simple to-
the-metal code today. It's not hard, or at least it's not meaningfully harder
than Apple II or C64 hacking.

It's just that no one does it. All the vendors ship integration libraries and
fancy IDEs for all these boards, so what everyone chooses in practice is one
of these, or an RTOS that provides an even more abstracted view. And that's
not a bad idea either of course.

But the hardware is still there, and still fun, and still useful for real
tasks in the modern world. Start hacking.

~~~
david-given
I've never hacked assembly on an AVR, but I have on the MSP430, and it's a
really elegant architecture to work on; expressive enough to let you get stuff
done without hurling your development board at the wall, but constrained
enough to make figuring out a neat optimisation both satisfying and useful.

Also, the MSP430X has 20-bit registers, just for that added level of
surreality.

However, even I have limits: stay clear of PIC12. It's just... bizarre, and
not in a good way.

(Somewhere I have 2/3 of an 8080 emulator for the MSP430, written in machine
code. It ran on the basic Launchpad, with 2kB of RAM, and booted CP/M using an
SD card for storage and an external serial SRAM device for memory swap. Sadly,
while I got it talking to an AT keyboard, I never got a screen to work, and
I've since broken up the hardware for other projects. The emulator core was
1kloc of assembly. The 8080 is surprisingly orthogonal.)

------
david-given
...one of the items on my Very Long List Of Potential Projects is a self-
hosted compiler for a proper modern type-safe C-like language for the 6502. I
was planning to target the BBC Micro, as it's the only 6502 8-bit I've found
with a real operating system, but it ought to be easy to port.

Making it self-hosting means lots of interesting design choices: I was
planning that it'd be a multipass streaming design, where each stage would
consume tokens from the previous stage and write out tokens for the next
stage, keeping in-memory as little state as possible; depending how much RAM
you had you could pipeline stages together for faster compilation, provided
you were willing to have less memory available for symbol information.

One other interesting feature is that a lot of these early processors don't
really do stack-relative addressing, so stack-frame-based languages like C and
Pascal generally work really badly. (The Z80 failed at this, too.) The
solution here is easy: forbid recursion. Now there are no stack frames! So
each variable is effectively static. This simplifies the design no end, as
well as playing to the processors' strengths in being basically memory-memory
architectures.

Deciding what variables to put where becomes an easy and effective exercise in
optimisation. On the 6502, placing frequently-accessed variables in zero page
makes the code smaller and faster. Walking the call tree and figuring out
which variables are never used at the same time allows variable storage to
overlap. And since calling a function involves copying values directly from
the caller into the function's parameters, which are just static variables
like everything else, then if you can find places where the value lives at the
same address in both the caller and the function, then you can skip the copy
entirely...

Ah, well. Maybe one day.

~~~
sehugg
You'd probably want to disallow/discourage structs as well, favoring striped
arrays, because the $aaaa,x addressing mode is a lot more efficient than doing
pointer arithmetic in zero-page. (Would be cool if the compiler could figure
this out, too...)

~~~
david-given
I probably wouldn't want to do automatic striping of arrays of structures,
because it'd only make sense in some circumstances, but it'd be trivial to add
logic to the code generator to use indexed addressing modes --- you'd need to
check to see if the thing being indexed was an array with bounds small enough
to be indexed with an 8-bit variable.

<thinking out loud follows>

...that would produce something like:

    
    
        lda index
        rol a            # scale for 16-bit values
        tax
        lda address+0, x # read low byte
        ldy address+1, x # read high byte
    

== 11 bytes (assuming index and address weren't in zero page). But of course
if I were reading a 16-bit value, I'd probably be wanting to dereference it as
a pointer or do arithmetic on it, so I wouldn't want to read it into registers
all at once --- the 6502 likes streaming maths through the accumulator a byte
at a time.

Something like 'result = array1[index] + array2[index]' would end up:

    
    
        lda index
        rol a
        tax
        clc
        lda array1+0, x
        adc array2+0, x
        sta result+0
        lda array1+1, x
        adc array2+1, x
        sta result+1
    

== 24 bytes!

(When I was about 10, the 6502's lack of 16-bit arithmetic made me very sad.
It still does, but it did then, too.)

~~~
spc476
You could always incorporate SWEET16
([https://en.wikipedia.org/wiki/SWEET16](https://en.wikipedia.org/wiki/SWEET16))
to support 16 bit math.

------
adam_seeliger
This brings back some memories.

