Programming the C64 with Visual Studio Code

I credit the C64 that I had as a kid and magazines like COMPUTE! / Compute's Gazette for my career in software. I taught myself 6510 assembler and started writing some simple demo-like things on that machine, and got hooked on the feeling of creativity that it unlocked.

Funnily enough I'd been thinking that it's about time I tried (again, as an older person) to write a game or a demo for the old 64.

It's absolutely amazing what people are able to get out of these 40+ year old machines now, and I love that there's still a vibrant scene.

In addition to the tools specified in the article, I would also recommend "retro debugger", it's an amazing tool for single stepping through code and seeing what's going on, even letting you follow the raster down the screen to see what code is executing on given scaliness.

Also, there are some really good youtubers out there helping to demystify how various games/demos work.. Martin Piper comes to mind as a good example.

Retro game coders achieve some pretty astounding results sometimes. One of my favorite examples is one who optimized super Mario 64 to such a degree that it runs with much better framerate on the original hardware. Also, multiplayer was added: https://www.youtube.com/watch?v=t_rzYnXEQlE

One of my favorite retro projects in this real-time TRS-80 (Model I assembler and emulator that assembles and runs Z80, literally with each key press. Mind boggling how today's CPUs can emulate and entire 8-bit computer dev-process all between key presses in a browser. https://www.teamten.com/lawrence/projects/assembly-language-...." The author even says "How about: With every keystroke in the IDE’s code editor, we assemble the whole program, reset a virtual TRS-80 to a known state, install the program, and run it??

> My favourite feature, however is being able to use labels instead of line numbers.

I guess that's less of a feature and more of a necessity? Actually, this was one of the questions on my mind when I started reading the article. If you remember how those old BASIC dialects worked, you basically decided the line numbers for each line by yourself. The common strategy was to increment by 10, then you had some space to insert additional lines if needed without having to renumber everything (including the destinations of GOTOs and GOSUBs). Subroutines got line numbers in the 1000+ range so they didn't interfere with your main program (example here: https://www.c64-wiki.com/wiki/GOSUB). Of course this system would be extremely confusing in an IDE that shows the actual line numbers of the source code by default.

Maybe this is a good place to ask a question regarding the hardware that is required to transfer code from and to your C64. I have a C64 and a 1541 sitting in my basement in a box and I sometimes take it out to check if it still works (it does).

After watching one particularly insane demo [1] I decided that I need to run them on my own machine for full experience. The question is what hardware is necessary to run them. After a little research it seems that something like a Kung Fu Flash cardridge and an SD card is all that I need to put on my Christmas wish list. Can anyone with more insight tell me if this is the right way to go?

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

Is not worth learning 6502 much better and even relevant since 6502s are still printed, rather than God-forsaken BASIC?

Besides as I tried as a child and all the magic is hidden behind POKE/PEEK commands, the basic itself is unlike Apple II basic or DOS basic. And with all the peek/pokes it implies going on the assembly level.

I did go on the assembly level for x86 when I was 14 and never regretted it. One of the top coder ppl that I knew started x86 assembly when he was 10-12 and only got into the Java bandwagon when he got in university, meanwhile mixing C and Asm.

I have many other reasons to believe such knowledge is not too hard for children to understand.

What I love about this is that it should be relatively trivial to extend it to, at least, all emulators supported by VICE.

Cool project, looks like they support a number of assemblers and compilers, too. It’s not clear if it also supports the ca65 macro assembler as a standalone assembler as part of their cc65 support, or if it only supports the c compiler.

Shameless plug: I cobbled together a simple VSCode extension for (so far) KC85, C64 and CPC - only for assembly coding/debugging though.

The 'special sauce' is that the assembler and emulators compiled to WASM and directly integrated into the extension (e.g. the emulator is running in a VSCode tab, everything is properly sandboxed):

https://marketplace.visualstudio.com/items?itemName=floooh.v...

...and it even works in the VSCode browser version, e.g. you can go here and press 'dot' to start into VSCode:

https://github.com/floooh/kcide-sample-kc854

It *is* really quite amazing how productive 8-bit assembly coding feels with modern tooling (e.g. when you have a tight edit-build-debug loop, and having a debugger that lets you inspect the state of the entire hardware, not just CPU registers).

Here's the accompanying blog post: https://floooh.github.io/2023/12/31/vscode-wasm-wasi.html

Amazing to see this alive and kicking in this day and age.

I grew up programming the 8-bit Atari and it was such a great time to experience. Information was scarce without internet, so magazines and word-of-mouth was so important. Once you collected enough information, you could pretty much hold a mental model of the entire machine in your head, and the only limitations were the number of cycles you had per second or the effort you were willing to put in. I firmly believe this is how I developed the mindset of stepping outside of the problem and readily looking for out-of-the-box solutions that pays dividends to this day.

Programming was a mix of BASIC and machine language routines (not even assembly as you hand-assembled to machine bytes) similar to how someone might use Python with C calls but at lower levels of both. Later on I tried compiled languages like Pascal but it ran like a dog, not tuned for the slow floppy or memory constraints of these machines. Getting a macro assembler was next-level, where you could write everything to be as fast or small as possible. Self-modifying code for wasn't only common practice, it was quite necessary for performance.

Other great pastimes were reverse-engineering games and copy protection in an arms-race. Most were pretty simple and it was always exciting to see completely new techniques or super-complicated multi-pass self-modifying or otherwise obfuscated code.

The filesystem on the floppy disks were also easily understood with sector chaining and a free sector bitmap, so you could write low-level routines like undelete or a defragger. Modifying the floppy drive with custom sector sequencing and RPM tuning could improve timings to get higher throughput and finding that you can add SRAM to buffer an entire track really sped things up. The simplest and cheapest thing was to punch a hole in floppy disks and write to the other side (of a single-sided floppy).

Having this level of understanding made you believe that you could do pretty much anything and everything (just not always fast enough) and makes you program without boundaries except the hardware. Even then it was simple enough to modify parts of the hardware like ROMs or extend it with helpers plugged into the bus or PIO (parallel I/O joystick) ports much like the GPIO on a Raspberry Pi.

The graphics system on the Atari was really something else, with 'display lists' of data that defined memory addresses and display modes (character or raster) that could be defined for each (character or raster) row, along with color palette lookup tables that you could modify to change all the colors using those values. Even the serial SIO daisy chain on the Atari was the basis of what is now how USB enumeration and command/reply works.

Shout-out to Bill Budge's Pinball Construction Set (PCS) originally for the Apple ][ and also on Atari. Of course being a kid I mostly made video games and tools for making video games like sprite editors, character/tileset editors, font editors, and level editors. PCS blew my mind and later got me into making programs that build applications, following the likes of Visual Basic (but running on OS/2 PM).