I had a good time with PICO-8 - and I think it retains its core appeal - but I've moved on to "genuine" retro hardware with the new crop of machines like CX16, Mega65, or my personal choice, Agon Light. The specification ends up being tighter when there's a board design, chips and I/O ports, and these new machines, like Picotron, are relatively uncompromised in what they can achieve within the I/O spec. You can emulate them, talk to the hardware directly, run BASIC or C or Forth or whatever other language.
Lua might be too slow to run interpreted on real 8-bits as in the Pico series, but it can be used as the base for a cross-compiler instead, and that presents a different spin on the specific coding challenge: Why not create an ultimate development environment, something that generates the precise code needed for that type of project? That's the direction that the highly optimized PICO-8 games took, and it is likewise seen in new demos for C64, Spectrum, A800 etc. - the "big hardware" is leveraged towards the old stuff in a way that can ignore the assumed paradigms of both.
> but I've moved on to "genuine" retro hardware with the new crop of machines like CX16, Mega65, or my personal choice, Agon Light.
I just wish these would move on from the same crop of retro CPUs (z80, 6502, maybe 8080) and clone VDPs on FPGA. I want a retro-style 2d/blit-based machine, but with more advanced hardware. Maybe a Cortex-M, z8000, 68000, low-end Risc-V, etc. Still give it BASIC in a boot ROM, but some more 90s style headroom to grow into.
I guess what I'm saying is, I totally get that all these people grew up on Commodore 64s and are trying to recapture that magic. However, the Amiga/Atari/BeBox/etc hacking days shine way more with me.
I would love to see the alternate world in which the z8k or 68k were finished in time for use in the IBM PC. Intel is dominant today almost entirely due to the 8086 being available 6-12 months earlier than competing 16- and 32-bit processors.
I have one of the originals and spent hours messing around with it. It's a great little computer and MMBasic is pretty nice. Thanks for the memory reminder.
And open reference designs that fit on 4-layer boards (!!!!) despite using DDR2. Though I think most people would be more comfortable with 6-layer boards (which is possible with OSHPark today).
Something like an STM32 Discovery board is a good option for recapturing the mid-90s magic. You can get a ~200-MHz Cortex-M4 or M7 with a few MB of flash, external SDRAM, and a display for less than $100. They have really basic hardware 2D accelerators.
The on-chip peripherals are well-documented, but off-chip peripherals require some digging to figure out how to program correctly.
You can debug with GDB surprisingly easily, or find a Forth to throw on there and just start poking registers.
No. Microcontrollers are the improper solution for this problem.
You can run full blown Linux efficiently at 500MHz or 600MHz processors like STM32MP1 processors, powered by AA batteries or other small battery packs.
There's also SAMA5D2, and a few other competitors in this space (both above, and below, the STM32MP1).
When we're talking about "consoles", that's "plug-and-play executables", meaning you now want a proper compile / library -> ELF + loader == Linux kernel, security, etc. etc.
Besides, a DDR2 chip gets you like 512MB of RAM for $4 and easily fits within the power-constraints of AA-batteries. There's very little benefit to going to the microwatt-scale devices like STM32 Discovery.
----------
Microprocessors for the win. Entry-level MPUs exist for a reason, and there's a ton of them well below Rasp. Pi in terms of power / performance.
There's many at the 2D level of graphical performance, but 500MHz is still a bit low for this. You'll probably want to reach into faster 1000MHz / 1GHz MPUs and push into STM32MP2 if you're reaching into 3d levels of performance. (Which is beginning to look like a cut-down cellphone chip really)
I guess it depends on which part you think is fun. Using a big microcontroller is more about pushing the hardware to its limits. Using a small Linux system is about taking advantage of existing libraries. The Playdate has an STM32F7 and it seems to do pretty well as a console.
I liked the 32F746GDISCOVERY which is $56 at Digikey. It has a Cortex-M7 CPU, 1 MB built-in flash, 8 MB of SDRAM, and a 480x272-pixel touchscreen. Games can go on a microSD card. There's a USB OTG port you can use for input.
A low-res screen like this works well because the chip can't rescale its video output.
ST provides libraries for all the peripherals so it's pretty easy to jump in if you know C. I think microPython works on a lot of these boards, too.
it looks like the agon light actually runs an ez80 which runs pretty fast and can address the whole 512k of ram without paging which does give you that sort of late-80s/early-90s headroom
The eZ80 is indeed quite fast, and the 24-bit space is a comfortable size for values as well as addressing - I've been working with it in Forth and haven't felt deeply constrained by that size(occasionally needing the double number operations, but nothing more than that). The graphics spec is a little bit below most 16-bits in terms of color depth, since it's VGA 2-bit per channel, but the screen resolutions also go quite high, so I expect a lot of 640x480x16 or 800x600x4 games.
Meanwhile, the ESP32 acts as an ultimate co-processor through the VDU protocol inherited from the BBC Micro. That's a part of the architecture that I really appreciate, because it positions software design around the serial I/O and how effectively you delegate your tasks to the VDU. Early reactions from people who are used to 8-bit coding were a bit perplexed because they couldn't push a lot of stuff down that pipe, but as the firmware has developed, the ability to define complex, shader-like programs has also built up. Nothing stops you from describing, e.g., a tilemap engine in terms of a program that stores map data, tiles, and sprite assets in VDU buffers, and then launches a program to do all the array processing needed to blit the tiles and display the sprites when given a camera position.
That's cool because it means that your graphics engine is decoupled from the CPU language. The same VDU sequences will work in Basic, assembly, Forth, C, etc.
I think this is less people who grew up with C64s and more people who didn't trying to capture the magic without having to learn assembly or making sprites with graph paper and a hex editor.
Sure, but there was a whole other magic era that followed that. That also got to work with low-level assembler and direct framebuffer/video access. But wasn't constrained to 320x200x8 screens with pictograph fonts ("petscii") and POKE/PEEK.
It had other limits to explore other than shoving as much as you could into 64k of memory and 1Mhz of processing power.
Enough already with retro hardware that reproduces the early 2d games aesthetic. We need to step up the game and make retro hardware that reproduces the early 3d aesthetic.
This is completely my subjective opinion, but I find "early 3D" ugly. In my opinion, pixel art has aged better. In fact, some of it still looks beautiful to me. But early 3D I find almost completely unappealing.
About the only exceptions I can think of are some flightsims like SSI's Flanker (which had very complex graphics for being simply flat-shaded 3D) and the games that emulate this nowadays, like Tiny Combat Arena.
The development cost -- of the tooling and the games, let alone hardware! -- is too high. Additionally, 3D games aren't products of their host hardware as much as (older) pixel art games are/were.
I started using a graphics card with a 34010 before there were tools available for it. I did ports of GNU binutils (gas and ld) to target it then wrote some firmware in assembler for an X11 server to call to do basic tasks like filling rectangles, line drawing, copying with colour expansion for displaying fonts.
Still have the ISA card but haven't powered up the machine it is in for a long time.
+1 My kids and I had a lot of fun with Pico-8, building simple games and learning basic geometry.
The community (inherited from Pico-8) is already implementing cat/wget/grep[1] and, of course, Minesweeper[2] in Picotron! Whatever Joseph White/zep is building brings back the early days of Internet and IRC where the everybody builds and shares unashamedly while having a ton of fun!
Thank you zep for making computing fun again for more mere mortals!
I'm curious how old your kids were when they started hacking on PICO-8 code?
My son (7yo) likes block-based programming (using Scratch, Scratch Jr and Octostudio) and Minecraft, but I'm wondering what a smooth on-ramp might be for PICO-8 or similar.
I got my first computer when I was about 10yo, so I was content to read through the books that came with it to learn the basics of BASIC and a little 6502 assembly. But I don't think that will work due to age, availability of other devices etc.
My kids are 12 and 14 and I can't get them interested in coding beyond what they might do at school. They showed an interest in Scratch, but I believe I introduced it WAY too early. Moreover, it moved them too quickly past the creative aspects and into writing code. Also, years later, I showed them PICO-8 and they weren't terribly interested.
In hindsight, I would recommend working with them at a young age (<10) to design game art and ideas. Then, the parent implements it and ports it to a portable platform. The child sees the creative aspects and the final output, but is shielded from the coding side in the early days. I imagine a child playing a game they designed on paper with crayons would be really satisfying. It would almost be like magic!
Then, let the transition to the coding side happen more organically or through a school program or some such. Maybe when they finally ask, "So, parent, how do I actually code these games?"
That's what I've been doing with one of my kids. They're designing the sprites and maps in the PICO-8 sprite editor and I'm taking the lead on showing them how to do the rest.
They've also enjoyed tweaking the sprites of existing PICO-8 games.
There are efforts to port pico8 to microcontrollers, but the real problem with lua is memory (easily requires 4MB of memory which is only available on high-end microcontrollers).
Ok, but which language feature(s) of Lua is it which inherently requires so much memory? I understand you wouldn't exactly get a 100% standards compliant implementation, but what are the hard parts?
With Lua's design, each bytecode operation requires a bunch of memory accesses, these microcontrollers only have a limited amount (~500KB) of SRAM, so you need to place this memory on PSRAM (RAM over SPI) which has "significant" latency for these microcontrollers.
It's definitely possible to use standard Lua and run _some_ of the Pico8 games, but not all.
Lua itself does not require a lot of memory, but PICO-8 guarantees 2MiB of usable RAM
A big difference I see between this Lua and PICO-8's is that the former is compiled, whereas the latter is interpreted.
How it manages to run Lua with such limitations, the documentation of Lua Flash Store (LFS) goes into detail.
> The ESP8266 has 96 Kb of data RAM, but half of this is used by the operating system, for stack and for device drivers such as for WiFi support; typically 44 Kb RAM is available as heap space for embedded applications. By contrast, the mapped flash ROM region can be up to 960 Kb, that is over twenty times larger. Even though flash ROM is read-only for normal execution, there is also a "back-door" file-like API for erasing flash pages and overwriting them..
> Lua's design goals of speed, portability, small kernel size, extensibility and ease-of-use make it a good choice for embedded use on an IoT platform, but with one major limitation: the standard Lua RTS assumes that both Lua data and code are stored in RAM, and this is a material constraint on a device with perhaps 44Kb free RAM and 512Kb free program ROM.
> The LFS feature modifies the Lua RTS to support a modified Harvard architecture by allowing the Lua code and its associated constant data to be executed directly out of flash ROM (just as the NoceMCU firmware is itself executed).
> This enables NodeMCU Lua developers to create Lua applications with a region of flash ROM allocated to Lua code and read-only constants. The entire RAM heap is then available for Lua read-write variables and data for applications where all Lua is executed from LFS.
That's still such a tiny amount of RAM, not nearly enough for PICO-8.
..Oh I see, the project PicoPico mentioned up-thread uses ESP32 Wrover with 4MB PSRAM - instead of Raspberry Pi Pico which it started with but didn't have enough RAM.
Well, having just seen the entrance of the rabbit hole, I can imagine the attraction of PICO-8 and working with such constrained systems - what a challenge!
The constraints fuel creativity, but it also pushed me to start writing a Lua compiler for PicoPico, which shows promise but is also a massive scope creep and mostly the reason I've not worked on PicoPico for a while
As much as I love Lua its very difficult to shoe-horn into an 8-bit CPU, especially with limited RAM... but there are other efforts to bring more modern languages to these platforms, and one that strikes me as interesting is dflat, from 6502Nerd:
The Pico8-inspired TIC-80 project can use WASM, although it’s a pretty heavy fantasy console too. The WASM-4 project might be another option to look into.
Lua might be too slow to run interpreted on real 8-bits as in the Pico series, but it can be used as the base for a cross-compiler instead, and that presents a different spin on the specific coding challenge: Why not create an ultimate development environment, something that generates the precise code needed for that type of project? That's the direction that the highly optimized PICO-8 games took, and it is likewise seen in new demos for C64, Spectrum, A800 etc. - the "big hardware" is leveraged towards the old stuff in a way that can ignore the assumed paradigms of both.