Jump to content

Development of Nubus graphics card outputting to HDMI?


Recommended Posts

29 minutes ago, Gorgonops said:

Even if you were on PDS in a 68040 Mac doing a block transfer from RAM I suspect you'd have problems sustaining numbers still substantially south of 100MB/s. That's a guess but a semi-educated one.

Here's a link to a Motorola 68040 manual:

 

http://www.bitsavers.org/components/motorola/68000/MC68040_Designers_Handbook_1990.pdf

 

Chapter 9 has memory access time calculations. They give me a headache, but my rough interpretation is that the normal transfer modes of a 68040 would allow a 33mhz 68040 to transfer to and from onboard cache at around... 66MB/s?, while burst mode would peak around 106MB/s? (The manual says this would require 20ns-ish SRAM, which is obviously much faster than the 60ns FPM you have for main memory in a Quadra.) So, yeah, totally, bus speed is piddlingly slow by comparison of what needs to stream out the HDMI port.

Color me more and more impressed at what the video systems inside $5 Raspberry Pi Zeros are capable of doing with *shared memory*. Jeeze.

Link to post
Share on other sites
  • Replies 185
  • Created
  • Last Reply

Top Posters In This Topic

3 hours ago, Gorgonops said:

It is kind of a scary number, isn't it?

A little bit...

 

After a quick Google search, it appears the Spartan 6 doesn't quite support 1080p at 60Hz. And in fact, I see now the VA2000 lists 1080p @ 30Hz support as experimental. This is not a show stopper, of course. There is still plenty to learn. 

 

It appears Lukas is developing a successor to the VA2000 called the ZZ9000, which so far appears to be a carrier board for the MYiR Xilinx Zynq-7020 FPGA development board, with a lot of interesting features including full 1080p support, but release of schematics and sources is pending. This is one of the dev boards I was originally considering but my desire to stay close to the VA2000 project, plus its significantly higher price ($120) led me away from it.

 

Edited by dlv
Link to post
Share on other sites

Yeah.

 

Anyway, forget all the crazy stuff for now, definitely. I'd say pick a nice, easy target that gives you plenty of headroom slop like 480p in a few color depths (say 1 bit, 256 color indexed, and high/true color) and concentrate on the problems that *need* to be solved before creating new ones. ;)

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

Anyway, forget all the crazy stuff for now, definitely.

Very sensible. How about adding 8-bit grayscale to your proposed spec? That would that be a baby step toward the CLUT ridden mess of 8-bit gaming, no? Out of curiosity, at what point did games begin to require a color monitor?

Link to post
Share on other sites

... or, maybe more precisely, I think loading the CLUT with grays is how cards like the Toby do it. It's certainly possible there exists "direct-map" gray cards, I haven't remotely digested the information in the Apple docs sufficiently to be confident in saying you *have* to have a CLUT for grayscale. (It does make some sense to have one, though, if you're supporting 16 or fewer grays and want to be able to tweak the distribution for anti-aliasing.)

Link to post
Share on other sites

LOL! Just posted another of my morning musings in a new hacks thread, definitely inspired by you, dlv. I think such may be built right into QuickDraw. If it works on non-color Macs I'd think it might apply sans CLUT? Dunno, not awake enough to research further.

 

http://lowendmac.com/2013/scuzzygraph-and-scuzzygraph-ii/

 

CLUT might be built in the box though, but worth mentioning? Eight colors/grays ought not need CLUT?

Edited by Trash80toHP_Mini
Link to post
Share on other sites

Cool idea, I'll be following this project! 

 

I'm a firm believer that you need to crawl before you can walk before you can run. I like the idea of targeting the simplest design possible first, just to get SOMETHING working, even if it's slow or limited. You can always make improvements later. If the initial goals are too lofty, it's easy to get bogged down in complexity, get discouraged, and give up without anything to show for it. At least that's what happens with half my projects. :-) 

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

I think such may be built right into QuickDraw. If it works on non-color Macs I'd think it might apply sans CLUT? Dunno, not awake enough to research further.

