For the record, if you were porting Minix to a homebrew 68k machine MacMinix probably would not be the best place to start for the very reason that it *is* encapsulated inside of a MacOS program. There were other 68k versions (Atari ST and Amiga, for instance) that were more "bare metal" and thus would provide more in the way of useful bootloader/initialization/etc. code.
For anything more powerful like an ARM system... not to be cruel to it, but Minix is pretty straight-up a waste of time. Minix is slower than Linux, by design, doesn't exactly have much of a track record when it comes to multi-platform-ity, and suffers from an absolute dearth of device drivers even on its native 386 platform. If you absolutely abhor Linux but still want something UNIX-like there are ARM ports of FreeBSD and NetBSD, they'd probably be your best options. (But peripheral support is sorely lacking at this point for most "multimedia" SoCs, in large part because of "blob issues". But drivers *may* actually happen someday, unlike the prospects for Minix.)
This project (which I'd forgotten about) is indeed interesting, if for no reason than it demonstrates the sort of overhead you can expect from "completely emulating" video hardware with a small 70-ish Mhz ARM slaved to an external RAM via GPIO pins. You would have to optimize this a *lot* to squeeze color out of it, let alone substantially higher resolutions.
Thank you. Again, a lot of it is just thinking out loud. Occasionally when you do that you'll manage to have someone with a good idea or two overhear it.
The SAA5050 still requires something like a 6845 for video address generation. It's still a semi-interesting chip; it combines a "character generator" (which in most systems was literally nothing more than a ROM full of character glyphs) with the actual pixel generation hardware/shift register, so if you're happy with the text-mode character set it's a way to save a few chips. (Its successor basically has the 6845 built in. Again, if you're happy with a simple text display it'll do but if you're after graphics or want your own character set it's not ideal.)
The outline of my Propeller idea starts with the assumption that the Propeller itself is a *little* too slow to just act like a memory device itself, IE, present itself so a "master CPU" can just shove bytes into its internal HUB RAM. Projects like the Prop6502 deal with this by actually making the "master" CPU a slave from a clocking perspective, but from what I've seen of that approach it just doesn't seem to scale too well. My idea is to instead have the "master" CPU talk to plain old SRAM and have the Prop regularly copy segments into its internal buffer. For "text/tile" systems like the Commodore PET or TRS-80 doing that would actually cut the memory bandwidth required for video a *lot*. For instance, the TRS-80's 64x16 video system only uses 1K of RAM, but each character is 12 scanlines tall, so each 64 bytes on each character line is scanned 12 times, making for a total of 12K's worth of memory reads for each frame. At 60 FPS NTSC that's 720KB/sec. If you only had to read the 1K once per frame then you've cut the speed requirement to 60KB/sec. That's so low that you could easily allow the Prop to only steal a RAM cycle every ten CPU cycles or so and operate somewhat asynchronously. In *theory*.
Obviously the limitation is that if you're doing full-screen graphics instead of characters/tiling pulling a whole framebuffer puts the bandwidth requirements back to even with "hardwired". My thought there is for graphics applications the Prop could be set up to accept *commands* written to some area in RAM and behave basically like a 9918A or similar. (Code already exists to emulate sprite engines like the Commodore VIC-II.) Unused HUB RAM on the Prop could be used as a tile cache and sprite buffer, meaning after an initial load the screen could be manipulated very quickly with minimal bandwidth requirements. (The design could include the capability for the Prop to write data back to RAM, in order to update things like sprite position, collisions, mouse cursors?, etc. That would also, again in theory, make it possible to do things like let a PS/2 keyboard on the Prop emulate a memory-mapped matrix with no additional hardware.)
Anyway. Again, blawblaw.