you can’t as easily place code outside the low 4k.

Ok this was bugging me for a while, but then I realized we can just split the RAM into banks, and swap them in and out as needed. This even works perfectly with the built-in web compiler if you keep you bank offsets at 0x1200, 0x2200, etc… (so that the jump addresses calculated by the compiler still work once “reallocated”). It’s quite convenient that the compiler still compiles all the jumps just fine, it just truncates the high bits (bits 13-16)… so in order to run the code all we need to do is copy it back into the 0x200 to 0xFFF range.

My proof of concept places the “loader” at 0xF00… which gives you 14 banks of 3328 bytes… of course the code in one bank can’t directly call another… they are more like 14 mini programs you can swap in and out on demand… The copy code could be faster, but I was optimizing for size (64 bytes currently), not speed. It currently takes 29,000 ticks now to switch banks, but you could easily reduce that by a factor of 10 if that was a requirement.

Update: Around 4,500 cycles when optimized for speed, so if you burned 100% “cpu” you could swap banks 4 times per frame running at ludicrous speed… so it would be possible to have rendering code and update code in different banks and swap them per frame… and still have 55% of the cycles available for your actual code to run…

And if you wanted the full 3584 bytes for each bank you could (with a tiny bit of effort) relocate the loader itself to < 0x200 (after boot)…

The proof of concept just places one of the demos at 0x1200… and then :main just sets the bank address and than calls swapbank… after the bank is swapped in control returns to 0x200.

Proof of concept:

https://johnearnest.github.io/Octo/index.html?key=VXhioVqu

That's pretty good. I guess you have plans for a game with a lot of code :)

Still I would classify this as outside the realm of "easily" when talking about where you're putting code, vs just putting your code first and data second. Ludicrous speed is mostly used for when you don't care if the program had any home of running on anything resembling real hardware. You don't have to stick to that restriction, of course. For standard Chip-8 it's closer to 20, 30 cycles. XO-Chip being the imagined slightly upgraded hardware I like to think it tops out around 100 cycles and try to keep my programs limited to that. That's just me though :)

Keep pushing what's possible though! I'm looking forward to whatever it is you end up making for the jam. It should be interesting.

I guess you have plans for a game with a lot of code

Maybe, I just didn’t want to feel “limited”. :-)

Well I think “easy” still applies as in you can use the existing compiler, NATIVE code, existing labels, etc… the amount of hoops to jump thru really isn’t that large. There is no need to write a virtual machine, etc… for a game split into modes (world map, fight mode, inventory mode) something like this might work really well.

For standard Chip-8 it’s closer to 20, 30 cycles. XO-Chip being the imagined slightly upgraded hardware I like to think it tops out around 100 cycles

The optimized code clocks at 4400… 2-3 seconds (for 20-30 CPS)… so I’d call that “viable” even for old hardware, you could show a small progress bar. If you have 100+ cycles than it’s less than a second to swap a whole bank.

And again you could mix this with a progress bar or some other type of animation (if done carefully)… so it’s possible you could even hide the delay from the user with some type of transition.

Curious: Is it really common to have devices that have the 64kb to run XO-Chip, but also NO CPU speed? I though really XO-Chip only existed for Octo explicitly. Or perhaps that’s why you say “imagined”… you’re just creating artificial constraints…

It's a viable option for sure, just more of a pain than say, not having to do that :)

You are correct, XO-Chip is a fantasy console imagined in the vein of Chip-8 as a reasonable extension without crossing over into something like Pico-8 or trying to make Gameboy game etc. There are no "realistic" models for what XO-Chip could or couldn't do because it never existed. This is all just for fun. :)