Jump to content
dlv

Development of Nubus graphics card outputting to HDMI?

Recommended Posts

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. 

Share this post


Link to post
Share on other sites
On 3/8/2019 at 5:21 PM, Gorgonops said:


The Macintosh LC is shipped with 256 KB or 512 KB ofVRAM (video RAM). With this configuration, main memory is not used for storing video data. If VRAM is not installed, it is possible to use main memory for video storage, though it is not recommended. With this configuration, main memory can only support the 640 x 480 monochrome video mod

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.

Share this post


Link to post
Share on other sites

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

 

Edited by Trash80toHP_Mini

Share this post


Link to post
Share on other sites

Still thinking about eventual PDS to NuBus conversion:

 

On 3/8/2019 at 1:16 PM, trag said:

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.

 

On 3/9/2019 at 1:46 AM, Gorgonops said:

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?

 

Quote

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.

 

Quote

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.

 

On 3/9/2019 at 11:36 AM, Gorgonops said:

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 >

Edited by Trash80toHP_Mini

Share this post


Link to post
Share on other sites
14 minutes ago, Trash80toHP_Mini said:

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
9 hours ago, Trash80toHP_Mini said:

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.

Maybe you need to draw me a picture to explain what the heck you're talking about. If you're trying to share the same lines between the Nubus interface and VRAM refresh you'll need to have separate buffers isolating those lines from the bus most of the time, and video refresh is going to *stop* when you're handing the memory bus over to Nubus. Or are you trying to say something else?

Also, unless I misinterpreted what it was saying Apple's development docs actually seemed pretty explicit about saying that if you're interfacing a peripheral that's less than 32 bits wide you have to handle bus resizing on the card, the bus as implemented on the Nubus Macs is one size fits all. (I recall some specific verbage about the 68030's built-in bus sizing magic not applying to Nubus cards *and* that not being implemented natively on the bus itself.)

 

8 hours ago, trag said:

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.

Yes, the SRAM suggestion was mostly a suggestion for keeping as simple as possible if you decided to split the bus interface circuitry from the video refresh circuitry. (IE, using some PLDs or whatever for the Nubus/PDS glue "south" of the memory bank and an FPGA for the video generation.) Arbitration for that scheme would be pretty simple. But if you're going to let the FPGA do it all using the built in DRAM interface might totally work, expecially if you can set up some sort of FIFO buffering to handle the latency.

Share this post


Link to post
Share on other sites
On 3/10/2019 at 9:39 AM, Trash80toHP_Mini said:
On 3/9/2019 at 3:56 PM, dlv said:

I think I found a cheap ($20) Chinese FPGA board on eBay that is comparable to the miniSpartan6+.

That's great news, inkage?

QMTECH's XC6SLX16 board available for sale from many vendors on eBay such as:

 

https://www.ebay.com/itm/XC6SLX16-Spartan-6-Xilinx-FPGA-Development-Board-w-Micro-SDRAM-Memory-32Mb/264229717341

 

You can find the schematics, documentation for the board and its components, and example code FPGA code, under their GitHub project for the board here:

 

https://github.com/ChinaQMTECH/QM_XC6SLX16_SDRAM

 

I chose this board because it is the closest to the miniSpartan6+ used in the VA2000 project:

  • Xilinix Spartan 6 LX16 (the miniSpartan6+ came in either LX9 and LX25; specs say the LX16 is closer to the LX25)
  • 32MB of SDRAM
  • 108 user I/O pins
  • SPI NVM for FPGA bitstream and ROM

For the proposes of this project, its only major shortcoming compared to the miniSpartan6+ is the lack of a built-in HDMI port but that could easily be provided by a carrier/daughter board. Of course, that means less than 108 I/O pins will be available for PDS/NuBus but there should still be enough?  There is a DDR2 version of this board but I want to reuse as much of the MNT VA2000 project as possible (including SDRAM controller code for the miniSpartan6+).

 

Anyway, I've been reading documentation of the three chips on the QMTECH board, understanding how it is all wired together, and comparing with the miniSpartan6+. The QMTECH board and Xilinx programmer are on their way. Baby steps... setup the development environment then see if I can program the board and blink some lights :) 

Edited by dlv

Share this post


