bB 256k, 128k, 64k, 32k, 16k, Multikernel Frameworks

[+Gemintronic]

1 hour ago, Karl G said:

I don't understand the concern with RAM. It could be initialized in the startup bank like normal. I don't see how using a multikernel framework would create more issues. 

 

Since each 4k is its own compiled game you have to tell the special score_graphics.asm what bank to completely switch to.  So, once you switch over it's like starting a new cart except with the RAM in a used state.  Or, at least the random state that real hardware can power on with.

 

So, you need a jump table and a variable (I feel a superjump variable is a good name *shrugs*) to make the jump manageable.  But, you also have to safeguard against unintended changes / states in that superjump variable.  Maybe?  My brain not so good at the logistics.

 

If you immediately clear the vars on boot in bank1 then when you jump back to it.. it'll clear that superjump var again.  Your jump mangement code now thinks it should help you jump to the first bank.. where the init code clears vars..  my head!

 

Debugging might be fun too if that superjump var gets randomized by the state of RAM on cold boot.  Or, my super secure cleanroom agile kanban code makes an oopsie and sets the superjump var wrong.

[CPUWIZ]

I think what he is getting it, is that you can have one kernel be the master, which clears the RAM.  Then it uses one byte in RAM as the "level number" and you simply do not clear RAM again and manage it properly in the other kernels.