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

Development of Nubus graphics card outputting to HDMI?

Franklinstein

Well-known member
A quick tidbit regarding the LC PDS:

Originally designed for the LC and its 16-bit system bus, this connector was built to directly interface to the 68020 at 16MHz. The LC PDS also included audio and FPU present pins in addition to a handful of others to allow the use of cards with some sound capabilities (specifically the IIe card) and to install an FPU in a machine where a socket was not present on the logic board, an example of which is shown in the picture of the Radius Pivot video card above and also familiar to people with early LC PDS Ethernet cards.

The LC II kept the 16-bit system bus and clock speed, the only change being a move to the '030, but since they shared the same bus protocols, the LC PDS still operated exactly the same as in the LC. This is also true of the Color Classic, which was essentially a slightly redesigned LC II logic board in a compact case.

The LC III (and III+, Color Classic II, Performa 520, 550, and 275, all the same basic architecture) changed things a little: the system bus was now 32-bits wide, but thanks to the 68030's dynamic bus sizing feature, a legacy 16-bit LC PDS card can be installed with no problems. Because the system bus was now 32-bits wide, a small extension to the original LC PDS slot was added that provided the signals to expand the slot up to a full 32 bits. Now known as the LC III PDS, this extended slot became Apple's standard low-end expansion slot across their entire consumer line for about 4 years, with (most) cards originally designed for the LC able to be used in up to a Power Macintosh 53/63xx series machine. Of course, after the switch to the 68040, the LC PDS is no longer a true PDS: it resides on an '040-to-030 bridge chip of some sort, and depending on which computer it's in. These psuedo-PDS slots also ran at a fixed 16MHz whether they were 16 or 32-bits and regardless of the system bus speed of the computer. The original Comm Slot is basically an LC PDS in a different form factor, with both running at a fixed 16MHz off of the '030 bridge chip.

What I'm not entirely sure about is whether the LC/LC III PDS was always clocked at 16MHz, even in the LC III and III+ where the system bus is 25 or 33MHz respectively. ISTR that it was stated in some of the Apple dev material that it is always fixed at 16MHz, but I don't know how it's achieved: the LC III PDS is still directly connected to the processor's pins in the LC III and III+ with no buffers or arbitration devices in between. 

 

Gorgonops

Moderator
Staff member
So how many lines are necessary to address enough VRAM to do 720p @24-bit?
Actually, I realized I kind of lied when I said you needed 20 address lines for 1mb... *if* you were using 32 bit wide memory. In that case you'd need 18 address lines. (Since your 1mb would be organized as 256 kilowords.) Not that it makes much difference. Anyway... since 720p 16x9 is just under a megapixel for 24 bit you'll obviously need about 3mb of RAM, so... still talking 20 lines.

My vague thoughts on this problem of affordable FPGA boards not having enough I/O to decode both the PDS/Nubus slot *and* a control bus for a RAM bank actually sort of boil down to, well, okay, so don't do it all in the fpga. Just spitballing here: use the FPGA to handle the output circuitry and timing generation, implement the bus decoding with some simple PLDs, and do address generation with a couple binary counters. (Which are choreographed by the FPGA, along with the bus contention signals.) Offload the bus decoding and effectively multiplex a few control signals into your 20-something line RAM address bus with the counters and I see you getting away with, I dunno, maybe as few as around 50 I/Os on the FPGA proper? Not to handwave excessively, but this is essentially how a real mid-90's level of integration card would work.

I'd also suggest using plain old SRAM instead of DRAM for simplicity. 4MB of it, which should be ample, isn't going to cost that much.

 
Last edited by a moderator:

Trash80toHP_Mini

NIGHT STALKER
Yay! You guys have broken it down to the my toddler building block playtime on the floor level again! [:)] FPGA is up on the adult's train set build level, the board looks like a bog magical black box from down here.

On the NuBus conversion of the PDS development board front:

Check out the first chapter in Designing_Cards_and_Drivers_for_the_Macintiosh_II_and_SE_-_1987 for the NuBus primer. It describes the first rev, discrete logic implementation of NuBus (pre-NuChip) in the first release Macintosh_II. Breaking the NuBus block out to its basics for logic analysis and PAL raid missions on the Mac_II.1 Logic Board is the current line of investigation in the age old SE/30/NuBus project. Treating that discrete logic as a black box for the Model T performance NuBus version of the proposed Indy Brick Yard Roadster performance PDS dev board seems the thing to keep simmering on the back burner.

@Franklinstein very glad to hear tell of that 16-bit/24-bit VidCard for the LC Slot! Such would be a great first look at the discrete PLD/SRAM FPGA feeding funnel proposed by @Gorgonopsabove.

 
Last edited by a moderator:

