Follow

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.

Β· Β· Metatext Β· 5 Β· 8 Β· 6

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.

@freakazoid@retro.social 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.

@freakazoid@retro.social 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.

@alexandra @freakazoid IP networking is definitely at odds with single tasking.

However, an event-driven architecture like what Oberon or Contiki uses would work quite well for it.

@vertigo @alexandra @freakazoid We have nice IP network "modems" now for 8-bits, like FujiNet, or the adapter (really a Pi0) on SpecNext. They just look like any serial port.

@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.

@freakazoid @alexandra @vertigo The Internet should be an isolated component, just as it was when IMPs ruled the ARPANET. FujiNet, etc. do ssh and everything else just fine. The client doesn't need to know about it, and doesn't need the security risks.

@vertigo @mdhughes @alexandra I kind of like the idea of physically separate processor for independent tasks, too. It was a common approach in early microcomputers. I think I’d rather have a RISC-V running an IP stack on the same core than have a separate but proprietary chip doing it, though.

@mdhughes @vertigo @alexandra @freakazoid And work with pretty much any terminal emulator. The one I have for my C64 works nicely with Bob's Term Pro from 1986.

@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.

@freakazoid @alexandra there is always PSRAM, dunno why it's virtually unused by hobby projects. It is DRAM packaged with a self refresh circuit built-in, and behaves externally mostly like SRAM.

@aperezdc @alexandra Oh, certainly. PSRAM would be my go-to for external RAM for more than a couple megabytes. I was mainly thinking SRAM for its much lower power consumption.

@alexandra Yes! All of those.

I was also thinking a modern one would be handheld, perhaps with a form factor like the PocketCHIP.

@freakazoid@retro.social 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.

@freakazoid@retro.social 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.

@freakazoid @alexandra i went with the competitor back in the day and was very happy with the HP200 keyboard.

@freakazoid@retro.social 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.

@freakazoid@retro.social 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.

@jauntywunderkind420 @freakazoid @alexandra I think some of the new folding Bluetooth keyboards might be ergonomically big enough now.

@alexandra @drwho @jauntywunderkind420 That’s not a bad idea. I’d be fine with having to use a table for it as long as it’s still pretty portable. I still think it would be ideal for it to fit in a pocket, though, and I’m not too keen on having to make it usable without a keyboard.

@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.

@alcinnz @freakazoid A HyperCard-inspired environment would be very interesting with a Lispy language backing it.

@vincent @vertigo @alcinnz Emacs is the lisp-based environment I was talking about using daily, but I'd want to use a modern lisp, and probably a simple one like R7RS scheme.

@vincent @vertigo @alcinnz Emacs, the Oberon System, RISC OS, ROM BASIC, APL, Smalltalk/Squeak, and Racket/DrRacket are my favorite inspirations so far.

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.

@freakazoid @vincent @alcinnz @drwho I'd like to reply to this with my thoughts, but I'm not yet in a convenient place to do so.

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”.

@freakazoid

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

yeah, I'm old

Probably I'm a bit biased toward macro πŸ€·β€β™‚οΈ

@freakazoid @AbbieNormal Micros had a few extra jacks that sometimes didn't get used much, as I recall. An HDMI port or two would not be amiss.

@freakazoid @AbbieNormal I like smaller screens because then I can see everything at once. I have some eye issues when it comes to larger fields of vision. I did Inktober this year on a 10 inch.

@Sandra @freakazoid

I see

probably an ideal computer should account for diverse needs

@freakazoid Boot into a programming language/os, like the Commodore and the Atari.

On-board nonvolatile storage.

Nice sound.

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.

@freakazoid I was thinking a microSD card under a little hatch.

@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.

@freakazoid NAND flash is pretty snappy to boot off of. Over USB3, anyway.

Sign in to participate in the conversation
R E T R O  S O C I A L

A social network for the 19A0s.