Although it runs Commodore BASIC (itself based on Microsoft BASIC as many machines were) it was never intended to be an "emulator" or compatible with the C64 or any other machine. It is its own machine, just as the ZX Spectrum, Atari 800, etc. were also distinct from the C64. [...] Ultimately C64 compatibility is not the aim of this product.
[1]: https://www.commanderx16.com/forum/index.php?/about-faq/
I guess the PICO-8 has some kind of CPU limit, but it's orders of magnitude over the 8-bit 6502 consoles it's broadly mimicking. That was sort of disappointing to me.
Like I said: fantasy-console abstract machines don't aim for technical limitations; but rather, for stylistic limitations. They don't want to impose upon you low-level technical barriers, for you to just treat those limitations as implementation-time programming puzzles to be overcome or worked around. (If you want that, just write games for an actual retro console!) Rather, they want to impose high-level constraints that influence your design-time choices. Less like typing on a broken keyboard; more like writing a poem with constrained rhyme-scheme and meter.
That's why these are "fantasy" consoles — their particular lack of technical constraints means that they can actually require a decent modern CPU/GPU/etc to run; and so could never have actually existed in the era they borrow their aesthetics from.
I've been working on an (IMO) sophisticated tactical game with strong AI in Pico-8 for just about two years now, and I can say that this is not true.
> which would require some kind of CPU-cycle accounting tracking
This is pretty much what it does.
Pico-8 tracks an arbitrary "cycle" budget, which is used to calculate how much computation you're allowed to perform per frame. You're absolutely not going to compute at "bare metal" speed.
Here's some info in the (community) docs:
https://pico-8.fandom.com/wiki/CPU
I don't know how this does/does not compare to the 6502, because I unfortunately don't have any experience there. But you're absolutely not going to get bare-metal performance inside of Pico-8.
You're right about limiting code-size, though. For my own project, the code size limits have proven far more difficult to work around than the performance limits.
Tangent now, but these are some of the Pico-8 limitations:
- screen is 128x128 pixels
- only 16 colors are available (sort of... there's a "hidden palette" too)
- cartridge size may not exceed 32 kb
- cartridge may not contain more than 65k characters
- Lua AST may not exceed 8192 tokens
That last one has been the hardest constraint for me to manage, by far.
Anyway, Pico-8 is a ton of fun. Try it out if you're inclined :)
1. it's compute-resource-constrained — so you can't just transpile DOOM into the "fantasy console's" native programming language / bytecode ISA and expect it to run well, but instead have to learn to program directly for the console's native programming language or ISA — close to the (abstract) metal — to do anything of note with it;
2. it exposes low-level "primitive" features in its native programming language / bytecode ISA, in the form of system calls or MMIO registers, to accelerate graphics/sound operations without consuming (abstract) CPU cycles; thus allowing games developed for the console to run well at 30/60FPS, despite the resource constraints. Where usually these calls are themselves constrained to only allow for "retro" things (e.g. allowing audio only in the form of a set number of square-wave frequency channels.)
In other words, a "fantasy [retro game] console" attempts to achieve a similar set of "artistic constraints" for game development that you get from developing for a real retro game console, like the NES or Gameboy. Except that the artistic constraints imposed by fantasy consoles are usually not low-level technical constraints in the system's (theoretical) microarchitecture, but rather arbitrary ones, and therefore are often less frustrating (think: memory bank switching) and more inspiring to the creative process (think: limited color palette per art asset.)
There may or may not be physical-hardware implementations of a "fantasy console's" abstract machine. A well-known example of a "fantasy console" with only virtual implementations is the PICO-8 (https://www.lexaloffle.com/pico-8.php).
Or you can think of it like this: what if the Super Nintendo never existed, but there still ended up being "SNES emulators" that all agreed on how they should interpret/run "SNES ROMs" — all implementations of a shared abstract-machine standard? Developers would then be producing "SNES games" not to run on a physical SNES, but instead solely so that you could then run them on a compatible emulator. That's a "fantasy console."
This thing — the uConsole — isn't a "fantasy console" itself, per se (i.e. they're using the term wrong), but rather a device focused on running multiple fantasy-console emulators. It's basically like any of the many "retro handheld" devices out of Shenzhen recently — except this one's got a keyboard! :P
A fun example of a more true hardware "fantasy console", where the hardware is itself an implementation of a particular fantasy-console abstract machine, is the https://www.commanderx16.com/.