5 ms·

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,

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.

vintermann 3y ago
> Lua might be too slow to run interpreted on real 8-bits as in the Pico series Would it necessarily be all that much slower than Basic? It's a very small and othogonal design.
- benob 3y ago
  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). https://github.com/DavidVentura/PicoPico https://github.com/DavidVentura/PicoPico
  - vintermann 3y ago
    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?
    - deivid 3y ago
      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
      - lioeters 3y ago
        There is a Lua implementation for microcontrollers called NodeMCU. > Lua based interactive firmware for ESP8266, ESP8285 and ESP32 https://github.com/nodemcu/nodemcu-firmware 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/ 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!
- boffinAudio 3y ago
  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: https://github.com/6502Nerd/dflat/wiki https://github.com/6502Nerd/dflat/wiki (See language description here: https://github.com/6502Nerd/dflat/wiki/2.-Language-Description https://github.com/6502Nerd/dflat/wiki/2.-Language-Descripti...) Maybe something like this could evolve/be adapted for continued modern development needs?
  - thesnide 3y ago
    I dream of a pico8 clone, but with forth instead of lua....
    - jamesgeck0 3y ago
      There are some forth WASM compilers, right? 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.
kelvinquee 3y ago
+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! [1]: https://www.lexaloffle.com/bbs/?tid=140771 https://www.lexaloffle.com/bbs/?tid=140771 [2]: https://www.lexaloffle.com/bbs/?tid=140678 https://www.lexaloffle.com/bbs/?tid=140678
- rahimnathwani 3y ago
  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.
  - krumpet 3y ago
    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?" Just my non-data backed opinion...
7thaccount 3y ago
Agon Light looks awesome! I like my ZxSpectrumNext a lot, so I appreciate these dedicated machines.
deaddodo 3y ago
> 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.
- aidenn0 3y ago
  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.
- dragontamer 3y ago
  I have to imagine that this is the purview of embedded 2D microprocessors / OSes like Linux4SAM. https://www.microchip.com/en-us/development-tool/linux4sam.org https://www.microchip.com/en-us/development-tool/linux4sam.o... With well made compute modules: https://www.digikey.com/en/products/detail/microchip-technology/ATSAMA5D27-SOM1/8536637 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).
- rjsw 3y ago
  I would start with the MIT CADR CPU in an FPGA and add modern hardware round it like Ethernet, USB host, 2d blitter, etc...
- qooiii2 3y ago
  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.

vintermann 3y ago

> Lua might be too slow to run interpreted on real 8-bits as in the Pico series Would it necessarily be all that much slower than Basic? It's a very small and othogonal design.

benob 3y ago
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). https://github.com/DavidVentura/PicoPico https://github.com/DavidVentura/PicoPico
- vintermann 3y ago
  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?
  - deivid 3y ago
    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
    - lioeters 3y ago
      There is a Lua implementation for microcontrollers called NodeMCU. > Lua based interactive firmware for ESP8266, ESP8285 and ESP32 https://github.com/nodemcu/nodemcu-firmware 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/ 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!
boffinAudio 3y ago
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: https://github.com/6502Nerd/dflat/wiki https://github.com/6502Nerd/dflat/wiki (See language description here: https://github.com/6502Nerd/dflat/wiki/2.-Language-Description https://github.com/6502Nerd/dflat/wiki/2.-Language-Descripti...) Maybe something like this could evolve/be adapted for continued modern development needs?
- thesnide 3y ago
  I dream of a pico8 clone, but with forth instead of lua....
  - jamesgeck0 3y ago
    There are some forth WASM compilers, right? 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.

kelvinquee 3y ago

+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! [1]: https://www.lexaloffle.com/bbs/?tid=140771 https://www.lexaloffle.com/bbs/?tid=140771 [2]: https://www.lexaloffle.com/bbs/?tid=140678 https://www.lexaloffle.com/bbs/?tid=140678

rahimnathwani 3y ago
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.
- krumpet 3y ago
  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?" Just my non-data backed opinion...

7thaccount 3y ago

Agon Light looks awesome! I like my ZxSpectrumNext a lot, so I appreciate these dedicated machines.

deaddodo 3y ago

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

aidenn0 3y ago
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.
dragontamer 3y ago
I have to imagine that this is the purview of embedded 2D microprocessors / OSes like Linux4SAM. https://www.microchip.com/en-us/development-tool/linux4sam.org https://www.microchip.com/en-us/development-tool/linux4sam.o... With well made compute modules: https://www.digikey.com/en/products/detail/microchip-technology/ATSAMA5D27-SOM1/8536637 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).
rjsw 3y ago
I would start with the MIT CADR CPU in an FPGA and add modern hardware round it like Ethernet, USB host, 2d blitter, etc...
qooiii2 3y ago
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.