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

[lovingboth]

Some but not all of that is provided by the Neo6502.

[autopope]

Remembering the Amstrad PCW ... Mallard Basic on the PCW supported the CHAIN MERGE syntax for merging in external BASIC files with the current program, so it was easy to load overlays out of the RAM disk (for non-Liams: overlays were CP/M's precursor to DLLs, statically linked but could be loaded in from external files). It also supported indexed database files via ISAM -- not as easy to use as dBase II, but viable for bespoke business applications of the day.

[liam_on_linux]

Thanks for that!

I don't think I ever tried that. I had a toolkit for Mallard BASIC that gave it graphics commands, and I spent my time mucking around with fractals.

But in my first job, the company, CSL Delta, sold a custom payroll app tailored for Manx tax law, and the original version was entirely in GW-BASIC. It was a 300-400kB app, and GW-BASIC only allowed 64kB of code+data. (8086 "small" model, I think it's called: a single segment of RAM.)

The develop, my boss Alan Wright, worked around this with highly modular code: a main menu loaded other modules, but if you loaded a BASIC file from BASIC in the right way, it overwrote the code in GW-BASIC's memory but not the data. He had a big COBOL-style block at the start of every module specifying all the variables and warning you not to overwrite them, so the main menu created all the data structures, then submodules let you enter paypacket data, amend employees, run reports etc. -- all without recreating or initialising any variables.

It was actually very elegant, very carefully structured, and lavishly commented. Clear, easy to read, easy to work on.

My first and last ever programming job was amending the reporting module so it worked on an 80-column printer. The app had long ago sold enough to pay off its development so now was selling cheaply enough a customer bought it who was too cheap to buy a 132-column dot matrix.

I worked all Friday, took it home and worked all weekend in the PC Emulator on my Archimedes, finished on Monday morning and showed it to Alan.

He said my code was clean enough, but what if we wanted to drop a different column, or add one back?

I paled and said I could do that in another day or so.

He said no, why don't we just store a flags array, and if a column has a "1", print it, and if it has a "0" don't.

He ripped out my few hundred lines and replaced them with his routine, 10% of the size and far more flexible. It had some checks if stuff would fit and so on, too.

He didn't bother to sit down while doing it.

I never professionally wrote code again, apart from the odd shell script.

Anyway: yep, GW-BASIC could do that too.

Snag with the overlay structure: we couldn't compile it with QuickBASIC 3. Not without a major rewrite, anyway. (Side effect: all customers had full source code.)

Alan wanted to rewrite the payroll in QuickBASIC 4, which was fully modular, no line numbers, etc. Management refused to let him: it offered no functional improvement, and it was still selling profitably.

He quit, started his own company, and rewrote it from memory and proceeded to sell a few more copies.

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

Intentional constraints

[fjmilens3]

As the person behind the Cody Computer I can explain a bit. The constraints are a design feature; this isn't intended for someone who wants a high-end computer with a 6502 attached. There are certainly technical constraints in terms of the Propeller selection, and you could probably slap a Pi Zero or more powerful MCU on there and bit-bang the 65C02 bus from ARM assembly, but that's not what this was trying to be. Someone like yourself really isn't the target audience for it, and I'm not sure there was a target audience for it aside from the parts that made a dog smile or wag his tail; the three of us had fun working on it over the years, and it's shared because someone else might be inspired from it the way other projects gave me ideas.

It's a computer, but in reality, it's more of a toy. It captures the essence of an early home computer. It can exchange files and data over serial communications (instead of a cassette port), it has an expansion port, you can make a cartridge for it, you can program in a simple BASIC and assembly, and it has an intentionally limited feature set that would let you make simple games or programs for it. It's not trying to compete even with the more advanced systems of its era much less something like the Mega65 or Commander X16 or whatever else. A kid today isn't going to have the same sense of wonder with a computer that I did with my Commodore 64 at the age of three, but I think something like this might have come close as a family project and modern-day equivalent.

Think of it like a radio kit, either an old crystal radio kit or a more modern one; those aren't going to compete with what a Raspberry Pi and a software-defined-radio setup are going to do. Or in model rocketry where one might build simple, fun rockets with limited payloads, things you can study, understand, and then take down to the local park or salt flats; if you're just interested in putting something in the air, you're better off just buying a drone. Or in model railroading where you could go for a system with DCC or you could build one using traditional wiring, switches, lights, and solenoids.

My wife once introduced me to a PBS program, The Woodwright's Shop, from North Carolina public television. The presenter not only did woodworking but talked about its cultural significance. He went so far as to quote Jacob Bronowski in The Ascent of Man, discussing how once man began working with wood and stone it changed our conception of working with materials and the external world, how they could be cut, crafted, manipulated according to underlying principles. I think that I was lucky enough as a kid to have toys that encouraged the same spirit, and that's what this thing is trying to be.

I remember in the summer of 2019 when I got the original breadboard more or less working, then Cody walked around it on the living room floor and sniffed all the ICs. I knew at that point that if a very smart Pomeranian was checking out all those black rectangles that came in the mail and got plugged into a breadboard, a smart kid building something like this with mom or dad would also be interested in what all those obvious, visible parts did too. You can also see that philosophy in the 3D printed side of it or the nature of the PCB design.

From a purely practical perspective, by the time you end up with a more modern 65C02 or 65816 system with many of the advanced features you describe, you might be better off with an FPGA or emulated system anyway. At best you'd probably end up plugging an FPGA board or Pi Zero into something with a 65816 and calling it a day. You could assemble it at home, but I'm not sure it would have the same impact. By way of comparison, why write games in the Pico-8 "fantasy console" when you can do so much more without it? The simplicity and the limitations are part of the charm. This is like that for people who have an interest in retro electronics, computing, and also brandish a 3D printer and a soldering iron.

The other issue with a more fully-featured design is that it can often take away from the simplicity and intentional limitations that make something educational or fun. Saint-Exupery said it best although in a different context: Il semble que la perfection soit atteinte non quand il n’y a plus rien à ajouter, mais quand il n’y a plus rien à retrancher. Au terme de son évolution, la machine se dissimule. In this case, of course, we don't want the machine to disappear, but we want it to show itself in a simple way that also levels the playing field.

It's not really aimed at computer people, at least not that kind or in that sense.

Re: Intentional constraints

[liam_on_linux]

Thanks for this, and for taking the time to reply!

You don't actually spell out who Cody is or was, either here or in the homepage. I had a glance at the PDF of the manual and I see a photo which tells me a little more, but still is not unambiguous or unequivocal. Cody is/was your dog?

I sort of see your points. I do see the appeal of something very simple and minimal, and that one can build oneself from just a few ICs. (Not that that's something I'd particularly want to do, myself.)

I think we have personally got mutually opposed philosophies about this, and some of them I coincidentally expressed in a recent article of mine, which has gone on to do rather well. You might find it interesting.

How a good business deal made us underestimate BASIC.

Young Americans in the '80s maybe got to explore computers via a C64, and aside from the pricy Apple II -- which wasn't better in every way, just more expandable -- that was home computing. (I don't know; I wasn't one.)

Young Brits probably got a Sinclair Spectrum, with much weaker graphics and sound, but a much better BASIC. But unless their parents were rich, if they dabbled in BASIC as I did, they probably aspired to a BBC Micro.

My take is this: give kids a good BASIC and a fairly unconstrained environment if you can. (The BBC Micro had hardware-driven "MODE 7" graphics using a Teletext chip, so you got most of the paltry 32kB RAM free. Most users chose that, and wrote programs that flipped into graphics mode as required. The cut-down Electron machine didn't have the Teletext chip, was thereby crippled, and flopped.)

The take here seems to be that '80s American kids' take away was "the Vic-20 was awful and the C64 not much better, but I got here fine, so that's enough."

My take, as an '80s Brit kit, "my BASIC was pretty good and I could get Beta BASIC, and given that, I did fine. I would give kids absolutely the best BASIC and graphics I could fit, and tailor my machine to fit that."

Does that make sense?

[blackmetalbuddha]

If you're looking for something that ticks off most of your wishlist, I'd say check out the ZX Spectrum Next.

It’s got modern graphics with up to 256 colors and high-res modes, with screen resolutions up to 640x256. Plus, you get hardware sprites, layers, and scrolling.

For memory, it has up to 2 MB, with bank-switching options, and you can easily work with large data in BASIC — kind of like how the ZX Spectrum 128 did with RAMdiscs.

The NextBASIC environment is actually really solid if you’re into structured programming. It’s a big step up from the original ZX Spectrum BASIC. As for speed, the top CPU speed is 14 MHz in turbo mode, which is much faster than the original.

It also supports SymbOS, so you can run something more like a modern OS if that’s what you’re into. It’s definitely a good balance between retro nostalgia and some of the stuff we expect from modern machines.

[liam_on_linux]

If you're looking for something that ticks off most of your wishlist, I'd say check out the ZX Spectrum Next.

Thanks for this!

In fact, I do have one. It's sitting right next to me at this second.

The snags for me are that NextBasic is rather weird and nonstandard, and classic Spectrum languages like BetaBasic can't access the new hardware.

I sort of wish they'd taken, say, SE BASIC or something and worked with that, rather than strange enhancements to Sinclair BASIC. A clean break and a cleaner language.

[mpe400]

Classic 8bit is too constrained, but how about 8bit++? 6809 with some 16bit I mean.
To avoid price, obtainability, reliability problems go the FPGA route.
There is an interesting design at turbo9.org for a 6809 implementation. (impressed by the team BTW)
Video with very balanced discussion about design choices over here : https://www.youtube.com/watch?v=8ScT86RKopQ
Bitstream for Arty-A7-35 exists so maybe it can be made to run on this : https://machdyne.com/product/kirsch-computer/ (disclosure I am a total n00b at FPGA, but I appreciate the effort of designing a board).
Check out the Machdyne Timeless Computing philosophy to see if this resonates with you.
WIBNI we could have a hypersonic version of the Dragon 32? Up to 2 orders of magnitude faster...
Might even run a version of Lisp for 6800 if BASIC is not exactly your thing.

[liam_on_linux]

There is an interesting design at turbo9.org for a 6809 implementation. (impressed by the team BTW)

That is impressive. Not my personal goals, I think -- I am not a C programmer for instance -- but the 6809 was always praised. And of course it can run OS9, which still exists in some form.

Video with very balanced discussion about design choices over here : https://www.youtube.com/watch?v=8ScT86RKopQ

I am not a video watcher but maybe some time I can.

Bitstream for Arty-A7-35 exists so maybe it can be made to run on this : https://machdyne.com/product/kirsch-computer/

Interesting... I will read more on this.

(disclosure I am a total n00b at FPGA, but I appreciate the effort of designing a board).

Me too.

Check out the Machdyne Timeless Computing philosophy to see if this resonates with you.

Very interesting!

WIBNI we could have a hypersonic version of the Dragon 32? Up to 2 orders of magnitude faster... Might even run a version of Lisp for 6800 if BASIC is not exactly your thing.

:-)