Josh Goebel

How would custom editors have their own graphic resources (sprites, etc) if the only memory they had access to was all from the currently loaded user cartridge? I wonder if...

> Maybe TIC-80 needs a notion of RAM as in "memory for data of running program"? So It already has 96kb of RAM. But variables inside the language runtime and...

Just adding another 8 banks and saying banks 0-7 are user cartridge and banks 8-15 are editor could work, but I'm not sure how annoying (or not) that would be...

> Erm, no. It has 96kb of address space, We're arguing over semantics. I understand there is the "fantasy device" RAM and then there is the JS/Lua/etc runtime memory. I...

> as the TIC doesn't pass keyboard events to cartridge. Sure it does. `key` and `keyp`. Funny I'm more interested in a code editor than the others.

I've been trying to think about how to even start/approach this (forgetting the more mundane concerns like data access)... currently the idea is we have a single `currentVM`... a single...

> We actually probably need two full VMs too Actually this is a given/requirement (unless we plan to reinit the VM every time we context switch) I think... you shouldn't...

I don't think the path forward here is easy (I think it'll require a bit of effort and willpower). But I think I'm starting to imagine how the entire architecture...

> but what the TIC80 architecture looks like now is the result of the evolution of the project Sure, don't take any of this as a critique of your amazing...

> The same problem we fixed earlier with the keyboard registers, the user can break the system mapping from the game, perhaps we could fix it the same way as...