Gorgonops

Moderator
Staff member
I'd also suggest using plain old SRAM instead of DRAM for simplicity. 4MB of it, which should be ample, isn't going to cost that much.
Just to note, I did do a quick look for parallel high-speed SRAMs, and maybe "that much" is a matter of degree. For chips that can be hand soldered (vs. BGA) you're probably looking at around $7-10 a megabyte. That's peanuts compared to what it cost once upon a time, but I know how people in this particular corner of the hobby freak out at the thought of spending money for new build stuff...

 

Trash80toHP_Mini

NIGHT STALKER
Yeah, there is that. ::) But if you put NuBus and Zorro II/III multiplexing layers into the same black box for later wouldn't you be opening development up to a much less stingy, more technically oriented hobby freak population with a far more advanced retro-dev cult? That's part of what I thinking of (along with enlistment of the emulation gang) as insane levels of collaboration.

Implementing this proposed VidCard at that 16-bit input/24-bit output LC board level would be exactly what's needed for the VidCard Project to branch off to 16-bit PowerBook VidCard, LC, CC & Co. expansion interfaces.

< ridiculous tangent mode? >

Keeping the single Slot ID decoding model of the Futura IISX VidCard/NIC Daughtercard would something to put a'simmering on the other back burner. The LC Slot Macs (and to a point, the IIsi/SE/30 twins) are in need of a dual purpose expansion card. 100bT/WiFi antenna and 24-bit 720p HDMI out the backplane slot cover of a CC or Quadra 605 anyone? [}:)]

< /ridiculous tangent mode? >

edit: not to get too ridiculous here, but designing to a form factor compatible with the smaller of 190/5300 or 1400 video cards would be a great pie in the sky miniaturization goal. If nothing else, keeping it to a form factor compatible with the LC spec and the Blackbird PDS spec seems the thing to do. Out of my depth again here, but would keeping I/O to that 16-bit bottleneck put the proposed VidCard on a PCMCIA card as well? Just spitballin' here as well as in the tangent above, but there are backplane PCMCIA Slot conversion cards for all manner of retro toys, including TAM applications as well as the PC and Amiga crowds.

 
Last edited by a moderator:

Trash80toHP_Mini

NIGHT STALKER
 @trag here are a couple of part numbers and a logo for that 68040 PDS connector. One is on what may be a handy edge card interface for a prototyping board adapter?

68040-PDS-Connector-DevBoard-Adapter-1.JPG

D5527 is on a 6100/DOS Card Adapter? H3489 is on a Quadra 610 riser? Add H1573 as the part number on the connector of one of my Quadra 700 boards.

 @dlv it's not the crisp 1080p HDMI output of your dreams, but I'm wondering what speed differential there might be between 720p on 16-bits of your Quadra 950's PDS vs. its internal video? I'm all but certain it'd beat the snot outta the NuBus Card you said you wanted to stick in there. [;)]

 

nickpunt

Well-known member
I was the one that picked up the 24bit LC Lapis ProColorServer on eBay recently. Let me know if you need to know anything about it. It works, I just can't get the extension to load.

 

Trash80toHP_Mini

NIGHT STALKER
You find all the best bits nic! I was just looking through the NuBus in SE/30 reboot you kicked off for applicable goodies here. That card is a fabulous conquest. From my vantage point getting a new tech version of it hooked into the NuBus Test Card's bits will wind up being the row to hoe at some point. For now, ramping that 16/24-bit 020 PDS design example to the three slot capable 030 PDSwould be the thing to accomplish. Dumbing it back down to the single $E interrupt 020 LC PDS will be a walk in the park by comparison. Interfacing with NuBus will be complicated, but a lot easier than dealing with it during basic hardware development.

I'll think about posting reference materials I've put together here and there in a unified bus theory thread. There's way to much and most of that discussion that data will be tangential, but important for this feasibility study. Patching a block diagram together from 680x0 to the discrete component implementation of Macintosh_II.1NuBus onto NuBus and breaking it out to the Macintosh II Video Card (TOBY) with or without the NuBus Test Card's well documented PAL (code and listings) would put it all on one annotated page. That and second page with the 680x0 PDS block diagram of same for comparison will be a neat thing to develop. [:)] It annoys me no end the way Apple presented the Cards and Drivers documentation in seemingly unrelated chunks. One fully documented example for building working card wold have been nice.

Got HiRes pics of that puppy to post yet, nic?

 
Last edited by a moderator:

dlv