Link to post
Share on other sites
11 hours ago, Gorgonops said:

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.

I was trying to ask if buffer and NuBus lines needed to be separate in figuring out how many lines mightpossibly be saved on the NuBus converted version.  The proposal I made for a 16-bit data/24-bit address, 24-bit color depth 720p LC VidCard development model (based on nic's card) has been  on my mind. It's an 020 PDS subset of the 32-bit IIsi/SE/30 PDS.

 

8 hours ago, Gorgonops said:

Maybe you need to draw me a picture to explain what the heck you're talking about. If you're trying to share the same lines between the Nubus interface and VRAM refresh you'll need to have separate buffers isolating those lines from the bus most of the time, and video refresh is going to *stop* when you're handing the memory bus over to Nubus. Or are you trying to say something else?

Nope, again, I'm not suggesting that.

 

8 hours ago, Gorgonops said:

Also, unless I misinterpreted what it was saying Apple's development docs actually seemed pretty explicit about saying that if you're interfacing a peripheral that's less than 32 bits wide you have to handle bus resizing on the card, the bus as implemented on the Nubus Macs is one size fits all. (I recall some specific verbage about the 68030's built-in bus sizing magic not applying to Nubus cards *and* that not being implemented natively on the bus itself.)

Not sure we're talking about the same thing. there was a mention of transfer modes in the BYTE article, but the CERN paper seems to be on point, it seems to do a good job of describing Apple's deviations from what became the IEEE 1196 Standard later in 1988.

 

______________________________________________________________________________________________________________________________________________________

 

p.18   Developing For The Macintosh NuBus-CERN-CM-P00062891


10.2 Non-aligned transfers

  

The NuBus interfaces of the Macintosh II family computers support all the non-alignment functionality of the 680X0 microprocessors. The interfaces generate multiple standard NuBus transactions with appropriate 680X0 dynamic bus sizing DSACK responses until the non-aligned access is completed. In addition to 680X0 longword accesses at odd addresses, non-aligned accesses are required for certain bit-field instructions which have 3-byte operands.

 

All non-aligned reads can be completed by a maximum of two NuBus transactions, since the additional bytes acquired by 32-bit word reads can be ignored by the processor. In the case of non-aligned writes however, up to three NuBus transactions may be required to split a 680X0 longword into component byte and halfword writes in the appropriate byte lanes. NuBus cards which can be accessed by non-aligned transfers must be able to support a full 32-bit read. In general, all RAM-like cards should support all NuBus data transfer types.

 

______________________________________________________________________________________________________________________________________________________

 

They stress the importance of 24-bit compatibility, Given the 16-bit data transaction limitation of LC PDS, The NuBus adaptation would need only handle 16 data bits using a couple less address bits than the 24 available in that transaction mode? So, is running the card/driver in 24-bit compatibility mode with a 16-bit data path a workable setup while the computer is running in 32-bit mode? Hope this makes some kind of sense? :blink:

 

 

On another note: there's no way a new NuBus VidCard will compete with the PDS version in terms of speed. Either the CERN paper or Byte article listed the maximum theoretical bandwidth limitations imposed by Apple's implementation of NuBus. It wasn't pretty.  Can't find it ATM, eyes are too tired. Can someone OCR those articles/Scan to PDF/whatever. Searchable text would be handy.

 

 

Anybody got a line on a source for Inside Macintosh Volume V?

 

Share this post


Link to post
Share on other sites
13 hours ago, Trash80toHP_Mini said:

They stress the importance of 24-bit compatibility, Given the 16-bit data transaction limitation of LC PDS, The NuBus adaptation would need only handle 16 data bits using a couple less address bits than the 24 available in that transaction mode?

 

There are still two different things floating around in your head that are sort of irreconcilable. Yes, Nubus supports byte and halfword transfers. (And unaligned transfers, which on the Motorola 68k are a fact of life because even though the 68000 architecture was designed as a "32 bit" ISA the original implementations were effectively 16 bit CPUs (one variant of which actually had an 8-bit bus) and instructions can therefore be aligned "off" from 32 bit words. x86 has the same issue. So any bus for these systems needs to be able to handle the situation.) Here's the thing about Nubus, though: *by definition* it always uses 32 bit multiplexed data/address words. You can't run a "24 bit subset" of it even if your plan is to only land a 16 or 8 bit peripheral that only needs some subset of the address lines. "Unaligned data support" simply means that if a read/write is split on an awkward non-word border it's smart enough to do two bus cycles and use the correct byte lanes to complete the transaction, instead of just losing half the transaction.

