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

Could always go halfway like the PCEngine/TG16 did and still be an 8 bit system but with 16bit extensions. That was always a fun lil half-console.

How many audio channels?

Genesis has 6 from YM2612, 4 from SN76489, for total of 10

SNES has 8 from S-SMP DSP

TG16 has 6 from HuC6280 PSG

PICO-8 has 4 with 8 waveform and effect algorithms

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.)

Maybe it could support 3d graphics?
or a fantasy co-processor made to deal w/ the 3d calculations.
like the SuperFX chip used in some 3d snes chips.

curious, I tough about it today...and you touh about it 3 years ago lol should be a good idea!

maybe using 68000 cpu?

There was actually another thread suggesting a PICO-16 recently - people in that thread mentioned the part of zep's PRACTICE 2018 talk where zep specifically says, "I designed a PICO-16 just to remind myself to not make that" (which suggests to us that it won't happen) but they also offered some suggestions of other fantasy consoles to investigate. Can't promise I saw all of them, but it looks like TIC-80, Pixel Vision 8, and quadplay were all mentioned, as well as a Discord server focused on fantasy consoles.

pico-16 would be perfect. The 8's graphics is just too rough to make out half the time what is happening, and sometimes even to read.

@Taqyon I mean we've got picotron now, I highly doubt we'll get somewhere in between pico-8 and picotron though, because picotron would be able to do everything a hypothetical pico-16 could do

But Picotron is just a dev environment? The only emulator we have is the pico-8? Something double the res would be so much more usable but still be small enough to keep it simple and niche.