Why are hobbyist 21st century 8-bit computers so constrained?

[liam_on_linux]

I learned about a new DIY machine to me, the Cody Computer. 

It looks kind of fun, but once again, it does make me wonder why it’s so constrained. Extremely low-res graphics, for instance. TBH I would have sneered at this for being low-end when I was about 13 years old. (Shortly before I got my first computer, a 48K ZX Spectrum.)

Why isn’t anyone trying to make an easy home-build high-end eight-bit? Something that really pushes the envelope right out there – the sort of dream machine I wanted by about the middle of the 1980s.

In 1987 I owned an Amstrad PCW9512:

• 4MHz Z80A
• 512 kB RAM, so 64kB CP/M 3 TPA plus something over 400kB RAMdisc as drive M:
• 720 x 256 monochrome screen resolution, 90 x 30 characters in text mode

Later in 1989 I bought an MGT SAM Coupé:

• 6MHz Z80B
• 256 kB RAM
• 256 x 192 or 512 x 192 graphics, with 1/2/4 bits per pixel

Both had graphics easily outdone by the MSX 2 and later Z80 machines, but those had a dedicated GPU. That might be a reach but then given the limits of a 64 kB memory map, maybe a good one.

Another aspirational machine was the BBC Micro: a expandable, modular OS called MOS; an excellent BASIC, BBC BASIC, with structured flow, named procedures, with local variables, enabling recursive programming, and inline assembly language so if you graduated to machine-code you could just enter and edit it in the BASIC line editor. (Which was weird, but powerful – for instance, 2 independent cursors, one source and one destination, eliminating the whole “clipboard” concept.) Resolution-independent graphics, and graphics modes that cheerfully used most of the RAM, leaving exploitation as an exercise for the developer. Which they rose to magnificently.

The BBC Micro supported dual processors over the Tube interface, so one 6502 could run the OS, the DOS, and the framebuffer, using most of its 64 kB, and Hi-BASIC could run on the 2nd 6502 (or Z80!) processor, therefore having most of 64 kB to itself.

In a 21st century 8-bit, I want something that comfortably exceeds a 1980s 8-bit, let alone a 1990s 8-bit.

(And yes, there were new 8-bit machines in the 1990s, such as the Amstrad CPC Plus range, or MSX Turbo R.)

So my wish list would include…

• At least 80-column legible text, ideally more. We can forget analog TVs and CRT limitations now. Aim to exceed VGA resolutions. 256 colours in some low resolutions but a high mono resolution is handy too.
• Lots of RAM with some bank-switching mechanism, plus mechanisms to make this useful to BASIC programmers not just machine code developers. A RAMdisc is easy. Beta BASIC on the ZX Spectrum 128 lets BASIC declare arrays kept in the RAMdisc, so while a BASIC program is limited to under 30 kB of RAM, it can manipulate 100-odd kB of data in arrays. That’s a simple, clever hack.
• A really world-class BASIC with structured programming support.
• A fast processor (double-digit megahertz doesn’t seem too much to ask).
• Some provision for 3rd party OSes. There are some impressive ones out there now, such as SymbOS, Contiki, and Fuzix. GEOS is open source now, too.

Comments

[symbioid]

If we're going to request going beyond the, uh, basics... What about another/different language? Or is that veering too far from the path?

I know every system and their mom came with BASIC back in the day, but IIRC Pascal and Logo were also available for a lot of systems as well. But I'm sure most of them still came default with BASIC.

I do agree that if you have a BASIC it needs proper structured capabilities. Would a VM/Interpreter system for that be best or a compiler, or a combo/option? /me wonders if there's a BASIC Bytecode Machine (surely there must be. though BASIC is so fast would it even be necessary?)

I'm also a fan of the idea of "hotswapping" OS's (but I don't think I've seen that much in home computing - like we have VM's now, and can boot into different OS's but what if you could do more/faster)...

What would it take to store the OS state and pause, like Switch does, then swap via a TSR program to a different OS? What would a cross OS data buffer look like, I wonder. You'd have to have some system standard for the OS's to communicate or some subsystem to interpret the data.

So much of this seems contingent on memory access and capabilities, I suppose. For some reason I was thinking 32k was the max ram possible on an 8 bit system (OK, by "for some reason", I was thinking of the memory upgrade option for our CoCo I which allowed it to go to 32k BASIC; but looking up I see most 8 bit systems utilized 16 bit memory addressing, so 64k is likely max).

256 color makes sense; I wonder if you could introduce an "alternate" palettized system for devs/demo people to play with the effects you can get from that.

I hadn't seen SymbOS before, that thing looks beautiful.

I think it'd be interesting to have a minimal "desktop"/commandline hybrid of some sort. Not sure what or how it would work, but I think it could be done - without having to ape the WIMP interface, and still provide a more elegant UI than pure text.

If I were a hardware guy this seems like it would be a fun project.

[liam_on_linux]

I am not passionately averse to the idea, but the thing is this:

I've found a lot of pro programmers vastly over-estimated non-programmers' ability to read code.

I myself as a dilettante can't read Forth, Lisp, Perl, APL, or most fancier things. Simple procedural stuff is my limit.

Stuff that looks simple and comparable to some is totally over the heads of most. This is the genius of BASIC.

So, if you were to propose something only slightly more complex, such as FOCAL or COMAL, then OK, but they went nowhere much because they offered little advantage over early BASICs and by the early 1980s BASIC had caught up and passed them -- for instance, BBC BASIC.

I wrote about this recently, in fact:

https://www.theregister.com/2025/01/03/reevaluating_basics_legacy/

A 3rd gen BASIC such as GFA Basic, or MS QuickBASIC 4, has some advantages, but as I said in that article, it demands a high price in simplicity and immediacy.