Jump to content
dlv

Development of Nubus graphics card outputting to HDMI?

Recommended Posts

9 hours ago, Gorgonops said:

Yeah... and after reading that  .  .  .

Reading what? MooshBrain mode had me neglecting to say that the "extended documentation" on the Macintosh II Video Card (TOBY?) was in DCaDftMF3e. The screencaps I posted wer from DCaDftMIIaMSE with a reference to dri9ver development in Chapter 9 of same.

 

Took a quick gander at both and it looks to me that all video mode settings are stored in DeclROM along with drivers for anything necessary. The Mac side consists of only the Monitors Control Panel remembering which video mode was last chosen and booting the system into that mode in single bit for Happy/Sad machine state indication before System/Drivers ever begin to load from disk. Presumably with a default setting of 640x480 for any worthwhile card at whatever silly frequency and 60Hz in the case of the proposed new development card.

 

Quote

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

The driver setup for any mode would reside in DeclROM per above with the Monitors Control Panel handling any mode switching. It looks like the only real purpose of coding an INIT for a card is to override whatever resides in DeclROM that may have become obsolescent.

 

This jibes with all my long experience with VidCards, NuBus and PDS. I've never NEEDED to load a driver to get basic function, most of the time at all resolutions/bit depth settings listed as available for any given VidCard. I'm sure a few exceptions have slipped through the cracks in my slowly crumbling mind, but the observation stands as a good rule of thumb.

 

Looking forward to having Volumes IV and V of Inside Macintosh arrive next week to confuse the crap outta me with info on driver coding. 8-o

 

< beats head on KBD in frustratiohn >

 