The ScuzzyGraph is not a standard graphics card by *any* measure. Most to the point, it's not compatible with Color Quickdraw. As has been discussed in previous threads it's basically more correct to think of that device as a kind of "live print preview" than a normal display. (The "8 colors" it supports are the named colors that B&W Quickdraw had knowledge of in order to print to an ImageWriter printer with a color ribbon.) In the context of designing a Nubus (or PDS card for anything other than *possibly* an SE or Portable) it's the very definition of non sequitur. That said, sure, it probably does *not* have a CLUT because, well, the only colors it supports are those 8 fixed ones, making a CLUT kind of unnecessary.

 

Now with that all out of the way: Obviously any Nubus card that supports a color monitor is going to have a CLUT. Unless you can think of a card that *only* supports 16 or 24 bit color modes, no possibility whatsoever to fall back to 256 or less, I'm going to feel comfortable standing by that. The "Gray Area" I don't know about is the few specifically-targeted-at-grayscale-only-monitors cards like the "Macintosh II Portrait Video Card" or the "Macintosh Two-Page Monochrome Video Card". Both of these cards support 1, 2, and 4 bit grayscale *only* on a single type of fixed-frequency monitor. Obviously they're not going to have a "CLUT" per-se because they only have a single output channel (and therefore no "C"), what I don't know is if there's still a knob to populate a "LUT" in the path between the ram output and the DAC in order to allow the grayscale palette be tweaked. (This was a thing that at least some systems with only a "few" grays, say 4 bit, did. The reason is that the human eye has a non-linear response curve to brightness that makes it easier to distinguish between light shades of gray than dark ones. Therefore if you're doing anti-aliasing it can be useful to adjust the palette appropriately.) Maybe Apple didn't include that refinement, in which case, sure, you won't need a routine in your driver to load a CLUT or anything like, I guess.

 

That said I'm not sure there's a lot of point here . A 1-bit mono mode also lacks a CLUT so shouldn't that be adequate to accomplish the "Hey, I made a CLUT-less card" milestone? Also note that when I called out the missing CLUT code in the manual it wasn't because I was thinking that loading a CLUT table in and of itself will be an impossible thing to accomplish, I was just generally commenting on disappointment that more concrete examples on how to communicate with the hardware registers *period* weren't in the manual.

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

The ScuzzyGraph is not a standard graphics card by *any* measure. Most to the point, it's not compatible with Color Quickdraw.

Either I didn't get the notion across or my head hadn't been de-muddled enough yet to even try. I think I was leading up to the application of native QuickDraw routines the ScuzzyGraph made us of, not using anything about the ScuzzyGraph hardware. More making a suggestion to ransack its drivers for hidden treasure or at least follow their lead a bit in research? Color QuickDraw would be an extended version of QuickDraw and should(?) still support those rudimentary grayscale/color routines spun into its makeup in support of the printers of yore, no?

 

Implementing CLUT free grayscale of QuickDraw alongside B&W in the first run might be worth exploring?

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

Color QuickDraw would be an extended version of QuickDraw and should(?) still support those rudimentary grayscale/color routines spun into its makeup in support of the printers of yore, no?

I have no doubt that Color Quickdraw still has backwards compatibility hooks to that 8-color syntax to avoid breaking anything, but... *sigh*

 

This is a thing that's been talked to death several times before. First off, there *is* no grayscale there; remember you kept thinking for the longest time that the Macintosh SE somehow was secretly grayscale because of some confuddlement with the fact that this 8-color thing existed in QuickDraw and therefore that somehow meant that if you could turn the right screw grayscale would come out of an SE despite all evidence to the contrary? This link:

 

http://mirror.informatimago.com/next/developer.apple.com/documentation/mac/QuickDraw/QuickDraw-59.html#MARKER-9-65

 

Explains the "colors" in original Quickdraw. (And, yes, they still exist as a backwards compatible construct in Color Quickdraw.) Here are the colors it supports:

 

Quote

The basic QuickDraw color values consist of 1 bit for normal black-and-white drawing (black on white), 1 bit for inverted black-and-white drawing (white on black), 3 bits for the additive primary colors (red, green, blue) used in video display, and 4 bits for the subtractive primary colors (cyan, magenta, yellow, black) used in printing. QuickDraw includes a set of predefined constants for those standard colors:

 


