• Hello, Guest! Welcome back, and be sure to check out this post for more info about the recent service interruption and migration.

Development of Nubus graphics card outputting to HDMI?

Trash80toHP_Mini

NIGHT STALKER
You mean, interfacing with the VRAM built into the motherboard (or whatever)? I doubt Nubus/PDS has enough bandwidth to pull the contents of VRAM at any usable frame rate. A FPGA board providing its own frame buffer to the system and outputting the video signal independently is definitely the way to go.
The latter, a VidCard has nothing at all to do with memory on the logic board. CPU loads the frame buffer on the expansion card and then the card mooshes it around and shoots it down the cable.

Unfortunately, it looks like the miniSpartan6+ FPGA board used in the VA2000 project is no longer sold which is too bad because, from what I've gathered, it was particularly well suited for this type of application (and relatively cheap).
I figured it would have gone by the wayside by now.

There are some boards (DE10-Nano, Zynq-7010/7020) that appear to be suitable (HDMI port, enough digital I/O pins, enough RAM, NVM to hold ROM) but these provide ARM cores that, from what I've gathered, share the memory on these devices and are therefore not suitable for low latency applications. Some projects (MiSTer for the DE10-Nano https://github.com/MiSTer-devel/Hardware_MiSTer) have gotten around that limitation by attaching memory to the I/O pins. My recollection from skimming through documentation is that 56 pins are required in Apple's Nubus, which rules out the DE10-Nano, for example, because half of the 80 I/O pins available on that board would be used by the SDRAM daughter board. I haven't looked more closely at the Zynq-7010/7020 but I suspect it has the same problem.
Really, just forget about NuBus and design for PDS if you're going to get anywhere, listen to Gorgonops. :approve:   Moving a working PDS card design onto NuBus is really no big deal by comparison to overall development.

For PDS you shouldn't need all that many DIO pins as I understand it.  @trag16-bit video would require sixteen data lines and four address lines plus PDS control signals, no? I'm guessing 24-bit would entail eight additional data and one address bit? From what I recall of the Amiga project, you don't even need all the 68030 control signals?

I agree. I think 1080p is probably the upper limit and there are still likely to be some issues, as you've pointed out.
XGA _______ 1024 x 768  =   786,432 pixels

WSVGA ____ 1024 x 600  =   614,400 pixels

720p _______1280 x 720  =   921,600 pixels which is less than

Mac 21" ___ 1152 x 870  = 1,002,240 pixels

1080p ____ 1920 x 1080 = 1,393,200 pixels, only a 39% increase over Mac 21" and far less than the 2 million plus pixels my IIfx drives adequately on its pair of NuBus cards.

I see no problem with 1080p, those cards have only 3MB VRAM each, but they are QuickDraw accelerated.

That's encouraging. I skimmed through the video card specific sections of the Nubus documentation the other night, and came largely to the same conclusion. I would be thrilled to have unaccelerated video; I think that would be a major accomplishment. Accelerated video can come later :)
The NuBus Video Card documented in that book appears to be the original TOBY card for the Macintosh II. You've got the Sample Video Card firmware listings in Appendix B and Appendix C is the sample driver. Look at the information from the point of view of the 68030, not the NuBus setup in between, that makes it a sample PDS Video card spec, firmware and driver for the purpose at the start of this adventure. Build up from that foundation to the pinnacle of 1080p HDMI output from a 68030 PDS Mac*** displayed on a dirt cheap, lowest common denominator panel.

I'll look into it. One concern I have is whether a PDS graphics card can be used early enough in the boot process? There's a length discussion about that in the Nubus documentation for video cards.
Page citation would be appreciated here, I don't see a problem so far.

*** That sounds like the definition of the Amiga project you linked, but for the obstacle presented by ZORRO III multiplexing.

 

Gorgonops

Moderator
Staff member
1080p ____ 1920 x 1080 = 1,393,200 pixels, only a 39% increase over Mac 21"
Uhm, I think your Calcucorn may be busted, because mine says that 1920x1080 equals 2,073,600.

