Is there a pin-compatible part in production now that you could use for prototyping?
Yep, in the STM32F4 and STM32F7 series. I'm reading the manual of the STM32F7 right now.
That's encouraging. [not needing an FPGA]
Pardon me for not digging up the exact link, but I gathered from bbraun's work that this series of micros have a PRU-like semi-independent fast IO subsystem that can bit-bang at ~100MHz or better. Even if that needs downstream muxing because of pin shortage, it sounds like it will be fast enough.
Not a separate processor like the PRU-ICSS in the TI chips, just fast single-ended I/Os.
I am more comfortable with the FPGA approach though, since it will buy us a bit more speed and flexibility at relatively low cost, which is kind of necessary. This accelerator won't be blazingly fast, certainly faster than an SE/30, but probably not as fast as a Quadra 700. But the cost will be closer to $100, not $160+. My design went the wrong way for a while because I was trying to design an architecture that would work on 68000 but be adaptable to 68020+. In restricting it to just 68000 (at least for now), I can go back on some decisions I made when trying to support 68020+ systems.
For example, these STM32 microcontrollers have a Quad-SPI interface, which I originally rejected as too slow for 68030 systems. The qSPI in the STM32F7 goes at 100 MHz for SDR or 80 MHz for DDR, and you can combine two together for a sort of Dual-Quad-SPI setup (different from Octo-SPI, which is kinda rare). This interface is plenty fast to transfer commands and stuff to the bus interface FPGA for a 7.8336 MHz 68000 system. So in reducing the pin count of the processor-FPGA interface from some 32 pins or something I had before, to the six pins of qSPI (4 data, clock, chip select), I can get a cheaper FPGA or some 4x more capacity for the same price.
There must be some existing code out there that could be adapted [for USB peripherals], yeah?
Probably, but I have heard a lot of bad things about many vendors' USB stacks, so we shall see. FAT32 is easy in comparison. There are a lot of FAT32 libraries around.
IMO, if you have USB storage sorted out, both SD and onboard flash would be redundant. At worst they could be designed in and left unpopulated.
SD is pointless, but there maybe should be the capability for more than the 2 Mbytes of onboard flash on the STM32H7. Might be useful to store a ROM image or system disk or something on the system. But yeah, the footprint can just be left unpopulated.
does the STM32H7 have Ethernet?
It does have part of what's required for an Ethernet interface, but it doesn't have the physical interface integrated. You have to send some digital signals that come from the STM32H7 to an external "PHY" IC. I would say that the main loss in this new design that users would care about is networking. There are USB WiFi dongles but I doubt anyone will write a driver for one of those.
So, call me crazy, but would the Mac itself be up to the task of uploading config data, via an INIT, CDEV or application? bigmessofwires has something similar working on one of his replacement ROM products.
That's a funny idea lol, but the problem is that some microcontroller or something actually has to connect some GPIOs to the JTAG header pins, and probably shouldn't itself be be on the JTAG chain.
The latest design I'm imagining uses a
Lattice iCE40 FPGA ($5 for "1k" capacity, comparable to the MachXO1200, $6 for 3x the capacity), which doesn't have JTAG, but instead has an SPI programming interface. That's much easier to talk to from the STM32H7, so problem solved. The iCE40 also is more accommodating of DDR signals than the MachXO, so that's nice. Actually, the iCE40 feels much more high-end than the MachXO, other than that it's a tad slower than the MachXO in its highest speed grade. iCE40 has no speed grades.
Possibly the most flexible thing to do would be to bring out all unused / available pins to a standard header (SO-DIMM?) with a documented pinout, and let future devs run wild with whatever they can use there.
Or all the STMs pins?
I'll make sure to break out the cool interfaces. There are several sizes of the STM32H7. BGAs aside, there are LQFP-144, LQFP-176, and LQFP-208 packages available.
The LQFP-144 ones don't support 32-bit SDRAM, which I wanted to use, so they're out. Also, about RAM, I have decided to use only one chip, not two. The routing effort for two SDRAM chips is much greater than for a single chip in the so-called "point-to-point topology."
So that leaves LQFP-176 or LQFP-208. I'm gonna go over the relevant signals soon and see which one is best. Ideally the LQFP-176 would be sufficient. So I dunno if there would be that many extra pins. When there are only two signal layers (on a four-layer board), and you have splits in the power plane, etc., that makes it hard to bring all of the signals somewhere, especially when the SDRAM and QSPI signals should have their impedances controlled, etc.
Going by what I see in my head involving the either/or connector capable MicroMac card, that probably won't work out due to clearances. :-/
The issue is that on the Plus, there isn't that much room between the 68000 and the power/video connector.
But also, the problem is that SE users will want to mount theirs with the PDS, not on the 68000, even with the Killy Klip. And it's not like you can mount a horizontal SE-style card in the PDS with the accelerator in there.