• Updated 2023-07-12: Hello, Guest! Welcome back, and be sure to check out this follow-up post about our outage a week or so ago.

Micro Conversions 1724PD LC PDS Video Card - AKA Memory Plus

David Cook

Well-known member
I just acquired a Micro Conversions 1724PD LC PDS Video Card hidden within a machine listed for 'parts'.

The PCB is labeled X56SC01B © Memory Plus 1994 USA. The other side has a sticker that reads M10646.
Micro-Conversions-1724PD-Card-Top.png

Micro-Conversions-1724PD-Card-Bottom.png

Running TattleTech and switching to the Nubus/PDS Slots tab revealed the actual product model number and vendor.
1724PD-Millions-Monitors.PNG

The Waybackmachine captured the company website starting in 1997. The documentation indicates that the card supports resolutions up to 1280x1024 and 24-bit mode up to 832x624. Woo hoo!

Even better, the card supports all computers with an LC III PDS slot. So, everything from the LC III up to the 6300, including LC 475 and Quadra 630. Given this is the first PDS video card I've run across, I feel very lucky.

The website includes a driver labeled pds.hqx. The driver is not necessary to run the card, per se. Regardless, StuffIt Expander (and everything similar) throws a -43 error when attempting to decompress the driver. Fortunately, BinHex 4.0 is 'dumb' enough to reveal the cause. The decompressed filename has a slash in it. Although not a Mac convention, clearly StuffIt tried to use the first part of the name as a folder path.

Unstuff-HQD-PDS-Accelerator.PNG

I am attaching a restuffed archive "Micro Conversions 1724PD.sit" with the filename slash replaced by a space.

The control panel (HQD PDS Accelerator v1.1) recognizes the card and the internal init launches at startup. However, it makes a beep at startup, which was not a good sign.
HQD-PDS-Accelerator-v1.1.4-Control-Panel.PNG
Although the card works, the performance is not great. It is about the same speed as IIci built-in video. I tried two machines (Performa 6200 and Quadra 630) and two operating systems (7.5.5 and 8.1). I figured perhaps the LC PDS slot was the bottleneck.1724PD-Slow-Performance-Without-Acceleration.PNG

However, the results weren't different with the driver installed and acceleration selected. Remember that beep at startup? That must indicate a problem. I set a break on SysBeep in Macsbug (command-power-button after Debugger Installed is displayed. Type ATB SysBeep <return> G <return>). It showed the section of code which is disassembled below in ResEdit.
IdentifyMemorySetup-SysBeep-Failure.PNG

Fortunately, the developer has left routine names in the code. So, it looks like the init is not able to find the card in memory at startup. I have not read the code carefully yet, to determine if I can patch it.

My request to the community is if you have either a different driver/control panel version, some sort of EPROM updater, ROM image, or maybe a full software installer, would you kindly upload on this thread?

Frankly, if you have this card and can try the attached driver to see if it works for you, it would still be of help.

Thank you,

David
 

Attachments

  • Micro Conversions 1724PD.sit
    25.8 KB · Views: 1

David Cook

Well-known member
Looks like you should recap it soon, those SMD caps won’t last long at this point.

Good call. Done!

Recapped.jpg

In fact, this caused me to find that the resistor bodge was broken. I originally assumed it was connected to a trace or via. But there's just solder mask that it is resting on. Based on residual solder on the chip pins, I assume it was originally soldered to the pin.

Bodge-Resistor-Broke-Off.jpg

Looks like it goes here.

Resistor-Soldered-Back-On.jpg

It didn't make any difference to performance or anything like that.

