> The real challenge, it seems, it simply that there are so few cycles left over to implement the actual game logic.
I haven’t programmed the 2600, but I expect that, in about every program for the 2600, running out of time for your game logic is unavoidable, and will make you go back to your universal, (relatively) easy to use kernel and tweak it to make it just a little bit faster for your particular use case.
Given that that kernel will be written in tight assembly, I expect that more or less amounts to a rewrite. You’ll use your knowledge f the kernel to write a new one.
Even on the NES and I'm sure more modern consoles and maybe any game.
You often round robin game logic.
Here's a fun example Castlevania on the NES by timing your movement precisely you can make it skip certain blocks being loaded. Making it leave a stair case or even a door.
Works because alternate even and odd frames responsible for loading different y coords for level data in blocks.
You don't really have that many spare cycles per line (unless you have double height pixels), and since there's not many registers either, you really can't get much done with the spare cycles, either.
You really do need to get almost all your game loop to fit into vblank, and spend most of the screen on time driving the graphics. NES and other systems with fancier graphics systems kind of inverted the script; on those you run the game loop during screen on, and mostly transfer data to the graphics unit during vblank.
I haven’t programmed the 2600, but I expect that, in about every program for the 2600, running out of time for your game logic is unavoidable, and will make you go back to your universal, (relatively) easy to use kernel and tweak it to make it just a little bit faster for your particular use case.
Given that that kernel will be written in tight assembly, I expect that more or less amounts to a rewrite. You’ll use your knowledge f the kernel to write a new one.