CONST
 ÝwhiteColor   =Ý30;
 ÝblackColor   = 33
 ÝyellowColor  = 69;
  magentaColor =Ý137;
 ÝredColor     =Ý205;
 ÝcyanColor    =Ý273;
 ÝgreenColor   =Ý341;
 ÝblueColor    =Ý409;

These are the only colors available in basic QuickDraw (or with Color QuickDraw drawing into a basic graphics port). When you specify these colors on a Macintosh computer with Color QuickDraw, Color QuickDraw draws these colors if the user has set the screen to a color mode.

Notice, explicitly, that there is no "grayscale" here. Period. Essentially this syntax was designed to give a programmer the syntax to represent color as a sort of spot-color separation which on a B&W macintosh would be dithered but, yes, when real color Macintoshes came along would magically show up in color. (Yes, it was actually possible to write software that would appear in color on the Macintosh II before the Macintosh II ever existed.) And the fact that the ScuzzyGraph actually worked with at least some software indicates that the use of  "basic" graphics ports for drawing screen entities continued for at least a while, no doubt because:

 

Quote

There are three advantages to using basic QuickDraw's color system:

 

  • It is available across all platforms, so you don't have to check for the presence of Color QuickDraw.
  • It is much simpler to use than Color QuickDraw.
  • It works well on an ImageWriter printer with a color ribbon.

 

But note, seriously, the word "Rudimentary" is used multiple times in this chapter to describe its level of functionality. This is not "real" color and it is not grayscale at all.

 

I simply do not know if it's possible to craft the necessary declaration ROM resource structures to indicate that you've plugged into a Color Quickdraw-equipped Macintosh a video card that's only capable of displaying "basic" Quickdraw objects. I will bet a shiny vintage nickel that no card like this ever existed. Also the Scuzzygraph distinctly was *not* a Nubus card and did *not* have a Declaration ROM so... seriously, I'm having a really hard time understanding why you think it would be relevant here.

Link to post
Share on other sites

Some questions from the uninitiated - what is the basic theory of operation for an unaccelerated NuBus video card? Does the Macintosh ROM already have routines that do pixel-by-pixel line and polygon and text drawing, and it just writes those pixels into a frame buffer whose address is mapped to the NuBus card's address space? NuBus is different from a processor direct slot or hardware mapped directly into memory space, so I guess there must be more to it than that.

 

Once you have a frame buffer in memory on the card, outputting a VGA signal from that is pretty easy and there are a million examples. I don't know anything about HDMI, but I'm guessing that's also a solved problem and it's not anything Mac specific. So basically the challenge is to build a card that sits on the NuBus and speaks NuBus protocol and that presents a region of memory to the CPU to be used as a frame buffer? What kind of device driver software is needed?

 

Is it certain that an FPGA is needed here at all, or could a fast enough microcontroller do the job? I see that NuBus is only 10MHz while inexpensive microcontollers can run at 120MHz+, so it might be possible to handle bus traffic in software. Bbraun did this for his Macintosh SE video card, which is some flavor of STM32 microcontroller connected to the SE PDS, no FPGA needed. 

Link to post
Share on other sites
22 minutes ago, bigmessowires said:

what is the basic theory of operation for an unaccelerated NuBus video card? Does the Macintosh ROM already have routines that do pixel-by-pixel line and polygon and text drawing, and it just writes those pixels into a frame buffer whose address is mapped to the NuBus card's address space?

Yes. This was chewed over some before, but the basics are that to Quickdraw all framebuffers are linear, with packed-pixel chunky (not planar) color space, and essentially all you do is point Quickdraw to where it lives and what its dimensions are and it goes to town.

 

23 minutes ago, bigmessowires said:

NuBus is different from a processor direct slot or hardware mapped directly into memory space, so I guess there must be more to it than that.

Not really. NuBus is still just a bus, memory attached to NuBus is mapped to specific locations in the CPU's memory map, and the CPU has direct access to it. Nubus has arbitration and all that but it's invisible to the CPU, the Nubus chipset handles the overhead and just tells the CPU that it's dealing with non-synchronously-clocked memory and has to suck up wait states as it takes its own sweet time. Logically speaking a properly designed PDS and Nubus video card can't be easily told apart so far as Quickdraw is concerned.

 

