> 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.
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.
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.
Exactly. The 'Asian sweat shop' vs. 'skilled tailor' is a perfect analogy for the state of software today. We’ve optimized for speed of delivery (Zippos and fast fashion) but we’ve lost the durability and resource-efficiency that comes from a tailor-made approach.
It’s fascinating that in 2026, we’re needing more and more powerful hardware just to keep up with the bloat of basic applications, whereas the Seawolves devs were finding ways to squeeze 'art' out of 64 kilobytes.
That’s true for the consumer's wallet, but the 'amortization' breaks down when you look at the systemic cost.
In software, the 'cheaply made coat' equivalent (bloated frameworks, unoptimized dependencies) creates a massive technical debt that doesn't just affect the buyer—it affects the entire ecosystem's energy consumption and hardware requirements. The Seawolves devs weren't just saving money; they were respecting the constraints of the medium. When we treat resources as infinite because they are 'cheap,' we stop being engineers and start being assemblers.
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.
> 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.
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.
It’s fascinating that in 2026, we’re needing more and more powerful hardware just to keep up with the bloat of basic applications, whereas the Seawolves devs were finding ways to squeeze 'art' out of 64 kilobytes.
In software, the 'cheaply made coat' equivalent (bloated frameworks, unoptimized dependencies) creates a massive technical debt that doesn't just affect the buyer—it affects the entire ecosystem's energy consumption and hardware requirements. The Seawolves devs weren't just saving money; they were respecting the constraints of the medium. When we treat resources as infinite because they are 'cheap,' we stop being engineers and start being assemblers.
I love the stacking of boolean ops before branches, too.