> However, you can save 1 byte of RAM by using the branch instructions instead, as long as you know which flag(s), if any, are guaranteed to be on or off at the jump point.
> For example, if you know the carry flag will always be clear at the jump point, and if the jump distance is within branching range, you can replace JMP with BCC.
However if the BCC crosses a page boundary it'll take 4 cycles, one cycle longer than a JMP.
> having tried to sabotage its Kickstarter campaign back in 2018 by viciously attacking me and attempting to have me "cancelled" for opposing his hysterical far-left views supporting the LGBT agenda and the degenerate filth of unfathomably evil "trans people" aka demonic monsters (views which, for the record as a conservative Christian, I unapologetically find utterly vile and abominable).
Flagged because people like this don't need attention
A link to the comment in question would be good. I had a quick go at finding it, but couldn't (though not to say I spent a huge amount of effort on this project).
But I agree that it's useful to highlight this kind of thing. If you disagree with the author, you probably won't then want to give them your time and attention, let alone your money. But, on the other hand, if you agree, maybe you'll feel the other way! Which is a roundabout way of describing my favourite thing about the internet, since I'm old enough to remember what it was like Before: whoever your people are, for good or for ill, you'll be able to find them.
Ah so with splites you can have a 24 pix wide column of arbitrary data that can be slid around left to right....and may act as an "echo" of the players movement like in this game...or possibly even different physics...
I love the stacking of boolean ops before branches, too.
There is something incredibly refreshing about looking at C64 optimizations. Today we throw gigabytes of RAM at simple CRUD apps, while these developers were counting every single cycle and byte. It’s a good reminder that 'efficiency' used to be a core requirement, not an afterthought.
Chris Wild who ported the Lords of Midnight to the PC, and then later worked with Mike Singleton to create versions for Android/iOS that were unfortunately only published after Mike's passing away, put together this series of articles about the optimisations Singleton used to squeeze so much into the limited memory of the ZX Spectrum and C64.
If I remember correctly Chris ported from the Spectrum. The data structures are particularly interesting using tokens/lookup tables to compress the data as much as possible.
Exactly. When your total memory is 64KB, all optimization is mature optimization.
It's a fascinating contrast to the modern 'move fast and break things' approach. Back then, if your routine was 3 cycles too slow, the sprite didn't just 'lag'—the entire raster effect collapsed. There was a level of deterministic discipline that we've largely abstracted away in favor of developer velocity.
And starting fires or making coats used to be forms of art, now we just buy a Zippo and a London Fog and call it an afternoon. Jobs evolve to specialize. I call that progress.
> However, you can save 1 byte of RAM by using the branch instructions instead, as long as you know which flag(s), if any, are guaranteed to be on or off at the jump point.
> For example, if you know the carry flag will always be clear at the jump point, and if the jump distance is within branching range, you can replace JMP with BCC.
However if the BCC crosses a page boundary it'll take 4 cycles, one cycle longer than a JMP.
From another post on their blog:
> having tried to sabotage its Kickstarter campaign back in 2018 by viciously attacking me and attempting to have me "cancelled" for opposing his hysterical far-left views supporting the LGBT agenda and the degenerate filth of unfathomably evil "trans people" aka demonic monsters (views which, for the record as a conservative Christian, I unapologetically find utterly vile and abominable).
Flagged because people like this don't need attention
This comment does not deserve to be flagged. It is worth knowing the bias of the source as it taints everything it touches.
A link to the comment in question would be good. I had a quick go at finding it, but couldn't (though not to say I spent a huge amount of effort on this project).
But I agree that it's useful to highlight this kind of thing. If you disagree with the author, you probably won't then want to give them your time and attention, let alone your money. But, on the other hand, if you agree, maybe you'll feel the other way! Which is a roundabout way of describing my favourite thing about the internet, since I'm old enough to remember what it was like Before: whoever your people are, for good or for ill, you'll be able to find them.
1 reply →
https://archive.is/CvXXP
Ah so with splites you can have a 24 pix wide column of arbitrary data that can be slid around left to right....and may act as an "echo" of the players movement like in this game...or possibly even different physics...
I love the stacking of boolean ops before branches, too.
Interesting stuff! Regarding game sales, other developers have had more success putting their games on physical media (particularly cartridges).
There is something incredibly refreshing about looking at C64 optimizations. Today we throw gigabytes of RAM at simple CRUD apps, while these developers were counting every single cycle and byte. It’s a good reminder that 'efficiency' used to be a core requirement, not an afterthought.
Chris Wild who ported the Lords of Midnight to the PC, and then later worked with Mike Singleton to create versions for Android/iOS that were unfortunately only published after Mike's passing away, put together this series of articles about the optimisations Singleton used to squeeze so much into the limited memory of the ZX Spectrum and C64.
If I remember correctly Chris ported from the Spectrum. The data structures are particularly interesting using tokens/lookup tables to compress the data as much as possible.
https://www.icemark.com/tower/index.html
Also some notes on Doomdark's Revenge where Singleton managed to create a bigger map and feature more characters.
https://www.icemark.com/gate/index.html
There was no such thing as premature optimization back then.
Exactly. When your total memory is 64KB, all optimization is mature optimization.
It's a fascinating contrast to the modern 'move fast and break things' approach. Back then, if your routine was 3 cycles too slow, the sprite didn't just 'lag'—the entire raster effect collapsed. There was a level of deterministic discipline that we've largely abstracted away in favor of developer velocity.
And starting fires or making coats used to be forms of art, now we just buy a Zippo and a London Fog and call it an afternoon. Jobs evolve to specialize. I call that progress.
And yet there's a difference between a cheaply made coat from an Asian sweat shop and one made with quality materials by a skilled tailor.
4 replies →