sad;lagjn;lrkg;oaerht;kjearhtk;jwe4ht;iowhaerfo[u3q4['otij34qlktn;qk34th;q3i4io;hg2q34jr'q23jh4rthq

Edited by Trash80toHP_Mini

Share this post


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

driver setup for any mode would reside in DeclROM per above with the Monitors Control Panel handling any mode switching. It looks like the only real purpose of coding an INIT for a card is to override whatever resides in DeclROM that may have become obsolescent.

Read the section you quoted carefully. It's pretty clear that there is, on a typical card,  a "driver" stored in the declaration ROM, along with initialization code. There's not much to this driver, but it's there to translate the "generic" mode setting API calls made by the system control panels, et al, to the actual register tickling that has to happen to program the video hardware to display the requested mode. As I noted in my previous "oh yeah" post this makes sense: different video hardware might use radically different methods. To do without some kind of driver code (ie, make initialization/modesetting at boot completely a high-level message passing affair) you'd basically have to put an embedded CPU on every card.

 

Roughly speaking this is the equivalent of the BIOS code there is on PC video cards from EGA onward that handles initialization and mode settings, it's not a "driver" in the "Windows driver" sense. (Or the "extension loaded from disk that enables enhanced functionality in the control panels or acceleration or whatever" sense.) On a typical card I doubt it took more than a few K in ROM. Quickdraw defines what the actual video modes need to look like and how they're manipulated so none of that is in the "driver" in the declaration ROM. All the driver does is program the raw registers to set up the field.

Share this post


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

It's pretty clear that there is, on a typical card,  a "driver" stored in the declaration ROM, along with initialization code. There's not much to this driver, but it's there to translate the "generic" mode setting API calls made by the system control panels, et al, to the actual register tickling that has to happen to program the video hardware to display the requested mode.

 

That's what I thought I'd said: The DRIVERS for a video card as in "Cards and Drivers" reside in DeclROM to bring the card online, allowing ?Mac machine state indication before disk access for loading the OS begins. Was that a comms error between us or am I missing something here?

 

Whatever "drivers" shipped on disk with the card set it up for special features via extensions a/o a provide a customized Control Panel replacement for the Monitors Control Panel.

 

I found a tidbit about VidCard Driver/INIT loaded at boot's ability to usurp function of the DRIVER in DeclROM to be interesting and possibly a handy development tool. Once a basic setup for implementing that is coded, up and working it might make tweaking DRIVER development possible w/o the need for removing and burning a new ROM for the card with each iteration. Might not be necessary if provision for updating an EEPROM on the development board via USB or the like would be better, Dunno about that stuff, but I thought I'd mention it. The latter would be better in terms of adding/tweaking display mode options in DeclROM, assuming that might not be possible to do from the host Mac?

Edited by Trash80toHP_Mini

Share this post


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

Was that a comms error between us or am I missing something here?

I think it's that, because I interpreted your second post as a claim that you *didn't* need a "driver" (in the context of executable code on the card) right after I'd convinced myself that in most cases at least you probably did. (The edge case of a strictly single-mode fixed function framebuffer like that in the SE/30, which does have a declaration ROM and otherwise masquerades as a Nubus video card, is one possible exception.) Apparently you thought I meant drivers on a disk.

 

The reason I was turning this over in my head is I was pondering the possibility of, for an initial stab at developing an FPGA-based card, if one could start with something just as dumb as the SE/30, IE, say an 800x480 1-bit monochrome fixed framebuffer. This would require less than 64k of RAM, I'm pretty sure some relatively cheap FPGAs could handle this without external memory. A card like this would likewise need only a *very* minimal declaration ROM, my question was 'how minimal'?

Share this post


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

The reason I was turning this over in my head is I was pondering the possibility of, for an initial stab at developing an FPGA-based card, if one could start with something just as dumb as the SE/30, IE, say an 800x480 1-bit monochrome fixed framebuffer. This would require less than 64k of RAM, I'm pretty sure some relatively cheap FPGAs could handle this without external memory. A card like this would likewise need only a *very* minimal declaration ROM, my question was 'how minimal'?

That sounds like a great Idea for a first run at this thing, baby steps. :approve: Since we don't need to use Apple's physical design guidelines we could get by with a generic adapter to PDS and smaller form factor carrier dev boards.

 

FitmentTrial.JPG

 

The mockup above was meant to have a PDS connector on the solder side for an outrigger development board plugged in thru the opening in the SE/30 chassis. Substitute a PCI connector for EuroDIN120 and all carrier revisions remain within the 10x10 SEEED square and are easily swapped out. Header/socket thruholes below the PCI connector would allow breadboarding a first rev "PCI" carrier board for the much shorter edge card connector. Keep the breadboard connector thruholes configured for EuroDIN120 and late model, much larger standalone carrier boards using those more expensive connectors would be handily installed/removed as well. A short run of adapter boards could be used through the entire development process.

 

edit: moving development boards onto 'PCI" was planned for major reduction in cost of development.

 

Edited by Trash80toHP_Mini

Share this post


Link to post
Share on other sites

Anything interesting or even progress to report from anywhere on this? Volume IV of Inside Macintosh with its "relevant information" arrived today, but the meat of the matter is in the "indispensable" Volume V waiting for me at the rental office for pickup Monday morning.

Share this post


Link to post
Share on other sites

Not a whole lot from me. Work has been demanding a lot of my time as deadlines approach.

 

The FPGA and USB programmer arrived last week but I need to source a 5V power supply to begin playing with it. In the meantime, I've been learning about TMDS encoding (used in DVI/HDMI/DisplayPort) and following through its implementation in the VA2000 project. I also began drafting a schematic of the daughter board but need to better understand 68030 PDS in order to understand how best to wire it to the FPGA. Towards that end I've been making (slow) progress reading through DCaDftMF3e and Spartan 6 documentation.

Share this post


Link to post
Share on other sites

Just had a thought, how non-trivial a task would it be to create a neck board for the SE/30 CRT that's entirely independent of the Analog Board.  Maybe designed for HDMI Input in grayscale at 640x480?

 

edit: guessing you'd need a driver to throw a blank screen at the A/B connector and vary resistance to the signal via the controller on the new neck board board. Kinda like running a DAC in reverse to attenuate the blank screen Analog power feed per grayscale input at whatever DOT clock might be required. Can the feed for a blank screen be fed into a capacitor circuit to smooth out the refresh cycles, converting power level cycling to a continuous feed for the kluge on the end of the CRT?

Edited by Trash80toHP_Mini

Share this post


Link to post
Share on other sites

Might be able to do it all in analog from any old card in the SE/30, but I'm figuring tha controlling the resistance delta and refresh rate froma a digital input would be a lot easier?

Share this post


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

Just had a thought, how non-trivial a task would it be to create a neck board for the SE/30 CRT that's entirely independent of the Analog Board.  Maybe designed for HDMI Input in grayscale at 640x480?

The neck board doesn't control the yokes so it's a non sequitur to talk about designing it for any particular resolution. You're going to get as many vertical lines as the A/B itself can handle.

Share this post


Link to post
Share on other sites

That's what I get for firing off a question just before heading to work. Forgot all about the deflection part of things. [:I] So we're stuck with baseline Compact Mac resolution and will need to set the proposed 030 PDS VidcCrd up for that as well as the 720p and below we were discussing.  IIRC, we've got the schematics of the Xceed Grayscale Neck Board, it's the FidCard itself that's 18k unobtanium and nigh on impossible to reverse engineer.

 

So the question remains: if we can cobble together a digital output VidCard, no mean feat that, might it be possible design a digital back end for whatever is needed on the analog front end of the Xceed neck board?

Share this post


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

So the question remains: if we can cobble together a digital output VidCard, no mean feat that, might it be possible design a digital back end for whatever is needed on the analog front end of the Xceed neck board?

It would seem the easier thing to do would be to just have an alternate SE-specific version of the card that outputs via a DAC so it can use the same neckboard as the original grayscale card.

Maybe it's just me, but it kind of seems like we're getting pretty far ahead of the game here dreaming about specific niche applications for a special sauce open-source video card that doesn't even exist yet, but... *shrug*.

 

Developments in another thread got me thinking about this one; I didn't know when I suggested it a few posts ago that a brain-dead NuBus 1-bit mono video card with only 64k of video RAM already existed. If someone has one of those and there's a straightforward way to get a dump of its declaration ROM replicating that card would probably be a *very* low-hanging fruit. (At least considering the minimum difficulty of this project.)

Interesting detail about that card, BTW. For "VRAM" it appears to only use a single pair of 120ns 41464 DRAM chips. That means it breaks the cardinal rule(*) of a "memory-like" Nubus card in only having an 8-bit wide memory bus. My guess is that big VSLI chip on it must have read-write buffers so every long-word read/write from the Nubus gets turned into four byte-wide transactions on the memory bus. If that's the case this card is probably slower than molasses in January even compared to a Toby card. This is a problem that can be easily avoided with an FPGA recreation, of course.

 

(* See "Byte lanes and 8-bit NuBus data transfers" in this technote, which verifies what was said earlier in this thread; video memory on Nubus has to at least *look* like it's 32 bits wide for Quickdraw to work. You can't just slap an 8 or 16 bit VRAM on there and tell Nubus to handle it *or* tell Quickdraw that ever other block of pixels is spaced X many addresses apart. Only solution is to buffer.)

Share this post


Link to post
Share on other sites

Was that auction pic I posted the card you were talking about in that thread? Recent posts in the eBay thread had me headed back here again.

 

That card's probably a dead end. The TOBY card is very, very well documented with bits and pieces scattered across several pf Apple's technical publications. IIRC, I'm still looking for the PAL listings? Pretty sure DeclROM development and driver development are well covered. Gotta re-read this thread when I'm not all bleary eyed. Probably said it before, but pulling the NuBus MUXmess off TOBY and getting its bits up and running on the 030 PDS would probably be a great warmup exercise for the HDMI project.

Share this post


Link to post
Share on other sites

The one advantage this card has over the Toby (the whole point) is a medium size FPGA might be able to store the framebuffer in its internal cells, which eliminates the need to worry about the memory bus (or the I/O pins needed for it.) That's the point.

Share this post


Link to post
Share on other sites

I guess I just don't see any point to working up a B&W card for a color Mac. An SE/Plus/Classic specific card for an LCD yes, but not for a grayscale neckboard in the SE/30. I'll try to pull all the Toby docs together to see how many parts of the jigsaw puzzle Apple provided might be missing when I have some time for a new project.

 

38 minutes ago, Gorgonops said:

Maybe it's just me, but it kind of seems like we're getting pretty far ahead of the game here dreaming about specific niche applications for a special sauce open-source video card that doesn't even exist yet, but... *shrug*.

It is that, but I try to hash out all the crazy angles ahead of time. Plant the seeds if all the features imaginable and then prune back the overgrown featuritis bush to come up with the framework for a reasonable spec.

Share this post


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

I guess I just don't see any point to working up a B&W card for a color Mac.

*Eyeroll*

 

Perhaps you're unfamiliar with the concept of iterative learning. The monochrome card wouldn't be the final destination, it would be an initial smoke test of the concept. For the third time, the mono card could probably fit *entirely* inside the FPGA and be trivially easy to implement on the video side, which would make it a good platform for working out bugs in your Nubus-on-FPGA implementation.

 

Frankly I'm of the opinion that there's a false economy you've latched onto here with the PDS vs. NuBus thing as well. PDS is somewhat *simpler*, in that it's not multiplexed and needs a little less in terms of state machine logic. However, it also needs more pins (with the possible exception of the 16 bit LC subset) and frankly isn't *that* much simpler, so is it *really* worth harping on it as the thing to do first?

 

(Don't forget, stateful logic is pretty much free with an FPGA, we're not talking about building this out of 7400 series ICs.)

Share this post


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

Perhaps you're unfamiliar with the concept of iterative learning. The monochrome card wouldn't be the final destination, it would be an initial smoke test of the concept. For the third time, the mono card could probably fit *entirely* inside the FPGA and be trivially easy to implement on the video side, which would make it a good platform for working out bugs in your Nubus-on-FPGA implementation.

Absolutely familiar with it and yes, because I'm seeing it from the perspective of discrete learning modules. That's why teasing apart the well documented Toby frame buffer for the Macintosh II has been my suggestion. Toby is a primary design example provided by Apple in every iteration of NuBus card design documentation and the best documented of the design examples. You're taking a whole deal in one attempt at a doing a simplified card approach which is great  .  .  .  once you've digested all the NuBus docs AND the Video Card/DeclROM/Driver development docs. Add to that a familiarity with FPGA development. That's a LOT in one bite! 8-o

 

I see what you're suggesting as one person described Inside Macintosh: x number of separate, inscrutable volumes all if which require a deep understanding of the others. So I'm suggesting we take a modular approach to the hardware, using bits and pieces Apple made available to developers..

 

- Much of Toby is implemented in a socketed ASIC which can be borrowed from a card anyone involved in the project could easily acquire rather than working from a theoretical model.

-  -  Apple did a very in depth examination of Toby in DCaDftMF3e after the card was discontinued and unavailable to developers in order to preserve the "learning module" it represented.

-  -  I figure Apple socketed that ASIC intentionally, making it a plug-n-play module for development.

- The Declaration ROM is socketed and can be borrowed from the card.

-  -  developing the DeclROM for Toby is the primary example of coding DeclROM/Drivers IIRC.

- Toby's NuBus multiplexing is implemented in PAL, GAL and discrete logic as was the first rev, pre-Nuchip Macintosh II.

-  -  teasing that implementation apart would be crucial in checking off the NuBus Box.

 

Stripping NuBus from the first run at VidCard design simplifies the project a bit more than you're figuring I think. Treating NuBus as a Black Box in the first run and then retrofitting the contents of the box as separate learning module makes it more easily applicable to any type of card in any later projects. As I understand it, the point of the exercise would be developing a Video Card the outputs HDMI. Being on the NuBus interface would be a secondary goal.

 

Look at it this way: The IIsi would be the perfect experimental machine. Its slot is pure 030 PDS the same as the SE/30, a buffered extension of the CPU. The IIsi NuBus adapter is the Black Box, ready for testing a working 030 PDS design for implementation on the NuBus conversion of that card, if and when.

 

NuBus is a gimmick, a more complex way to talk to multiple expansion devices on the processor's bus. PDS is a later development, a simplified (back to roots) approach to I/O analogous in many ways to proprietary Local Bus slots developed on the PC side of the tracks.

 

Added benefit of IIsi as project box would be that most serious development work has been done by SE/30 fanatics, luring them onto the tracks heading to NuBus would very much be the thing to do. [;)]

Share this post


Link to post
Share on other sites

You know, if the basic concept of framebuffer video was a difficult and obscure concept then maybe some of what you just said there would make some sense, but, hate to break it to you, it's not. The *only* parts of this exercise that are "mysterious" are the vagueries of NuBus (or whatever) bus glue and the software stack. Fire up Google and you can find dozens of sources for working FGPA framebuffers on the first page of results. This whole thread started out referencing an example of such. FPGA to HDMI is a solved problem.

 

Obviously the *very* first step in this exercise is to come up with some bus glue and hang an LED off it that you can blink by writing to a memory location. This happens before anything involving a declaration ROM or anything. *Next step* is grafting something that actually does something after your glue. A monochrome fixed frequency framebuffer needs either 1/4 or 1/8th the memory *and memory bandwidth* of a Toby work-alike and also ditches the need for any code or switches to change the memory architecture so, yes, it's easier to express in FPGA language than a Toby. If you had the declaration ROM contents off the original mono card you could probably easily use it unmodified, or, I'm guessing here, you could trivially modify the code in the SE/30 stub ROM to drive it.

 

The points above apply to either a PDS or NuBus prototype. Now, again, sure, if it turns out it's "easy" to jump straight to a framebuffer module that does external RAM then most of the advantages of going Mono for the first rev goes away.

 

What sounds like an absolute nightmare is taking a real Toby or whatever card and trying to replicate it piecemeal by pulling off ASICs and trying to guess what parts of what logic are implemented in them and how. Unless you have the complete schematics and specifications for those parts you're going to be better off just starting from scratch. (Which, again, you're doing with a copious pile of documentation.)

