I really like how #pico8 is so easy to develop with, has fun limitations, and nicely exports cross platform. But I also like how #uxn sounds, because it runs on many old devices and is an actual VM with a very flexible rom format.
What if there is something in between the two... Calling it "con". And here are some of the specs:
- 2 bit pixels (4 colors: #000000, #444444, #888888, #cccccc)
- 128x128 screen
- 64kb cartridge. Format requires the first 256 bytes to define a 32x32 label image. Followed by the fantasy console version, followed by uxn-like assembly.
- Just a single NES/Pico8 controller as input.
- Able to connect to other "cons" through some pin
... show moreI really like how #pico8 is so easy to develop with, has fun limitations, and nicely exports cross platform. But I also like how #uxn sounds, because it runs on many old devices and is an actual VM with a very flexible rom format.
What if there is something in between the two... Calling it "con". And here are some of the specs:
- 2 bit pixels (4 colors: #000000, #444444, #888888, #cccccc)
- 128x128 screen
- 64kb cartridge. Format requires the first 256 bytes to define a 32x32 label image. Followed by the fantasy console version, followed by uxn-like assembly.
- Just a single NES/Pico8 controller as input.
- Able to connect to other "cons" through some pins in memory.
And the rest of the specs I'm not sure about.
I like the idea of using assembly as the language, but I'm also afraid that it will be too annoying to program for. #uxn and #varvara don't have very many good games from what I've seen, the assembly language could be contributing to that.
Just like PICO-8 can store it's data in a single png image. This console could too. Here is an image that demonstrates the format. This image has only slightly more pixels than a ".p8.png" cartridge, but stores twice as much data (64KB).
I'd love to hear random thoughts or constructive feedback about the idea. For now it's just a thought experiment, not sure if it will actually go anywhere.
