Not going to lie, this seems to scratch an itch I haven't thought about since the days of the Pocket C.H.I.P. If the keyboard is even remotely useable, I am interested.
This scratches an itch I don't have but I always believe I do. I have a pocket chip colecting dust in a box yet I think I realy just need to go do an impulse buy of uconsole wich I won't have a good use for but it's so cute.
I loved everything about the Pocket C.H.I.P - but that keyboard made the entire concept unusable. I am hoping (perhaps foolishly), this keyboard will be marginally better... but we will see :)
This keyboard looks very similar to the one used on the DevTerm. If so then I can tell you that it will be similarly unusable, though an improvement over the Pocket CHIP's little button keys.
The Pocket CHIP created this itch for me, but the keyboard on that thing made me realize how everything can be so good and just completely fall apart around one detail.
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.
It's not quite pocketable, and it doesn't have a keyboard at all, but the Steam Deck has totally been that device for me. I've been really impressed with how good the controller mapping can be; set your joysticks to be Rotary macros, and combined with the huge number of buttons you have yourself a fantastic little chording keyboard. The built-in controller mapper supports keyboard layers and conditional output (eg, when in this section of GUI, output from button chord L3-R3 should be XYZ). Anybody using vim or tmux familiar with this modality should be comfortable. Also, the Rotary menu, should you choose to use it, can be labeled (including with emoji, if that's your jam), making the whole thing incredibly flexible.
GDP makes some good fits for this. I'm partial to the MicroPC, but I mainly use that when troubleshooting network issues. They have a whole lineup, each geared towards a different market segment.
I used to write a lot of code on my beloved HP48 while I was a student.
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.
No. Someone else in this thread who has opined that the build quality was mediocre, but I forget who. i personally don't mind rubber keys for operational use though I would not want to write anything longer than an email or a HN comment with one.
""small size" and "usable keyboard/UI" are mutually exclusive"
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.
strange; it was one of the best 'membrane' style keyboards I had ever used. I dig mine out once in awhile to fiddle with mostly because of the k/b. Maybe I used it to the point of wearing it in?
You have to scroll down a bit to the image that describes the keyboard in great detail. It includes a mouse trackball. The keys use some kind of clicky switches. The buttons themselves are possibly hard plastic (a good thing). Colour me impressed.
This definetely scratch an itch, but i already have a macbook pro from 2006 with Linux 32 bit and still nice battery. Ok that one is too big. But my 2011 macbook air with latest ubuntu run as a charm and is behind my sofa when i need :)
Immediately went to buy, and I'm really not clear on what I should be buying. There are three different varieties and it's hard to tell what the differences are.
The actual SoCs used on each type of core module are somewhat well hidden (no mention on the main website as far as I can see) but can be found through a bit of research:
Carrier board has some sort of ESP32-esque WiSoC, plus LTE daughter board is listed alongside the products. I can't find which exact SoC is being used though...
Same. Took me a while that there is a Raspberry Pi 4 Compute Module version and multiple versions with other ARM boards with different specs.
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.
> 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.
Unless you know exactly why you have a strong preference for any of the others, and availability concerns notwithstanding, I'd suggest the Pi CM4 model based on the larger ecosystem surrounding the board.
Good advice, but worth noting the CM4 isn't included and there are a surprising number of CM4 variants now. They only advise one specific model number (104000 - the 4gb ram no onboard storage CM4), clarification on this would be good too.
The advice for the no-storage CM4 is because the modules are designed to work with either onboard eMMC or external SD, but the interface is shared so you have to pick one or the other. If you use an eMMC CM4 the sd card slot would not function, but it should otherwise work. The 8GB ram CM4 would also be fine of course.
(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)
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.
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).
It's not as small as your EeePC, but I very much enjoy my PineBook Pro [1]. I'm running Manjaro Plasma KDE on mine, and I can do just about all I want, dev wise on it: docker, ddev, vscode, firefox, chromium, LibreOffice, etc. It's about as powerful as a mid-tier Chromebook.
I have a Thinkpad X120e Chromebook that still kicks with Gallium OS on it. I think you can pick those up for about $50 USD now. There's a Chromebook version and a "regular" version.
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 vaguely feel like there's an alternative version of me that, like, 10 years ago resisted the urge to get a smartphone and now owns something like this.
But for the actual me, I can't see the point really.
Maybe I’m naive but what exactly is this? I couldn’t figure anything out from the website other than it’s a handheld device that shows a text console. What is a “fantasy console”? Why would a indie game developer want one of these devices?
It's a small linux handheld with a slightly anemic ARM cpu, a full keyboard, and metal case.
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.
Not really sure why they're branding it as a console when it's basically a portable Pi, and therefore far more versatile than "game console" implies. I suspect that will cause some confusion among potential customers who initially just see it as a game engine runtime.
One of the immutable laws of Raspberry Pi usage is that, for every application, a Pi will be either massively overpowered (this) or completely unnecessary (using them for "learning programming" when you have a perfectly good computer right there).
Truth, though I had to fight off the temptation to get one of those Elecrow Pi Laptops with a breadboard-type electronic kit inside. I don't think the RPi is overpowered for this - maybe for the stated purpose of emulating 8 bit games, but I like the idea of a general purpose computer that is not trying to be a tablet or TV.
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.
It's a shame there's no official PICO-8 runtime for any of those little devices, last time I checked compatibility was a bit spotty from the open-sourced reimplementations. Things have probably gotten better on that front since I last looked though.
This thing supports a Raspberry Pi compute module so I assume it will run the Pi version of PICO-8.
A "fantasy [retro game] console" is an abstract machine (like the JVM is an abstract machine, or like the Flash runtime is an abstract machine, or like BASIC is an abstract machine) with two key properties:
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.)
I don't think you are correct about the X16, it is not that compatible with the C64. From their FAQ [1]:
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.
Just a minor point -- the Commander X16 isn't actually compatible with the Commodore 64 -- it's kind of like a fantasy version of what the Commodore 64 could have evolved into if they had stayed with that rather than shifting to the Amiga. It's "Kernal" compatible with the Commodore 64, Vic 20, and PET, meaning that developing for the platform should feel comfortable to programmers of those machines but it can't just run software for those machines unported.
That's fascinating. Thanks for giving such an in-depth explanation. Doesn't appeal to me at all, but I can totally see why people find these constraints interesting.
Especially considering that some of the all-time greatest games were developed on similarly constrained hardware.
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.
I believe that, rather than a CPU usage limit (which would require some kind of CPU-cycle accounting tracking, which would impose a high overhead on a system that's based on high-level source-code interpretation rather than on a bytecode virtual machine), the PICO-8 chose instead to go the route of limiting code complexity by just limiting (Lua source) code size. So your code can go as fast as you like — you just can't have very much of it. Which seems to result in practice in games that have similar features and play-styles to retro-games, despite the constraint coming from a different direction.
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.
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 :)
The Steam Deck is a fantastic console for indie game developers, IMO. World class hardware, you can program your game on it, test on it, and ship on it.
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.
It's the console equivalent of a musical groovebox. Selling the idea that you just need to buy this device and you can make music/games too! It'll be a lot harder but it'll be more "fun" because you're limited creatively.
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.
The "fantasy" part of this things is the price... For that price I can get a full computer/ chromebook that supports Linux, I wouldn't put more than 100 bucks on something like this when ALL it can do I can do it with Termux on an Android phone...
Absolutely true, but typing on a screen is a royal pain in many contexts. I like this design because it looks like a moderately rugged industrial computer that's not a clamshell and has a useful keyboard (I grew up with things like ZX Spectrums so this isn't the negative for me that it is for many others).
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.
As an alternative for people interested in developing on handhelds like this, homebrew for old consoles (PSP, 3DS, etc) is always fun. There are also hundreds of millions of those still floating around, so there’s a real chance people will actually play your game, and you potentially contribute to delaying their trip to the landfill.
Truth! I do homebrew on my N2DSXL and the developer tooling there is fantastic [0]. Same with NES and even older handhelds like the DMG-001.
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.
Device wiki pages on Lineage are enough. The process isn't complicated, and boils down to a handful of steps after downloading the requisite files. Off the top off my head:
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)
Honestly, if someone could make an x86 compute module in the form factor, there's no reason the uConsole couldn't run Steam and Proton. The tech isn't quite there yet though, so it makes more sense to target low-power emulators for this form factor.
I've been looking for something like this for use as a serial terminal in the datacenter, with a bit of additional features (e.g. quickly starting up a DHCP server on the LAN port or similar)
Are there similar terminal devices that already include one or two DB9 serial connectors?
ClockworkPi also do kits for a device called DevTerm. I have one, I like it a lot. Keyboard is... not great. But you can make your own expansion boards.
I really wanted to get a DevTerm but so far the built quality and keyboard have kept me from pulling the trigger. What do you like about it? What are you using it for?
yeah, but it's rather overkill for that purpose (read: expensive), and that swiveling display doesn't inspire confidence. I'd rather find something more ruggedized
This is the kind of device designed to look so attractive for certain people that it would be an impulse buy: metal case, exposed screws, lots of ports for peripherals, full (mechanical?) keyboard and lots of buttons, a nice built in screen, raspberry PI inside… it’s like you’re describing an attractive woman.
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.
> Why is an indie game developer going to build things for this particular niche platform?
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.
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".]
There are hundreds of millions of PSPs, Vitas, DSes, 3DSes, Gameboys, etc floating around in the hands (or closets) of actual users out there.
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.
> But when you go beyond that, what is the point of this?
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.
With a bit of a broken heart I have to concur. Tiny screen, tiny keyboard, usability not included. I still kid myself after all those years that I will actually use my old EeePC for a "cool retro something" - even had DOS installed and made wired Ethernet work! - but nope, it's just painful. And that thing actually has a keyboard not designed to be operated with a stylus!
The catch is that every single part of the system is some kind of janky hack job.
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.
Iffy software support. If you look at the Clockwork Pi forums there's a lot of complaints about a lack of updates. There's some community support for alternate/upgraded software, but the user base is small enough that we're talking "download a ZIP file from a rando who says it works for him". It's DIY but also "figure it out yourself".
I bought both a DevTerm a04 and DevTerm r01. The catch is software support (if this is going to be similar to other clockwork pi products using the same modules), which is entirely left up to the community. With that said, the community mostly supports the a06 and RPi CMs. Their hardware is actually quite good, as is customer support for that hardware. Just be advised that anything other than Rpi and a06 are going to be very rough on the software side of the house.
I really want to like this kind of devices, but... seriously, this keyboard seems very uncomfortable to type with, and the "pad buttons" to play games look even worse!
It's an interesting little computer that I would love to try once, but very likely wouldn't spend money on it.
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.
It looks very cool and would love to find a use for it to justify buying it. Id love to use it as a dedicated device but does it instant boot? Does it at least hybernate properly?
On my similar Devqterm, ambian takes around 30s to boot. There might be hibernation, but I don't use it. I actually like the quasi-instant system shutdown you get with the physical power off button (though I'm sure it's reprogrammable)
Is there an ETA on when this would actually ship? I'm very tempted to order one, but I've already been waiting a good long while for a different handheld device with a physical keyboard (Astro Slide 5G) so I ain't exactly keen on doubling that number unless there's some timeline for these getting out the door.
> there are people to chat with on IRC.
> If the question is "Are there still people that use IRC?", then "Yes.".
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.
ON e photo shows what looks like a radio spectrum, which I'm guessing came from the optional 4G LTE modem. It would be great if that modem could be used as a generic SDR, putting programmable sniffing capabilities in a small portable device.
If it helps you temper your hype: it looks like the keyboard is made the same way as the devterm, but smaller, and the devterm keyboard is already a mushy mess of tiny keys.
And I've used good tiny keyboards, but that is not really it.
I wish it had something similar to a Blackberry Bold keyboard. That keyboard kept me on Blackberry for a long time. I used it for SSH as well and it was pretty comfortable.
This.. or something like this, looks like a fun little interface to hang on the wall. Though the keyboard might be a bit extreme for that, given the difficulty to type on the wall heh
You're not touch-typing on this keyboard anyway. As a size reference, that grey bulge on the back case houses two 18650 batteries. This keyboard is for thumbs.
No. It has a mini-pci-e shaped port and some nvme fit that size, but i believe it is for expansion boards (like the cellular module?) you could add NVME via USB port, but this thing is more like a raspberry pi, and not going to have the IO to use NVME much faster than SD card speeds.