Share this post


Link to post
Share on other sites

The frame buffer stuff I'm not worried about ATM, that's for you folks to work out. I'm working on lining up that copious pile of relevant documentation. The common referent happens to be Toby. NuBus implementation was a lot more difficult for developers back in the day than I think you're assuming. Take another look at How_the_Macintosh_II_Nubus_Works_Byte88 They were serious development engineers who acknowledged the significance of help they received from an engineer at Apple. I don't think anybody still working at Apple knows jack about NuBus. :lol:

 

25 minutes ago, Gorgonops said:

Obviously the *very* first step in this exercise is to come up with some bus glue and hang an LED off it that you can blink by writing to a memory location.

That'd be building the NuBus Test Card design example. [;)]

 

Byte article: The NuBus Test Card Apple designed the NuBus Test ,Card so Mac II motherboards could be fully exercised during bum-in with both slave-and master-mode transfers. The design of the NTC has been made available to developers. It has also been published in Designing Cards and Drivers, complete with all the programmable array logic equations. The NTC gives designers an excellent opportunity to evaluate NuBus operation without first having to complete and de-bug their own designs. The NTC gives designers an excellent opportunity to evaluate NuBus operation without first having to complete and de-bug their own designs. In addition, the PAL equations are easily modified to form the basis of a slave, master, or composite design. The PAL listings are available in Designing Cards and Drivers.

 

