The only 68k Macs with DMA SCSI under Mac OS are the Quadra AVs. (IIfx has hardware for it but only A/UX uses it).
-
Hello Guest! The forum software will be upgraded weekend of 06/26. See this announcement thread for more information.
DingusPPC: A more accurate PowerPC Mac emulator
- Thread starter kataetheweirdo
- Start date
Would the upgrade have actually been a 6200 board? (As opposed to a LCPDS 601 card)
The only issue with running 6360/6400/6500 etc boards in a 630 chassis is the lack of 3.3V from the PSU. A 6300 or 6320 board would drop into a 630/6200 with no problem.
I'm not sure.
If not, what does a PPC upgrade for a 630 look like?
I see. I thought it was something along those lines, but I couldn't remember for sure (my knowledge is a bit rusty from having been on the sidelines for the better part of a decade (2019-ish to now-ish)).
c
Question for the hive mind then, is there one?
Indeed.
A quick search uncovered this LEM article (take it with appropriately-sized gain of salt): https://lowendmac.com/2016/powerpc-601-cpu-upgrades-for-68040-macs-with-lc-pds/
If the article is correct (why wouldn't it be?), there apparently was an Apple Power Mac Processor Upgrade (APMPU for short) made by DayStar and featuring initially a 66 MHz PPC 601. DayStar also marketed the upgrade directly as the PowerCard 601, and later also released a 100 MHz version of it.
When DayStar went under, Sonnet took over the design and sold it as the Presto PPC.
Hopefully someone can confirm all this.
c
Hmmm. I guess the card came with a full GD emulator, 4MB PPC ROM?
Cr CroissantKing’s reply.
Not necessarily. If the system boots from 68K, it’ll check for a PPC ROM, but it could be a minimal ROM. Then you could load the PPC ROM from disk, like a NewWorld Mac does, because you already have a CPU that can do that. Then juggle the (PPC) MMU tables so the ROM is in the right location, then jump to the right place in the PPC Rom, it’ll reboot and we’re in PPC mode.
I should clarify, I suspect these upgrade cards do actually have whole 4MB ROMs.
Last edited:
The machines had what was essentially a 6100 ROM set on board, according to one of the Daystar support dudes I communicated with, way back when in the days when if you called for support, you might end up talking to one of the engineers. These outfits were small. Often just a couple of guys.
There were three basic types of PPC upgrade from Daystar. Ones targeted at the IIci cache connector (Turbo601), ones with the Quadra PDS connector, and ones with a 68040 PGA connector.
I don't think there was one for the Color Classic/LCII connector, but I could be mistaken. I did not know that the Value040 existed until I ended up with seven or eight of them.
In all cases, because they're based on the first revision of the 68K emulator included in the X100 ROMs, using Connectix's "Speed Doubler" will provide a substantial boost in performance for most tasks.
There were three basic types of PPC upgrade from Daystar. Ones targeted at the IIci cache connector (Turbo601), ones with the Quadra PDS connector, and ones with a 68040 PGA connector.
I don't think there was one for the Color Classic/LCII connector, but I could be mistaken. I did not know that the Value040 existed until I ended up with seven or eight of them.
In all cases, because they're based on the first revision of the 68K emulator included in the X100 ROMs, using Connectix's "Speed Doubler" will provide a substantial boost in performance for most tasks.
No. Apple engineers call it pseudo-DMA. It's supposed to work like that: an I/O ASIC provides a special HW register whose content will be moved over the real DMA interface to/from the target device. In PowerMacs, it's mostly the Curio ASIC.
The I/O ASIC provides all required signals for the DMA interface, just like a real DMA engine.
Programmed I/O (PIO) is slightly different: it doesn't use DMA signals and it always transfers 8 bits at a time.
The AMIC ASIC in the Power Macintosh 6100 provides all three types of transfer interfaces: PIO (8-bit transfers), pseudo-DMA (16-bit transfers) and real DMA (bulk transfers). The former two are used by the ROM loader to locate and load the required device drivers that switch to real DMA.
Last edited:
I had heard of pseudo-DMA, but I didn't know how it worked. I was just going by @Arbee 's post earlier in this thread:
Here, he explains that on the Quadra 630/Performa 630, which is essentially the basis of the Px200, SCSI transfers are managed by an unrolled loop of
move.l (a0),(a1)+ instructions. It's an issue, because it means a corresponding emulator has to either be interruptible at the hardware level or (in their case), back up the registers until each 32-bit word is available. To me that looks like PIO, but even if it's pseudo-DMA, it appears to me to be as much of a CPU hog as PIO.OK.
Apple's pseudo-DMA is PIO, given the processor is doing the actual transfers, it's just that the I/O ASIC (or PAL on the SE and Classic) is effectively a small cache in the middle. The transfer rates are better than pure PIO, but not by a lot, and you're blowing a lot of CPU cycles on SCSI transfers while Amiga and PC users get to look smug.
It did allow them to avoid properly invalidating the caches in Mac OS for a few years longer than they should have though. (Reportedly very early IIfxes came with a System version installed that did use true DMA but it was quickly changed after owners reported massive disk corruption).
It did allow them to avoid properly invalidating the caches in Mac OS for a few years longer than they should have though. (Reportedly very early IIfxes came with a System version installed that did use true DMA but it was quickly changed after owners reported massive disk corruption).
Bringing this back to the original topic, I've been running MacTest Pro on a Power Mac G3 Beige emulation. Some of the tests are still failing, such as timer tests in VIA failing. I've also ran some of the older versions, but I will probably need to run them once fixes have been implemented.
I'm aware of the said unrolled loop - it's part of the old SCSI Manager 4.3.
It doesn't cause any issues in DingusPPC because the 53C9x will generate an interrupt after some amount of data has been transferred: either function complete when the transfer counter drops to zero or bus service request in the case the target switches to some other SCSI bus phase, or disconnect when target decides to hang up.
One of those interrupts will wake up the SCSI FSM that will move to the next step in the SCSI transaction.
DingusPPC doesn't emulate low-level SCSI signals. SCSI emulation is at a higher-level because the SCSI controllers used in Power Macintosh - be it a 53C9x variant or MESH - also operate at a higher level. The guest SW has no means to see the low-level SCSI signals other than via the status register that mostly tells which SCSI phase the bus is currently in.
I believe you are correct here; I remember excitedly waiting for the Sonnet Presto PPC for my CC, only to be disappointed that they never released it, arguing that the data bus was too limited to make it worthwhile.
I get where they were coming from - 16bit RAM on a 16MHz bus, versus a CPU that had a 64bit bus and, well, you wouldn't run it slower than 50MHz. You'd end up wanting to put RAM on the upgrade like the crazy SE upgrades.
Indeed. I ended up with a MicroMac ThunderCache Pro (TCPCC32F) and stuffed the 4 extra SIMM slots that were still 16 bit. Woo! An extra 16MB RAM for a total of 26MB! 50MHz 030, 68882 FPU. When the Sonnet Presto Plus finally showed up (sans PPC), while the numbers on paper were way better, the performance increase was negligible, due to that 16MHz bus. And shortly after that we wrote up LEM's "Road Apple" article
Are you sure the accelerator card RAM is 16bit? There isn't really a sensible reason for them to do that.Indeed. I ended up with a MicroMac ThunderCache Pro (TCPCC32F) and stuffed the 4 extra SIMM slots that were still 16 bit. Woo! An extra 16MB RAM for a total of 26MB! 50MHz 030, 68882 FPU. When the Sonnet Presto Plus finally showed up (sans PPC), while the numbers on paper were way better, the performance increase was negligible, due to that 16MHz bus. And shortly after that we wrote up LEM's "Road Apple" article
Remember that the motherboard ROMs and the LC PDS slots were already 32bit.
The RAM on the SE upgrades that were often similar to LC cards were mostly / all 32Bit.
This is a reproduction 25MHz 040 Presto in an LC - the CPU performance uplift is huge, and that thing doesn't even have an L2 cache, let alone onboard fast RAM.
Last edited:
Yeah, per Micromac it's a 16 bit RAM bus on those accelerators, reinforced by it permitting SIMMs to be installed in pairs. A strange choice for sure.
One does need to be careful with benchmarks vis-a-vis real world performance since it depends a lot on the particular test's working set. If it's all in internal L1 caches, it'll show a huge improvement, but if you're spending a lot of time poking RAM, not as much....
50mhz 030 + L2 cache and fast (albeit 16 bit) local RAM I would expect to outperform a 25mhz 040 sans L2 cache in real world usage. However, the presto plus has onboard memory, with that populated I'd expect a different story...
Similar threads
