At some point processes like this can turn into the quest for an entirely different computer running the OS from inside an actual Mac.
Also, featuritis kills.
Also, featuritis kills.
That’s why my aim is to build up single-function gizmos which are halfway well documented and work really well. Once I have enough of those I can combine them into an all-in-one thing.At some point processes like this can turn into the quest for an entirely different computer running the OS from inside an actual Mac.
Also, featuritis kills.
I've wondered how the MDU memory controller in the IIsi would react to a second memory controller on the PDS.Maybe we should just make an accelerator for the IIsi with 128 MB onboard RAM lol
Interesting. Means that write-back caches could use burst writes to speed things up. But they would likely need to bus-master the bus to access the memory, which makes them a lot more complicated than the common write-through designs that were common back in the day.Semi-relatedly, did you know that the IIsi and IIci chipsets support a burst write to RAM? 68030s can only do burst reads, not burst writes
Interesting, the IIci actually has NuChip30 which likely handles 20MHz-33MHz system buses. Out of town ATM, so don't have access to my library. Dollars to doughnuts the seminal NuChip of the Macintoshes II, IIx and IIcx used were only compatible with their common 16MHz system bus.The NuChip is designed for asynchronous operation between the 68030 bus and the NuBus. So internally it has two clock domains and carefully passes signals between them to coordinate the timing. The same chip as on the IIsi NuBus adapter is on the IIci motherboard and on there it connects to the 25 MHz 68030 bus clock domain and the 10 MHz NuBus clock domain. So this is why I concluded that the 68030 bus clock is independent of the NuBus clock when it comes to the NuChip bridge.
It's not too hard to do the bus mastering. For example the WarpSE's CPLD is already a sophisticated enough bus master. The 7.8336 MHz PDS master signaling/timing is totally done by the CPLD. None of the fast 68k's signals go directly to the bus. There are a bunch of fairly complicated logic equations in between and this implements the two-word posted write buffer, where the WarpSE's fast CPU can write to the slow PDS framebuffer twice in a row with zero wait states. The CPLD does all the timing to trickle these writes out to the PDS slowly while the fast CPU is allowed to access fast RAM and ROM.Interesting. Means that write-back caches could use burst writes to speed things up. But they would likely need to bus-master the bus to access the memory, which makes them a lot more complicated than the common write-through designs that were common back in the day.
Beware, it may not be pin-compatible.Interesting, the IIci actually has NuChip30 which likely handles 20MHz-33MHz system buses. Out of town ATM, so don't have access to my library. Dollars to doughnuts the seminal NuChip of the Macintoshes II, IIx and IIcx used were only compatible with their common 16MHz system bus.
So wondering if @trag can find his stack of IIcx boards and remove NuChip from one? I've got a few IIsi NuBus Adapters. Got a sneaking suspicion that a NuChip30 -> NuChip downgrade will make the IIsi NuBus Adapter comptible with the SE/30?
Project30 fifth edition coming up!?!
Interesting, the IIci actually has NuChip30 which likely handles 20MHz-33MHz system buses. Out of town ATM, so don't have access to my library. Dollars to doughnuts the seminal NuChip of the Macintoshes II, IIx and IIcx used were only compatible with their common 16MHz system bus.
Or you could send me one of those spare adapters so I have one to test and recreate with a reasonably small FPGA and a bunch of 74ABT651 ;-) ;-)So wondering if @trag can find his stack of IIcx boards and remove NuChip from one? I've got a few IIsi NuBus Adapters. Got a sneaking suspicion that a NuChip30 -> NuChip downgrade will make the IIsi NuBus Adapter comptible with the SE/30?
I second that. Though to be fair, as much as I like NuBus, by now it seems to me to make more sense create PDS device for the SE/30 (or IIsi) rather than try to kludge in some old NuBus device. Which NuBus device could go in there other than framebuffer and/or Ethernet? The hardest part of that by now is writing the Ethernet driver, as there's only one available example for the old DP8390 and modern devices are quite different to program.Instead of repurposing old NuChips, we should just reimplement it.
That's quite different than Apple's implementation - did you have DMA support? (NuBus -> memory).I wrote out the bus timings for a non-DMA-capable 68030-to-NuBus adapter a long time ago. It was quite easy to do and the whole design required only XC95144XL CPLD and 12 74AHCT574 register chips to implement.
I think for a first pass we oughta omit DMA support since plenty of cards are just slaves. The bidirectional ‘646 and ‘651 registers/latches used in the Mac II NuBus implementation are quite expensive these days. They are more than twice as much as unidirectional buffers or latches. It would be better to just double up on unidirectional ‘573 latches or ‘574 registers. So omitting DMA, we need four 8-bit registers to send the address from the 68030 bus to the NuBus, four to send write data from the 68030 bus to the NuBus, and four to receive read data from the NuBus to the 68030 bus. If we want DMA, we would have to add another four register chips. Then there is the matter of the PALs. Evidently the original Mac II required 12 PALs to implement the NuBus interface. That would fit in the Xilinx CPLD. Omitting DMA support would let us trim it down to just three or four GALs.That's quite different than Apple's implementation - did you have DMA support? (NuBus -> memory).
Shoot me a PM! I've got one from which I've already excised the CoPro, in determining that having two in the system wasn't the problem.Or you could send me one of those spare adapters so I have one to test and recreate with a reasonably small FPGA and a bunch of 74ABT651 ;-) ;-)