Methinks the same equations are to be found in the firmware on the Toby card, but that's a guess. Haven't checked into it yet, but I see no reason for Apple to have confused the issue by differentiating the NuBus interface implementations on any of the four design examples documented for developers.

 

Not talking about reverse engineering Toby, it's in there. Playing with its bits is one thing and a side issue Noodling what we need for the project out from the docs with a working card in hand is another thing entirely.

 

 

 

Share this post


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

Not talking about reverse engineering Toby, it's in there.

I'm not even sure you know what you're talking about, because what you said here is exactly the opposite of your first ball of blather, IE, first you're reading me the riot act for suggesting using a minimal frame buffer implementation instead of something apropos of a "Color Mac" and launching into this big spiel about "noodling around" with components pulled off a real Toby video card, and now you're trying to say, oh no, it's not the frame buffer you were talking about at all, it's *all about* unlocking the impossible mysteries of Nubus. If that's the case then why the *$%^ were you getting all in my grill for making the a suggestion that essentially boils down to "instead of trying for an amazing final product in one go here's an idea for an intermediate proof of concept"?!?!

 

You know, that's great if there's a Nubus test card that's fully documented with the PAL code all written down. Interestingly what that translates to is it indeed might actually be easier to implement Nubus glue instead of PDS because, hey look, there's a fully documented reference example! Why did you just throw that out after all that slagging and harping about PDS?

 