Note that the reason that Apple (and a lot of workstation vendors) liked that 1152x870(ish) resolution was that it's basically the highest 4:3 aspect ratio video mode that fits neatly in 1MB of RAM (It leaves less than 46k) at 8-bit color depth. (By comparison, 1024x768 wastes 256k, and 1280x960 needs almost 180k more.) Conveniently enough 1MB is also the same size as a 24 bit standard Nubus slot space, which means that there's no issue with using the card at its full (indexed) resolution regardless of whether the Mac is in 24bit or 32bit addressing mode. I'm certainly aware that they made Nubus cards with more VRAM than 1MB and capable of resolutions up to the 1600x1200 ballpark, but I frankly do not know what complications that introduces to the drivers and hardware of said cards. (I'd assume some of those really capable last-gen ones only worked in 32 bit addressing mode?)

TL;DR, going over one megapixel may significantly increase the complexity of what you're trying to do here. If you want to make a first crack at this I'd probably suggest drawing the line at 720p.

 

Trash80toHP_Mini

NIGHT STALKER
Probably, but likely the loose not on its keypad is at fault. Thanks for the correction, my head was not really in it tonight at work.

WXGA - 1280 x 768 = 983,040 pixels would be what I was really thinking, does that scale to 1080p well enough or is it better just to go with 720p scaling for a 1080p display? That's why I posted 720p, didn't want the table to be too complex  .  .  .  would have been nice had it been correct though. ::)

 

dlv

Active member
Really, just forget about NuBus and design for PDS if you're going to get anywhere, listen to Gorgonops.  :approve:   Moving a working PDS card design onto NuBus is really no big deal by comparison to overall development.
I'll take a look at PDS but part of the motivation for me is doing this for a Quadra 950, which is the only 68k Mac I really care to collect. I imagine targeting the 68040 PDS is technically not any more difficult than targeting the 68030 PDS but there are likely to be other challenges, e.g., the '040 PDS connector, which is why I had been exploring Nubus. That's all; I don't doubt designing for PDS is a better route.

I see no problem with 1080p
I was speaking to the usability (i.e., UX/UI) of classic MacOS at resolutions beyond 1080p which, at pixel densities we're seeing on modern panels, might suffer.

The NuBus Video Card documented in that book appears to be the original TOBY card for the Macintosh II. You've got the Sample Video Card firmware listings in Appendix B and Appendix C is the sample driver. Look at the information from the point of view of the 68030, not the NuBus setup in between, that makes it a sample PDS Video card spec, firmware and driver for the purpose at the start of this adventure. Build up from that foundation to the pinnacle of 1080p HDMI output from a 68030 PDS Mac*** displayed on a dirt cheap, lowest common denominator panel.
Which book are you referring to? It doesn't appear to be "Designing Cards and Drivers for the Macintosh Family (Second Edition)" (appendix B and C appear to be PAL listings).

Page citation would be appreciated here, I don't see a problem so far.
I did not mean to imply there's a problem - just my unfamiliarity with how PDS video cards interface with the system and vise-versa.

As for the citation, I was mainly inferring from the "Additional firmware requirements of video cards" section (beginning on page 130) in chapter 8 of part I, in the book "Designing Cards and Drivers for the Macintosh Family (Second Edition)", which discusses the various structs necessary in the video card's ROM to enable the system to detect and use the video card. I just looked through the TOC but don't see an equivalent discussion for PDS video cards.

If you want to make a first crack at this I'd probably suggest drawing the line at 720p.
That's a fine suggestion. Thanks.

I want to temper expectations though - at this stage, I'm just trying to assess what would be involved and solicit guidance from more experienced people.

 
Last edited by a moderator:

Gorgonops

