Comment by derefr | Hacker News Reader

Comment by derefr | Hacker News Reader

Parent Full thread

I'd love a PICO-16: a fantasy console almost-but-not-quite like a GBA, extended in some ways (e.g. resolution, sound channels) and reduced in others (e.g. palette, maximum ROM size.)

There are tons of these little "retro console" devices lately—the Bittboy, LDK-game, etc.—that people just treat as emulation devices, when they actually have hidden potential for running native game software as well, with more power than you can get out of them through an emulator. (They're actually usually as powerful as the original PSP, but only have the GPU capabilities of the GBA, making these consoles into a sort of unique alternate-history blend of 2001-2004 era gaming.)

But no games are being written directly for these devices, because they're all slightly-differently specced: different screen-sizes; different amounts of RAM; etc.

A hypothetical PICO-16 "platform", in my mind, would basically be an abstraction over the cross-section of native capabilities of these devices (with maybe some additional tasteful constraints on top), while still allowing to take advantage of the full hardware in a way you can't by just e.g. writing SNES or GBA homebrew.

Maybe the "platform" could even come in a few separate "profiles", where games could be either targeted to a specific minimum profile, or could respec themselves to the highest profile supported (sort of like how Z-Machine games work in detecting the VM's multimedia capabilities.) Take it far enough and PICO-8 could just be the base PICO-16 profile!

I'm working on something like this, but as time has gone on I've made technical constraint less of a priority and focused more and more on the I/O and "bus" model itself, because that's where the ultimate bottlenecks lie. If you have all the processing power in the world but only a 256x256 space to draw in and a limited number of commands to draw with, you still have an interesting constraint.

One of the things I found myself doing with PICO-8's setup was prematurely optimizing code for size, which presented a new kind of puzzle(how to express things in fewer Lua tokens) but didn't feel good in terms of authoring finished work(I made a nice 3D maze wireframe renderer - and then stopped there). So with my own fantasy console I'm prioritizing other things beyond size/retro aesthetic, while still thinking about limitations. "Diversity" has become one of those things: you will have some ability to swap out graphics and sound cores, and use a variety of programming languages. The fixed spec approach makes it harder to make each part really distinctive and not just another "tiles and sprites and chiptunes" doddle.

Since I made the foolish decision to support 3D cores it's taken a while to get a renderer going, though, and I finally decided to speed things up by releasing with 2D first and adding more later.

Neat. Obviously swappable cores in cartridges were a big part of the longevity of the NES and SNES consoles, and it will be interesting to see what sorts of trade-offs you decide to make for the various cores (and their interactions).

Very cool! Have a page or repo up to follow your work?

I have a little landing page on itch.io which can be followed if you have an account (but the content is getting embarassingly out of date): https://triplefox.itch.io/galapagos

Current release plan is to get some builds out late August/early September, both free and paid(paid simply gets the updates faster). Then later on, I can think about plans to open up development. PICO-8 took about two years from conception to release and I'm getting to around the end of year one of mine, and just about everything has had multiple iterations, but the first release will be a basic "run at the command line, code in your text editor, store assets in the file system" kind of environment. Releasing means I think the basic design is mostly settled, so after that all the UI and IDE functions will become possible.

Panic, the mac app development group, is making a custom handheld console for original retro-ish games: https://play.date/

AFAICT the Playdate is actually an instantiation of a less powerful abstract machine than even the PICO-8; closer to an Arduboy.

In my experience Pico-8 maxes out at something kinda-sorta approximating 4MHz, although in the words of the author, "PICO-8 CPU costs are made up and essentially silly when looked at too closely."[1]

The CPU in the Playdate prototype runs at 216MHz.[2] The numbers aren't directly comparable, but I'd wager that the Playdate will have _significantly_ more headroom.

1. https://www.lexaloffle.com/bbs/?tid=33883

2. https://twitter.com/zhuowei/status/1132447884719210497

I would love to see a PICO-OS. Something in the same spirit, but for making little simple apps instead of games, in the style of a 90’s OS.

That's also something I have thought about. I always figured I was mostly alone and there wouldn't be any demand for such a thing.

The way I imagined it working was a simple instruction set emulator that mmap()ed ROM images and had a fixed RAM size (in the order of 64k). Have an adjustable resolution, but simple fantasy console style display. Also the option to allow the apps to call host commands.

It would be ideal for things like volume controls, and pop up calculators etc. Maybe a really lightweight Winamp style mpd front-end.

Initially this struck me as an idea when I was hunting for what was eating memory on a 256Meg machine. I found the Volume control (one slider, and a menu dock item) required 4meg to operate.

It is something I have considered. The Fantasy console I'm making is currently uses an 8-bit AVR instruction set, but I have wondered about making the same virtual hardware interface accessible from WASM.

The open-source TIC-80 is a less-constrained fantasy console if you're not aware:

https://tic.computer/

It's not really "less constrained" in any way that matters, though. Sure, you can write more than 8K of Lua and the display resolution is a bit wider, but you don't get a dedicated DSP+sequencer for audio, multiple graphics layers with affine transforms/color math, SRAM(!), a real-time clock, etc. I can't even build a Tamagotchi with this ;)

In other words, for my needs, TIC-80 is still entirely dominated by just using https://github.com/rust-console/gba to write GBA homebrew in Rust. (And everything has a GBA emulator. Everything!)

A viable PICO-16 platform, to me, would have to offer a clear improvement over the "GBA homebrew in Rust" solution.

(Even if all it is, come to think of it, is the GBA's ARM7TDMI ISA extended with some more hardware registers and instructions, and a PICO-8-like IDE for building those "GBA+" ROMs. Such an approach would come with the benefit that you could build a PICO-16 runtime by just starting with a GBA emulator and adding features. You could even choose encodings for the new ops such that they would look like NOPs to old GBA emulators, making PICO-16 "GBA+" ROMs gracefully degrade into regular GBA ROMs when run on a regular GBA emulator—very much like how Gameboy Color games work, or how SNES ROMhacks and homebrew support the MSU-1 audio chip.)

Reply on news.ycombinator.com