If one didn't know better one might get the impression that you're being contrary just for the hell of it. Whatever, dude.

Share this post


Link to post
Share on other sites

Sorry, not trying to be contrary, I'm a bit manic and not particularly rational these last few days. Also trying to sort things out here in between downsizing sessions as a reward. Taking a break ATM. The reason I asked about SE/30 card possibilities above was not just that it would be related, I also wanted to keep the thread alive.

 

I thought I was saying I didn't understand the point of the single bit card as it applied to Apple offering it in the first place more than to your suggestion we reinvent that flat tire. I see now why you took it as only applying to the card build you suggested. Again, sorry about that. In terms of a first experiment your suggestion does make sense to me now if the NuBus pincount is possible and the PDS pincount is not on the I/O setup of a given FPGA.

 

1 hour ago, Gorgonops said:

You know, that's great if there's a Nubus test card that's fully documented with the PAL code all written down. Interestingly what that translates to is it indeed might actually be easier to implement Nubus glue instead of PDS because, hey look, there's a fully documented reference example! Why did you just throw that out after all that slagging and harping about PDS?

I'm glad you posted about building a blinky LED card as the first step. That's what got me to do an in depth post about the NTC. The article in BYTE is the very first item on the list of reference material links I posted on the previous page. [:)]

 

What's on the other side of the NuBus glue IS a PDS card when you get right down to it. The Apple docs make it very clear that developing for the "newfangled" SE/30 PDS should be done in exactly the same manner as developing for NuBus. DeclROM/Drivers and "Card" can be grafted onto the NuBus easily with the Slot Manager handling the interfaces as if the same thing. I see working up the intermediary interface glue as an unnecessary concern until there's something proven to be working on the card end of the NuBus gimmickry.

 