Moderator
Staff member
WXGA - 1280 x 768 = 983,040 pixels would be what I was really thinking, does that scale to 1080p well enough
It's a different aspect ratio than 1080p so if you want something that scales naturally to 1080p it's a bad choice. It's also not a particularly common resolution for stand-alone monitors; 1280x800 and 1366x768 are both (probably) more common, although, again, they're far more likely to be found as panel sizes in cheap laptops than in monitors. Of this motley crew of also-ran resolutions 1280x800 is probably about the best to target because at least its 16:10 ratio *is* pretty common (it's a widespread small laptop/table panel size, and it also scales by 1.5 and 2.0 for 1920x1200 and 2560x1600, which are also "not rare", albeit less common than 16:9 monitors) *and* it likewise comes in at *barely* under one megapixel. (1366x768 is barely more.)

I did not mean to imply there's a problem - just my unfamiliarity with how PDS video cards interface with the system and vise-versa.
So, I believe the tl;dr there is from a software standpoint a PDS video card shouldn't look much different from a Nubus one. I'm looking at the same reference you are right now, and while, yes, it doesn't specifically include an example of a PDS video card *if* you build such a card that maps to the appropriate "Pseudo-slot" addresses and includes a declaration ROM (whose contents will essentially be identical to a real Nubus declaration ROM) the same mechanisms that allow such cards to be ID'ed and used at boot time will apply.

Just an offhand comment about "Designing Cards and Drivers for the Macintosh Family"... it is kind of hilarious how the book essentially slags Nubus over and over again for being needlessly complicated...

 
What might be worth trying first is to develop this idea in software - i.e. Build the design into an existing emulator such as Basilisk II then graft it over to hardware. Can definitely be useful for debugging and obtaining an understanding of how OS would interact with a video card expansion.

 

Trash80toHP_Mini

NIGHT STALKER
Which book are you referring to? It doesn't appear to be "Designing Cards and Drivers for the Macintosh Family (Second Edition)" (appendix B and C appear to be PAL listings). 
Well there's a lucky break/happy coincidence, You're looking at DCaDftMF2e from 1990 and I was looking the 1992 3e in book form. I rarely reference the PDF versions. Designing_Cards_and_Drivers_for_the_Macintosh_Family_3ed_1992 You'll find the link on this page with a great article at the bottom. IIRC the Byte article describes the trials and tribulations of NuBus development for the newly released 68020 Macintosh II, which predates introduction of the SE/30's 68030 PDS by a stretch. They would have been working from Designing_Cards_and_Drivers_for_the_Macintiosh_II_and_SE_-_1987 Haven't seen that last one before, now I've got some new reading to do.

If someone has and is familiar with the Inside Macintosh series, could you please check for PAL listings of the Macintosh II Video Card a/o Sample Video Card for us? With that we should have most of what would be needed to re-create the TOBY card as the basic design reference I think.

The three Card Design books in the NuBus architecture development series appear to be cumulative AND subtractive, with each referring back to need for an understanding of the previous editions as well as GttMFH in both editions.

fej8.jpg.56120f5f4cde6131d4233c08cdf33ffa.jpg


Later version:

53d4.jpg.037ac413ec87955ad7e15bbe53a84194.jpg


Those are from BMOW's stickied Hacks thread:





I see there have been a couple of replis posted while I was piecing this together so I'm signing off on this one at the point for a look see.

 
Last edited by a moderator:

Trash80toHP_Mini

NIGHT STALKER
YAY! Those development roadmaps hit page break discontinuity barrier just right for a change!

What might be worth trying first is to develop this idea in software - i.e. Build the design into an existing emulator such as Basilisk II then graft it over to hardware. Can definitely be useful for debugging and obtaining an understanding of how OS would interact with a video card expansion.
Fabulous! :approve: That would open development up to an insane level of collaboration.

It's a different aspect ratio than 1080p so if you want something that scales naturally to 1080p it's a bad choice. It's also not a particularly common resolution for stand-alone monitors; 1280x800 and 1366x768 are both (probably) more common, although, again, they're far more likely to be found as panel sizes in cheap laptops than in monitors. Of this motley crew of also-ran resolutions 1280x800 is probably about the best to target because at least its 16:10 ratio *is* pretty common (it's a widespread small laptop/table panel size, and it also scales by 1.5 and 2.0 for 1920x1200 and 2560x1600, which are also "not rare", albeit less common than 16:9 monitors) *and* it likewise comes in at *barely* under one megapixel. (1366x768 is barely more.)
Yeah, that's what I was WAG'n and why I was trying to keep the table as simple as possible. 1280x800 looks like a winner along with 720p, I'm posting from a 1920x1200 LCD right now and you've said it's the highest resolution that Analog VGA can handle so it follows that it's the best/highest resolution interface that'll work with a VGA/ADB KVM switch for a 68k thru G4 classic OS collection.

So, I believe the tl;dr there is from a software standpoint a PDS video card shouldn't look much different from a Nubus one. I'm looking at the same reference you are right now, and while, yes, it doesn't specifically include an example of a PDS video card *if* you build such a card that maps to the appropriate "Pseudo-slot" addresses and includes a declaration ROM (whose contents will essentially be identical to a real Nubus declaration ROM) the same mechanisms that allow such cards to be ID'ed and used at boot time will apply.
Yeah, that's exactly right according to all docs in the series by my read and why a PDS card poses no boot display problems. As I said, PDS postdates NuBus and as I understand it, the ZORRO III is pretty much the equivalent of the 68030 I/O architecture of IIsi/SE/30 with an unnecessary (ZORRO II connector/card compatibility) multiplexing setup. Many(most?) NuBus Macs and all NuBus architecture PowerBooks follow the 68030 interface model. Miniaturization of a baseline PDS design would open the 190/5300 and 1400 video card slots to current display tech as well as a larger BlackBird PDS expansion card.

 
Last edited by a moderator:

Trash80toHP_Mini

NIGHT STALKER
edit window expired: From the prelude to the VidCard section, the greater depth of VidCard development was added because the TOBY card had been discontinued, being no longer available to developers. So your second edition Appendices A/B were shoved back to C/D in the third edition.

 

trag

Well-known member
Conveniently enough 1MB is also the same size as a 24 bit standard Nubus slot space, which means that there's no issue with using the card at its full (indexed) resolution regardless of whether the Mac is in 24bit or 32bit addressing mode.


There was either a thread about this or discussion about it in an earlier thread about video card building.  If it had its own thread, it was one I started.  I kind of remember starting a thread asking that specific question, but I could be misremembering.  IIRC, someone knowledgeable claimed there was a mechanism to handle addressing more than 1MB in a slot even with the machine in 24 bit mode.   Maybe I'll hunt for it later, hoping that the old thread is not amongst the victims of hte software transition.

Targeting PDS is a good idea because I doubt that a new-work card in a Nubus slot will perform any better than the old NuBus cards did no matter how whizbang the new hardware.   NuBus is really really slow.

However, I hear you about the 68040 cache slot.   Has anyone identified the make and model of that connector and gone looking for a supply in the wild?   I've been able to find supplies of connectors like the Cache and ROM connectors for X100 machines and the Alchemy family.    That 68040 PDS connector may be more rare.

 
Last edited by a moderator:

trag

Well-known member
The FPGA that replaced/is replacing the Spartan family has on-board DDR2 controllers.  They're only 16 bits wide, but I think some of those chips have four of them.   DDR2 is fast enough that with good logic, one could probably send an acknowledge to the 680x0 processor on the next cycle after any transaction.   Might have to use an internal SRAM block as a FIFO buffer because of the latency though.   Anyway, that would hit the theoretical maximum speed, absent Quickdraw acceleration.

The biggest challenge is finding a development board with enough IO brought out to connectors to interface with the 680x0 bus.   I don't  think there is one.    A custom board would be needed.   And someone or some service would have to solder down the multi-hundred pin BGA FPGA.

 
Last edited by a moderator:

NJRoadfan

Well-known member
Yeah, that's exactly right according to all docs in the series by my read and why a PDS card poses no boot display problems. As I said, PDS postdates NuBus and as I understand it, the ZORRO III is pretty much the equivalent of the 68030 I/O architecture of IIsi/SE/30 with an unnecessary (ZORRO II connector/card compatibility) multiplexing setup. Many(most?) NuBus Macs and all NuBus architecture PowerBooks follow the 68030 interface model. Miniaturization of a baseline PDS design would open the 190/5300 and 1400 video card slots to current display tech as well as a larger BlackBird PDS expansion card.
The Zorro II bus on the Amiga is pretty much a direct pinout of the 68000 (24-bit address bus) plus a bus arbitration chip called Buster to handle DMA. Zorro III upgraded this to 32-bits all around and expects a 68030 or 68040.

 

Gorgonops

Moderator
Staff member
One of the slightly interesting tidbits the "DCaDftMF" book where it contrasts the simplcity of PDS with the painful drudgery of Nubus is how it notes that when you use the 68030 PDS it lets you take advantage of the dynamic bus sizing abilities of the 68030, which makes it relatively simple (compared to Nubus, apparently) of implementing a card for said bus that's only eight or 16 bits wide. (For instance it suggests that this functionality would make it relatively trivial for a designer to make SE and SE/30 versions of the same expansion card containing an 8-bit widget on it.) Obviously if you're looking for MAX POWER you're going to want to have a 32 bit wide card but... on the flip side, if you're interested in literally porting that Amiga Zorro II-targeted card design over it should be completely possible to build a 16-bit wide video card for 68030 PDS. (Which would add up to very minimal changes.)

(For the record I'm pretty sure the VRAM built into an SE/30 is only 8 bits wide; for all practical purposes it's implemented as if it were a *really* brain-dead PDS video card, including a stub Declaration ROM.)

68040 PDS might be another kettle of fish. Doesn't the 68040 require external arbitrators to handle different-width peripherals? (I kind of thought that was one of the reasons why Apple was so much in the business of using 68040->68030 bus bridge chips in so many cheap-o desktop and Powerbook models...)
 

There was either a thread about this or discussion about it in an earlier thread about video card building.  If it had its own thread, it was one I started.  I kind of remember starting a thread asking that specific question, but I could be misremembering.  IIRC, someone knowledgeable claimed there was a mechanism to handle addressing more than 1MB in a slot even with the machine in 24 bit mode.   Maybe I'll hunt for it later, hoping that the old thread is not amongst the victims of hte software transition.
There may well be. I certainly haven't read the manual that's being bandied about here well enough to say one way or the other. All I will say is it seems to have a lot of contradictory statements about 24 vs. 32 bit mode. (In the SE/30 PDS section, for instance, there's a specific blurb about how since the SE/30 only included 24 bit Quickdraw a video card designer should factor in having to bundle a RAM-resident 32 bit Quickdraw implementation...)

 
Last edited by a moderator:

Gorgonops

Moderator
Staff member
Completely, utterly off topic: I was looking at the 1992 (verses 1990) version of the "Designing Cards and Drivers..." book and I ran across this paragraph on page 275, Chapter 12:

[SIZE=11pt]The Macintosh [/SIZE][SIZE=10pt]LC [/SIZE][SIZE=11pt]is [/SIZE][SIZE=12pt]shipped [/SIZE][SIZE=11pt]with 256 [/SIZE][SIZE=10pt]KB [/SIZE][SIZE=11pt]or 512 [/SIZE][SIZE=10pt]KB [/SIZE][SIZE=11pt]ofVRAM (video [/SIZE][SIZE=10pt]RAM). [/SIZE][SIZE=11pt]With this [/SIZE][SIZE=12pt]configuration, [/SIZE][SIZE=11pt]main memory is not [/SIZE][SIZE=12pt]used [/SIZE][SIZE=11pt]for storing video data. If [/SIZE][SIZE=10pt]VRAM [/SIZE][SIZE=11pt]is not installed, it is possible to use main memory for [/SIZE][SIZE=12pt]video [/SIZE][SIZE=11pt]storage, [/SIZE][SIZE=12pt]though [/SIZE][SIZE=11pt]it is not [/SIZE][SIZE=12pt]recommended. [/SIZE][SIZE=11pt]With this configuration, main memory can only [/SIZE][SIZE=12pt]support [/SIZE][SIZE=11pt]the 640 [/SIZE][SIZE=12pt]x [/SIZE][SIZE=11pt]480 monochrome [/SIZE][SIZE=12pt]video [/SIZE][SIZE=11pt]mod [/SIZE]
Uhm, whut? Has anyone ever actually tried this?

 

Franklinstein

Well-known member
Completely, utterly off topic: I was looking at the 1992 (verses 1990) version of the "Designing Cards and Drivers..." book and I ran across this paragraph on page 275, Chapter 12:

Uhm, whut? Has anyone ever actually tried this?
I was aware of this but I haven't tried but it's mostly because I don't have a working LC at the moment.

I assumed that this function was possible because the LC and Classic shared components (so in the LC with dedicated VRAM it does color, but in a Classic without VRAM it does monochome), but apparently this wasn't the case; though similar, the video chips are different between the two models. So why did this function exist? No idea. Maybe for testing? This is one of the reasons I was curious as to why Apple used so many custom chips. If you already had a chip that can do what you need it to, why build another one that's only slightly different? Seems kind of a waste.

68040 PDS might be another kettle of fish. Doesn't the 68040 require external arbitrators to handle different-width peripherals? (I kind of thought that was one of the reasons why Apple was so much in the business of using 68040->68030 bus bridge chips in so many cheap-o desktop and Powerbook models...)
IIRC there's a blurb in the 68040 UM about a dedicated Motorola chip that you can implement in your design that basically does this, possibly by acting as an '030 bus interface bridge. 

I'd still like to know why Moto decided to abandon the byte steering and dynamic bus sizing features in the '040. They were useful features and I doubt Apple was the only one making use of them.

 

Trash80toHP_Mini

NIGHT STALKER
The Zorro II bus on the Amiga is pretty much a direct pinout of the 68000 (24-bit address bus) plus a bus arbitration chip called Buster to handle DMA. Zorro III upgraded this to 32-bits all around and expects a 68030 or 68040.
Sounds about right, Zorro II = SE PDS (with multiple slots?) and Zorro III = SE/30 Multislot PDS. Why did Commodore not use slots with mor pins rather tha going the multiplexing route. Seems overly complicated for no apparent reason from the start. They could have used a slot extension like the PC or a more capable, higher density connector like EuroDIN?

DMA was damn cool at that time in that market segment though. Protected memory? Not at all familiar with Amiga.

 

Trash80toHP_Mini

NIGHT STALKER
The biggest challenge is finding a development board with enough IO brought out to connectors to interface with the 680x0 bus.   I don't  think there is one.    A custom board would be needed.   And someone or some service would have to solder down the multi-hundred pin BGA FPGA.
Again I'm wondering just ho many address and data lines need be implemented for 8-bit/16-bit/24-bit Video cards? Am I wrong in my guess that along with most(?) control signals you'd need only 24 data lines and 5 address lines for a 24-bit VidCard implementation?

The Radius Pivot LC manages to output some-resolution-or-other from half the 68020 I/O bus.

s-l1600.jpg.616d045d972284fa8a2a188a72abad57.jpg


edit: the Pivot would also be half the 68030 bus in LCIII Q605/LC475, the Quadra 630 and all its descendants that used the LCIII PDS. NICs for the entire series never crossed over to the 32-bit side of the split LCIII split connector AFAIK. Was there a 16-bit Vidcard for that slot and did it need to use the LCIII slot extension?

 
Last edited by a moderator:

Gorgonops

Moderator
Staff member
Am I wrong in my guess that along with most(?) control signals you'd need only 24 data lines and 5 address lines for a 24-bit VidCard implementation?
Yes, you're wrong. The VRAM is addressed as a chunk of memory so you need at minimum the same number of address lines as accessing that much RAM would take. So for a 1MB VRAM card you'll need to decode at least 20.

(On the memory buffer side you'll only need half that many if you're using DRAM with row/column multiplexing, but the PDS bus doesn't do that.)

 

Trash80toHP_Mini

NIGHT STALKER
So how many lines are necessary to address enough VRAM to do 720p @24-bit?

edit: are we barking up the wrong tree with a standard FPGA development board engine? Do any graphics chipset developers have a hardware/software development kit that would be more suitable for massively parallel(?) throughput or is any other type of programmable logic available? Might FPGAs be used in parallel on a custom board that might be produced for applications requiring high numbers of DIO pins? Dearth of DIO pins appears to the bane of development in the Pi world.

I'm out of my depth entirely at this point. I've got all three levels of the card development docs in my head w/o the knowledge base to make sense out of or really do anything with it that's more than rudimentary. Never figured I'd have need to delve into Inside Macintosh and not at all sure I could deal with it? I hope pointing out the layered nature of Developing Cards and Drivers series was a good enough contribution. iLost! :blink:

If anyone could search Inside Macintosh and the Developer CD series for TOBY Card PAL Listings I think finding them anywhere would be a big contribution. If we can get the well documented TOBY card up and running as "PDS hardware" in an emulation environment I feel that would be a huge first step forward, but what the h**l do I know? :mellow:

 
Last edited by a moderator:

Franklinstein

Well-known member
Again I'm wondering just ho many address and data lines need be implemented for 8-bit/16-bit/24-bit Video cards? Am I wrong in my guess that along with most(?) control signals you'd need only 24 data lines and 5 address lines for a 24-bit VidCard implementation?

The Radius Pivot LC manages to output some-resolution-or-other from half the 68020 I/O bus.

edit: the Pivot would also be half the 68030 bus in LCIII Q605/LC475, the Quadra 630 and all its descendants that used the LCIII PDS. NICs for the entire series never crossed over to the 32-bit side of the split LCIII split connector AFAIK. Was there a 16-bit Vidcard for that slot and did it need to use the LCIII slot extension?
I'd figure the video controller would be responsible for the pixel depth, since it could have a wider 24 or 32-bit memory bus on the card compared to the 16-bits available through the LC PDS slot. For example, there was a Lapis ProColorServer 24-bit LC video card on eBay recently. Like the Radius card, it's only a 16-bit LC slot interface. There were very few 32-bit LC III PDS cards developed; I don't remember ever seeing one in person. I assume most of the ones that did exist were video cards or accelerators.

 
Top