Strictly speaking it does get more complicated than that because where exactly the screen buffer goes depends on whether the Mac is in 24 or 32 bit addressing mode, etc, but *generally* to a Mac a video card is just RAM.

 

27 minutes ago, bigmessowires said:

s it certain that an FPGA is needed here at all, or could a fast enough microcontroller do the job? I see that NuBus is only 10MHz while inexpensive microcontollers can run at 120MHz+, so it might be possible to handle bus traffic in software. Bbraun did this for his Macintosh SE video card, which is some flavor of STM32 microcontroller connected to the SE PDS, no FPGA needed. 

I wouldn't strictly rule it out, but I don't think it's a particularly great approach either. BBraun's card acts as a "snooper" looking for updates to the block in the SE's main memory where the framebuffer is stored and copies updates on its own sweet time, it doesn't have to respond in real time to any bus arbiter. NuBus isn't clocked that fast but some of the things it would have to respond to are *very* time critical. I've seen several failed attempts to map a microcontroller directly onto CPU busses as slow as a 6502 and trying to write software that can flawlessly stay synchronous with it. It's a tall order.

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

copies updates on its own sweet time,

Actually, I want to add an asterisk to that because even though I read the theory of operations of that device not that long ago I'm having trouble remembering if the copy operation could be "delayed" or if it had to catch writes as they happened. Still, the general point remains that it's "shadowing" the actual framebuffer, not acting as it, which means:

 

1: it only cares about writes. If the Mac wants to read the state of a pixel it gets it from the real RAM, which also means:

 

2: if it misses a transaction that's just a transient artifact in its capture output. If it were the only copy that would be a fatal error.

 

I really think people are worrying too hard about NuBus. There's a sample implementation in the manual and all the scary parts fit in a small handful of 74xx parts and PALs. (And the PAL equations are there.) Famous last words, but how hard can it be? (And conversely, why would a software implementation be easier?)

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

... seriously, I'm having a really hard time understanding why you think it would be relevant here.

Thought it might be worth mentioning. It's not, got it and I'll zip it. Remembered it wasn't real color, BTW, not real grayscale either, dithering in B&W maybe? Just thought rudimentary QuickDraw primitives might be useful on a simple card for something a bit more than B&W

 

Before I learn to crawl I gotta learn to roll around on the floor for a while. :mellow:

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

I really think people are worrying too hard about NuBus.

Yeah, I find myself going back to a NuBus design:

  • Easier than I expected to understand (so far). E.g., after a few hours tonight, I understand, at least at a high level, how single transaction reads and writes work. 
  • Maybe avoid having to re-read the Motorola MC68030 manual for now. It's not clear to me whether a read of the NuBus/NuBus90 specification is necessary yet.
  • Electrically slightly less challenging (10MHz, fewer I/O pins, fewer things to solder when the time comes)
  • Will work in my Quadra 950 :) No need to source a Mac with a 68030 PDS (although I think I want an IIfx some day) 

I've also been musing about the possibilities a FPGA with ARM SoC opens, just for fun. It might be possible to do some really neat stuff like running WebKit on the ARM cores and rendering to a framebuffer that's overlayed onto space within the window of a custom browser interface. A hardware web accelerator. 

 

Some thoughts on current discussion:

  • I wouldn't rule out the use of a fast microcontroller either but I believe a FPGA really is the right tool here.
  • I'm not worried about color depth or CLUTs appreciably affecting complexity? I'm oversimplifying but I suspect that B&W output will be just as challenging as true color, but once we figure out any sort of output, other modes will follow.
Edited by dlv
Link to post
Share on other sites
1 hour ago, dlv said:

I'm not worried about color depth or CLUTs appreciably affecting complexity? I'm oversimplifying but I suspect that B&W output will be just as challenging as true color, but once we figure out any sort of output, other modes will follow.

I wanted to elaborate my thinking: I think true color is actually a natural choice to target at the beginning because it's what the HDMI TMDS encoder takes as input. Supporting B&W would require extra FPGA logic to stream 1-bit pixels and convert them into a 24-bit pixels to feed into the encoder. That is probably not hard but I wouldn't know where to begin with a design. Similarly, supporting a CLUT would need extra FPGA logic to perform the lookup and stream 24-bit pixels. I'm certain these are solved problems, but let's follow the path of least resistance. 

 