The target machine of the OP is the Quadra 950, so the end game is without a doubt NuBus. But I feel the spring training games should be played on PDS for simplicity sake and for the added flexibility in terms of machines supported.

 

@trag any luck identifying the 040 PDS connector from the pic/info I posted?

 

 

edit: G, you snarked me pretty good yourself about that iterative learning thing. I snapped back at that without realizing I'd not made it clear that I thought Apple's card was a very dumb idea.

 

Edited by Trash80toHP_Mini

Share this post


Link to post
Share on other sites
On 4/13/2019 at 4:27 PM, Trash80toHP_Mini said:

What's on the other side of the NuBus glue IS a PDS card when you get right down to it. The Apple docs make it very clear that developing for the "newfangled" SE/30 PDS should be done in exactly the same manner as developing for NuBus. DeclROM/Drivers and "Card" can be grafted onto the NuBus easily with the Slot Manager handling the interfaces as if the same thing. I see working up the intermediary interface glue as an unnecessary concern until there's something proven to be working on the card end of the NuBus gimmickry.

Sort of feel like a broken record at this point, but here it is again: this entire project (almost) is about the "intermediary interface glue". Basic non-accelerated Macintosh video cards are *extremely* straightforward devices; they're arrays of RAM with the pixels arranged in a linear, contiguous fashion and the pixel format is well documented. (it's packed-pixel "chunky".) Here is a project that implements the equivalent of a "Toby", IE, 640x480x256, using a single 144 macrocell CPLD. (And not just that, it can do widescreen 848x480 too, and it also handles 16, 4, and 2 color bit depths, all of which are interesting for smoke testing a Mac video solution, and although I'm not going to say this with 100% certainty my broad skimming of the docs suggests it uses the correct memory mapping, or at least very close.) Obviously this example isn't directly what we want for the final solution, but the reason I'm pointing it out is that this design implements a "Toby" in less than 1/10th the gates that are available in the FPGA the OP wants to use for this project. Making a "video card" to stick behind the bus glue isn't the challenge here, the bus glue is. (And the Declaration ROM contents, but at least that is copiously documented.)

 

As to "what is on the other side of the NuBus glue being a PDS card", that might be broadly true (though not really) when you're talking about discrete electronics, but it's not true if we're talking about an FPGA. When you're done designing the video portion of your FPGA video card you're not going to be standing there literally holding a bunch of wires in your hands that directly correspond to the address and data bus of a Motorola 680x0 CPU, you're going to have a structure that essentially consists of a black box with some "holes" in it that stuff like data transactions and addresses need to come in and out of, and you need to build the bridge between those virtual holes and the I/O pins on the FPGA package. There is actually very little reason to think that building a 680x0 bus arbitrator is going to be inherently easier than a NuBus one other than you're significantly more likely to find example code from someone who built it already. (For instance, the Amiga 2000-targeted video card the OP opened with; Zorro II is *mostly* just straight-up 68000 so it probably *isn't* that hard to convert it to 68030 PDS; since 68030 PDS supports bus-sizing you can even keep it a 16 bit card. 68040 is another story.)

