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.
Keyboard image blowup: https://static.wixstatic.com/media/3833f7_df1d45d717da4487ba...
Its meant to look like something you would have wanted 35 years ago, a nostalgia bait.
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.
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...
Don't underestimate the "collecting cool things in a drawer" crowd.
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.
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.
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.
You have this problem as well? mmm technolust.
smd dome switches with rubber cover, as mechanical as ZX Spectrum keyboard
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 novelty is why they exist.
Not trying to yuck in anyone's yum, just point out that yes this is great and so is the deck...
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
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)
RPI-CM4 Lite: Broadcom BCM2711
A-06: Rockchip RK3399
A-04: Allwinner H6
R-01: Allwinner D1
Some of them require an adapter that you have to purchase separately.
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.
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.
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.
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).
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
Are there similar terminal devices that already include one or two DB9 serial connectors?
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.
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"
And I've used good tiny keyboards, but that is not really it.
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...
With the Pi CM4 module installed, there are loads of options that will work just using the USB port.
More here: https://github.com/paladin-t/fantasy
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.
Has anyone seen this anywhere else?
