ClockworkPi – uConsole, “fantasy console” for indie game developers
clockworkpi.com
clockworkpi.com
resisting the urge...
So, I'm leery about this and other things like it. I want a portable, pocketable computer on which I can hack and code away at fun things like graphics and games when I'm bored or waiting in line or whatever, but I'm becoming increasingly convinced that "small size" and "usable keyboard/UI" are mutually exclusive.
Might just give this a try, though!
The keyboard was good enough, nice tactile feedback and relatively good software handling of multiple and rapid key presses, contrary to the TI calcs that had horrible keyboard handler (only one key press at a time)
I miss the way I was able to simply relax and write code without having to sit in a chair.
I believe that thumb typing keyboards can be good and high quality.
I wish that a company like Teenage Engineering would follow the exact same recipe as Clockwork Pi with with a higher quality finish and keyboard.
Not at all, before the smartphone there were several phones with very usable keyboards, I think it's just that a quality keyboard can't be made for cheap and/or in a small production run.
I really wish there was something like one of those old phones with either arm or risc v and 4G. I don't need it to be capable of doing phone calls, I just want a small cellular connected pocket computer with a great keyboard.
Its meant to look like something you would have wanted 35 years ago, a nostalgia bait.
Keyboard image blowup: https://static.wixstatic.com/media/3833f7_df1d45d717da4487ba...
(It's possible through a different hardware design to support a secondary, slower sd card interface for an emmc cm4 via the SDHOST peripheral connected to some GPIO pins, but the pi cant boot from it)
RPI-CM4 Lite: Raspberry Pi CM4 104000 lite (ARM Cortex-A72 quad-core, 4GB LPDDR4, WIFI 2.4 GHz, 5.0 GHz IEEE 802.11 b/g/n/ac wireless + Bluetooth 5.0, BLE)
A-06: A-06 Core module (ARM64-bit Dual-core Cortex-A72 + Quad-core Cortex-A53, Mali-T864, 4GB LPDDR4)
A-04: A-04 Core module (ARM64-bit Quad-core Cortex-A53, Mali-T720, 2GB DDR3)
R-01: R-01 Core module (RISC-V 64bit Single-core RV64IMAFDCVU @ 1.0GHz, No GPU, 1GB DDR3)
Some of them require an adapter that you have to purchase separately.
RPI-CM4 Lite: Broadcom BCM2711
A-06: Rockchip RK3399
A-04: Allwinner H6
R-01: Allwinner D1
Still don't know what the best board is for my use case. I would like to have a dumbed down environment which is optimized for this handheld format and lets me start some editors and fantasy consoles from a menu.
Yes to that adding some instant on/off/hybernate . Would be great to capture ideas when they come and not wait for the thing to boot and make other decisions. Something like a dedicated device but configurable for other tasks.
On the "little machine for custom jobs" front, can anyone suggest a low cost subnotebook, x86-64 or ARM (i.e. Chromebooks OK) where I can wipe the Google software and install some version of Ubuntu? I've been using EeePC Seashell machines for that for years, but they're wearing out and I need something close to current production.
I'm looking for a machine where there's not too much difficulty doing this. That varies with the machine. Some require removing a jumper to let you overwrite the OS. Some require overwriting flash memory with somewhat sketchy binaries.
The older GPD Micro PC can be found for a bit cheaper than their newer ones. But they're likely more expensive than you are looking for I think! Though on the other hand, they're very easy to run whatever OS you want on them
I suggest picking a machine from https://mrchromebox.tech/#devices , filtered to the ones that support the full "UEFI Firmware". Conveniently, this also lists the needed method to make the firmware r/w if you care about that. Of course, this depends on you considering MrChromebox non-sketchy, but he is AFAIK reputable and if you prefer all the source is on GitHub.
Oh, and annoyingly I suggest that you avoid ARM Chromebooks; firmware support and OS options aren't there (yet, I dearly hope).
But for the actual me, I can't see the point really.
How is that optimal compared to "I can see the point and I like it"
I.e. separate money from man before cognitive functions have a chance.
There are various "fantasy consoles" people make video games on, like the piko-8^1 (which the indie darling Celeste was originally developed for) and the TIC-80^2 (Providing a more PC-like experience). It might be best to think of them as emulators for computers/devices that never existed. Some platonic ideal of game consoles past. They're often programed in LUA and provide limited RAM/Display-resolution/palette-depth, etc, in order to provide a retro feel while not requiring you to program in actual assembly.
Personally I'd be more interested in this as a field-device/development-environment/tricorder type unit. It seems like a great unit to hook a chip programmer up to, or one of those open-source FPGA-based oscilloscopes, or other lab instrumentation.
There are a bunch of Chinese handhelds that people use for emulation, some of which can run PICO 8 games.
My Anbernic RG351V does it but I don’t think it came with the stock OS, requires some tinkering.
Anyways, there is already a small market for handheld “fantasy console” players that might respond positively to the open nature of the clockwork pi devices.
This thing supports a Raspberry Pi compute module so I assume it will run the Pi version of PICO-8.
1. it's compute-resource-constrained — so you can't just transpile DOOM into the "fantasy console's" native programming language / bytecode ISA and expect it to run well, but instead have to learn to program directly for the console's native programming language or ISA — close to the (abstract) metal — to do anything of note with it;
2. it exposes low-level "primitive" features in its native programming language / bytecode ISA, in the form of system calls or MMIO registers, to accelerate graphics/sound operations without consuming (abstract) CPU cycles; thus allowing games developed for the console to run well at 30/60FPS, despite the resource constraints. Where usually these calls are themselves constrained to only allow for "retro"-style output (e.g. allowing audio only in the form of a set number of square-wave frequency channels.)
In other words, a "fantasy [retro game] console" attempts to achieve a similar set of "artistic constraints" for game development that you get from developing for a real retro game console, like the NES or Gameboy. Except that the artistic constraints imposed by fantasy consoles are usually not low-level technical constraints in the system's (theoretical) microarchitecture, but rather arbitrary policy-based constraints imposed by the abstract-machine standard on conforming implementations, and therefore are often less frustrating things to be worked around (think: memory bank switching), and instead are more inspiring constraints to be embraced to fuel the creative process when making a game (think: limited color palette per art asset.)
Or you can think of it like this: what if the Super Nintendo never existed, but there still ended up being "SNES emulators" that all agreed on how they should interpret/run "SNES ROMs" — all implementations of a shared abstract-machine standard? Developers would then be producing "SNES games" not to run on a physical SNES, but instead solely so that you could then run them on a compatible emulator. Although, in theory, nothing would stop someone from making a real hardware SNES conforming to the abstract-machine standard — and then SNES ROMs would work on it as well. That's a "fantasy console."
For a given fantasy console, there may or may not be any physical-hardware implementations; though usually there aren't. A well-known example of a "fantasy console" with only virtual implementations (i.e. emulators) is the PICO-8 (https://www.lexaloffle.com/pico-8.php). While there are hardware devices that present themselves "as" a PICO-8 "console", they do this by using some other ISA to run a full OS kernel, which then launches into a userland PICO-8 emulator. There is no hardware device whose CPU+BIOS enables it to natively execute PICO-8 code. (It's the difference between a NES Classic, and an actual NES.)
Meanwhile, this thing — the uConsole — isn't a "fantasy console" itself, per se (i.e. they're using the term wrong), but rather a device focused on running multiple fantasy-console emulators, which therefore doesn't even attempt to present itself as being any particular "fantasy console's" hardware. It's basically just one of the many "retro handheld" devices out of Shenzhen recently (which often ship with fantasy-console emulators) — except this one's got a keyboard! :P
A fun example of a more true hardware "fantasy console", where the hardware is itself an implementation of a particular fantasy-console abstract machine (and where the abstract-machine standard and the hardware implementation were co-developed to make this possible), is the https://www.commanderx16.com/ — which is both a fantasy-console in its full capabilities, but is also a backward-compatible superset of the abstract-machine model of a Commodore 64, and so compatible with Commodore 64 software/games (so this abstract-machine can also be thought of as an "enhanced" Commodore 64 — like how the Gameboy Color was an "enhanced" Gameboy — making "enhanced ports" of Commodore 64 games an especially easy/interesting project.)
Although it runs Commodore BASIC (itself based on Microsoft BASIC as many machines were) it was never intended to be an "emulator" or compatible with the C64 or any other machine. It is its own machine, just as the ZX Spectrum, Atari 800, etc. were also distinct from the C64. [...] Ultimately C64 compatibility is not the aim of this product.
[1]: https://www.commanderx16.com/forum/index.php?/about-faq/
I guess the PICO-8 has some kind of CPU limit, but it's orders of magnitude over the 8-bit 6502 consoles it's broadly mimicking. That was sort of disappointing to me.
Like I said: fantasy-console abstract machines don't aim for technical limitations; but rather, for stylistic limitations. They don't want to impose upon you low-level technical barriers, for you to just treat those limitations as implementation-time programming puzzles to be overcome or worked around. (If you want that, just write games for an actual retro console!) Rather, they want to impose high-level constraints that influence your design-time choices. Less like typing on a broken keyboard; more like writing a poem with constrained rhyme-scheme and meter.
That's why these are "fantasy" consoles — their particular lack of technical constraints means that they can actually require a decent modern CPU/GPU/etc to run; and so could never have actually existed in the era they borrow their aesthetics from.
I've been working on an (IMO) sophisticated tactical game with strong AI in Pico-8 for just about two years now, and I can say that this is not true.
> which would require some kind of CPU-cycle accounting tracking
This is pretty much what it does.
Pico-8 tracks an arbitrary "cycle" budget, which is used to calculate how much computation you're allowed to perform per frame. You're absolutely not going to compute at "bare metal" speed.
Here's some info in the (community) docs:
https://pico-8.fandom.com/wiki/CPU
I don't know how this does/does not compare to the 6502, because I unfortunately don't have any experience there. But you're absolutely not going to get bare-metal performance inside of Pico-8.
You're right about limiting code-size, though. For my own project, the code size limits have proven far more difficult to work around than the performance limits.
Tangent now, but these are some of the Pico-8 limitations:
- screen is 128x128 pixels
- only 16 colors are available (sort of... there's a "hidden palette" too)
- cartridge size may not exceed 32 kb
- cartridge may not exceed 65k characters
- Lua AST may not exceed 8192 tokens
That last one has been the hardest constraint for me to manage, by far.
Anyway, Pico-8 is a ton of fun. Try it out if you're inclined :)
I like little consoles like this but I never get one because I'm almost certain it would be novel and almost nobody I know would end up having one, unfortunately.
Update: and, importantly for the Steam Deck, you have a wide player base out of the box. Maybe not as much for the Deck itself (yet) but definitely on all three PC platforms.
The nice thing about the Steam Deck though is that you can carry around your development environment on the same machine. You still have to cross-compile to reach the 3DS and such.
I'm tinkering with 3D-printed slide-out landscape keyboards, but there are a lot of commercially available bluetoth keyboard cases.
1. The 2014 Nexus 7 packs a FHD screen compare to the 720 in TFA. Its display is shockingly crisp for an 8-year-old device
1. Enable ADB on device
2. Unlock the bootloader
3. Use fastboot to install TWRP
4. Boot into recovery and use TWRP to complete installation from zip files (Android ROM, Google apps)
The novelty is why they exist.
It would be neat if it was easier to broadcast the experience of playing the game to more folks like how playing back a song recorded from a groovebox doesn't require much more than a device with speakers than can play an audio file.
Not trying to yuck in anyone's yum, just point out that yes this is great and so is the deck...
It is indeed quite limited, but I like terminal environments and (again) grew up with very constrained menu-driven software, so this is less of an toy than a very customizable tool; I'm not really interested in the game console emulation. One that can fit in a cargo pocket and is surprisingly affordable. The lack of a touchscreen or camera are pluses for me.
Are there similar terminal devices that already include one or two DB9 serial connectors?
But when you go beyond that, what is the point of this? Why is an indie game developer going to build things for this particular niche platform? In the end, I would buy this and it would just end up as another random device in a drawer. Nice aesthetic, but useless.
You have this problem as well? mmm technolust.
Very similar interfaces as the tic-80, and no doubt pico-8 compatible. There's already a software/games library, plus it runs normal linux.
This is a linux computer where the terminal is the primary intended interface. Anything you can run on ARM and linux (like everything in retropie) should be supported out of the box. Terminal-based games don't need fancy GPU drivers and optimizations like the Steam Deck. There should be no porting needed except maybe some keymapping for the non-keyboard buttons, but that's normal.
Good point. As Yegge said, "[It's] all just plumbing for Emacs, anyway."[1]
[1] http://steve-yegge.blogspot.com/2008/04/settling-osx-focus-f...
FSV of useless, maybe. In theory, there's a market for retro game designers who would appreciate this device for their hobby.
Kind of tempted to buy it myself to replace late night or in-bed usage of mindless scrolling of Twitter and Reddit. [Edit: I guess this part is right in their headline: "bedroom programmers".]
Those are consoles that are fully hacked, with high quality open source toolchains and SDKs, and emulators.
If you have a retro handheld game development itch, those will scratch it better than anything else, especially since there’s a real chance people will actually play your game.
Developing for those old consoles also means you potentially delay them going to a landfill.
Not to say the gadget in OP isn’t worth buying, but the “indie dev” value proposition isn’t that strong IMO.
Don't underestimate the "collecting cool things in a drawer" crowd.
smd dome switches with rubber cover, as mechanical as ZX Spectrum keyboard
I don't like the idea that every tech purchase must somehow prove its worth or be measured as "worthy" somehow - if you enjoy devices like these and like collecting them - have at it!
Some of the things I enjoy most are frankly "pointless" in the eyes of most; don't let this stop you. You aren't buying a life-changing large purchase like a house or a car here. Sometimes these things work out, sometimes they don't.
The point of devices such as this is often that they indeed have no specific point... they are for fun as much as anything else you can think up.
Too good to be true. What's the catch?
I have one of their GameShell devices. The things on the sides that look like knob controls are actually clasps to hold the thing together. Took me a week just to figure out how to SSH into the thing. Screen resolution and picture quality is really bad. All of the buttons feel awful, with a lot of latency on presses. WiFi just craps out whenever you breath a little hard on it. Performance is about like trying to run modern Linux on a 15 year old PC. Lots of fantasy consoles preloaded, but the screen, performance, and buttons all add up to making it a terrible experience, and there are only one or two good games for each, anyway. Lots of very poorly implemented PyGame games that have such neat features as "no way to kill the process from within the app to return to the main menu" and none of them are actually even close to good ideas, say nothing about complete or decent games.
It's an interesting little computer that I would love to try once, but very likely wouldn't spend money on it.
even hilariously bad Commodore plus/4 had better usability https://en.wikipedia.org/wiki/Commodore_Plus/4#/media/File:C...
I see a big chip straight between mipi screen socket and compute module doing hdmi-mipi conversion, telling me rpi foundation is still stubbornly fighting ability to use mipi dsi port on the pi.
weird question.
it's a chat interface. there are people to chat with on IRC.
Is that a valuable thing to you? Who knows.
If the question is "Are there still people that use IRC?", then "Yes.".
I know it's probably a 'mover-and-shaker' HN thing, but not everything needs to be rephrased to compare against value/time.
That's a reasonable interpretation of the question. Even so, a lot of IRC communities have moved to Discord and such to lower the barrier to entry in participation.
The underlying question is more likely "Are the people I would chat with still using IRC?" which can only be answered if you know who the people you want to chat with are.
With the Pi CM4 module installed, there are loads of options that will work just using the USB port.
And I've used good tiny keyboards, but that is not really it.
More here: https://github.com/paladin-t/fantasy
Has anyone seen this anywhere else?