What should a “modern microcomputer” be like? I’m thinking about writing up a set of requirements, but I imagine someone already has. Even if it’s not exactly what I want, I need inspiration.
I am being deliberately vague about what I mean by "modern microcomputer". I certainly mean "small", but not necessarily physically small so much as "small computing". Also "personal".
I think the software is as important as the hardware, which is why I don't think something like the RPi 400 really qualifies. It could qualify with the right software, I suppose.
@email@example.com Assuming you mean "microcomputer" the way a C64 or a BBC Micro is a microcomputer...
1. Instant access to an easy programming environment.
2. Single-tasking, at least by default.
3. Low-level access to easily-programmed hardware.
4. Simple preloaded software.
@firstname.lastname@example.org Of course, to be modern, it should have at least a few hundred megs of RAM, IP networking (preferably Wi-Fi), a decently fast CPU, a bitmap display model, and support for modern IO standards (USB, HDMI, SD, etc.).
These goals might conflict.
@mdhughes @alexandra @vertigo The default ESP8266 firmware acts like a modem, too. I’ve been thinking a lot about just treating IP like a circuit-switched serial network, but I think I’d like a bit more functionality than that. SSH, SSL, FTP, maybe a simple network filesystem. Doing it in the OS seems more amenable to that.
@alexandra A few hundred megs seems reasonable, though with single-tasking and the kind of OS and interface I imagine it might be overkill. I’d love to be able to use SRAM, but it’s too expensive for more than a few megabytes.
@alexandra Yes! All of those.
I was also thinking a modern one would be handheld, perhaps with a form factor like the PocketCHIP.
@email@example.com Handheld is nice, but you have to wonder about input on such a small thing; handheld keyboards have never been the best...
@alexandra You’re right. Maybe clamshell? I could touch type on my Psion 5mx, though something slightly larger might be better for general use.
@firstname.lastname@example.org Clamshell helps more with cutting down size than actually making a good keyboard, though you can re-spend the dimensions you save on a larger keyboard. One of the big problems with portable keyboards is they're too thin to have much feedback though, and clamshell can make that worse...
It's a problem that's been fought by many engineers over decades. I'm sure there are solutions I'm not thinking of.
@alexandra The keyboard on the Psion 5mx had pretty good feedback, and I’m happy with the feedback on the modern Apple chiclet keyboards.
@email@example.com Could take a look at the PinePhone keyboard, it looks pretty nice. It's a sort of dockable situation, as wide as the phone is tall for landscape use, and with "real" keys.
@alexandra I was thinking clamshell mostly for portability. I want something like my Psion 5mx but more like a microcomputer than a PDA.
@firstname.lastname@example.org Yeah, I guess the clamshell chiclet keyboard design some phones have used would work. Not everyone would love it but it'd be usable.
@freakazoid @alexandra beaglebone is dated as shit but it still had the best damned ideas going for it. you plug it in to another computer and it presents as a network interface & storage, the storage includes a url to itself, which is a web IDE for itself.
there's also microhdmi, if you want to work locally.
regarding input devices, personally, i believe strongly in bluetooth. a fold up or roll up bluetooth keyboard, especially one with integrated trackpad or pointing stick, allows for so much ergonomic freedom. nfc pairing would help make that happen quickly/easily, with no other input devices to start with.
@freakazoid @alexandra @drwho alas no longer in production but i personally have a small stash of bluetooth Stowaway keyboards. very pocketable and surprisingly good for coding, especially if you can remap some keys (so android is still kinda painful afaik).
there's options like the "BB Q10 keyboard pmod" that are a good small size input device. this one doesn't have the "trackballer" pointing device, alas. these are kind of pocketable. but personally i'd so much rather have a pocketable Stowaway plus pocketable computer than a computer that also has to dedicate so much real estate to input devicing. i think- not sure. prove me wrong? ;)
it's software complex, but the beaglebones usability without input device is really remarkably awesome. they really pushed & did good.
@freakazoid All I know is that I want an eink screen (should be more than capable of displaying most of I want from computing), and I love functional programming! Maybe it boots up into a cross between Scratch & Haskell? Those should complement each other well.
To do any real authorship on it I'd want a keyboard, but maybe that can fold away for consumption...
Can't say I've ever played with a microcomputer...
@alcinnz E-ink is nice for a lot of things, but for a microcomputer I think you want a color display that can update fast enough to play games. Something like the display on the OLPC might be ideal.
@freakazoid Fair enough, eink isn't great for typical videogames.
I certainly like the concept of designing a Haskell-like language with Scratch-like visual syntax though for games! Could minimize the need for a keyboard that way, using drag & drop instead.
To handle live interactivity in this setting you could use "Functional Reactive Programming": Define a "timeline" datatype represented as a timestamped linked list to represent the I/O. Images & sounds could be other datatypes.
@alcinnz FRP is pretty cool. Something that could make functional programming as accessible as BASIC on an Apple II or Commodore 64 would be revolutionary. But I wouldn’t have any idea where to even start. I have plenty of ideas for building a Scheme-based OS. Heck, I use a Lisp-based one daily.
@freakazoid A Lisp. Decent choice.
What I'm imagining is a three column visual UI: a column listing which functions (and constructors) are available, one where you edit the selected function, and a column for previewing the behaviour in slow motion with random data. Types would be colour coded.
Functions would be defined as a chain of "Given _ do _" blocks where you could draw links from the pattern to where the captured data should be inserted in the body.
I like that Oberon doesn't compromise its modeless UI just to make it easier for beginners. Instead they include a book. ROM BASIC and a lot of other early systems were similar because they simply didn't have the room. I would make it self-documenting like Squeak and Emacs, though.
@vincent @vertigo @alcinnz @drwho As for sound and video, I'd love to include an FPGA to emulate a SID, VDC, etc, but I think that would probably add too much complexity and cost. It's probably better to use a fast enough CPU to emulate that stuff in software and run everything under a hard realtime kernel, perhaps as a fixed set of processes: sound, video, GUI, I/O handling, network, and the running application.
Executive summary: I think you're on the right track. Dedicated modules talking over a message passing interconnect of some kind is the way to go, unless you really need the bandwidth. But, even there, a modern SPI link can haul 3MB easily without employing any kind of tricky technology. That's 3x the bandwidth of a C64, so it could readily handle even basic 2D games.
Backplanes aren't always the best expansion option.
@alcinnz The language question is one place I get stuck. I feel like you want a language-based interface, but I think the language should be more of a shell or “glue language” than an application or systems programming language. Maybe Scheme or something.
I imagine there are lots of videos of “the microcomputer experience”.
one thing I realized, through the years, is that, given some level of cpu and ram capability, the size of the monitor is more important than the size of the ram or of the cpu
Phones don't cut it, for me
You can consume through phones but you can hardly create
@AbbieNormal At 17 and certainly at 30-40 I think we’re getting well beyond what I think of as a “microcomputer” though.
@freakazoid Boot into a programming language/os, like the Commodore and the Atari.
On-board nonvolatile storage.
Thing is, there has to be a pre-existing software ecosystem in place to make people want to use it. Having the machine boot into Python or BASIC or something would be nice, but not having to write everything from scratch to have fun with it would be necessary.
@drwho I agree. One thing I think it should be able to do is emulate old micros and consoles, like go-play and other ODROID Go firmwares, or RetroArch. But the emulators should behave more like program loaders, so you just start the program you want rather than starting the emulator as a separate step.
This is starting to sound like it might be a useful project even without hardware. A shell with libretro built in.
@drwho Ferroelectric RAM seems ideal for nonvolatile storage. If we use PSRAM for main memory then everything just gets copied into it on boot. I love the idea of SRAM with NOR ROM using XIP to speed up boot, but I think it adds too much cost and complexity. The OS should be small enough and FeRAM fast enough that copying should be plenty fast. And it gives us something to do with the ludicrously oversized RAM we’ll probably be stuck with.
@drwho I guess the biggest commonly available F-RAM chips are only a couple megabits, so I guess microSD is probably the most practical way to go.
With NAND flash as main storage, I'd probably also want to have a NOR flash for the OS itself, because I think instant boot is important.
A social network for the 19A0s.