Yep, it's astoundingly inefficient. I've been meaning to pull the code back into working memory and do the things I mention in Future Considerations, but it took long enough just to do this write-up; could be years before I get around to it.
Hey, thanks for checking this out. I wanted smooth motion to keep close to the JS piece that inspired this; it seemed like it should be eminently possible to get smooth motion, after all.
And yeah, I was reminded of Bresenham's algorithm a few days back, and had a suspicion that I've basically redone it independently (and inefficiently) by doing the trig. As mentioned at the end there, the math isn't where I'm losing most time in rendering though.
The Mastodon release post (cite 0) has comments talking about doing the score recalculation only at time of collision, but the worst thing I do is use a block of RAM for the playing field and another block of RAM for the _display_ of the playing field. Copying those blocks of 20 bytes, gosh it's slow.
Over the years I've written a bunch of things in the orbit of retrocomputing, the largest of which was an incremental game based on a C64 emulator. Somehow I've never written anything substantial for the C64 itself; this post documents my learning while implementing a graphical effect in assembly language, over the course of twelve thousand words and three digressions into side quests.
Let me know if this was entertaining, useful or even both.
That's absolutely great read - especially recently I'm trying to get back to the childhood fun with C64 myself and re-learn some of the little programming I did back then, learn something new. Articles like this are a treat, thank you!
It's worse than that even: there are delays after every _bit_ transferred, due to various design decisions that were made along the way, which is why the C64's disk drive is slower than the previous computer (the VIC-20), which is slower than the one before that (the PET).
I wrote about the decisions and the resulting delays for one of those 100-post Threadapalooza projects in 2024, compiled here for easier reading: https://imrannazar.com/articles/commodore-1541
Not buying that, C64 had like 5-10 pcb revisions so spinning another one wouldnt be extraordinary, and in the mean time they could put bodges on old stock pcbs or you know, supply USERPORT cable as thats where 6526 is wired to. Original Kernal has no traces commodore ever tried to use hardware shift register, they simply left VIC20 bodge and didnt even try accommodating fixed 6526.
If nothing else, you can put up a static page on the basics of Boglehead-ish finances; a copy of The Flowchart from /r/personalfinance would be a great low-effort stop-gap.
Mm, I still recall the time my Windows 98 installation corrupted its registry somehow. The only fix was to reinstall, and the machine had no floppy or CD drive... getting Windows back on there was a task.
No floppy or CD? You were just asking for trouble then IMHO. It was common to have to reinstall windows every 6-9 months in the win9x days. That didn't even really work for ME, but by then win2000 came in to save the day. Software was primarily distributed on CD those days, being without a CD drive must have been a huge hardship.
I vividly remember having to reinstall Windows also in the XP days at least once a year due to malware or due to anti-malware software slowly strangling the OS.
Reminds me of a ROM-hack for Zelda: Ocarina of Time from a few years ago, that was presented in the release video as using unused assets and storyline from the game itself, when it was actually almost entirely new material. A great technical achievement, to be sure, but somewhat dishonest in its presentation.
