Picotron Is a Fantasy Workstation
lexaloffle.com
lexaloffle.com
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.
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.
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.
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.
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.
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)
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.
Pico-8 had so much care put into its goals and intentional limitations: and so far Picotron seems to have that same level of love and thought. It's delightful, and I don't want to stop making things with it.
I've used many of the clones of pico-8 and they all feel like they miss the point. They "improve" on the limitations, but are just... not satisfying. Funnily enough, I've tried three times to make my own JavaScript version of what Picotron is ("what if I made a more feature-rich version of Pico-8 to use for prototyping in game jams?") and each time abandoned it because it felt like the Pico-8 clones: adequate, functional, but not inspirational.
I don't know who makes Pico-8 and Picotron, but hats off to you amazing person/people for making such likable software!
I too put Aesprite in this category, but the big one for me is Godot. After years of from-scratch OpenGl projects and dabbling with Unity, I leaned into Godot 100% around 2020, and ever since it has been my #1 joy-sparking piece of software.
I’m noticing a trend of newer indie software distributing assets in png files, what’s with that?
But even emailing scripts for work got flagged. This png format would probably avoid that.
Also good thing it’s lossless. Other wise those multiple save jpg artifacts could cause interesting bugs.
There's a whole subculture that embraces glitches in gaming, graphics, etc. Folks run around collecting screenshots and videos of these ephemeral artifacts. It's fairly complementary to speedrunning gaming culture.
Reminds me of the time they would distribute tape deck based software via the radio.
*Not as much as 0.1a but there's still kinks to be worked out for 0.1c.
Of course, despite the machine itself (pico 8 that is, and this thing too) being proprietary, all the user-programs are source-available if not open source. It's really educational and I love it.
There will be compatible implementations of this thing, but the pico-8 tools were so refined, and pico-8 was so cheap, that I can't imagine not giving the dude 10 bucks. (i.e. the open source implementations might just run the program but not come with all the cute tools like the IDE, the pixel sprite/map/etc editor, or the music tracker), that was well and truly worth the money. Pico-8 is one of the only pieces of paid-for software I haven't hated.
Tl;dr: I think pico-8 is wonderful, I think the community and free programs are wonderful, and I think given that, this will also be wonderful.
I'm a fan and have been for a while.
But it is not a clone of PICO-8. It offers a resolution that's very similar to that of the Game Boy Advance, so it serves as a nice transition stage towards GBA development. You can then enjoy your games on a console like Anbernic RG351P that's optimized for GBA games (2x integer scaling, same screen ratio). It's a specific use case, but one where TIC-80 shines.
I'm not trying to be contrary, I'm really just trying to find what the unique thing about PICO-8 is since nobody has been able to articulate it, yet many people appear to feel it.
But GGP made the argument out to be altruistic, that paying for one over the other is because it's better for the world. If that is the motivation, I would want to donate however much I could afford to the one with highest impact!
(For those new to Pico-8, hit 'esc' from the Lua console to bring up the editor tools, then click on the icon in the top right.)
Indeed, but I have a gripe with it that I cannot get over, the editor's font is too damn hard to read, I tried get used to it but to no avail. The games however are very playable, fun, inspiring and the community couldn't be better.
I'm too spoiled by modern text editors to accept the embedded one for any long time
Is that ballpark, or throttled for consistency? The FAQ has a "How Fast is the CPU?" item, but that just discusses being fast and faster than PICO-8.
Practically, it’s not significantly more headroom than PICO-8 had because the screen is so much larger. You’ll have to use a low resolution screen mode if you want to do CPU-heavy things that wouldn’t fly in PICO-8.
> Picotron supports PICO-8 style shorthand syntax, almost the whole API, and other compatibility features that make it relatively easy to port PICO-8 cartridges. However, it is not designed to run PICO-8 carts out of the box, because the underlying machinery is quite different. For example, Picotron uses floating point numbers, and so can only approximate PICO-8's fixed point math behaviour.
https://en.wikipedia.org/wiki/0x10c https://github.com/lucaspiller/dcpu-specifications
Late shaving cardware Roombas
Anybody know if the picotron is more tightly bounded in this way when it comes to memory usage in the programming system, and elsewhere, to turn it into a "true" constrained environment?
I’m not sure how Apple gets away with forcing people to pay $99/yr to be able to let people install software without getting a warning. I guess it’s a minor issue. I have added a few installs to my “yes I really want to use this software” list on my m1 air, but I still think it’s a little bit silly. It’s obviously some sort of security feature, but Apple isn’t my mother.
Apple gets away with it because Mac users tend to be much higher software payers than those on other OS.
Not saying it isn't some sort of business extortion
I already owned a legit copy of Pico-8 and Voxatron...do I get it automatically?
I can surf the web, edit LibreOffice files, record audio in Audacity on my nice Rode microphone, watch video files in VLC, remotely VNC in, transfer files in and out over SSH's SFTP, etc.
Pretty much all that's really missing, to fill it out, is Zoom (or some such functional equivalent) with a fast-enough frame rate on video calls. And this is not, strictly speaking, the fault of Raspberry Pi, et al.
Running Emacs/Cider I'd have to kill other apps and reboot my REPL a couple times a day. Emacs would also leak memory and need a restart every couple of days
i wrote a simple firefox extension that unloads em all with a button click, but it’s no different than restarting ff or spamming clicks in :unloads
This of course is how electron should work as well. A canvas only frame that loads whatever rendering system you want, which could be a browser, or it could be Unreal engine.
How many levels of abstraction do we need to run software reliably? The fact that browsers have effectively become operating systems should be worrying enough.
No wonder we have all these fantasy projects that take us back to when our computing environments were actually pleasant to use. I would partly blame the invasive tracking and needless complexity of modern OSs for that, but the ever growing software layers around hardware makes no sense at all. We should question any such design decision, and strive to simplify this ball of complexity instead.
In my original comment above I wrongly assumed it _was_ on by default
The only problem is the accumulation of CPU use from web apps.
Consider adding more swap space so that older tabs have an out-of-the-way place to stay.
Plenty of people still use systems with 4GB and lower and it works fine as long as the number of tabs they open is limited.
I don't believe a browser couldn't be designed to have a small RAM footprint. All my tabs could be suspended and saved to disk when in the background (and not spinning any tasks). They can be read back into RAM near instantly when I tab back to them
My Chromebook with 8Gb ram has dozens of tabs and web apps open in Chrome, runs one VM with Android and another VM with Linux in turn running Firefox and more. All without breaking a sweat.
Works beautifully. I have to restart the computer about once a month because of Catalina bugs, but Firefox is super stable.
I shut down my laptop at the end of the day and turn it back on the day after, regardless of bugs. Why do you try to reboot it as little as possible?
I'm similar, I prefer maintaining state with things until I'm done with them, which makes the current models so frustrating, for all Apple talked about skeuomorphism, for me it's always felt so fake, it's only ever skin deep, I open a webpage and until I'm done with it, it should stay that way.
I've navigated down a third of the page? I've partially filled in a form field? Keep it! There's probably a reason I put that there!
It's not like when I put a piece of paper down on my desk it resets to it's original appearance and orientation every morning. It retains the scribbles and notes! Maybe you like someone else tidying your desk every morning, but I hate it!
Real things exist, our memories exploit these properties so well and what do we get, software that's all about returning to some pristine state that makes it harder for me to recall and use.
I'm curious if they're going to do this same thing with their spatial os, or whether they'll work out that persisting things until people are done with them is a feature.
Sometimes I also use stand-by or, if it is to keep the state up until the next day, hibernation. But that's rare. In most cases, I just use Firefox's function to restore my previous browsing session. That would not restore half-filled forms, but I rarely deal with forms, especially long ones. As for reading or editing documents, most software will open the document at the point you where when you last closed it.
Shutdown takes 20 seconds. Startup requires the FileVault password, then 20-30 seconds, then a login, then another 20-30 seconds until desktop is usable (and a few more until Firefox is).
If this was my work computer, it wouldn’t be so inconvenient to restart / shutdown once a day. But for what reason?
I’ll replace it when it breaks.
With respect to power draw - there is no simple way to force hibernation on Catalina AFAIK, but the power draw in sleep is minuscule - it hardly registers on my wattmeter (and e.g. it loses only 2-3% percent per day of battery while sleeping).
Not even close.
My 2003 bought multimedia Athlon XP desktop had 512 MB!
Except for the built-in HDMI video and the seamless plug-n-play networking that is...
Also, the limitations of 8 bit (and 16 bit) computers also made them more approachable. I "designed" some cool-looking sprites (actually they were called "players") on my Atari 800 back in the day, although I'm not good at drawing, so I would be hopeless at producing something more hi-res...
Original IBM PC in absence of other drive would attempt to boot from cassette and then drop you into similar BASIC interpreter - the "GW-BASIC" included in DOS was the same except it was shipped completely as file on disk drive instead of being ROM.
NT didn't have included programming language before NT 4.0 SP4, when WSH was added, it was also part of Outlook 97 and IE 3.0.\
The original computer to ship without any programming tools that was targeted at general population was Apple Lisa, I seem to recall mention of at least one loud consumer complaint if not lawsuit based around expectation that general purpose computer should have some tool included.
It was on the CD but it wasn't installed automatically.
More often I use some old application, like the nowadays BSD-licensed ex-Autodesk Animator. It is fun to figure it out and more fun than modern applications in many ways. I even bought an old used book about it and read cover to cover. Limited compared to modern graphics software, but "cozy" is a great way to describe the experience.
If you're looking for specific use-cases, that's exactly what userland software is for. Userland software takes the general computer and converts it to something specific. If you are looking for a cozy environment that supports creative, limited programming work, you run userland software for that!
It's like software-defined networking except software-defined creative environments. Some people prefer Photoshop, and others Picotron. The computer gives you the choice, and userland software is the mechanism by which it does so.
If anything, I'd like to turn your observation around: isn't it marvellous that the same machine allows one person to run Photoshop and another Picotron, with almost no change required to switch between the two environments?
That's a pretty hard line you have drawn there. There is no reason why it cannot be that. There are several open source window managers which tried to have a vibe. KDE had a cozy vibe. We have a Hanna Montana Linux, which was definitely awesome as a kid. I find it obnoxious that society has decided these infinitely flexible machines will have the personality of an iron smelter.
(Maybe Emacs is not cozy to you. But the fact that it is to a significant number of people explains why it still has fans in a world where Visual Studio Code is eating everything.)
Picotron is supposed to emulate a particular form of cozy: that of the very general-purpose computers of the 1980s and 1990s: classic Mac, Amiga, Atari ST, even Windows. What I'm lamenting is a sort of fall from grace wherein even Microsoft, of all companies, tried to shape the computing environment to bring support and comfort to the user rather than exploit them and introduce churn and friction for its own sake.
I think in computing there's the other issue that modern programming has a big focus on safety and security which was absent in the 8-bit era. If you sit down to make a Mac app you're not only going to compare your work to Apple's own, but you're also going to be constantly distracted by things that aren't "fun" like slow compilers, type systems, notarization and code signing etc. These are all important for people who use computers as end users but if you just want to hack about and make something they suck away the energy.
I wonder if generative ai might someday have a similar effect? Imagine a "make me a game" tool, with LLM-like "Fortnight, in space, with cute animals, and classical music". Ok... "the default music sync with action is fine, but as health declines, make the tone darker. And give my dog an oboe theme." Removing design-space cliffs, scattering defaults and highways, adding exoskeletons, as alternatives to shortened horizons. Kids today finger paint with pigments that would be the envy of painters past who ground their own - "use only charcoal" still has a role, but... there's also neon pens with sparkles for diaries, stamps in kid paint programs, and ... . Imagine a future coloring book, with speech to text to outline image, collaborative coloring, and "ok, now make that a 3D rigged avatar, skinned in the style of an oil painting". Making it easier to fly around the space, rather than lowering the ceiling.
Uhhh... have you seen Pico-8 development. People can excel on that thing. The limitations make the achievements even more remarkable. If you want to see the excellence in coding, combine the two and check out the people who wrote BBC BASIC raytracers in a tweet. If anything, we're in a glut of shitty code today partly because our comparatively powerful machines, combined with a race to the bottom in terms of churning product out quickly, make writing and shipping something extremely unoptimized far, far easier than taking time to polish the end product.
I think you're onto something, in that the Pico-8 and Picotron are going for the "vibe" of retro home computer/console programming but are not capturing the true essence of it. With 8-bit home computers, you started off in BASIC and could build simple games and stuff -- but if you wanted to write anything performant then you had to drop down to assembly and there was a significant difficulty spike there. So even back then we were dealing with "unfun" stuff. (In general, the enjoyment you got out of such work was proportional to the effort you put in.)
Even so, the span in which you can excel is far more limited. Nothing stops you making 8-bit graphics today (see Notch) but people and especially kids will compare what they can do to, say, Call of Duty and lose interest when they realize how far away they are. Micro games at least tended to be made by one person, so it was theoretically possible to get that level of skill yourself.
Our current devices are almost unlimited.
When I wanted my own laptop more "cozy", without the silliness of "you can only press two keys at a time, so no chords", and "most of it isn't a touch surface, and can't even tell which finger pressed were on the cap", and "it's oblivious to hand pose and gestures above the surface", and "the screen is only 2D and can't even tell where you're looking", I had to kludge the entire stack from hardware to apps. If you could sculpt, dance, and sing code, perhaps 8-bit might have less appeal? Like the appeal of entering programs with faceplate bit toggles instead of a keyboard?
Maybe. Counter argument: pico-8 mobile/tablet. Counter counter, historical state of pico-8 mobile/tablet??
No, it's a software (& hardware) design issue. Computers just aren't made to be tinker-friendly anymore.
Eg. back in the day, I had a trio of editor+assembler+debugger on MSX2 (often running from RAMdisk). For many programs, edit-assemble-test cycles were a few minutes at most. With nothing loaded, machine would boot into BASIC seconds after power-up.
So: develop on target device, even with that being Z80 based machine with ~256 KB RAM (which was already comfortable). Several vendors of these MSX machines would send you a full schematic / service manual for a nominal fee. Hardware mods were commonplace. Youngsters who'd never touched a computer could be tweaking BASIC programs within an hour. With patience you could wrap your head around the whole machine.
Nowadays: boot computer, wait, click on fancy icons. No default programming environment(s) in sight. 'Poke' some hardware port? Not happening. Modify any of the built-in software? Forget about it. Or at best: first download multiple GB's of development tools, spend the next week(s) buried in documentation. Not for the faint-hearted. Let alone newbies.
Yes, computers have become faster. But also more complex. Some of that complexity is justified. Or even necessary. Much of it is not, and is just heaps & heaps of technologies / abstraction layers & legacy cruft.
Nod. That silly only-on-my-own laptop project had a device-driver->full-screen-browser stack, so "Reimplementing wheels - sigh. But no libinput, linux gesture mess, window managers, xlib/wayland, ... - oh dancing-lightly-through-tulips yay!".
I enjoyed lisp machines, which handled complexity differently. DonHopkins comments on a LispM ergonomics thread:[1] "It was not just the hardware, or the software, or the culture, or the interesting problems you could solve, or the zeitgeist of that time in history, but a rich combination of all those things and more, that is so hard to capture, describe or reproduce -- or even believe, if you haven't experienced it first hand. [] Those giant keyboards, with all their wide special purpose buttons topped with hieroglyphic keycap labels, in combination with the huge screen, three button mouse, and of course all the great software turning on and off the little dots on the screen that you could dive into, explore and modify at will, the printed and online documentation, the networked developer support community, all carefully designed to work together seamlessly regardless of cost, gave you the feeling of being in control of a very heavy, expensive, well built, solid, powerful, luxury automobile, with rich [...]".
I guess I was wondering if hardware-wise, part of what allows pico-8 to retain appeal, is we've largely stalled out on a half-century-old keypress-and-mousemove ux plateau. If it used some other "similarly" old interface tech (front-panel bit switches, paper tape, terminals as forms), the appeal would seem less.
The appeals of pico-8 and lispm seem somewhat related. But for lispm's cutting-edge "luxury car" power-user-ness. Perhaps the -8'ness constraint, and resulting bounded goals, is what makes doing the stack tractable (witness smalltalk but-do-you-have-a-library-for-X struggles)? But they've also struggled with adoption, which the Scratch-like lower-barriers-from-lower-ceiling might help with?
The smalltalk folks, with a (also keyboard-mouse) vision of full-stack, but with high-ceiling kid appeal, have struggled with both. And, maybe, XR might offer windows where society's UX and approach to software is more malleable.
So what are the implications for designing a powerful full-stack system that attracts a broad user base? To take advantage of some possible "XR is now gelling - as with phones, we're about to do a giant societal software rewrite - the course of future societal computer-and-software UX is briefly malleable"? Ideally one that instead of mac/lispm tractability-through-singular-hardware, has complexity-handling-power sufficient to blend Z80-to-insaneXR hardware-software diversity into something accessibly/appealingly/cozy tractable?
[1] https://www.youtube.com/watch?v=S-7UszmI1K4 [2] https://aesthetic.computer/ Then press "Enter" and enter "list".
The wallpaper is named "triplane," but that's a biplane.
Disclaimer: I'm one of the contributors of the list of [2].
Previously this guy made Voxatron, which I imagine paid for PICO-8, and that presumably paid for Picotron, so if I don't buy Picotron, then perhaps I'll prevent his next work of art from coming to fruition?
Yes it bothers me a little bit that PICO-8 itself isn't open source, but I can't see the alternative, otherwise how can the dev afford to be spending time thinking about and working on these new things?
It's not as though this is a huge company, or that there are alternative means of generating income from it (no Enterprise wants PICO-8 support, for example).
I don't see an alternative to giving the dev a few bucks to keep making art projects that I love.