This post recaps some of the C64 coding tricks used in my little Commodore 64 coding competition. The competition rules were simple: make a C64 executable (PRG) that draws two lines to form the below image. The objective was to do this in as few bytes as possible.
These people are wizards.
These are fun little programming challenges, although too arbitrary for my taste. I’m a bigger fan of things like “Crobots” where the objective is somewhat more meaningful with more room to be creative.
https://en.wikipedia.org/wiki/Crobots
Takes me back to my roots!
I know it seems arbitrary, but the skills learnt doing stuff like that has left me writing better more compact IoT code than I otherwise might have!
cpcf,
Yeah, there are a lot who don’t appreciate such skills. It’s often dismissed as premature optimization, and while there may sometimes be merit to this accusation in extreme cases, I feel the industry tends to be more guilty of leaning the other way and ignoring optimization opportunities until the level of bloat becomes unsolvable without throwing more hardware at the bloat problem. Even relatively basic applications today can easily require one or two magnitudes more computing power than it would have in the past.
For better or worse, the market doesn’t seem to punish bloat and inefficiencies, we’ve mostly just accepted it as normal. While there are still those of us who grew up coding for older systems with much less power, we’re kind of becoming dinosaurs.
Well the need for clever tricks come actually sooner than expected, because management wants to keep the cost of IoT device down, right? That means you are limited to some 8-bit microcontroller with limited amount of flash but ever-growing list of functionality. Hence there becomes the need to start optimizing the code.
As someone who is dealing with such limitations on automotive world, then I can tell, that the code size is an important thing to consider and while the programming is done in C then the compiler output gets always analyzed manually to see how the assembly is generated and if needed, the C code is restructured to force the compiler to use more efficient instructions. The last resort is to write hand assembly. But yes the need to squeeze the code into limited space is a real issue in mass-produced and cheap embedded world.
I started on c64 as well – (who remembers coding by op codes in the ML monitor in the Epyx Fastload cartridge? Good times) – and have never outgrown the instinct to squeeze a little more speed & efficiency out of what I do today. It’s hard to unlearn a foundation built on the idea that every byte of memory and every cpu cycle counts. Honestly, I think it gives you a design advantage. I can’t count how many times I’ve seen code that was overly bloated & complicated due to poor design. Instead of approaching like the development of a well-oiled engine, it looks more like a bunch of mismatched odds & ends poorly glued together.
“These people are wizards.”
Eh – no. Nothing special going on here. Nowhere near the wizardry found in the hey-day of Atari 8-bit systems and the C64. No one even bothered with undocumented instructions. As the article even says about the ONE TRICK used in the contest – “This trick was one of my favorites in this compo. It was also independently discovered by pretty much every participant.”
I think this compo was aimed at the larger group of C64 enthusiasts rather than the “wizards”. Drawing an “X” on the screen in text mode? No wizards would bother with such a lame task, even with the addendum of making it as small as possible.