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!
[1]: https://www.lexaloffle.com/bbs/?tid=140771 [2]: https://www.lexaloffle.com/bbs/?tid=140678
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.
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?"
Just my non-data backed opinion...
They've also enjoyed tweaking the sprites of existing PICO-8 games.
Would it necessarily be all that much slower than Basic? It's a very small and othogonal design.
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
> Lua based interactive firmware for ESP8266, ESP8285 and ESP32
https://github.com/nodemcu/nodemcu-firmware
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.
https://nodemcu.readthedocs.io/en/release/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!
https://blog.davidv.dev/making-a-handheld-pico8-console-part...
https://blog.davidv.dev/pico8-console-part-2-performance.htm...
1: https://en.wikipedia.org/wiki/Dynamic_random-access_memory#P...
https://github.com/6502Nerd/dflat/wiki
(See language description here: https://github.com/6502Nerd/dflat/wiki/2.-Language-Descripti...)
Maybe something like this could evolve/be adapted for continued modern development needs?
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.
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.
https://www.microchip.com/en-us/development-tool/linux4sam.o...
With well made compute modules: https://www.digikey.com/en/products/detail/microchip-technol...
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).
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.
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)
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.
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.
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.
It had other limits to explore other than shoving as much as you could into 64k of memory and 1Mhz of processing power.
Very much in the spirit of the early home computers (inc a decent BASIC) but with a lot more oomph.
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.
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.