I have the original handheld console Pocket Chip[1] which came with PICO-8. My son is now enjoying it as a learning tool for game development, but it's quite slow to boot up and there are no more software updates Next Thing Co. is no longer around.
Clockwork Pi (who make the DevTerm) is creating a sort of spiritual successor, the uConsole[2] and they've just started taking preorders. I don't know if it comes with PICO-8, but you could always load the FOSS TIC-80[3] instead. I like that they've included key caps to the buttons as the typing experience on the Pocket Chip was terrible.
This link discusses how many cycles you have for your game per frame at 30fps and 60fps, and specifies how many cycles different functions, variable accesses, etc take, and methods of optimisation.
Very interesting, I’ve been reading up on/reminding myself about 6502 opcodes and their cycles recently. It’s kinda cool that Pico-8 is documented to a similar level, even if it seems like those limitations seem artificial (you get a set number of cycles regardless of the speed of the host computer.)
> you get a set number of cycles regardless of the speed of the host computer
If you look at all the PICO-8 clones/inspired platforms without such a restriction, it's hard to overestimate how prescient this was. Basically all of them had raytraced 3D games in their 200x200 pixel box in week 1, which regardless of palette limitations completely kills the 8-bit vibe for me.
Also, this restriction ensures that all the newest PICO-8 games also run on the very old PCs that children might have access to, which I think was great for the health of the platform.
I love pico-8, but it’s never really seemed like a VM to me—at least in the sense that there are virtual instructions running in the background. It feels more like the constraints and memory mapping are integrated into an event loop with a Lua API to interact with the “machine”. Does anyone know precisely how the internals work?
That is exactly how it works -- the implementation doesn't look much like an emulator for real hardware. Although there is a VM running underneath (a lightly modified Lua 5.2 VM), it is not exposed to the user except for the purpose of counting cpu cycles (around 2 per vm instruction). Operations like drawing sprites subtract cycles from the same pool using over-simplistic rules e.g. 1 cycle per non-clipped pixel. There is a limit on Lua memory (2MB) which is similarly silly -- every time it is exceeded, an emergency garbage collection is issued to find out if an OUT OF MEMORY error is needed.
PICO-8 is driven more by the design goal of giving a strong impression of a machine rather than being a well-formed definition of one. It certainly takes liberties with what should be plausible when it suits, but most interactions with the lower level (e.g. poking pixels to video ram) are plausible enough that the fourth wall is not broken.
There are machines that go all the way down to the metal though, which gives them their own kind of allure:
Wow! I am honored that you took the time to provide such a comprehensive response. Thanks for all the work you’ve done with pico-8. It has brought a lot of people (myself included) a lot of joy!
I think Pico-8 tries to capture the spirit of 8-bit computing more than the reality. The most popular 8-bit computers came with a BASIC, and many home users (me at the time included) programmed that to move some sprites around, and never really went into assembly language. Lua seems more inspired by BASIC than most modern languages, so Pico-8 feels like coding for a very friendly 8-bit computer with an ultra-high-powered BASIC. But it doesn't really simulate an actual CPU that this BASIC interpreter would run on.
Interestingly enough the machines PICO-8 is inspired by can pull of way amazing things that are miles beyond what it offers.
(See demoscene.)
PICO-8 is on par with the old Tiger Electronics game.com "console" or even a bit worse, quite a lot inferior to NES.
Even then, with cleverness you can do a lot with it. Including proper raycasting. Picostein 3D. :) Or rather POOM.
Even with their quirky hardware choices and slow CPUs. The style was mostly due to speed wotg which the games were cranked out, plus lack of knowledge and skill of particular authors. Pooling knowledge leads to some amazing results.
Clockwork Pi (who make the DevTerm) is creating a sort of spiritual successor, the uConsole[2] and they've just started taking preorders. I don't know if it comes with PICO-8, but you could always load the FOSS TIC-80[3] instead. I like that they've included key caps to the buttons as the typing experience on the Pocket Chip was terrible.
1. https://en.wikipedia.org/wiki/CHIP_(computer) 2. https://www.clockworkpi.com/uconsole 3. http://tic80.com/