SuperMac PDQ, Spectrum 8, 24, Thunder ROMs

[jmacz]

OK - that fixed the ROM issue then.

Yup, the first 1.27 image works. Thanks!

 

[David Cook]

Here are three ROMs for the community that I haven't seen uploaded before now. Enjoy!

1. SuperMac Thunder 24 v3.1. This is newer than the previous archived version of 3.0.


The board is a revision P that originally shipped with ROM v1.7.0 that someone upgraded.




2. SuperMac Spectrum 24 Series IV v3.1. This is newer than the previous archived version of 1.7.2, which adds support for newer versions of the SuperMac software. It also allows on-the-fly resolution switching.

As a hack, I'd been using the v3.0 ROM from the series V board. So, I wonder whether this 3.1 ROM will work in both IV and V boards?

The seller indicated that this came out of a Radius 81/110.






3. SuperMac Spectrum 8 24 PDQ v1.7.2B. This is newer than the previous archived version of 1.6.0, which adds support for System 7.5.

I wonder why '1.7.2B' and not '1.7.3'?


Oddly, I have two Spectrum 8 24 PDQ cards that are significantly different. At first I assumed REV A was the older card, and that they moved things around to add crystal spots on the REV B card. But, the revision A board is part number 7682-002 copyright 1992, and revision B is part number 7682-001 copyright 1991. Why not call this a different card? Maybe they had leftover boxes and enough different card models already?


- David

 

[jmacz]

This is great, thanks! Looking forward to trying them.

 

[MacOSMonkey]

Good archiving! The newer gen boards are all basically the same, as I have mentioned elsewhere in other posts/threads. So, you can use Thunder ROMs in (newer/non-xilinx) PDQ/PDQ+ boards, etc. AFAIK, nobody needs the PDQ/PDQ+ ROMs for anything, unless they want slower/software-gimped graphics acceleration performance or are interested in historical/retro benchmarking.

The only major differences are, for example, that the Thunder board has GWorld RAM sockets and there are DSP board connectors...but non-issues as far as the PDQ/PDQ+ with Thunder ROMs inserted are concerned. I don't think the oscillator spin broke or v3.0/3.1 variants broke this ROM universality, but you can certainly test it.

All of the Squid01-SMT02-BSR03 board variants were mostly just a marketing exercise (with related product name-smithing). Shhh! Don't look behind the curtain, the Wizard of Oz is busy doing nothing and hoping you won't notice!

 

[jmacz]

The 24 IV 3.1 ROM works for me. Thanks!

The Spectrum 8 24 PDQ ROM.. these names are so confusing I tried it in my Spectrum 24 PDQ and didn't work, then realized it's meant for the 8*24 PDQ.

 

[David Cook]

The 24 IV 3.1 ROM works for me. Thanks!

The Spectrum 8 24 PDQ ROM.. these names are so confusing I tried it in my Spectrum 24 PDQ and didn't work, then realized it's meant for the 8*24 PDQ.

Fantastic! I'm glad to hear that. The feedback makes it worth reading and uploading the ROMs.

Even though @MacOSMonkey has taken the time to provide the inside scoop multiple times, I still get confused as to variety of boards SuperMac produced. They certainly were prolific (even with just badging).

 

[CC_333]

Even though @MacOSMonkey has taken the time to provide the inside scoop multiple times, I still get confused as to variety of boards SuperMac produced. They certainly were prolific (even with just badging).

Same here.

It seems like they just pushed out every possible variation of the same basic hardware, and marketed each variation as a separate product, to create such a wide range of products that almost every segment of the video card market had at least one model to choose from.

c

 

[Arbee]

Thanks for all of these dumps! I'm taking a break from adding full Mac systems to MAME now that 68K is almost complete and adding some more NuBus video card emulations, and the ROM dumps are obviously necessary for that. The Radius Thunder IV GX (who came up with these names?) is up and running except for the acceleration and figuring out how it IDs non-Apple monitors now. Fortunately the acceleration looks like an evolution of the Spectrum PDQ's accelerator which we already fully support. The Thunder IV GX's internal registers in general make it obvious that it's a SuperMac design that was re-branded when the companies merged.

Eventually I'm going to start writing up the internals of these cards on our Mac technical wiki @ https://wiki.mamedev.org/index.php/Driver:Mac_68K:Tech_Info