There are two totally valid ways of tackling this project:

 

Strategy One: concentrate on implementing a Mac-compatible (in terms of internal memory layout) framebuffer that outputs via an HDMI port (IE, build it, load it onto the FPGA, and demonstrate it making pretty pictures based on the contents of VRAM that you populate by stuffing in bytes via SPI or a serial port) first and then tackling writing the bus glue for whatever bus you think is easiest and coming up with the needful declaration ROM contents to get the Mac to see your device as a video card at boot (note there's an intermediate step possible here where you get the glue working and test it by writing a simple driver program that "pokes" pictures into the card's video RAM without the Mac "knowing" about it.)

Strategy Two: do the opposite. Figure out how to handle the voltage conversion and whatever issues to get your FPGA sitting on the bus lines (again, whatever bus floats your boat) and write a bus arbitrator that maps some trivial device into the Nubus slot space. (Either the space assigned to your real Nubus slot or the psuedoslot space if you went PDS.) Bang together a simple program that lets you poke bytes into the FPGA and blink a light or whatever. Then pick some halfway milestones, like mapping a chunk of RAM into that space as if it were a framebuffer and verify you can read and write to it reliably, and playing around with declaration ROMs. And then, FINALLY, worry about making the contents of your RAM card drip out the back of the computer via HDMI.

What is leaving me scratching my head is what exactly is the strategy you're advocating for here. Frankly my opinion is that strategy two might broadly be the better idea, but if playing with video cards sounds like fun then there's no harm in strategy one... although, frankly, it looks to me like strategy one actually turns directly into two as soon as you're happy with your video architecture. It seems to me like you keep saying all the steps in strategy/part two will be magically much easier with PDS and I don't think that really follows. Maybe I'm terribly wrong about that, but at best it seems to me we're probably talking about, I dunno, a few percentage points of effort plus or minus off the total project.
 

On 4/13/2019 at 4:27 PM, Trash80toHP_Mini said:

G, you snarked me pretty good yourself about that iterative learning thing. I snapped back at that without realizing I'd not made it clear that I thought Apple's card was a very dumb idea.

I apologize for the breach in civility. I'm not going to justify it, but I was simply getting a little annoyed at all the off-topic editorializing about all the stupid terrible things Apple did with Nubus and how it was totally unknowable and... etc. All I was attempting to point out in bringing up the mono card is that theoretically at least it's possible to set a *very* low bar for what counts as a "working" video card, and if the point is to actually complete this project (or at least encourage someone to try) setting the targets as close as possible just might help grease the wheels. Therefore I'm not sure that all the negativity about Apple and comments about how hard and terrible and unknowable Nubus is are really that helpful.