I had a chance to look at the code some more.
1. FindOurBoard looks for either the PDS or the NuBus board driver by name. It successfully finds the PDS driver.
2. It then gets a device list and compares the device list to -48 on the LC III. I assume it is the PDS driver it finds.
3. It then gets the master pointer to driver in memory by offsetting from the UTableBase.
4. Then it enters IdentifyMemorySetup
5. It calls _SRsrcInfo with slot $E (pseudoslot for LC PDS) id 1 extdev 0 on the LC III. It successfully finds it.
6. It calls SFindStruct(16). It successfully finds it.
7. It calls SFindStruct(3). It successfully finds it.
8. It calls SReadStruct and successfully returns a record that starts with 1.2.2b<00> That's the version of this particular card.

All successful so far in finding the driver and card EPROM resources. Now is where things get weird. The init code scans the version string until it hits <00>. Then it moves back to the final character and does the following.

Will-Never-Branch.png

It stores a 'b' in the version string on top of whatever was there (which was already a 'b' for my card). It then moves a constant 'b' into DO. The BEQ will never branch because 'b' is never zero. That forces the global flag $3626(A4) to be set to 1. It is then checked to see if it set to 1 (yes, you just did that). So the BNE will never branch and the beep always happens.

This code makes no sense. I suspect it was a last minute hack to force a particular driver state.

Regardless, I altered that portion of code and it made no speed difference. That is, the card's performance was no better than unaccelerated without the driver. So, I have to continue following the code until I reach the QuickDraw patch section.

- David
 

David Cook

Well-known member
I finished reverse engineering the 68k init code. And.... I got accelerated graphics working!

*cough* *cough* awkward silence *cough*

Go back to their marketing page to read carefully constructed sentences such as:
24-bit Accelerated graphics card for 6300/630 type PDS Macs
Allows work in photorealistic color to proceed without the bothersome delays


Something smelly is about to be revealed.

Let's take a look at the code. There is only one routine that calls SetTrapAddress (which is used to patch the System). All the code that calls this is in one section. That aren't very many traps. In fact, each of the first calls get the existing trap address, so there are only 7 traps patched.
Patching-Quickdraw.PNG
The first 3 traps refer to QuickDraw BitBlt when doing a simple copy of on rectangle of bits to another. The second 3 traps refer to QuickDraw BitBlt when doing a fill/erase with a pattern. The last trap is QuickDraw DrawSlab used by lines and arcs under specific circumstances.

So, this is only accelerating three QuickDraw calls. But that doesn't explain why I was seeing no change in performance in my tests.

Let's look at Anon4, which is the first QuickDraw trap overridden. It checks for two variables, $14 and $15. The contents of those variables both need to be non-zero to execute acceleration. Otherwise the original trap (ROM or System software) is called.
Checking-two-flags.PNG

A cool feature of this card is that if you start with acceleration on, you can toggle it on/off without restarting. The driver registers an address in Gestalt that performs the on-the-fly toggle. Behold variable $15! That means one of the conditions is whether the user has enabled acceleration. (Note: (A0) and (A1) both refer to the address of Anon16 that they are using to store the variables. So, ignore that difference.)
Toggle-Acceleration.PNG

The second condition (variable $14) checks something for the constant value #$20. That's 32 in decimal. What is something that might be that value? Ahhhh, the number of bits for each pixel! Millions of colors = 24-bit-mode = actually uses 32-bits because that aligns nicely in memory on a 32-bit processor machine.
Checking-for-32-bit-mode.PNG

So, the two conditions to kick in the three patched QuickDraw routines are:
* The user must select accelerated graphics
* The card must be in millions mode

Running Norton tests now reveals a measurable difference between acceleration on and acceleration off. And, it confirms that a very narrow set of routines are accelerated. (FYI: I used the card's off-the-shelf driver without any hacks. So, I didn't break anything.)
Two-very-specific-acceleration-cases.PNG

When they said "24-bit Accelerated graphics card" they were being literal. That is "24-bit Accelerated", not "24-bit graphics and Accelerated graphics". And when they said "Allows work in photorealistic color to proceed without the bothersome delays" they mean "But non-photorealistic color will still have bothersome delays."