The unknown for me is how MacOS interfaces with CLUTs but that mystery can wait.

Edited by dlv
Link to post
Share on other sites

Dlv, I like this idea, and let me know if I can do anything to help. 

 

I'm not really worried about NuBus, but I only mentioned using an MCU because I think it could be much simpler than using an FPGA, assuming it's fast enough to work at all. At least in my experience, it's much easier to use a microcontroller than an FPGA. The development experience for an FPGA is more challenging, the tools are complex and confusing, it's difficult to wrap your head around what the Verilog or VHDL is doing, and the simplest operations seem to require 10x more effort and have 100x more bugs. But an FPGA would certainly give you the most flexibility and speed, and as Gorgonops mentioned the MCU might not be fast enough to meet tight timing requirements anyway. You'd have to look at where the critical paths are in a bus transaction, that can't be covered with wait states or something, and determine if the MCU could keep up.

 

An FPGA with integrated ARM would be neat, if you have a plan for the ARM. There are also simple open source soft-core CPUs that you can implement in the FPGA logic, if your FPGA has enough resources.

 

Supporting only true color sounds reasonable if you want to keep things as simple as possible. I think adding a CLUT is only a very small increase in complexity, though. Verilog pseudocode for a 640x480 frame buffer with 307200 pixels:

 

True color:

reg [23:0] frameBuffer[0:307199];
reg [18:0] pixelAddr;
reg [23:0] output;
always @posedge clk begin
    output = frameBuffer[pixelAddr];
    if (pixelAddr == 307199)
        pixelAddr = 0;
    else
        pixelAddr = pixelAddr + 1;
end

 

Indexed color:

reg [7:0] frameBuffer[0:307199];
reg [23:0] clut[0:255];
reg [18:0] pixelAddr;
reg [23:0] output;
always @posedge clk begin
    output = clut[frameBuffer[pixelAddr]];
    if (pixelAddr == 307199)
        pixelAddr = 0;
    else
        pixelAddr = pixelAddr + 1;
end

  

 

 

Link to post
Share on other sites

If you haven't seen it, here's a great discussion of how a basic NuBus video card works: http://dec8.info/Apple/How_the_Macintosh_II_Nubus_Works_Byte88.pdf If you can get your hands on the "NuBus Monitor" software they describe, it would be a very helpful debugging tool.

 

I was thinking that another advantage of using a CLUT is that it requires less RAM. Up to 800 x 600 x 8-bit will fit into 512KB, while anything in true color requires more than 1 MB RAM. That may not seem important, but I think it could be. The SRAM chips that I've seen top out at 512KB, so you could build a CLUT-based card using SRAM instead of SDRAM, making the memory interface much simpler. I know SDRAM interfaces are a "solved problem" and there are wizards and things to build them for you, but it always hurts my head just thinking about it. In contrast, an SRAM interface would be dirt simple to build and understand and verify that it's correct.

 

Here's an updated version of my earlier code, modified to assume the framebuffer is in external SRAM instead of internal FPGA memory. The CLUT is small and can stay in internal FPGA memory. Hopefully it's clear:

// SRAM interface
reg [18:0] address;
wire [7:0] data; 
// internal state
reg [23:0] clut [0:255];
reg [18:0] pixelCount;
// output stream to video converter 
reg [23:0] output; 
always @posedge clk begin
    // get a byte from the framebuffer in SRAM
    // the pixel count is the SRAM address
    address = pixelCount;
    // do a CLUT lookup for the framebuffer byte that was
    // fetched on the previous clock cycle
    output = clut[data];
    if (pixelCount == 307199)
        pixelCount = 0;
    else
        pixelCount += 1;
end

Additional minor advantages of the smaller memory requirement are fewer address bits to decode (so fewer I/O pins needed), and the ability to fit the whole address space of the card into the 1 MB slot space of the Mac's 24-bit memory map.

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

