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.
Upgrading IIsi onboard RAM to 4MB
- Thread starter Zane Kaminski
- Start date
More of to complement the vintage computers. That is what is happening across the vintage computer communities. For example, there is a brand new accelerator for the Apple IIGS that offers insane amounts of memory as well as higher clock frequencies along with CDEV to control it and enable/disable features. That didn't change the IIGS but complements and fills in the legacy accelerators that are hard to obtain.
I don't see that as changing the vintage computer but making it more fun and useful.
I don't see that as changing the vintage computer but making it more fun and useful.
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.
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, but a sophisticated accelerator could collect video RAM writes in a few stream buffers and then burst them out to the IIsi’s RAM. That would nearly double the video RAM write speed.
I've wondered how the MDU memory controller in the IIsi would react to a second memory controller on the PDS.
If it properly decodes all address lines and doesn't answer for addresses beyond what it supports, then it should be easy.
To enable the memory in MacOS, at least for some reasonable quantity, it should simply be a matter of 'fixing' the bank table in the ROM, which is trivial to do with the existing Flash ROM SIMM. In fact, I've already bought the IIsi, the ROM SIMM, the ROM programmer, and made my own PDS adapter
Still have to convince myself my design for a "IIsiFPGA' would work. Then it would be matter of supporting the '030 bus protocol, likely synchronous words for the framebuffer and synchronous burst for the 'memory expansion' so the '030 can efficiently load into cache. I know of two implementations of FPGA talking to a real '030 bus, so that should not be a major issue (including the MAXI030). Currently WiP.
Though I've recently wasted time investigating whether I could identify the pinouts of the P4 connector in the Sun 3/80 workstation, which is highly likely to be very similar in concept to a '030 PDS (and uses a bog-standard 96-pins DIN 41612 connector).
LCIII is a different pinouts and form factor from the IIsi, but logically it would be exactly the same to support. I switched from the LCIII to the IIsi as my 'lead system' as ROM modification is easier in the IIsi.
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.
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!?!
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.
This burst writeback thing is basically an extension of the posted write buffer in the WarpSE, but with reordering and more buffering capability. We need a structure with, say, four stream buffers. Each stream buffer would have a 4x32 bit buffer for write data, a 28-bit address field (bits 31 through 4), a 16-bit byte mask field (one bit for each byte in the burst), an address comparator, and a timer. Every time the fast CPU writes to RAM, the stream buffers use their comparators to check if they are storing data that can be combined in a burst. If so, that data is put into the stream buffer and the write cycle is terminated.
On the bus master side, it checks to see if any of the stream buffers are full or their timers have expired. Full stream buffers are burst-written into RAM. On the other hand, a timeout in the stream buffer before it's filled all 16 bytes causes the master to execute multiple write cycles to commit the data into Mac RAM.
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!?!
Instead of repurposing old NuChips, we should just reimplement it. 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 don't have enough time to do the layout but I can do the schematic, start the rough layout, and do all of the CPLD stuff if you @Trash80toG4 or anyone else is interested in finishing the project.
Edit: you could also make it out of a few PAL/GALs instead of the Xilinx CPLD. The rev. A Mac II had like twelve PALs to do it (!) but we can do with less by implementing only one slot and omitting DMA support.
There could be another reason for the 'upgrade' from NuChip to NuChip30; synchronous cycles.
The 68020 is the MacII only does asynchronous cycle (unclocked), the 'slave' (memory controller, NuChip, everything else on the memory bus) must answer via /DSACK0 and /DSACK1.
The 68030 added synchronous cycle (clocked by the CPU clock), the 'slave' may answer via /STERM (but asynchronous still works). It also has a burst mode which is a 4-words (16 bytes) read-only variant of the synchronous cycle.
DCDMF3 (p317) explicitly states for the PDS slot that the SE/30 memory controller answers asynchronously (/DSACK) while the IIsi memory controller answers synchronously (/STERM). It means a bus-mastering device talking to the memory controller, such as the NuChip, must be able to understand the appropriate response for each machine.
The memory controllers in the IIci and IIfx support burst mode as well to better enable the cache (burst mode is used to fill out cache lines in the '030). The IIsi does as well (DCDMF3 p344). The NuChip is unlikely to use burst mode though, that would be useful for NuBus block transfer but those aren't supported before Quadras.
So theoretically, a NuChip could support:
(a) asynchronous (/DSACK) as slave -> works in all II and related (68020 or 68030)
(b) synchronous (/STERM) as slave -> works on 68030 only (so not Mac II or Mac LC)
and:
(c) asynchronous (/DSACK) bus mastering -> works in system with a memory controller supporting asynchronous (/DSACK) cycle (all 68020, machine-dependent for 68030, includes SE/30, DCDMF3 p317)
(d) synchronous (/STERM) bus mastering -> works in system with a memory controller supporting synchronous (/STERM) cycle (machine-dependent, includes IIsi & IIfx)
DCDMF3 p355 makes it clear that for the IIfx, the NuChip in there only answer using /STERM. I haven't seen that clarified for other systems, but the IIfx is the only one with both PDS and NuBus pre-Quadra.
According to the Bomarc schematic, the NuChip in the IIcx is connected to DSACK but not /STERM, while the one in the IIci is connected to both /STERM and /DSACK, so it's likely newer NuChip will do synchronous cycle but might still have the ability to do asynchronous. The schematics cannot say whether those are input (for bus mastering), output (for slave mode), or both.
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 ;-) ;-)
More seriously, from the sync/async PoV, a 'newer' NuChip might work in a SE/30 as long as no bus mastering is involved. A IIcx NuChip is indeed more likely to work as it will only do asynchronous cycle. However it would be a shame to kill a working IIcx... also:
*beware* the pinouts between the two is completely different. You cannot just replace one by the other, and it's unlikely some bodge would help, as most signals have moved pins. You need to design a new PCB with the appropriate NuChip and support component, such as the 74ABT651 that may be a replacement for the IIcx' 74ALS651. The IIcx schematic can be used for reference, as you essentially need to reimplement that part between the '030 bus and the NuBus connectors (newer Macs have custom components to consolidate the job of the 74ALS651, so the IIcx is the best reference).
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.
That's quite different than Apple's implementation - did you have DMA support? (NuBus -> memory).
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.
Last edited:
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.
Very optimistic that the vanilla NuChip from IIcx approach should work, it's supposedly the same machine as the SE/30.
Last edited: