Lost game from the '80s: Scumbotron!

[ahenry3068]

Alternatively same approach but have all your code and graphics in 1 file but write a separate "loader" again utilize banked ram for some code

[paulscottrobson]

My (Neo6502) version, not quite complete. No Brains .... and obviously no collision detection which makes surviving easy but scoring a bit difficult.

https://www.youtube.com/watch?v=tzpN1NQkSEk

Oh! I missed that - it looks fantastic!

Now playable https://www.youtube.com/watch?v=wik5QBKo2SI

[EyeballKid]

Offload the graphics and maybe some of the code to a separate file. Put less used routines in banked ram

TL;DR: I'm too lazy.

Separate files are cheating!
I decided pretty early on that getting it into a nice single .prg file would be a nicely arbitrary restriction.

My self-decompressing .prg file is only 35KB, which does leave a few more KB of compressed data to play with (could squeeze maybe 10-15KB of new code in there, I'd say).
But the existing code already decompresses to the full 40KB, so any new code would have to go into banked ram, which would just be a bit of a pain. Even just using a single bank (an extra 8KB), it's outside the otherwise-continuous address space, so there'd be a lot of hoop-jumping to get routines properly located. Even more so if I ended up actually having to do bank switching. It'd be easy enough to do in assembly... but... well... I'm old and lazy now. Even if I like the idea of writing games in 6502 assembly, there's no way I'm actually prepared to actually _do_ it I can't really bring myself to write anything that's not portable these days.

[ahenry3068]

Offload the graphics and maybe some of the code to a separate file. Put less used routines in banked ram

TL;DR: I'm too lazy.

Separate files are cheating!
I decided pretty early on that getting it into a nice single .prg file would be a nicely arbitrary restriction.

My self-decompressing .prg file is only 35KB, which does leave a few more KB of compressed data to play with (could squeeze maybe 10-15KB of new code in there, I'd say).
But the existing code already decompresses to the full 40KB, so any new code would have to go into banked ram, which would just be a bit of a pain. Even just using a single bank (an extra 8KB), it's outside the otherwise-continuous address space, so there'd be a lot of hoop-jumping to get routines properly located. Even more so if I ended up actually having to do bank switching. It'd be easy enough to do in assembly... but... well... I'm old and lazy now. Even if I like the idea of writing games in 6502 assembly, there's no way I'm actually prepared to actually _do_ it I can't really bring myself to write anything that's not portable these days.

I mentioned this earlier but are you loading your code from $0400. If your loading it at $0800 or $0801 your missing out on 1 contiguous Kilobyte you could be using. $0400 was Video Ram on the c64. $0400 to $07FF are unused RAM on the X16

[EyeballKid]

I've put the source code up on github if anyone's interested: https://github.com/bcampbell/scumbotron
Requires llvm-mos-sdk and golang to build.