SuperMac PDQ, Spectrum 8, 24, Thunder ROMs

[Phipli]

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.


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).

I feel it accelerates some, but not many primitives. I think it either accelerated rectangles, lines or both, when I tested on real hardware. It absolutely didn't accelerate rounded rectangles though!

It's a few weeks since I ran the tests and I only saved a photo of the overall performance I think. I'll double check.

 

[Arbee]

MAME emulates the Am29000. It was used for 3D math in MicroProse's ill-fated arcade games (F-15 Strike Eagle and Battle of the Solar System). I don't actually have an 8*24 GC declaration ROM dump or I might've tried that already.

I happen to have a large source tree from "brand RO" and they didn't put any acceleration in the declaration ROMs as far as I could see, it's all in the software. And those declaration ROMs were also written almost 100% in C as well.

 

[Melkhior]

MAME emulates the Am29000. It was used for 3D math in MicroProse's ill-fated arcade games (F-15 Strike Eagle and Battle of the Solar System). I don't actually have an 8*24 GC declaration ROM dump or I might've tried that already.

Oh, interesting. I was thinking of things like MiSTer rather than MAME, but they could have those arcade as well. And a software emulation is a first step anyway. Might be interesting to be able to emulate the 8*24 GC one way or another.

The ROMs for the 8*24GC are in a ROM archive on archive.org, I believe. https://archive.org/details/macroms, in "
Mac_ROMs/Misc/Video\ cards/Apple\ Macintosh\ Display\ Card\ 8-24/Dolphin\ 8-24GC/".

I happen to have a large source tree from "brand RO" and they didn't put any acceleration in the declaration ROMs as far as I could see, it's all in the software. And those declaration ROMs were also written almost 100% in C as well.

Yes, the declaration ROM is really for basic stuff like the slot manager resources and simple drivers - and those mostly for stuff needed at boot time, like disks and framebuffers. You wouldn't want more fragile software like acceleration in it, and anyway it would be loaded too early anyway. Same for less critical drivers.

There's no hope you could share said source code, I suppose? Declaration ROM source code is interesting if not super useful (the Pickles one is already available and my own is open-source on GitHub, so that pretty well covered), but the acceleration stuff would be quite valuable a resource to have access to.

 

[Arbee]

I plan to release this stuff, but it's pretty much a raw archive of part of someone's work drive. So the organization needs to be sorted out and I need to separate the technical stuff from the personal stuff.

The source they got from Apple for the 24MxQ declaration ROM is in there too, and as you'd expect it's a copy/paste of the DAFB driver from the SuperMario tree. I'd love to know how and why that deal happened. It just seems so weird that Apple would give them a complete card and declaration ROM.

 

[MacOSMonkey]

re: am29K.
Right - The 8•24GC was an expensive beast to behold (and to hold in your hands - quite a heavy board). Anyway, I was momentarily confused and misread your post. Sorry about that.