I've also been musing about the possibilities a FPGA with ARM SoC opens, just for fun. It might be possible to do some really neat stuff like running WebKit on the ARM cores and rendering to a framebuffer that's overlayed onto space within the window of a custom browser interface. A hardware web accelerator.

Sadly that's probably easier to pull off than the "obvious" use for an embedded ARM SoC, which would be to do Quickdraw acceleration with it, IE, essentially clone something like the 8*24GC. There's an article floating around explaining in detail how that card works and suddenly you're in a whole new world compared to the "here's an array of memory, point the CPU at it".

 

(Accelerated quickdraw introduced a ton of new concepts like off-framebuffer rendering, etc.)

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

I think true color is actually a natural choice to target at the beginning because it's what the HDMI TMDS encoder takes as input. Supporting B&W would require extra FPGA logic to stream 1-bit pixels and convert them into a 24-bit pixels to feed into the encoder. That is probably not hard but I wouldn't know where to begin with a design.

+1 for true color. Such would be the heart of the matter for any high end NuBus VidCard spec. and that's exactly what we're talking about here when you get right down to it. NuBus cards with CLUT for low color, low resolution (relatively) output would only have been used for gaming in Macs of the II-IIcx era. NuBus gaming abruptly ended when internal video was introduced with the IIci.

 

Only the IIcx lacks a spare slot for for a Toby or High Performance card from Apple which remain inexpensive on eBay. The added cost of a used MultiSync LCD is reasonable cost and far more attractive a proposition for any Mac collection, remaining useful in a primary workstation right up through the spanned screen Notebook setup from which I'm making this post and its eventual replacement. Said display is a better solution for gaming across the full spectrum of internal video Macs NuBus AND PDS.

 

The IIfx would be the only flyer in the NuBus group and should wait until such time as a 68030 PDS card might be targeted and achieved in a quest for 040 PDS. IIfx remains a non-standard, outer ring flyer even in that group and need never be targeted.

Link to post
Share on other sites
9 minutes ago, bigmessowires said:

If you haven't seen it, here's a great discussion of how a basic NuBus video card works: http://dec8.info/Apple/How_the_Macintosh_II_Nubus_Works_Byte88.pdf If you can get your hands on the "NuBus Monitor" software they describe, it would be a very helpful debugging tool.

It's several pages back, so I'll re-post my list of reference materials:

 

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

 

_______________________________________________________________________________________________________

 

I have the wood pulp based media version of Technical Introduction to the Macintosh Family, gone over it and not found any reason to add it to the list.

 

 

Link to post
Share on other sites
  • 68kMLA Supporter

Here is a summary of my thinking, back when I was looking at this type of project.

 

The FPGA development board I was looking at (something in the Spartan family) had a DDR2 chip on board and a rudimentary VGA out port on board.   The VGA port was actually something like a ridiculously crude (resistor ladder?) D to A converter, but servicable.

 

Code for displaying images through the VGA output for the development system was available.   Code for using the DDR2 chip was available.

 

My thought was that the starting point should be, as others (Gorgonops) have noted above, choose a segment of the DDR2 to use a frame buffer.    Point the VGA display code for the development board at that region of memory.    

 

Then the two tricky parts remaining, are:

 

1)   Provide a (mumble, what'sit'called?) ROM that will tell the host system this is a video card.  

 

2)   Provide an interface so that reads and writes on the NuBus (or PDS) interface come from and go to the segment of DDR2 being used as a frame buffer.

 

You can work up to these things in small steps.   I would start with:

 

1)  Get the VGA display code working.   Display a solid color or other test images.

2)  Learn to write to and read from the DDR2 using potted code.

3)  Learn how to point the source for the VGA display at the DDR2 chip.

4)  Change the DDR2 contents and watch to see the VGA display change.

5)  Interface the FPGA development system with the Macintosh electrically.
6)  Get the FPGA interface to the Macintosh bus working.   Try some simple write to/read from experiments from Macintosh to FPGA.  Perhaps something as simple as a program on the Macintosh that pokes an address in the FPGA/expansion card address space and lights up an LED on development board.

7)   Get the declaration ROM recognized/working.

8  )  Set up the declaration ROM to point at the segment of DDR2 chosen to be the frame buffer.  