Active member
Hi - It’s a busy weekend so I haven’t had a chance to read or do much more research but on Friday evening, I think I found a cheap ($20) Chinese FPGA board on eBay that is comparable to the miniSpartan6+. It doesn’t have an HDMI port, so that will need to provided by the carrier board. That shouldn’t be any harder than the circuitry necessary to interface with PDS. In fact, I seem to recall from the VA2000 schematic, that the pins of the FPGA are just wired directly to the HDMI pins. 

I’m totally happy to pay $20 to experiment with this FPGA board. I think a great first step would be to wire an HDMI connector and see if I can get it to output something. 

 

johnklos

Well-known member
[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]
Very, very interesting... I just recapped an LC II board and tested it with VRAM installed. I'm going to give it a try without.

 

Trash80toHP_Mini

NIGHT STALKER
Despite my position that 030 PDS development should be the first step, research on translation of that 030 PDS design to NuBus as stage two should be done at the same time. Maybe dedicated, paired threads for the two stages linked back to this topic would be better than just the one?

How the Macintosh II Nubus Works -  Second 1988 Mac Special Edition • B Y T E - software developed in their NuBus card build might be available?

Developing For The Macintosh NuBus-CERN-CM-P00062891 - its list of reference materials is invaluable. I've been searching documents on the list. Those easily found online crossed off:

Inside Macintosh

Volume I

Volume II

Volume III

Volume IV - listed as having relevant information

Volume V - listed as indispensable and I've not found it yet

X-Ref

IEEE 1196-1987 - Standard for a Simple 32-Bit Backplane Bus: NuBus - withdrawn in 2000 so this may be difficult to come by - https://standards.ieee.org/standard/1196-1987.html

Nubus Designer's Workbook for the Mac II from Eclipse Technology, Inc - commercial publication, https://isbnsearch.org/ was no help,probably doesn't have one. Need used book source?

That's what I've put together so far. The gang at Mac OS9 Lives has posted an excellent listing of the Developer CD Series: ADC Developer CD series (1991-2002) ISTR the first one being important to this project for whatever reason, but I lost the reference for why. Possibly error corrections, hopefully with additional NuBus development information:

Developer Helper Volume 1: Phil and Dave’s excellent CD

 
Last edited by a moderator:

Trash80toHP_Mini

NIGHT STALKER
Still thinking about eventual PDS to NuBus conversion:

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.
From the IEEE spec, NuBus only requires 48 lines outside of power and ground. IIRC Apple hardwired some connections IRQ for mobo/board(?) and four Slot ID lines for card. The latter could be fielded off FPGA and passed on to it in sequential reads on a single line at startup? A few control lines will likely not be required for a video card. If we keep within the 16-bit data bus constraints on nic's 24-bit LC Lapis ProColorServer that also stays within PowerBook I/O bus spec.

Actually, I realized I kind of lied when I said you needed 20 address lines for 1mb... *if* you were using 32 bit wide memory. In that case you'd need 18 address lines. (Since your 1mb would be organized as 256 kilowords.) Not that it makes much difference. Anyway... since 720p 16x9 is just under a megapixel for 24 bit you'll obviously need about 3mb of RAM, so... still talking 20 lines.
If that's the case, we're talking about using only 20 of the 32 multiplexed address/data lines of NuBus, no? That could save another 12 I/O pins on the FPGA, no?

My vague thoughts on this problem of affordable FPGA boards not having enough I/O to decode both the PDS/Nubus slot *and* a control bus for a RAM bank actually sort of boil down to, well, okay, so don't do it all in the fpga. Just spitballing here: use the FPGA to handle the output circuitry and timing generation, implement the bus decoding with some simple PLDs, and do address generation with a couple binary counters. (Which are choreographed by the FPGA, along with the bus contention signals.) Offload the bus decoding and effectively multiplex a few control signals into your 20-something line RAM address bus with the counters and I see you getting away with, I dunno, maybe as few as around 50 I/Os on the FPGA proper? Not to handwave excessively, but this is essentially how a real mid-90's level of integration card would work.
Wondering here if more of the NuBus interface might be handled on the FPGA given possible reductions above? My reason for thinking that wouldn't work would be need to dump 32 bits of data from the SRAM thru the FPGA at output time? Gotta ask though. Not that important a consideration here as board size won't be any problem at all for a NuBus implementation. Connector and backplane placement require a minimum PCB size that's quite large.

I'd also suggest using plain old SRAM instead of DRAM for simplicity. 4MB of it, which should be ample, isn't going to cost that much.
Definitely sounds like the way to go any which way, speed and refresh complexity alike.