Some of you may be familiar with the decade-old MESS version of those pages, this has a lot of corrections and additions now that we emulate systems up through the Q630/LC580.

Also, some of the cards have MacsBug symbols in the ROM drivers, which is always nice.

 

[MacOSMonkey]

@David Cook Blame Marketing, as usual.

Spectrum/24: Original, non-accelerated

Spectrum/24 Series III: 1st gen acceleration (daughtercard GAL-based) - great as Gen 1's go, but make sure you use the v1.1 ROM.

Spectrum/24 PDQ: 2nd gen acceleration (Xilinx-based - a big, heavy board with lots of parts). Faster than the previous gen, but not very cost-optimized. The worst problem was the Quark XPress bug. Make sure you have the v1.27 ROM.

Thunder/24: 3rd gen acceleration with GWorld and DSP daughtercard sockets (custom-ASIC-based -- Squid01, or SQD01) - use the latest ROM available.

The confusion comes in after that -- there was 1 mature chipset group for core video functionality (SMT02-controller, BSR03-bit-shift register, SQD01-accelerator) for the later boards that became the PDQ+, Spectrum/24 IV (rebranded Thunder) and Spectrum/24 V, along with GX, etc. In the early days of the transition, it was still possible to buy the slower boards at the same time as the latest ones. So, you could get a Spec/24 Series III (with or without the accelerator daughtercard, where the one without replaced the original Spec/24), a xilinx Spec/24 PDQ board...or you could get a PDQ+ board that had identical components (less the extra RAM and/or DSP board sockets) to the Thunder or Spec/24 IV/V, albeit with a gimped/slower ROM as a marketing skew. There was also a RAM-crippled version that was an Specturm/8-24 that would do 24-bit in 13" mode, but only 8-bit at larger sizes to (eventually) replace the non-accelerated Spectrum/8 Series III.

So, as I have said elsewhere, forget the PDQ+ ROMs. They are a basically a waste of time and were just a way for SuperMac to sell the same underlying board design with gimped performance at a cheaper price while achieving manufacturing economy of scale. It's hard to fault this strategy however, since SuperMac dominated the graphics acceleration space and had the best/fastest accelerators with optimal COGS.

Maybe this abbreviated summary will also help in addition to my other posts on this topic.

On the subject of the futility of certain Marketing-related discussions:

A real conversation from some prehistoric time:
Support: "The users of Multi-User SuperLaserSpool are very confused about how we are marketing the product."
Marketing: "Great! That's exactly what we want. We want them to be confused!"
Support: "But...we're wasting huge amounts of time fielding confused (or angry) user calls and having to explain something that you could easily correct on the packaging/collateral to accurately reflect the product. It's not actually a Multi-User product. It's just a bundle of 5 copies of the Single-User version in the same box!"
Marketing: "And your point is...?
Support: ...

 

[Melkhior]

the Spectrum PDQ's accelerator which we already fully support.

Oh, nice! Didn't realize those cards had been understood that well already. From the code, it looks like the acceleration is limited to rectangle fill and rectangle copies... I guess the NuBusFPGA isn't too far behind then

 

[Arbee]

Right The PDQ at least isn't super ambitious about what's being accelerated. You could probably pretty easily put similar functionality in NuBusFPGA, the declaration ROM is the hard part.

Does anyone know if the specific model on the Thunder IV GX (1152/1360/1600) is from the ROM or is the ROM universal and it detects it? In emulation the card is showing in the Radius software as a 1360, but it'll do 1600x1200 in 24 bit no problem.

 

[MacOSMonkey]

@Arbee It would take a lot of work to replicate what the SQD01 does in the later board designs, but that is not to say that some things couldn't run more quickly on modern devices. I think the squid chip had hundreds of thousands of test vectors (at least) before tape-out. And, it was at least a year in the making.