Link to post
Share on other sites
  • 68kMLA Supporter

Ultimately, for VGA output, I was looking at something in this family for a, geeze, I'm having vocabulary failure today, the thing a majigger that acts as the D to A converter and changes a stream of pixel data into video out data.

 

 

ths8135.pdf

ths8200.pdf

THS8133.pdf

ths8134b.pdf

 

The THS8135 is less than $10 at Digikey.

 

But to start with, using the VGA output provided on the/a development system simplifies matters tremendously.  Leave all the CLUT stuff for later, unless the Macintosh requires it and won't work without it.

Edited by trag
Link to post
Share on other sites
37 minutes ago, Trash80toHP_Mini said:

+1 for true color. Such would be the heart of the matter for any high end NuBus VidCard spec. and that's exactly what we're talking about here when you get right down to it...

A couple comments:

 

#1: If you look at the advertising flyers for Apple's *own products* (I looked up a few when I was checking to see what grayscale depth things like the Portrait card support) Apple actually lists as a feature in some of them that the card can let you use fewer colors for greater performance. I *really* think you might need to take a step back and think about how fast these machines actually are. The Quadra 950 went to 24 bit color at 832x624 with PDS-speed VRAM and even at the time I don't think anyone would have described that mode as "fast".

The counter argument is, of course, that cards like SuperMac's wares that went up to 1600x1200 did exist, and in fact existed over Nubus, but they *were* accelerated.

 

#2: Handwaving games is great and all, but the fact is you *will* be sacrificing software compatibility if your main display is locked only into True Color mode, and while it may be all right for some people to say "oh, well for that stuff I keep around this old Multisync I connect to this other card/motherboard video" that's not a super helpful suggestion for a lot of other use cases.

 

#3: Seriously, a CLUT isn't hard and I wish I hadn't mentioned it. The sample driver code in the manual *does* lay out the boilerplate for what functions you need to support for handling the Quickdraw transactions that write values to the CLUT, the part that was missing was the code for actually writing updates onto the Toby hardware, which strictly speaking isn't important unless the goal is to make a register-level compatible hardware clone of the Toby. The reason I bemoaned that is at least when I skimmed it the first time it was unclear to me exactly where the hardware registers (including those to set the CLUT table, but a lot of the others too) are mapped in slot space and, possibly importantly how the division between the "RAM space" and "Control Space" is handled when both need to be crammed into a 1MB slice while running in 24 bit mode. This is a thing you're going to have to at least minimally figure out even if you have a card lacking a CLUT. And I'm sure the information is there somewhere, I just didn't really grok it the first time.

 

But, *shrug*, whatever.

 

58 minutes ago, bigmessowires said:

Here's an updated version of my earlier code, modified to assume the framebuffer is in external SRAM instead of internal FPGA memory. The CLUT is small and can stay in internal FPGA memory.


The dev board that's been bandied around for this has 32MB of (DDR?) SDRAM with a 16 bit bus width on it, the assumption so far has been that the framebuffer will live in that. (Which of course is going to necessitate a read/write buffer for the Mac to be able to reach it, but that shouldn't be a huge deal.) But, yeah, the CLUT should definitely live internally. It only needs to hold 256 24 bit words of memory, IE, less than 1K, so it shouldn't be a big deal.

 

4 hours ago, dlv said:

I wanted to elaborate my thinking: I think true color is actually a natural choice to target at the beginning because it's what the HDMI TMDS encoder takes as input.

One question about that? Does the TDMS encoder operate on "a word at a time", or is there some kind of streaming function with it? IE, are there primitives hard-coded into the FPGA board's hardware design that accelerate grabbing bytes straight off the DRAM memory? Unless something like that is in play then I don't see the problem with inserting a CLUT; as BMoW's pseudocode shows, you can basically think of the CLUT as if it were a 256 pixel long framebuffer, with the pixel value the output circuitry reads from the "clutbuffer" determined by using the data value fetched from the actual framebuffer as the address.

Even if there is some kind of "streaming" where "streaming" is a FIFO of some size on the FPGA that still shouldn't be a problem, you can load that FIFO with the results of the indirection described above, right?

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

×
×
  • Create New...