What if there was a followup to Pico-8, almost as like a next-gen version of the console, kind of like the NES to SNES. Since Pico-8 was meant to be 8bit, this would be 16bit, called Pico-16 Features would include:
- Larger cart size, using .gif rather than .png for export and .p16 for the other format
- Using the same easy to learn lua code
- increasing cart limit from 32k compressed to 120k compressed
- color palette increased from 16 colors to 64 colors
- multiple maps
- larger sprite size of 16x16
- backwards compatible to load and play but not export pico-8 carts
A really good example of a system that's between power-of-two bit sizes is the SNES (or the Apple IIgs, with the same processor).
The 65816 succeeded the 6502/6510 we know from Apple II/IIe and VIC-20/C64 days. Instead of a single 64k memory space, it had up to 256 banks of 64k, effectively giving you 24 bits of address space. You could either spend extra code space and cycles on absolute 24-bit addressing, allowing you to read any bank at any time, or you could work within your current bank as if you were in an oldschool 16-bit address space. That's what you'd do most of the time. I think the IIgs actually sandboxed its multitasking OS's processes as one per bank.
It was a pretty good system and often produced quite compact, fast code if you simply gave your data formats and algorithms some extra thought to accommodate the arrangement. I really enjoyed working on it, back in the day.
I'm not sure how well you could translate something like that to a fantasy console, though. You could definitely do some kind of banking though. Heck, even the multi-megabyte memory expansion thing that came out way too late for the c64 did it with banking, just not in full 64k pages. I think it switched 8k pages, not sure. I've seen full-motion movies people did on c64s where they were basically just changing the bank register once per frame, having previously encoded the entire movie into raw c64 screen data stored without compression on the memory expansion.
It might be fun to be forced, say, to arrange sprite memory pages intelligently so we can switch them as we flow through rendering a scene. Kinda like a manual texture cache. You could also page map data in and out, allowing for huge maps if you're willing to do some extra work. The actual hardware layout might remain the same, as if this were a small increment in tech, leaving sprite ram and map ram and so on where they are, but with the ability to page in 4k or 8k blocks from a much larger rom, rather than just the direct-mapped blocks we have now. Maybe the same with audio, though that would suggest a need for smaller pages, e.g. 256 bytes maybe.
(This is basically a nicer version of the reload() trickery we're able to do with additional carts, but since you're meant to be changing a bank register, rather than loading/dma-ing data, the switch would be instant and there'd be no spinning cart icon in the corner.)
[Please log in to post a comment]