Duplicating a Plus in that manner is easy. Anything later, you have to duplicate the functionality of the system controller ASICs, or at least come close. This gets, as you'd expect, more complicated as the line goes on (e.g. LC 3's ASIC includes the SWIM II disk controller inside of it). Not to mention once you get to machines with Egret/Cuda you're dealing with a 6805 configuration that Motorola made custom for Apple, which is a pain in and of itself.
We do have the advantage that we could pick and choose function blocks from various Macs and reprogram the Universal Table in the later ROMs to recognize "our" Mac, although I'm not sure how well the OS would play along.
I'm not sure I would call it "easy". But I agree it should be theoretically possible to build a new Mac entirely from FPGAs and other new hardware, without using any existing Mac parts - at least for something similar to the early Mac compacts. There was a guy at 68kmla talking about something similar about a week ago, based on some new 68020 FPGA core. Basically you're talking about building something like the Minimig board, except for the Mac. In fact, there already exists a preliminary Mac Plus core that runs on the Minimig.
I was suggesting something different though - take a stock SE board, bbraun's video out invention, and a jury-rigged power supply to replace the SE analog board, and you could make a little pizza box SE. I'm assuming the power supply wouldn't be difficult (?), and bbraun's already mostly solved the hard part with the video out. Then you could, um, well I don't know what you'd do with it. But it would be cool.
Given how the video board is connected to the SE bus, it might also be possible to use it to emulate some kind of disk storage and other fun things too.
It's pretty amazing that today's low-cost microcontrollers are able to snoop, decode, and process the 68000 bus traffic in real time, in software! That's kind of blurring the line between a hardware peripheral and an emulator.
I've been messing with this again, and made a bunch of changes to send the memory writes over USB. I think that's just too much churn for the cpu to keep up with the 68k bus writes. I could try doing a toggle to only send when a full 64 byte packet has been buffered up, but I'm not sure that'll improve things enough to make it worthwhile.
I'm thinking I'll go back to sending the whole screen over on a regular interval, for now. I think there's some opportunity for speeding up the USB stack on this thing to hopefully get a higher framerate. Right now, it's only sending packets every 40th SOF, and it's doing a memory copy into the DMA buffer. I can probably rework all that to just DMA the screen buffer and save the memory copy.
I had ADB running on the original send-the-whole-screen polling implementation. A drawback I noticed was it'd occasionally miss a bus cycle. In my experiments with porting my ADB implementation to an arduino, I'm realizing my implementation is horribly inefficient, which was ok when I was dealing with the stm32f0 and un-loaded stm32f4 because they're ridiculously overpowered for the task. It's probably time to rework that, but I think I'll focus on the video side of things for the moment.
I looked at the datasheet for that TI TFP410PAP chip to do HDMI. That doesn't look too bad, particularly if I could rig up a way to just toggle all 24bits of data as all 0's or all 1's, since the SE's video is just 1bit anyway, and I don't think I can find 24 spare GPIO pins. It does seem like I'm running close to the edge on sampling the 68k bus, but toggling a gpio is going to be a lot less load than dealing with USB.
That would be awesome if you use the HDMI chip - then you can explain to me how it works.
So is the problem that sending every video write over USB eats so much MCU time that it misses some 68K bus cycles? It seems like there should be a way to do the USB transfer "in the background", but it's not a DMA transfer and the MCU isn't multi-threaded, so maybe not.
I'm surprised that it's not possible to update the entire screen buffer over USB at 60 fps. My math says that's about 1.5 MB/sec... hmm, what is the standard USB bit rate? 10 megabits/sec? Maybe you could compress it with a simple RLE approach?
What about combining the two approaches, and sending over a list of memory changes, once every 1/60th second? It might bog down during heavy animations, but most of the time the list of memory changes from frame to frame would be tiny and it would probably have no trouble keeping up with 60 fps.
Yeah, USB is lots of CPU time. Lots of interrupts. Basically whenever a frame can start on the bus, there's an interrupt to see if there's anything to send. That's not enough to interfere with too much, but the processing of each transfer is pretty CPU intensive to setup, which is where it falls down with sending memory access. Theoretically, it's much more efficient to just do a large DMA transfer, although it looks like I've got a bit of work to do to speed that up.
It seems like I should be able to setup a transfer during a vblank interval, then let the DMA engine handle it "in the background" while the next screen refresh is happening. Even if it takes 2 vblank intervals to send the contents, 30Hz would still be pretty slick (since it's not displaying on a CRT). I'll have to experiment a bit.
I remember that transferring between two boards via USB was the major bottleneck in sprite's Mac SE/ARM: he was down to four frames a second.
Pardon me if I've missed something along the way, but would it be perhaps better to mount the Beaglebone on the PDS card itself, rather than the Discovery board? I realise it's a jump in price, but then you have the PRUSS 200MHz IO modules to do bus banging, with DMA straight into the Linux engine.