The main thing missing from it vs a real Beeb is the fact that a real Beeb is a real Beeb!
That's not a particularly constructive attitude. Why participate in a conversation about building your own computer if all you're going to do is trash homebuilds for not being as good as something that cost (in inflation-adjusted terms) ten or twenty times as much? (And by definition isn't going to be as collectable as the original because, well, it's not collectable, it's brand new.)
Certainly not "just as good", but not entirely useless, either. The main thing missing from it vs a real Beeb is video output.
I would say the lack of similar graphics capability *does* disqualify the thing from really qualifying as a "Beeb" in the minds of most users of the original. Sure, if you were using your BBC micro for some sort of process control function or whatever the "recreation" can do that just as well without wasting up to 20k of RAM on a useless framebuffer, but I imagine most "Beeb"-ers will be sorely disappointed it doesn't play Elite or whatnot.
(What I suppose it does do is demonstrate how device-independence was a strength of the original BBC firmware/operating system. It's pretty impressive that even the BASIC interpreter doesn't rely on pounding directly on the underlying hardware, most of which is missing in that board. Of course, it also demonstrates my point that homebrewing your own computer that incorporates better than port-mapped terminal graphics is apparently "hard" because almost nobody does it.)
Note that in most computers that *don't* use the 6502 and have to use bus arbitration for DMA video it's generally transparent to the programmer as well, it just has some side effects with regard to instruction timings. Broadly speaking the system is going to run slightly slower than its clock speed would indicate compared to a system that doesn't share RAM with video.
The ZX-81 had a "fast" mode where it would stop updating the screen to run a chunk of code at double speed.
The ZX-81 (descendant of the ZX-80) is one of those really unusual cases where the CPU is *directly involved* with updating the screen, so it's sort of in its own category in terms of the magnitude of the performance hit that comes with rendering the display.
In a typical DMA video the graphics hardware consist of a pile of counters designed to generate memory addresses to be fed into the RAM as needed to fetch the values needed to generate the display. (These can be discrete parts, as in the very early systems, or part of a dedicated video IC like the very common 6845 CRTC). In system incorporating a CPU like the Z-80, 68000, or whatever, anything that doesn't have as predictable a bus cycle as the 6502, the possibility exists for the video hardware and the CPU to want RAM at the same time. You can solve that either by letting the CPU win (which will cause a dropout on the display), or you can tell the CPU to wait. (Obviously you can't just let the video system "win" without pausing the CPU, that will cause a crash when the CPU fetches garbage instead a valid data byte.) If you're gruesomely interested in the details
you can flip to page 16/27 of the TRS-80 Model III technical reference and read how it does it, it's about as simple of an example as you'll find. Systems which use "main memory" instead of a dedicated block may use slightly more granular systems; the TRS-80 only generates a wait if the processor accesses the contended area, but if it does it's stuck halting the entire system until the end of a line of pixels is reached. If the CPU is always executing code from the same RAM as video then either the CPU will be halted what usually amounts to about 1/3rd-1/2 of the time (IE, it only executes code during the blanking areas all the time), or if the clock/memory speed is fast enough it may only be halted "as needed", with reads from video going through latches that grab a byte FAST and leave as much time open for the CPU as possible. (This still wastes a fair amount of CPU time, the exact amount depending on the speed of the memory subsystem. That's why dedicated memory video cards are still considered more desirable than the alternative. Worst case even a single-ported DRAM-based card will only make you wait a few ticks now and again, and only when you're specifically writing to it.)
What makes the Sinclair ZX-80/81 special is that they lack those address counters, and in fact lack dedicated video memory at all. Instead the video display is a linked list of arbitrary size, and to display video the CPU is jumped to the beginning of the linked list at the start of a line and is fed NOPs by the video hardware, which causes the CPU to advance its own address bus a byte at a time until it hits the "end of line" marker. (the bytes read during those NOP periods are fed to the character generator and shift register.) It's a clever way to get rid of some hardware, but it comes at the cost of monopolizing the CPU entirely while displaying a frame of video. (And all the CPU's state needs to be pushed onto the stack and restored when it's time to run user code.) The ZX-80 is always in "Fast Mode", because it "manually" has to keep track of when to take time out of its busy schedule to render the display and it's not at all sophisticated about it. (Basically it only shows a display when it's waiting for user input.) "Slow Mode" on the ZX-81 uses a little bit of additional hardware in the timing circuitry to generate a non-maskable interrupt to grab the CPU's attention when necessary, telling it to drop everything and go render the display. Rendering the display monopolizes *most* of the CPU's time, but it does let it juggle running a user program at the same time. Slowly. With considerably more pain than a more "sophisticated" system experiences.
But again, blawblawblaw. (I just like talking about these systems because I've been mulling over ways to substitute a quick MCU for all that timing hardware, because I badly want DMA video on *my* homebrew computer. The smallest flexible alternative is something like a 6845, but they still need a fair amount in the way of support chips and in theory if I can make something like a Propeller do what I want I can reconfigure the video layout just by loading a new firmware image.)
Right now I am more interested in creating the bare minimum of necessary firmware. I just want a monitor program to start. I think it's important to make the system unobtrusive and modular; like a set of tools rather than a guiding framework. That's somewhat intentionally vague... I haven't thought much about it yet, but my basic feeling is that "useful set of tools" is more enticing than "esoteric operating system."
Well, there is sort of a reason why people want a real OS kernel. If you don't have one you are, in essence, stuck with having to make every program you run on the system the OS. To a first or second order of approximation that's how, for instance, the original MacOS worked, and it was *not* a trivial system to program for. (And also, obviously, if your system lacks a real OS, even if it's just a simple DOS, it's going to be very difficult for it to be "self hosting".) Arguably architectures like that can work well for embedded systems that require real-time response, but offhand the only application I can think of that calls for rich graphics in that category is something like a game console. Which... would certainly be an interesting thing to build, and if it's cool enough you might be able to find people wanting to hack on it, but without Googling up an exact list I can say that there's already quite a few DIY game console projects out there...
I honestly had no idea that the blobs were so pervasive. I knew that the RPi had one and that my beagleboard's omap3530 had one, but I didn't know they were so deeply integrated into the low-level functions. I thought they were just for graphics and DSP stuff. Maybe it's not such a big deal. Owning every aspect of the system isn't a philosophical requirement of mine...
I'm sort of "eh" when it comes to blobs, as long as the blobs can be distributed and loaded from an arbitrary operating system and present a documented API once loaded. That way the hardware isn't useless under alternative OSes, you're just stuck accepting that you can't fix any bugs in the peripheral; it works or it doesn't. Hardware from the day before blobs could have bugs too, and you'd be just as screwed if it's bad. They're EVIL when they're locked completely inside a binary driver for a particular OS and only speak ancient Greek to it and it alone, rendering the thing a doorstop under any other circumstances. Unfortunately the latter is *not* rare.
I know I have limits, but I'm trying to learn as much as possible, and I can cut things out and/or relax my requirements as I find things that are beyond my abilities. I can't solder BGA by hand, but I can manage QFP and SSOP just fine, and those are still somewhat common. My high frequency PCB design skills are lacking and some system integration topics give me trouble, but app notes are my friend there. Plus, with my preferred PCB service (OSHPark) I can get high quality 4 layer boards for $10 per square inch, so prototyping costs aren't too high.
So, regarding your original goal of using a 68000-series CPU, have you seen this:
Project Kiwi
By any chance? It uses mostly late-80's vintage components so it doesn't meet your "modern" specification, but it would probably be educational to at least see what he's done there as from a software environment standpoint it looks a lot like what you might be after.
You might also, just for the heck of it, want to get yourself a Propeller Demo board to play with if you haven't seen one in action. (I have one myself and have been slowly working through the tutorial.)
It's only 32k of core RAM and has some irritating gotchyas here and there, but it's also a *really* cool toy for banging on hardware at a very low level. There are several projects on the Propeller forums that involve adding SPI RAM and an SD card interface to the plain old demo board and transforming it into a simple little self-hosted computer, IE, something you can program in BASIC and load .spin or assembly code files on without tethering to a Mothership. (And there's also all the emulator projects, but I sort of think those are a little silly other than demonstrating how *fast* the basic hardware is.) I know it's puny compared to your ultimate ambitions but if nothing else it could be a good "how graphics work" primer.