Just to note, I did do a quick look for parallel high-speed SRAMs, and maybe "that much" is a matter of degree. For chips that can be hand soldered (vs. BGA) you're probably looking at around $7-10 a megabyte. That's peanuts compared to what it cost once upon a time, but I know how people in this particular corner of the hobby freak out at the thought of spending money for new build stuff...
Is SRAM in BGA packaging smaller in footprint a/o cost? Thinking here about miniaturization of the PDS design for use in PowerBooks. Would BGA parts for SRAM and FPGA reduce size requirements a/o automated assembly costs? Assembly cost would also apply to PDS and NuBus implementations. Hand soldered assembly for prototyping and production of boards would be one thing, production boards another and something to keep in mind. At this point we're talking carrier board/off the shelf breadboard oriented FPGA unit.

< /WAG and spitball mode >

 
Last edited by a moderator:

Gorgonops

Moderator
Staff member
That could save another 12 I/O pins on the FPGA, no?
No. If data and address are multiplexed on Nubus then you'll need 32 lines for that function on Nubus, and *completely separately* you'll need data and address lines for your VRAM bank. (Assuming you've decided to do the bus interface and the 'video card itself' on the same FPGA.) It kind of seems to me you keep conflating the *computer's* address and data lines with the separate needs of the video hardware's address generation and refresh circuitry.

Remember, technically speaking how you arrange your VRAM is completely arbitrary as long as whatever you come up with is in aggregate fast enough. If your target is a 4MB framebuffer (which covers 2^22 addresses), you could spend 32+22=54 lines between data and addresses for a 32 bit wide channel to a simple non-multiplexed bank of SRAM, or, if it's fast enough for your needs, in theory you could get away with, I dunno, 19 lines, for an 8-bit wide bank of RAS/CAS-addressed DRAM? (11 lines for RAS/CAS and 8 data lines. Obviously you'll need a few more in either arrangement for control signals.) The latter is a perfectly feasible arrangement as long you find DRAM that can cycle fast enough to answer the refresh needs of the display with enough left over bandwidth to allow the CPU read/writes to happen without excessive latency.

 

Trash80toHP_Mini

NIGHT STALKER
Nope, if only 20 of the multiplexed lines are utilized for NuBus transactions from a card the others can be held at whatever state, they're null in both states. NuBus can also act in 16-bit mode if necessary, unless Apple borked that part of the spec as well.

 

trag

Well-known member
In one of the old threads where I discussed this ambition, I did a count of I/O lines needed with some options.  But, I was focused on PDS cards.   Again, I don't think you'll see any meaningful improvement in performance over mid to high end NuBus cards of old with a new NuBus card, no matter how shiny the RAM and FPGA.  The bandwidth of NuBus is just too much of a bottleneck.

With PDS, there's something close to 80 lines needed for the CPU interface.   You could cut that down a little by using external logic on the higher address lines and a control signal, but I envisaged a system that would address a DDR2 DIMM, which meant a video card to start but a RAM/RAMDisk replacement/system later.     At the time DDR2 was the cheapest bang for buck memory.  And a single DIMM meant that at least 512MB of RAM would be sitting there for use.

Now, the Spartan replacements (or are they new Spartan lines?) have multiple DDR2 controllers embedded on the chip.  Advantage, one doesn't have to muck about with dropping in code for it.   Disadvantage, one can't take modular code and expand it to DIMM width like you could on the old systems.   Advantage, any development system for that generation is already going to have a 16 bit wide DDR2 DRAM chip on board, so the IO are already routed and the memory chip is already present on the development system.

Get one of those development systems and the memory is already there, albeit, only 16 bits wide.  Every 32 bit transaction will take two 16 bit transactions, but since DDR2 usually has a minimum burst size of 4 this doesn't create a performance issue*.   You just need PDS lines and some way to do video out.   However, there still aren't enough I/O lines on most development systems to get a PDS interface going.

While DDR2 has a ton of latency, it runs crazy-fast compared to the old machines.   At 200/400 MHz, even if you need 6 cycles to execute a read or write, you can still get back to a 25MHz bus in one cycle with an acknowledge.   And that's ignoring buffered write schemes where you just immediately tell the  host it's done, while you finish the house keeping.

I see the attraction of SRAM though.   It's a lot simpler.   I've programmed assembly language firmware drivers for DDR2, so it's complexity doesn't worry me.

*Getting transactions started in DDR2 is where the biggest performance challenge is, latancy.  Once the transaction is going, getting 2 words or 4 words vs. 1 word takes almost no extra time relatively speaking.  Especially when one considers that the DDR2 is operating at 200 - 600  Mega-transactions per second and the host bus is only running at 16 - 25 MHz.

 
Top