To be fair, this is an awesome non-accelerated card. It provides a second monitor on machines lacking NuBus and PCI. It supports up to 1280x1024 monitors. The pan and zoom modes are wicked smooth.

Now that I have figured out the acceleration, I can let that go and appreciate the card for all that it does well.

- David
 

olePigeon

Well-known member
LOL. That is some sneaky-ass marketing. I still enjoyed this deep dive. You have some serious talent. I'm quite envious.
 

David Cook

Well-known member
I still enjoyed this deep dive.

Thank you for the compliments! Like all the other members, I love this time period of Macintosh computers. For me, getting the chance to buy stuff that I could never afford back then, and solving the puzzles of how they worked, provides a great deal of happiness and satisfaction.
 

olePigeon

Well-known member
Thank you for the compliments! Like all the other members, I love this time period of Macintosh computers. For me, getting the chance to buy stuff that I could never afford back then, and solving the puzzles of how they worked, provides a great deal of happiness and satisfaction.
Any idea if populating those 2 extra VRAM pads might improve color depth at the other resolutions?
 

Melkhior

Well-known member
That's 32 in decimal. What is something that might be that value? Ahhhh, the number of bits for each pixel! Millions of colors = 24-bit-mode = actually uses 32-bits because that aligns nicely in memory on a 32-bit processor machine.
The acceleration should be internal to the card if implemented well - the bitness of the host is unlikely to be relevant. It's likely the DMA engine they use to do the BitBlt is limited to 32-bits aligned address and/or width. It makes the DMA a lot easier to implement.

It is also somewhat lazy coding :) They could have accelerated BitBlt at lower depth, provided source and destination have the same (mis)alignement. The peel/tail loops are done by SW, and the bulk of 32-bits access are done by the DMA engine. Or at least the fully aligned case entirely by hardware (the NuBusFPGA acceleration Init does this still-a-bit-lazy one for depth < 8, if source and destination are byte-aligned and multiple of 8 in width then they are accelerated).

Nice dive into the acceleration code. You mention DrawSlab for lines and arcs - did you seem some benchmark where this seems to make a difference? "Lines" seems slower in the results you share, and "Round/Rects" & "Oval" don't seem to benefit much...
 

David Cook

Well-known member
Benchmarks aside, does the UI feel snappier than unaccelerated?

No, not really. However, I suspect if I was editing a millions-of-colors photo larger than the window size, that the accelerated scrolling would definitely be noticeable.

You mention DrawSlab for lines and arcs - did you seem some benchmark where this seems to make a difference? "Lines" seems slower in the results you share

"Accelerated" lines seem to be consistently worse in every benchmark I've tested. DayStar PowerDemo v5.3 goes from 4.4 per second down to 2.6 per second with acceleration on. Buggy implementation? Unfinished work?

Norton reports at least a ten percent decline in line drawing. I retested in System 7.1 (in comparison to System 7.1.2). In 7.1, unaccelerated lines was repeatedly around 1.52. I now need to go back and test System 7.1.2 unaccelerated to see if why that's lower than System 7.1. (Extensions? System? Spurious test?).

1724 more tests.PNG

In the tests above, notice that LC III using built-in video in thousands of colors seems better at most tests. In fairness, that's half the bandwidth (16 bits of color vs 32 bits of color). Accelerated 1724 still beats built-in video for scrolling and filled rects, even with the disadvantage of millions of colors.

Apple Personal Diagnostics shows an improvement with acceleration.

1724 Apple Personal Diag.PNG
Any idea if populating those 2 extra VRAM pads might improve color depth at the other resolutions?

That's an interesting question. Maybe I'll track down some extra memory chips.

- David
 

olePigeon

Well-known member
@David Cook I have some DIP version of that VRAM, but the only surface stuff I have is 80ns. Probably too slow. I could send a couple DIP chips over to you if you wanna just solder on some bodge wires.
 
Top