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.<p>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.<p>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.<p>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.<p>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.
I credit the BASIC and machine language byte code type-in programs for reinforcing my attention to detail and being able to track down software problems.<p>Kids these days[0] will never know the "pleasure" of spending hours typing in some cheesy BASIC game only to have to track down any number of syntax errors!<p>[0] Get off my lawn!
I had a C64 as well. My school had a programming class and we all shared a TRS80 (I think). I remember writing a program to find prime numbers and thinking about various optimizations. Mine was fastest, and I was proud. Then the boy that wrote directly in assembly ran his... That was the moment I decided to get good. :-)
I still keep the Reference Guide on my desk to remind me of my roots and how far things have come and yet how much they remain the same.
Definitely try as an older person!<p>I have similar experiences and sentiments myself. One difference is I was into Apple and Atari computers, but that does not seem to matter all that much.<p>As a younger person, I did demos and explored the tech plenty without actually building finished applications and or games.<p>Learned a ton! And had major league fun. Great times filled with bits of understanding I draw on all the time.<p>And YES! Good grief, the pixels are dancing in ways nobody would have predicted back then.<p>When I hop on the machines today I find them simpler than I remember and fun to program.
POKE 53280, 0
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: <a href="https://www.youtube.com/watch?v=t_rzYnXEQlE" rel="nofollow">https://www.youtube.com/watch?v=t_rzYnXEQlE</a>
<a href="https://www.youtube.com/watch?v=QB3oHdSjfCE" rel="nofollow">https://www.youtube.com/watch?v=QB3oHdSjfCE</a><p>Dragon's Lair. DRAGON'S fucking LAIR. On TI-99/4A. The original laserdisc FMV version, albeit heavily bitcrushed, on a 16-bit home computer from 1981.
Kaze? Yeah he's being doing insane things, like getting mario sunshine levels to run on his modded engine. Sounds like he's accomplished much much more too:<p><a href="https://m.youtube.com/watch?v=Drame-4ufso&pp=ygUEa2F6ZQ%3D%3D" rel="nofollow">https://m.youtube.com/watch?v=Drame-4ufso&pp=ygUEa2F6ZQ%3D%3...</a>
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. <a href="https://www.teamten.com/lawrence/projects/assembly-language-ide/" rel="nofollow">https://www.teamten.com/lawrence/projects/assembly-language-...</a>." 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??
> <i>My favourite feature, however is being able to use labels instead of line numbers.</i><p>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: <a href="https://www.c64-wiki.com/wiki/GOSUB" rel="nofollow">https://www.c64-wiki.com/wiki/GOSUB</a>). Of course this system would be extremely confusing in an IDE that shows the actual line numbers of the source code by default.
From a nostalgia viewpoint, adding labels feels a bit "impure". You might as well want to introduce other syntactic sugar, but at some point, you're no longer writing C64 BASIC.<p>But what if you had an IDE with convenient/native editing support for BASIC line numbers? It could auto-number on pressing enter, and it could have refactoring/renumbering support so that you can't miss a GOTO somewhere. But you'd always see and edit plain BASIC code. It feels like that might be fun.
That would be possible actually, but it would probably require support from the IDE for letting language plugins filter which lines are shown in the editor (which I don't think VS Code supports currently). Then the line numbers shown in the editor's gutter would be the line numbers defined in your code, and if you typed a new line starting with a line number, it could insert it at the location specified by the line number.
Is not worth learning 6502 much better and even relevant since 6502s are still printed, rather than God-forsaken BASIC?<p>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.<p>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.<p>I have many other reasons to believe such knowledge is not too hard for children to understand.
Shameless plug: I cobbled together a simple VSCode extension for (so far) KC85, C64 and CPC - only for assembly coding/debugging though.<p>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):<p><a href="https://marketplace.visualstudio.com/items?itemName=floooh.vscode-kcide" rel="nofollow">https://marketplace.visualstudio.com/items?itemName=floooh.v...</a><p>...and it even works in the VSCode browser version, e.g. you can go here and press 'dot' to start into VSCode:<p><a href="https://github.com/floooh/kcide-sample-kc854">https://github.com/floooh/kcide-sample-kc854</a><p>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).<p>Here's the accompanying blog post: <a href="https://floooh.github.io/2023/12/31/vscode-wasm-wasi.html" rel="nofollow">https://floooh.github.io/2023/12/31/vscode-wasm-wasi.html</a>
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.
Amazing to see this alive and kicking in this day and age.<p>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.<p>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.<p>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.<p>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).<p>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.<p>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.<p>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).
> 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.<p>Some of my favorite bits of The 8 Bit Guy's channel involve when he explains how the NES and SNES controllers work, and to demonstrate he goes "I wrote a little program on my C64 to poll the NES controller through the user port..." and proceeds to run it and what do you know, the C64 can read NES controller input, it just needs to be taught how.<p>I'm still a bit miffed about him dremeling out the screws on that rare IBM prototype, but he's still done some really cool stuff.
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).<p>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?<p>[1] <a href="https://www.youtube.com/watch?v=KPb6y44HagI" rel="nofollow">https://www.youtube.com/watch?v=KPb6y44HagI</a>
Kung Fu flash is probably all you need, with a few caveats (eg. With KFF the drive is "emulated" by intercepting kernal vectors rather than acting as a 1541 on the serial bus, so some software that eg. uses fast loaders or relies on the disk drive for offloading computation won't work).<p>If you want to get fancy you could go for something like an Ultimate II+ and a usb key, which will get you a bunch of extra functionally like network connectivity, extra SID support, pretty solid compatibility, REU emulation etc (but UII+ will also cost a lot more).<p>Given you've got a real 1541, maybe you could just copy files/disk images across to the real thing if KFF doesn't work for a particular program I guess?