On the original (Xilinx) Spectrum/24 PDQ, the parts were hand-routed to run at 40Mhz (hence the dedicated oscillator on the left-hand side), where that kind of performance was not possible with (then) contemporary auto-routing (where the best auto-routing maybe supported up to 20-25Mhz - I think that's right).

However, devices are much faster and software is better now than in the late '80s, so auto-routing FPGAs would probably be faster. In terms of what is being accelerated, the list is based on operations that had the biggest bang for the buck. There is always a certain amount overhead on patching the calls, so it didn't always make sense to accelerate (or prioritize development for) everything. Also, perhaps sneakily, not all accelerated functions of SuperMac are universally hardware-based. Some of the acceleration, like maybe the line code, was software-based (at least in the earlier accelerator gens) because QD32 had some areas that were not very optimized. For example, in the Spec/24 III, I think the lines were implemented in software, but were later integrated into Squid-based boards. There may have also been some things in 8-bit mode that were just sped up via software.

The hardware sophistication, including what could be accelerated, increased over time (from GAL->Xilinx->ASIC->+ GWorld & DSP). The acceleration matrix kept growing, including basic blits, polygons, regions, pixpats, lines, all the transfer modes, etc. Finally, in the case of later GWorld (Thunder/24, etc.) or even DSP acceleration (GX, etc.), those features required specific software integration at the application level.

I don't know that I would say that the configuration ROM is the hardest part, but there is definitely a hill climb there. Also, in terms of monitor detection, the later boards had cable sense for many common monitor configurations (13", Portrait, 16", 19", 21"), and for the other non-sense configurations there was Round Robin, mostly using the onboard clock synthesizer (later designs). On the earlier boards, as you can see, there are extra oscillator sockets (or bare pads) and the ROM ran timing loops at power-on to detect and build an available oscillator table to then feed likely configs to Round Robin. So, if there are extra oscillator sockets on the board, that is how they work.

@Melkhior The acceleration is not just limited to rectangles. Also, in 1989 (at least), it was a non-trivial task to disassemble, map, patch and/or optimize QD32. But maybe others have done some of that work now and made it public.

 

[Arbee]

@MacOSMonkey Thanks! It's always interesting to hear about how this stuff went back then. I'm about 6 years too young to have been working in the Valley in that 1988-1993 time frame and everything I've heard sounds like that was the most interesting time to be there. Apple was so random during those years, and then they managed to get even worse.

Regarding what the FPGA's actually doing: with the Spectrum PDQ 1.11 ROM and the appropriate software installed, I'm only seeing rectangle fill and rectangle copy operations being requested from the hardware. We get an error-free screen display in a variety of software just supporting those things in the emulation. I have no doubt the SQD-based boards do more interesting things though.

You definitely wouldn't have wanted to auto-route anything performance sensitive on those early Xilinx parts, but we're at the point now where people convert C code to Verilog with automated tools and it works.

 

[MacOSMonkey]

@Arbee Wellllll...nobody should really be using the v1.11 ROM for the original Xilinx-based Spectrum/24 PDQ (Shockwave) board. Use v1.27 instead. v1.11 did not work with Quark XPress, among other bugs/issues. There was also a file sharing compatibility bug, which I think was because of A0 register trashing across calls where A0 should have been preserved at the OS level, as I mentioned in other posts. But, that problem was fixed by Apple (because it was a system issue, I think)...but maybe also later redundantly fixed in v1.27 in case someone didn't have updated system software.

v1.11 was just an agile tweak to make up for the fact that the Shockwave release was relatively high-pressure to ensure Q4/1990 revenue. Maybe also to make Q3 numbers at the 11th hour. Lots of long hours - the norm rather than the exception, but always Promethean. Anyway, there were some palette/VBL/sound/pixel dropout issues. The problem was that palette (and/or maybe other board) updates were not being pegged to blanking (or other issues where interrupts were not being handled correctly) and the Xilinx parts took time to reprogram for new bit depths (a slight annoyance, but they were faster than the GAL daughtercard even if only an interim step to push performance until the Squid chip was done). So, users would either see certain types of transient artifacts or there would be other interrupt-related disruption (that could, for example, affect sound playback - maybe?).

In terms of what was accelerated, yeah, I guess it was mostly rectangles at the macro level (but not only) -- you should be looking at basic blits, regions, lines and pattern copies, and maybe certain transfer modes vs. others. Some line acceleration was done in software on the Series III/PDQ, but PDQ may have also had some limited HW line acceleration -- but you can verify that - see what hits the board during line calls. There may have been some other software-based speedups -- like pictures, maybe. Some of Apple's QD32 software functionality was not fully optimized in the Toolbox.

The acceleration theory was to intercept calls at the level of QD32 bottlenecks/primitives (where everything filtered down to a basic set of calls with the biggest impact on overall performance vs. required execution overhead). If you are using an emulator, you can probably spy on specific trap patching by looking at the behavior when the board ROM loads. Or, just use standard Macsbug on a non-emulated system (since the emulators don't have NMI support). I think acceleration load was triggered at Secondary Init (when the screen is opened/drawn). So, break on Secondary, then break on Get/SetTrapAddress.

Also, as I may have mentioned elsewhere, I think that the Shockwave board was the first one to integrate SuperMac's VDI (Video Driver Interface) code that allowed for patching/extending at boot time via a software patcher INIT. So, if you ever encounter a weird SuperMac INIT that is named something like "boardname_patcher" or that includes "VDI" in the name, that is what it is for. It is patching (or extending) board firmware at startup. There may be a few of these patchers floating around out in the world. I don't remember.

Anyway -- if I think of anything else, I will post it. I hope the above is helpful.

 

[Arbee]

@MacOSMonkey That's all awesome to know. I'm more directly familiar with the internals of QuickDraw on the IIgs, but it has the same set of bottleneck vectors that could be patched.

I don't doubt declaration ROMs had interesting bugs. One thing I've discovered writing an emulator where you can stuff 6 arbitrary cards into a Mac II is that cards don't always get along with each other, or even with others of themselves. Completely understandable, because testing anything like that in 1990 would've been difficult and expensive.

 

[MacOSMonkey]

@Arbee The main issues for all NuBus developers usually had to do with cards that were bus masters, like Apple's 8*24GC (also that card used block transfer mode). There may have been some issues for SuperMac with the 8*24GC along the way, but they were on the GC side. Also, SuperMac products ultimately outperformed it. The 8*24GC was a cool product that ended up being an amazing technology demonstration that used double the slot resources and didn't outperform the competition's single slot, non-block-transfer mode designs. But...cool design and it pushed NuBus to the limit.

There were some other issues that related to slot address space and CPU addressing mode (24- vs. 32-bit), especially prior to 32-bit clean systems. And, there were specific board anomalies, like the Spectrum/24 Series III in slot $B in 24-bit addressing mode -- I think the base address was decoded as $FB300000 instead of $FBB00000, which caused problems. The solutions was...just don't do that! That particular problem was an anomaly of address decoding by the SMT01 controller that I think was fixed in the SMT02 (Thunder, PDQ Plus, etc.). And maybe v1.1 of the Series III ROM was more graceful in slot $B. I forget. But, I seem to remember some extra management around use of _SwapMMUMode and trying to ensure that board was in 32-bit mode (plus maybe requiring the Mode32 INIT in older systems) to minimize the issue, since there was no problem decoding 32-bit addresses in the $FB000000 range.

SuperMac had great test coverage/effort (and the related positive impact of relentless QA on overall product quality), but there wasn't always full compatibility testing with every other kind of card. The test matrices kept increasing in size. But, to a certain extent, that didn't matter. SuperMac tested with important and/or exotic products -- like bus masters, etc. And when there were compatibility issues and caveats, they ended up in the release notes.

 

[Melkhior]

The main issues for all NuBus developers usually had to do with cards that were bus masters

Yes, there's probably some "interesting" combinations of behavior with bus mastering on NuBus, in particular to support block transfers;.. I did manage to make it work at hardware level (to some extent) in the NuBusFPGA, but not do anything useful with it for now. I have issues in the virtual <-> physical mapping, I think.

,Apple's 8*24GC (...) cool design and it pushed NuBus to the limit.

And a bit beyond I probably The idea of a "fully" programmable video device is cool (and might have been rooted in the TAAC-1 ?) and would prove successful decades later for NVidia, but it was way too early back then. Specialization is efficiency. The NuBusFPGA is currently using a very similar scheme (with a VexRiscv instead of an am29000), and it probably would be faster and/or more economical in FPGA area if it were a dedicated block.

the base address was decoded as $FB300000 instead of $FBB00000, which caused problems

Hehe, that would yes That one missing bit can be a killer...

The acceleration is not just limited to rectangles.

Rectangle shapes - but including blitting, fill, etc.

Also, in 1989 (at least), it was a non-trivial task to disassemble, map, patch and/or optimize QD32. But maybe others have done some of that work now and made it public.

It still isn't, in fact with the lost knowledge, it's probably harder. No more support from Apple and no more poaching experienced engineers from another company...
To the best of my knowledge, the only source code publicly available to do that kind of thing is in my acceleration INIT. If someone knows another, I want to know! Maybe someday some SuperMac (or anyone else!) source code will surface? That would be super useful. Unfortunately, I fear most proprietary source code from that era is definitely lost :-(

Meanwhile, usually in the acceleration CDEV it's possible to identify the traps that are being patched, and probably reverse-engineer some of the code by figuring the entry point for the replacement functions. It did point me in the right directions originally. But I didn't investigate much as it was too complex w/o real hardware to help figure out what's what. For instance, here's a QCOD (renamed to CODE to get the disassembly, though it's the hexa that is interesting in this case, the ASM is irrelevant in this part) resource from QuickColor (Radius?):

AB58, AB5A, AB59, ... are all internal QD32 traps. It's likely this is for the 'patching' part of the code to look-up which traps to patch and the offsets to the replacement codes.

With @Arbee mentioning full support for at least one accelerator in MAME, it might be possible to investigate in more details what is happening with the SuperMac acceleration for at least the early generation.

Theoreticallty, it's not really needed in the NuBusFPGA as it can implement the bottleneck functions - it's a full CPU. But it's a lot of work and would likely be overkill.

 

[MacOSMonkey]

For the 8•24GC, the hardware problem was with rapid, back-to-back NuBus transfers. There were other boards with this kind of issue -- accelerators, maybe -- like the Radius Rocket et. al. Luckily, for most users, if they had a SuperMac board, they didn't really need an 8•24GC. So, it ended up being a corner case.

The Rocket was more of an issue based on use case...but later SuperMac boards addressed it. So, if a user really had a hardware problem, then I think SuperMac would just replace their board with a new version with an SMT02 controller on it (which addressed all these issues, including also the slot $b problem, etc.) -- like a PDQ Plus (which was faster than all SMT01-based accelerator boards).

A number of hardware issues were tied to the SMT01 controller. It was a very sensitive 1st-gen attempt to replace the TMS parts and had little margin for error, especially with respect to video timing. There were numerous idiosyncrasies that, mostly, all had workarounds and it worked for 2 generations of boards. But, if you stepped outside the lines, it would instantly crash. Not so fun to debug.

To your point about efficiency, the 8•24GC was a cool hardware design and demo, as above, but the high-order hardware/implementation complexity didn't appear to result in meaningful or competitive performance gains vs. simpler, less resource intensive designs. So, the value proposition wasn't there. The Radius QuickColor boards also lost to SuperMac in video acceleration benchmarks.

Regarding the disassembly, the dump looks like a table, maybe with offsets. So, the code doesn't really matter, as you say. For this kind of detection (at least for SuperMac stuff), if you want to find the vectors, just break on _SetTrapAddress (Secondary Init), as above. Then, dump the code in the same general area. For SuperMac boards, the acceleration code is built into the firmware (but it was also possible to patch it externally). There may be some external INITs around that might be helpful.

And, as you say, MAME might prove to be handy. I have yet to set it up, but it's on my list.

It's interesting that you are using an am29K. I think SuperMac's ProofPositive RIP engine product was RISC/am29K-based.

 

[Phipli]

To the best of my knowledge, the only source code publicly available to do that kind of thing is in my acceleration INIT. If someone knows another, I want to know!

https://macintoshgarden.org/apps/bug-pickles-pickles-xa

There is acceleration code in those archives. Code available for both firmware and drivers.

 

[Melkhior]

It's interesting that you are using an am29K. I think SuperMac's ProofPositive RIP engine product was RISC/am29K-based.

No, the 8*24 GC was the one using the AM29000 - I use a VexRiscv, a highly configurable RISC-V core. I don't think there's a recreation of the AM29K for FPGAs or otherwise, they were not used in any popular computer or game console that I know of. But I didn't check thoroughly for things other than 68K.

https://macintoshgarden.org/apps/bug-pickles-pickles-xa

There is acceleration code in those archives. Code available for both firmware and drivers.

As far as i could tell from the available code, the Pickles only "accelerated" things like pan-and-scan - basically you just need to change the area of memory displayed on screen from a larger in-VRAM area. I didn't see any trap replacement or potential drawing code in the source code when I looked at it to figure out how to do the declaration rom (mostly the video drivers) and interfacing between ASM and C.
(the NuBusFPGA declaration rom is almost purely C, with just some data structures and stubs in ASM).