Share this post


Link to post
Share on other sites

No problem, didn't realize I was going on and on and on  .  .  .  [:I]

 

NuBus is far from unknowable, but from what I've read and from what I recall of bbraun's experimentation, getting a card up and running on NuBus ain't all that easy. Take another look at that BYTE article. The lead engineer and software team leader at YARC Systems had a bit of a time of it and they had help from an Apple engineer at a time Apple really wanted to help get developers on board. The article is about getting the well documented NuBus Test Card design example up and running so they could go on to design NuBus cards.

 

That said, there have been two revised editions of the 1987 DCaDftMIIaMSE they were working from, so it might be a bit more straightforward at this point?

 

2 hours ago, Gorgonops said:

As to "what is on the other side of the NuBus glue being a PDS card", that might be broadly true (though not really) when you're talking about discrete electronics, but it's not true if we're talking about an FPGA.

I said that badly, what I meant was that the NuBus chipset sits on the CPU Bus and whatever sits on a card downstream from the NuBus chipset on that card is for all practical purposes sitting on the CPU Bus as does a PDS Card. Both share the Declaration ROM/Slot Manager's address mapping setup. To get your FPGA to interface with NuBus chipset on a card you've already designed A PDS card for all practical purposes. Just sayin' the NuBus part can wait for a bit. Isn't it quite a lot more straightforward to just talk directly to the 030 PDS which translates to any later bridged 030 PDS, and also the 040 PDS in the OP's Quadra 950? With a Video Card in the 040 PDS Slot you wouldn't need acceleration!

 

2 hours ago, Gorgonops said:

What is leaving me scratching my head is what exactly is the strategy you're advocating for here.

I guess the above was about it. Several folks have been poking away at the SE/30 PDS for a long time here. Outside of bbraun, I can't think of a single person who's taken a stab at the NuBus beast. PDS is the best common denominator, especially if @trag can find those blasted 040 PDS connectors. Sealing a working PDS design up within the limited NuBus performance envelope can wait. The 040 PDS awaits!

 

 

FWIW, I'm just trying to assemble the relevant documentation. Some of this stuff has been banging around in my head since the 90s and moving forward to the third edition and backward to the original iteration of DCsDftMF2e that I started reading in earnest in the the early 'oughts has much of it mooshed around in my skull, so bear with me if you would.

 

Meanwhile I'll definitely be reading up on your suggestions, that VGATonic link looks interesting. :approve:

Edited by Trash80toHP_Mini

Share this post


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

To get your FPGA to interface with NuBus chipset on a card you've already designed A PDS card for all practical purposes.

And to reiterate: no, you have not and that's not even what we're talking about. So far as I can tell no one in this thread has seriously suggested using a discrete TI or other NuBus chipset on a card and sticking an FPGA behind it, what I've been talking about is implementing the NuBus protocol *on the FPGA fabric* behind nothing but some level converters. IE, going straight to NuBus with exactly the same physical glue you'll need to hook an FPGA to PDS. Except NuBus will probably need fewer I/O pins because it's multiplexed. (Remember, almost half the pins on a 96 pin NuBus connector are power or ground. It takes almost 90 pins to do a 32 bit PDS card. Check it yourself.)

 

That "Nubus test card" in the Apple docs is a complete sample implementation of NuBus without ASICs, including the PAL equations. All that can live on the FPGA. Directly. So, again, I repeat: electrically at least I see no reason why NuBus is harder than PDS. It actually requires fewer resources. Downside is you need to understand the protocol to implement it, but it *is documented*. So, *please*, stop repeating this idea that PDS somehow "naturally emerges" from the design of the video portion. It doesn't.

Share this post


Link to post
Share on other sites

I seem to have missed the part where I'm looking for the 040 PDS connector.  I think I just asked earlier if anyone knew the part number or where to find it.   I didn't mean that I wanted to take up the project.    Given enough time, I'll probably look into it, but given enough time, the Sun will turn into a Red Giant....

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

×