And in thinking about it further, I remembered that the ProofPositive actually used the MIPS R3000A processor (I think that's right), NOT the am29K. It was circa 1992. Maybe that factoid will be of interest to you RISCers out there.

 

[Melkhior]

I plan to release this stuff

Awesome

 

[MacOSMonkey]

Yes, the declaration ROM is really for basic stuff like the slot manager resources and simple drivers - and those mostly for stuff needed at boot time, like disks and framebuffers. You wouldn't want more fragile software like acceleration in it, and anyway it would be loaded too early anyway. Same for less critical drivers.

SuperMac's acceleration code was fairly robust and was intentionally built into the ROM (as part of the video driver). The ROM also included all the pan and zoom functionality and other advanced features, including VDI in later boards. Developers shouldn't make the (restrictive) assumption that everything is going to load at Primary Init at boot time when there is minimal OS support.

The point of Secondary Init is that it runs later and can do things that were not possible at Primary Init (like after QD32 loads or there is a valid graphics device). If a card happens to be the boot screen, then Secondary Init happens earlier (but still after Primary Init and when QD32 is valid). Otherwise, the OS/Slot Manager opens the screen and calls Secondary Init when the OS draws the primary desktop if there is a valid PRAM config (or after the user uses the Monitors cdev to set a valid PRAM configuration for the board) and there were also some patcher INITs (but not sure if they have persisted out in the wild).

You can tell that a screen has not been set up when it shows up with a light(er) gray pattern in Monitors. As soon as you set any mode, the rest of the setup finishes and the extended desktop becomes visible/available.

Boards can either load their drivers internally or externally, or even internally and externally under some circumstances -- like with the 8•24GC that had a separate init or via an external patcher. SuperMac's SuperVideo INIT (at least through v2.xx) was mostly just for external control and configuration. It would read, save (internally) and set slot resources (like when changing configs or using custom monitor configs) and install necessary hotkeys, but it was primarily a cdev. SuperVideo 3.x may have included additional functionality (for newer boards).

 

[MacOSMonkey]

The source they got from Apple for the 24MxQ declaration ROM is in there too, and as you'd expect it's a copy/paste of the DAFB driver from the SuperMario tree. I'd love to know how and why that deal happened. It just seems so weird that Apple would give them a complete card and declaration ROM.

Apple (also) published the source to an example video declaration ROM in Cards and Drivers. It was in their interest to help all 3rd parties develop video board products and to promote a diverse and competitive ecosystem. They tried to help developers see what might be possible (e.g. 8•24GC, etc.) and provided them with necessary tools, access (to people and prototypes), debug labs and other resources to succeed.

Besides the above supportive rationale, Apple's (retrospective) "anti-competitive" more corporate rationale was that they likely knew it was only a matter of time before they would roll over and crush all the 3rd party video developers via internal/built-in motherboard video solutions and their own big-screen displays. "Here's a reference design to help you out -- good luck with that one!" (Somewhat tongue-in-cheek, but history speaks for itself.)

The big 3 video companies (SuperMac, Radius, RasterOps) tried to do what they could to survive through the '90s (as did Apple, pre-Jobs return), but it was death by merger, dilution and obscurity. The same fate applied (somewhat synchronously) to the 3rd-party authorized dealer network. Apple eventually began pruning in the late '90s to prepare the way for the new Apple Stores in the early 2000s. 2001 was the monolithic rise of the Apple Store.

I used to love shopping at ComputerWare.

But, in some instances, helping developers also backfired for Apple, like in the case of the Clone Wars (killed by Jobs). Apple licensed the entire MacOS to Radius/SuperMac/UMax to try to gain more marketshare vs. the PC space (much more than just a video declaration ROM and/or reference design). But, all their strategy did in the end was lose money...and they couldn't compete, which became painfully obvious based on their dependence on hardware revenue.

All of that being said, Apple was very helpful to SuperMac through the early '90s with respect to video, digital video and QD32-related development -- the MacDTS team and QuickDraw, QuickTime and A/UX teams to name a few.

 

[Arbee]

@MacOSMonkey Do you know if SuperMac attempted any sorts of obfuscation/anti-cloning protection? The PDQ has all of the data lines inverted including VRAM writes (which is why you don't see plaintext when you dump the ROM with an EPROM reader on many SuperMac cards). I can explain that either as a deliberate thing (we've seen similar stuff in arcade games where it was definitely intended as protection) or simply as a side effect of how they're doing the NuBus interface. But the 1.27 PDQ ROM is writing large negative heights on the rectangle copy operation (the pattern fills are fine) where 1.11 didn't, which seems suspicious.

 

[MacOSMonkey]

@Arbee No - I don't think so. To see the ROM, just bit invert it. There shouldn't be any issues in terms of the acceleration code. It works when running on a Mac, so maybe it is on the MAME side -- possible sign extension problem/issue somewhere?

 

[Arbee]

Hmm. Our 68K integer code is extremely well tested (it passes 68KTorture and runs Apollo, Sun, SGI, Sony, and HP versions of Unix, among many other strong tests) so something weird is going on.

 

[Melkhior]

@MacOSMonkey (...)But the 1.27 PDQ ROM is writing large negative heights on the rectangle copy operation (the pattern fills are fine) where 1.11 didn't, which seems suspicious.

One possibility is that the hardware has a limited number of bits in those particular hardware registers, so upper bits could be irrelevant. The software might have stopped clearing/setting them for performance reasons. For instance, the NuBusFPGA software only has 14 bits for rectangle dimensions when blitting in the default configuration. Writing 0x8001 or 0x0001 is effectively the same.

If you own the real hardware, you could try to have a custom piece of software write in a 'storage' register for e.g. dimensions (one that doesn't trigger some computations, and might be expected to be shorter than 32 bits) and see if a read-back keeps all the bits or not. Assuming the HW will let you read-back the data, that is.

 

[MacOSMonkey]

One possibility is that the hardware has a limited number of bits in those particular hardware registers, so upper bits could be irrelevant. The software might have stopped clearing/setting them for performance reasons. For instance, the NuBusFPGA software only has 14 bits for rectangle dimensions when blitting in the default configuration. Writing 0x8001 or 0x0001 is effectively the same.

All QuickDraw coordinates are 16 bits (words). And, if you mapping things on the hardware side, you can expect that there will be 32-bit calculations to determine real physical addresses based on the board base address, which would be $fx000000 (32-bit mode) or $fxx00000 (24-bit mode). However, I'm not sure how that translates to the virtual domain of MAME. Assuming MAME mimicks full support for the 68K, then all the address and data registers should be 32-bit values. Also, for QuickDraw, gDevices and ports, there is a difference between local and global coordinates. Local to a port is not global to a device. Coordinates can be negative, so you can't clip the sign bit. See Chapter 2, Figure 2-28, p. 74 in "Programming QuickDraw" (Surovell, Hall, Othmer; 1992, Addison-Wesley).

Anyway, I don't know what's happening, but maybe a starting point for debugging would be to make sure that all QD coords are 16-bits (signed words). It's not clear to me exactly what you are doing, but is it possible that there might also be a register saving/trashing issue? For example, code should not assume the status of A0-A2 and D0-D2 while in the middle of a trap call (such as during a trap dispatch to a QD accelerator).

The Trap Dispatcher saves and restores these registers (mostly), but not D0 (result code) and maybe not A0 (return address - when bit 8 in the trap is set). Spying on register trashing across subroutine calls (stepping over) might also be a good place to start and is usually a quick debugging reward -- easy to spot vs. real-time or interrupt-based debugging/problems. Once you find the place where you think the coordinates are being changed, then just step into that subroutine.

If MAME is multi-tasking or using multiple instances, then you have to make sure that there is no register competition/trashing. Again, just throwing out some ideas. I don't know how it works. However, real-time debugging is very difficult. The best thing to do is to use extensive time-stamped logging for post-analysis or reg spies.

If you own the real hardware, you could try to have a custom piece of software write in a 'storage' register for e.g. dimensions (one that doesn't trigger some computations, and might be expected to be shorter than 32 bits) and see if a read-back keeps all the bits or not. Assuming the HW will let you read-back the data, that is.

I have several PDQ boards, including both firmware versions.

Maybe of historical or other interest: Make sure that you are not trying to do moves that start exactly at the origin. There was a fundamental problem in earlier OSes/versions of QuickDraw, where CopyBits would try to do a bitfield extract at the origin and would crash boards that didn't implement an extra buffer ahead of the board baseaddress. For example, some earlier SuperMac boards do not have any extra RAM when maxed out (like the Spectrum/24 and Spectrum/24 Series III - 3Mb only). But, I think this issue was fixed by the time Spectrum/24 PDQ shipped. So, maybe that issue is not affecting you. Hmmm.

 

[MacOSMonkey]

By "reg spies," I mean setting up monitoring to watch registers and break on some condition being true. That kind of strategy may not catch the exact moment of a real-time failure, but it might work well as a terminator for a multi-source log so that you know where to start looking as you back up through the logs.

The only caveat is that with extra logging and monitoring in place (that slows execution) to find some strange hardware/firmware issue, certain types of bugs may not be easy to reproduce, or subsequently may not happen at all.

 

[Aeroform]

After quite the journey I have now in my hands two Supermac SE/30 cards. Both with identical hardware, but two different roms (as expected / established earlier in the thread). One sold as the ”Spectrum/8 series II SE/30” and one (software gimped one) as the ”Colorcard SE/30”. Both support a wide range of monitors / resolutions through 4! oscillator sockets up to 1024*768 @ 8bits.

Unfortunately, info on these cards is extremely hard to find outside of some small press releases detailing their launch. It seems not many bought them (speculating..) and thus support wasn’t kept up with as early as System 6.08 being unsupported (Simply stalls on the Welcome to Mac message, also true for anything 7.x). I finally got one to run under 6.03, showcasing their cool monitor select code running before even the OS loads (I’m guessing this is part of the issue when it comes to OS support).

I had ordered a rom programmer but sadly it got lost on the way from China. The plan was to clone the Spectrum/8 version to unlock higher bit depth on the gimped card, BUT, as I have basically zero use for cards not running on System 7 and with the lost programmer, I’ll shelf this plan for now. Will look around and try to find someone with a programmer that could dump the roms for me to upload here.

Does anyone know if the (non SE/30) Spectrum/8 ii runs on never OS’s?

@Trash80toHP_Mini your rom had a different number from mine. Have you tried what OS versions your card support? Would be interesting to compare our roms if we could get them dumped .

 

[Arbee]

Anyway, I don't know what's happening, but maybe a starting point for debugging would be to make sure that all QD coords are 16-bits (signed words). It's not clear to me exactly what you are doing, but is it possible that there might also be a register saving/trashing issue? For example, code should not assume the status of A0-A2 and D0-D2 while in the middle of a trap call (such as during a trap dispatch to a QD accelerator).

Let me back up and explain a bit about how this works. At a base level we're fetching a 68K opcode from the appropriate place, doing what it says, rinse and repeat for however many processor cycles are in a frame. At the end of the frame, we output whatever's in VRAM from each video device present in the system according to how the mode/depth/etc have been programmed by the emulated software. There are no interruptions or multithreading. This all happens in one thread, which is why emulators have fairly high CPU requirements and benefit greatly when Intel/AMD/Apple make IPC (instructions per clock) improvements.

The advantage of all of that is that the emulator itself doesn't have to know anything about the Mac OS's internals to run things fine, we just have to behave like the hardware does when it writes to $F9xxxxxx or $50F00000 (VIA 1) or whatever. The running software is emergent behavior.

I haven't had time yet to look more deeply into this; it could be as simple as some hardware registers are emulated as write-only when they're actually read-write (I fixed a bug in the Quadra built-in video that had that exact cause recently).

 

[MacOSMonkey]

@Arbee OK - thanks. What 68K MAME core are you running?

@Aeroform - You are correct that the cards are identical. The ColorCard SE/30 (codename: Pugsley) was such a low-volume product that it wasn't worth having separate hardware vs. the base Spectrum/8 Series II SE/30 board (codename: Astro). You may have found one of the 10 that were sold with that ROM. Otherwise, what do you want to know about them?

They were boards from mid-to-late 1989 that were the SE/30 variants of the Spectrum/8 Series II (or Spectrum C) boards. They had a very short life. The main problem I recall with them was that they might sometimes lose their PRAM configurations. Not sure if that was ever verified or fixed, but probably not (since the ROM is 1.0). The ColorCard SE/30 ROM doesn't have a version printed on it, but I think it is 1.0d1 (you can check in SuperVideo or Monitors). It's just a 1.0 ROM with the big-screen configs hacked out of it, as you noted, but virtual desktops should still work.

In 1989, I think the SuperVideo version was in the v2.03-2.06 range. I wouldn't use anything earlier. Later is probably OK.

There might be an issue with the configuration screen and System 7 -- not sure. But, if it loses the config and won't reconfig, just boot from a 6.0.7 floppy and reset it.

 

[Aeroform]

@Aeroform - You are correct that the cards are identical. The ColorCard SE/30 (codename: Pugsley) was such a low-volume product that it wasn't worth having separate hardware vs. the base Spectrum/8 Series II SE/30 board (codename: Astro). You may have found one of the 10 that were sold with that ROM. Otherwise, what do you want to know about them?

They were boards from mid-to-late 1989 that were the SE/30 variants of the Spectrum/8 Series II (or Spectrum C) boards. They had a very short life. The main problem I recall with them was that they might sometimes lose their PRAM configurations. Not sure if that was ever verified or fixed, but probably not (since the ROM is 1.0). The ColorCard SE/30 ROM doesn't have a version printed on it, but I think it is 1.0d1 (you can check in SuperVideo or Monitors). It's just a 1.0 ROM with the big-screen configs hacked out of it, as you noted, but virtual desktops should still work.

In 1989, I think the SuperVideo version was in the v2.03-2.06 range. I wouldn't use anything earlier. Later is probably OK.

There might be an issue with the configuration screen and System 7 -- not sure. But, if it loses the config and won't reconfig, just boot from a 6.0.7 floppy and reset it.

You have impressive knowledge around Supermac, did you perhaps work there at some time? Thanks for sharing! Don't have any specific questions other than just really interesting to learn a bit about the history of the cards. Interesting to have it confirmed they weren't really a volume product, somewhat expected given the lack of info / coverage on these cards.

Unfortunately any system from 6.08 and onwards just results in getting stuck on the "Welcome to Macintosh" message as soon as the card is installed. I'm guessing because of how the config screen has been implemented, as it should appear just before (or just after, can't remember) that message. Perhaps some version between 6.04-6.07 also works, haven't tested those. Perhaps I should try to boot from a SS6 floppy and after that restart into os 7 to see if retaining the settings in pram (and thus avoiding the config screen) enables me to boot a more modern system. If so perhaps the config screen could be removed from the rom to improve system compabillity.

Would also be interesting to hear what the OS support was like for the non SE/30 Spectrum/8 ii, and if that version got any rom updates. And also ofc. how they compare hardware vise (eg. would a non SE/30 spectrum rom work in the SE/30 version perhaps?). Difference between spectrum ii & iii would also be interesting. It's super hard to find info on the Spectrum/8 ii irregardless of form factor.

 

[Arbee]

@MacOSMonkey I'm testing on the "macii" driver (original Mac II, '020 + 68851 MMU).

 

[MacOSMonkey]

@Arbee Gotcha. I am curious to learn more about MAME when I have some time -- especially how it subsumes 68K interrupts and other vector-table-related activities. It seems like there are a lot of different 68K cores.

@Aeroform For the SE/30 config issue, just boot from a 6.0.5 system disk to configure the board and it should work. I'm pretty sure that was the recommended solution (and I may have commented on it elsewhere). Once it's set, the config won't need to run again. But, if you find that the SE/30 loses the board PRAM config, then you will have to do it again. The config loss might be happening as a consequence of SuperVideo. If you find that the board is losing its config, reconfigure it and try running it for a while without SuperVideo installed. You will lose some features, but the board will still work. If the config still gets lost, then it is not a SuperVideo issue.

Don't waste your time with the Spectrum/8 Series II (Spec C) board. It was limited to 1024x768 60Hz. It should work under System 7 and did not have any built-in config screens. It was either cable sense-driven or set via SuperVideo. Also, it never really got any major updates and was soon replaced by the Spectrum/8 Series III board (codename: George -- still in the Jetson's theme), which was much more functional, worked in configurations up to 1152x870 and supported higher refresh rates to prevent 60Hz fluorescent lighting flickering (e.g.1024x768 75Hz). The Series III board is SuperMac SMT01-controller-based vs. the Series II which was TI TMS-based.

The latest version of the ROM for the Spec/8 Series III board is v1.3 and it supports many monitor configurations. Otherwise, if you want a dedicated 8-bit board with acceleration, you might be able to find a Thunder/8.

I have a Series II/SE30 board. I will look around for it. I don't think I have an SE/30, however.