Look, I know all of this is sheer speculation until someone extracts the digit and gets on with it. All I'm hoping for here is some constructive speculation to narrow down potentially worthwhile approaches. And, for the porpoises of this discussion, I for one am not even remotely concerned with preserving the "purity" of the original 64k ROM, nor keeping discussion narrowly focused on the original 128K Macintosh.
Personally I find the 64K ROM obsession rather silly, as there seems to be essentially zero evidence that its presence breaks *any* old Macintosh software. (The one small example that's been pointed to that ran on the original Macs but won't run on a Mac Plus are a few programs that used copy protection systems that are *actually* broken by the 800k drive, not the ROM.) But, eh, whatever.
I suppose the discussion still has to focus on pre-Plus models, so really the "purity" argument is whether or not we want to count a machine upgraded to the 512Ke standard as qualifying in that category. Personally I'd point to the fact that Apple practically gave away the "Macintosh Plus Disk/ROM Upgrade" as evidence that for anyone who actually *used* their original Macintosh, rather than tiring of it and throwing it in the closet, should of ended up with the equivalent of a 512Ke eventually anyway. And logic follows that after that they either got a Plus motherboard swap or the functional equivalent in third-party add-on cards, but at that point the discussion becomes moot.
So what we're concentrating on apparently is an upgrade for those leftover original Macs that the buyers hated, never used productively, and ended up abandoned in the closet for twenty years. Yay. :^b
Ethernet and WiFi is pretty much beyond its abilities / USB 1.1 host
Sure: I was picturing it more as a peripheral translator, to act as a go-between between the Mac and Ethernet/WiFi/USB chips - either through a new Mac driver, or pretending to be an existing peripheral such as a SCSI-Ethernet converter.
Hence finding the argument in favour of using a cheap ARM that already has those peripherals on-board interesting.
The Propeller is uniquely suited to the strange niche job of transparently emulating an existing peripheral chip because it's designed specifically to bit-bang and listen to I/O pin states in real time. (It doesn't use interrupts like a normal CPU, it has those eight cores so you can dedicate a few to endlessly polling and switching the I/O lines.) And ARM board is far less well suited to that, because it behaves like a "normal" computer + peripherals. Adding an ARM chip with a bunch of modern I/O ports would be a good way to add those functions to the Mac because you could use the power of the ARM to "dumb down" the modern protocols (for instance, you could offload the TCP/IP stack to the ARM), but what you'd get out of it is the ability to greatly simplify your Mac driver (and make it less resource-intensive). It's not a good route to eliminating Mac driver development entirely.
I suppose you could create some sort of hybrid where you have a Propeller dedicated to aping the interface of, say, the Plus SCSI chip, and then the Propeller communicates via a private bus (SPI, probably) with the ARM board. For just emulating disks that's huge overkill, but if you wanted to use the "SCSI Port" as a gateway to other functions I could see it.
Thoughts: lockstep the Prop [or whatever] to the Mac's oscillator, double or quadruple speed it internally, sample the TTL signals from the Mac's motherboard to the analogue board, leave blank pixels and lines to make up a VGA raster, then squirt that out another Cog using the existing VGA code. A brute force approach to not writing a Mac driver
There was a
thread about this a while back. Work on that sort of petered out, apparently. In principle it "could" work but I think you'd probably have to dedicate the Propeller solely to it with this approach.
(I did stumble across a discussion on the Parallax forums of people semi-successfully sampling monochrome PAL and NTSC signals, so there would be hope for this idea.)
Another more "elegant" possibility, which I *may* be wrong about, is it at least appeared to me from some light reading on the Mac's video system that it's possible to tell the OS to render the display in some other area of RAM. The original Mac hardware supported two locations for the framebuffer. (technically allowing for double-buffered rendering and animation, but the low amount of RAM pretty much nixed any programs actually taking advantage of that possibility.) If it's possible (and you'd have the look in the technical documentation to confirm it) to tell Quicktime an *arbitrary* location for the framebuffer you could map a block of fast SRAM (or dual-ported VRAM) somewhere higher in the memory map, and with a little extra hardware enable the Propeller to act as a DMA video generator.
(I could describe the additional hardware you'd need, but you'd have to run it past someone with more practical experience than I have to make it actually work.)
Heck, in theory you could be really incredibly skanky and map an ISA VGA card somewhere into the memory map, program its registers to set up an appropriate video mode, and tell Quicktime to render to it. In either case you'd undoubtedly run into some software (games mostly, I imagine) that blindly write to the default location of the framebuffer and thus barf, but there's no helping that.
Exactly - and give the Prop [or whatever] an SD card [or whatever] to play with.
Frankly, I think that's the only approach to *completely avoiding* writing custom driver software that has a snowflake's chance in heck of working. The NCR SCSI controller is pretty well documented, MESS emulates it well enough to trick the MacOS into working on it so you'd have an existing software model to follow when putting together your emulation... unless the Propeller is just plain too slow to pull off an emulation it should work.
But that deep-sixes the 64k ROM again. :^b