Let's go crazy here and pretend that you're intending to stick something like a Motorola 6821 PIA on a Nubus card. This is an 8-bit chip that has two 8 bit parallel ports and two sets of control registers. This effectively means that on an 8-bit computer you need 2 "address lines" to select between the I/O ports and the control registers. (Obviously this does not include the address lines you need to decode the memory address at which the chip actually resides in the address space, but let's pretend we're doing this in something like an Apple II that has pre-decoded slots that give you a "this line is active if this card is supposed to be" line; I believe Nubus in the Mac also has this, which makes "simple" Nubus cards a little more straightforward to build than, say, ISA cards, which do have to have full address decode on them.) What that document is saying about "narrow cards" (which technically is a different issue from 'non-aligned transfers') is that, sure, with our incredibly brain-dead 8 bit card we can take some shortcuts and effectively not care about the upper 24 bits of data we get from *either* the address or data cycles of the multiplexed Nubus lines if we place the PIO's data lines on the correct side of a full 32 bit word and specify that when we're communicating with this chip we specifically address the parallel ports and registers on word boundaries. (IE, instead of the PIA occupying "32 bits worth" of memory address space it's going to occupy 128 bits.) This mechanism is explained on page 18 of that document you linked to, under the header "data byte placement". THESE SHORTCUTS SPECIFICALLY DON'T APPEAR TO APPLY TO RAM-LIKE CARDS, WHICH A VIDEO CARD IS.

Let's say you're sticking a video card with an 16 bit memory bus in a Nubus slot. You do not have the option of 32 bit word aligning a 16 bit RAM by declaring you're only using two of the four byte lanes, because that would effectively mean that every-other-halfword of the video buffer would be missing. Macintoshes expect packed linear framebuffers, and when they're doing a block copy, move, memory fill, whatever, they expect to treat the RAM on the video card just like it's main memory, IE, I can just copy this from here and splat it over there. I'm pretty sure this is where the comments about PDS having the advantage of working directly with the 68030's dynamic bus sizing mechanism come from in the Apple card development manuals; a Nubus card can declare in its declaration ROM that it's only 16 bits wide, which the Slot Manager will honor at initialization (IE, it'll know to do word-level hopscotch when reading the rest of the ROM and piece it together in RAM rather than trying to execute any code on it in place), but it doesn't actually flip any hardware bits that will automatically map full word writes to only use the two byte lanes you stuck your VRAM on, it'd be on you to write a unique video driver (and probably rewrite Quickdraw) to deal with your weird non-linear vide buffer. So unless there's something that says otherwise in the video card section it looks to me like that just flat out won't work, and if you want to have an 8 or 16 bit wide VRAM on a Nubus Mac you're going to have to do it by sticking a 32 bit buffer on the Nubus end and blocking the subwords into your narrow memory with additional cycles. This might not be a big deal if your VRAM can cycle massively faster than the Mac can (See Trag's comment about how fast the 16 bit DDR interface on some of these FPGAs can go), but this *does* pose a barrier to literally taking an LC-slot video card and adapting it to Nubus. Best case the card will run about half as if it were 32 bit, all else being equal.

I've gone through the Apple development documentation looking for more information about byte lanes and, again, I could be wrong but I don't any indication that declaring the card as "narrow" in the byte lanes specifier does *anything* other than affect how it handles the ROM (apparently even 32 bit cards like the Toby video card that's used as the video card example, and make no mistake, its VRAM is 32 bits wide, being composed of 8 or 16x 64kx4 RAM chips, might have an 8-bit declaration ROM). Every indication to me is that a RAM-like card (verses some sort of register/data port device) needs to be able to deal with 32 bit read/writes.
 

Share this post


Link to post
Share on other sites
5 minutes ago, Gorgonops said:

Nubus card can declare in its declaration ROM that it's only 8 bits wide, which the Slot Manager will honor (IE, it'll know to do word-level hopscotch when reading the rest of the ROM and piece it together in RAM rather than trying to execute any code on it in place), but it doesn't actually flip any hardware bits that will automatically map full word writes to only use the two byte lanes you stuck your VRAM on. So unless there's something that says otherwise in the video card section it looks to me like that

I'm thinking along the lines that though the card itself may "need to" field 32 bits of addressing for memory, the for that card can ignore that "requirement" in the hopes of finding more wriggle room for the decoding setup?

Share this post


Link to post
Share on other sites
30 minutes ago, Trash80toHP_Mini said:

I'm thinking along the lines that though the card itself may "need to" field 32 bits of addressing for memory, the for that card can ignore that "requirement" in the hopes of finding more wriggle room for the decoding setup?

No.

Here's where I think you're also a little confused: it feels like you think there's something "magical" about a "16 bit" card (like an LC PDS card) that can output 24 bit color, and that somehow matters to the CPU side interface bus. It matters *not in the slightest*. Only the output circuitry cares about 24 bit color, and the only aspect it cares about is that the backing store of RAM is fast enough to feed the output circuitry's (be that a DAC, a TDMS encoder, whatever) insatiable hunger for uninterrupted pixel data on a very strict timing schedule. The CPU interface bus could be a single-bit SPI bit-bang if that's all you have to work with, Honeybadger just don't care. The thing that kind of matters with Macs is the built-in video rendering system, Quickdraw, has specific ideas about what the framebuffer should look like logically to it, and it's actually a really simple requirement, IE, that the frame buffer appear to it as a continuous array of RAM with linear pixel arrangements, not some "weird" arrangement with bytes or words of VRAM scattered in non-linear chunks or weirdly interlaced, et al. (Which was actually really common back in the 80's.)

So, in a Mac, video RAM is "RAM", so a the constraint you face on the Mac side is the same as if you were making a RAM card. A "RAM Card" for 68030 can be 16 bit or, heck, even 8 bits wide, and it's completely a trivial affair because the 68030 has specific support for accessing narrower blocks of RAM exactly as if they were fully 32 bits wide; all you need to do is pull up a sizing line when the read or write is made and the CPU will happily and completely transparently-to-software do two or four bus cycles instead of one to read/write a 32 bit word into/out of a 16 or 8 bit wide block or RAM respectively. It's completely transparent, Honeybadger, IE, Quickdraw, just don't care, nor does it have to. The point about Nubus is that sizing mechanism is not in play, a RAM-like card has to at least fake being 32 bit.

Ironically this whole discussion is sort of pointless when you consider that Nubus actually just doesn't have that many lines, and depending on how we're intending to arrange our video card a Nubus version might require fewer FPGA I/O lines than PDS does. Nubus being multiplexed totally helps us here if we're planning to have the same FPGA handle the computer bus and the video RAM; The entirety of the 32 multiplexed data/address lines and all the control signals on a Nubus slot is only 51 pins, not counting grounds and power leads. For a 16 bit PDS video card with 4MB you're looking at at least 38-ish for just data and address, not counting any control lines *and* making the assumption that you can actually get away with partial address decode on PDS. (I'm not 100% sure on that? I though the PDS Macs all offered a slot enable signal that's lit up when the address range is inside some predefined slot area and thus you'll only need enough address lines for your VRAM range, but if I'm wrong about that then figure a full 48 bits for data/address.)

So, again, unless there's something I'm totally misunderstanding about this from page 95 of the 3rd edition "Designing Cards and Drivers blaw blaw":

 

Quote

In general, peer cards must be designed to support the maximum size of transfer that any of their peers are capable of supporting. In particular, a peer card that is designed to cooperate with the MC68020, MC68030, or Mc68040 microprocessor on the main logic board of a Macintosh computer must properly handle 32-bit (NuBus word) transfers. If such a card contains, for example, an Mc68000 and has a local bus that is naturally 16 bits wide, the card must provide the hardware support in its NuBus interface to handle such 32- bit transfers. This would involve doing two local bus cycles for each NuBus word request.

 

A card with an Mc68000 processor must make two NuBus halfword requests to satisfy an access to a NuBus word quantity (for example, a pointer value). A Macintosh computer properly responds to these two requests. The same instruction when executed by the MC68020, MC68030, or Mc68040 microprocessor makes one NuBus word request. If the card with the Mc68000 does not respond with the correct 32-bit quantity, the program obViously does not execute correctly.

 

You should clearly indicate in the card's documentation exactly which kind of card it is and what types of accesses it supports.

 

Memory devices, however, must support all transfer types except for block transfer; the devices should always respond with all 32 bits in the addressed NuBus word. This rule allows RAM cards to be used as if they were on-board RAM in order to support nonaligned transfers, 68020 bit-field instructions, 68030 caching, and so forth.

You are stuck. A Nubus video card needs to be 32 bit. Which may not be that huge of a deal when designing one from scratch, but is important if you're trying to adopt a 16 bit card for another bus.

Share this post


Link to post
Share on other sites

If this database information is correct, the University of Utah library has Volume V. I could check it out to be sure if you'd like. It's not far from me. If it's there I can make copies or scan select pages/sections.
aksnXg9.png

Share this post


Link to post
Share on other sites

Thanks, I was hoping !V and V were readily available online for anyone interested to peruse. I'm guessing I/II/III and x-Ref were released on developer CD and so are now available for download? Just ordered IV and V in paperback for less than $22 and they'll arrive this time next week. Something to thumb thru in downtime at work or to lull me to sleep.

 

9 hours ago, Gorgonops said:

Here's where I think you're also a little confused: it feels like you think there's something "magical" about a "16 bit" card (like an LC PDS card) that can output 24 bit color, and that somehow matters to the CPU side interface bus.

Not magical, just a sweet spot for development. If we might keep 68030 PDS development backward compatible with that 68020 PDS subset used in all LC slot Macs that would be the thing to do. Moving it to a NuBus slot doesn't seem all that daunting a prospect from what I've been reading all these years. However, as you pointed out this approach would pretty much cut performance in half as opposed to a full 32-bit NuBus implementation and that would be a big no-no. We might not want to hamstring a card for the IIsi/SE/30 PDS by adhering to the LC slot model either, especially if it will make it easier to move onto NuBus and the 68040 PDS.

 

A 24bit 720p VidCard design compatible with the 16bit video card connectors in 190/5300 and 1400 as well as the Blackbird PDS now  .  .  .  THAT would be magical!

 

I got stuck in a late Eighties, 8-bit ISA interface to a ROM emulator frame of mind. You could break it down and lash it up in the easiest possible manner in hardware and then smoosh it all around in the software to fix everything back up at the far end of the cable. Which would, of course, be pretty much what NuBus was intended to render obsolete.

 

Once again, thanks for the education, Eudi.

 

@trag did you take a look at those part numbers and the logo in the 040 PDS connector pic? I don't recognize that triangle maker's mark?

 

 

Share this post


Link to post
Share on other sites
54 minutes ago, Trash80toHP_Mini said:

 

I got stuck in a late Eighties, 8-bit ISA interface to a ROM emulator frame of mind. You could break it down and lash it up in the easiest possible manner in hardware...

For all its many faults ISA at least made good use of dynamic bus sizing. (A feature Intel retained in the 486, unlike Motorola with the 68040...) An 8-bit-only ISA card is automatically byte, not 16-bit word, aligned.(+++)

 

As I noted it is technically possibly to make *pretty stupid* 8-bit cards for Nubus too, if you're willing to write your driver to deal with the consequences of having your I/O ports word-aligned. It is simply not an option for video cards or other "memory-like" things.(*)

 

(*) I may be misremembering some details, but I vaguely recall a horror story written by a Linux developer who claimed he discovered when writing the driver for a Mac NuBus ethernet card which utilized a brain-dead 8 bit 3com(?) chip commonly used on XT cards that the card *did* use only 8 bits to access the 2k packet receive buffer. The result was that to empty it when you got the interrupt you couldn't just copy it in one swoop, you had to in the driver read the contents from every fourth address and reassemble it in system RAM the same way the slot manager reassembles 8-bit declaration ROM. (Writes to the transmit buffer worked similarly.) When I read that years ago I didn't really get why you'd build the card that way, but having read all this junk now I get it.

 

(+++) Edit: another note: VESA local bus, the closest to PC world had to 68040 local bus slots, also supported dynamic bus sizing. The extremely popular Tseng Labs ET4000 VGA chipset only had a 16 bit bus width for most versions but it could still perform pretty well when stuck on a 33mhz bus.

Edited by Gorgonops

Share this post


Link to post
Share on other sites

So, let me get this straight: in practice, a video card for one of these Macs is, from the Mac's perspective, a RAM expansion that includes one or more frame buffers, and then components that read those buffers and sends them to a display? And that expansion attaches to the rest of the system through either Nubus or PDS? Does the video card have any other necessary responsibilities?

 

Is it possible to make bare minimum hardware that uses internal RAM as the framebuffer like the IIsi? Obviously it's most likely worth *not* doing that, just getting my head around the problem space.

 

What is QuickDraw acceleration, and how hard would that be to implement? I take it we'd need to include a coprocessor (obviously might be same chip, but logically, anyhow) that implemented Atkinson's calls directly instead of just telling the Mac that the framebuffer is over here and letting it figure that out? Would we patch the QuickDraw in ROM to do that?

 

How much does the Declaration ROM do vs. a system extension like many of the contemporary cards needed? How much external display support is built in?

 

edit: to be clear, I'm just making my research questions public, if no one knows all this off the top of their heads I'll be poring through the documentation provided anyway, but I'd appreciate the answers as well.

Edited by modulusshift

Share this post


Link to post
Share on other sites
1 hour ago, modulusshift said:

So, let me get this straight: in practice, a video card for one of these Macs is, from the Mac's perspective, a RAM expansion that includes one or more frame buffers, and then components that read those buffers and sends them to a display? And that expansion attaches to the rest of the system through either Nubus or PDS? Does the video card have any other necessary responsibilities?

Yes and none that I can think of offhand.

 

Quote

Is it possible to make bare minimum hardware that uses internal RAM as the framebuffer like the IIsi? Obviously it's most likely worth *not* doing that, just getting my head around the problem space.

Dunno if it's possible, but you're right about *not* doing the unthinkable from the perspective of bandwidth. IIsi setup is called Vampire Video because it sucks the blood out of system memory along with the performance levels of much greater throughput of dedicated (double ported?) VRAM.

 

QuickDraw acceleration is beyond my ken, but I'd think a concurrently running development project for a second version of the VidCard would be dynamite

 

Quote

How much does the Declaration ROM do vs. a system extension like many of the contemporary cards needed? How much external display support is built in?

DeclROM set a board up at startup and contained the drivers for a VidCard at the same time so you could see happy/sad Mac machine state indication and then watch the system extension icons load/fail to load as they're read from disk.

 

Quote

edit: to be clear, I'm just making my research questions public, if no one knows all this off the top of their heads I'll be poring through the documentation provided anyway, but I'd appreciate the answers as well.

Making any and all questions public seems like the true path to enlightenment to me. Heck, my silly/misguided questions about saving I/O lines on a NuBus implementation helped G understand something wondered about back in the day. In that light,"reading "all this junk" and playing ping-pong with the tidbits that stick out would seem to be the point.

 

 

 

edit: the first Meg of IIsi memory is dedicated/buffered from main memory so its contents can't be stepped on while it's acting as the internal video's frame buffer. Now I'm wondering if hardware buffering would have been required if the Mac OS had had a protected memory setup?

Edited by Trash80toHP_Mini

Share this post


Link to post
Share on other sites

My "off the top of the head" answers. Your mileage my vary:

 

1 hour ago, modulusshift said:

So, let me get this straight: in practice, a video card for one of these Macs is, from the Mac's perspective, a RAM expansion that includes one or more frame buffers, and then components that read those buffers and sends them to a display? And that expansion attaches to the rest of the system through either Nubus or PDS?

For a dumb framebuffer card that's about the size of it.

1 hour ago, modulusshift said:

s it possible to make bare minimum hardware that uses internal RAM as the framebuffer like the IIsi? Obviously it's most likely worth *not* doing that, just getting my head around the problem space.

Definitely not with Nubus, it'd just be too slow and high-latency. It might be a *possibility* on 68030 or 68040 PDS, at least for a very low-res card, but it would be nontrivial. (This is the sort of thing you really want built directly into the system chipset's RAM controller.)

1 hour ago, modulusshift said:

What is QuickDraw acceleration, and how hard would that be to implement? I take it we'd need to include a coprocessor (obviously might be same chip, but logically, anyhow) that implemented Atkinson's calls directly instead of just telling the Mac that the framebuffer is over here and letting it figure that out? Would we patch the QuickDraw in ROM to do that?

I'm too busy at the moment to Google for them, but I know there are several good articles out there that go into *reasonably* comprehensive depth about how Apple's 8*24GC accelerator worked, and it's basically the model for the breed. I don't know if there's strictly enough there to just sit down and start writing an extension for whatever hardware you stick on the card, but it's definitely a start.

 

(The 8*24GC used an AMD 29000 CPU on it, which was a general purpose RISC CPU that wasn't especially optimized as a graphics accelerator; its most common application for its relatively short market life was as a laser printer CPU. The 29000 family is stone dead so *replicating* the 8*24GC and using the same drivers probably isn't in the cards, but its architecture suggests some common modern CPU like ARM would be able to do the job just fine.)

 

23 minutes ago, Trash80toHP_Mini said:

 

Quote

How much does the Declaration ROM do vs. a system extension like many of the contemporary cards needed? How much external display support is built in?

DeclROM sets the board up at startup and contained the drivers for the card at the same time so you could see the happy/sad Mac machine state and then watch the system extension icons load/fail to load as they're read from disk. 

According to my reading of the docs strictly speaking a "dumb" video card doesn't have to have a "driver" per se in the declaration ROM, it only needs a bunch of resources that inform the built-in "Generic framebuffer support" in Quickdraw about the specific modes supported by the card and how to switch between them. It's not clear to me that any of this needs to be executable code.

This is for basic support, of course. I think even some "dumb" cards still required extensions to control some more advanced features? (Mode switching, refresh rate selection, etc?)

Share this post


Link to post
Share on other sites
1 hour ago, Gorgonops said:

According to my reading of the docs strictly speaking a "dumb" video card doesn't have to have a "driver" per se in the declaration ROM, it only needs a bunch of resources that inform the built-in "Generic framebuffer support" in Quickdraw about the specific modes supported by the card and how to switch between them. It's not clear to me that any of this needs to be executable code.

Quick answer to that would probably be found in the extended documentation of the TOBY frame buffer card for the Macintosh II. That appears to have been added in the third edition of DCaD after the discontinued TOBY frame buffer card was discontinued and no longer available to developers from Apple. I'd think providing drivers for the Macintosh II  in System ROM. Brain is moosh ATM, so:

 

TOBY-DeclROM-5.thumb.JPG.abdfd4c443d05a8641d412e84f2de5a1.JPG

 

TOBY-DeclROM-7.JPG.b4b3c6047731b9a697053321ea8623ad.JPG

 

 

 

TOBY-DeclROM-2.thumb.JPG.9336e31edbea9a79f945aaf5d1e19f68.JPG

 

Online PDF of DCaDftMIIaMSE is scan format, so I screen capped the DeclROM section, leaving off the "Card connectors" page.

 

edit: Resized second page to better match the first in picture flip mode.

 

Edited by Trash80toHP_Mini

Share this post


Link to post
Share on other sites

I've begun working on a schematic of the HDMI daughter board for the QMTECH FPGA, but I'm realizing that if I'm going to have PCBs made, it would make a lot of sense to wire in PDS (or NuBus), and save money and time... Guess I'll need to catch up and read the documentation you've all referenced. Stanford University (where I work) appears to have several of the "Inside Macintosh" volumes available, including one on QuickDraw, which I'm also curious about.

Share this post


Link to post
Share on other sites
On 3/14/2019 at 10:17 AM, Trash80toHP_Mini said:

Quick answer to that would probably be found in the extended documentation of the TOBY frame buffer card for the Macintosh II.

Yeah... and after reading that I realized that, wait, any video card beyond an extremely simple fixed-function framebuffer would probably require at least a bare minimum of driver code to initialize the video chipset; the registers for programming CRTC functions are not standardized by any stretch of the imagination, so unless the card was hardwired to come up in a usable video mode *and* there was no reason to ever switch modes then, yes, you'll need a driver to handle that.(*)

(* I'm curious if the "stub" declaration ROM that's inside of an SE/30 has any driver code in it, because its video hardware actually basically fits this description.)

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×