But #4 would probably be a much better place to start. Figure out how to interface with the Macintosh OS and bus without having to deal with the complexity of fancy memory with refresh requirements and such.
Darn, the short editing period. I meant to write, "But #5 would probably be a much better place to start."
#4 would be a nightmare as a place to start.
Here are some photos of the Micron Xceed Grayscale setup I acquired not long ago
Very nice. If you ever have them out of the SE/30 again, any chance of putting them on a scanner to produce images in which the chip part numbers can be read? Or do you have higher res. versions of photos #1 and #7 from that spread?
I think it would be interesting to do a comparison of the chips on #1 with a Daystar PowerCache '030 card to see if there is a one-to-one correspondence in the chips used. With a IIcx adapter, one should, in theory, be able to install a PowerCache '030 in an SE/30 CPU socket (physical layout problems ignored). And the IIcx adapter has no chips on board. It's just wiring. So, the cpu socket Daystar upgrade may contain exactly the same stuff as a PowerCache 030.
I'm not sure what use that info would be, other than being kind of interesting...
On photo #7, you seem to have a version of the video card which is considerably different from the one I've been finding images of. Do you know what the part number is on your video memory chips? There are sixteen of them there, and a bunch of chips downstream. It looks like it could be much closer to the description I read, and less like the description in the patent. In other words, yours might have the 64 bit wide memory arrangement. Do you know what resolutions are supported by your card?
Fantasy Requirements
2) Drive the external monitor at 24 bit color up to 1920 X 1280 at 60 Hz.
It might be amusing to cook up some tests to see just how long it takes a 16Mhz 68030 to redraw a framebuffer of that size. My guess is "quite a while".
Back of the envelope... 1920 X 1280 = 2,457,600 pixels. If millions of colors, then it's one word per pixel, so 2,457,600 words. The SE/30 bus is 16 MHz, but I don't think it can manage better than a write every two cycles. At least the timing diagram I saw seemed to indicate that the address goes up one cycle and the data doesn't go up until the next cycle.
In theory it might manage 8 Mwords per second. However, that's leaving no time for calculations. If it's just moving data from memory to the frame buffer, then, even if it never waits for the frame buffer, it will still be slowed down by the motherboard RAM. What is the memory (RAM) performance on an SE/30?
Still, unless the RAM is a lot slower than the CPU, it might be able to write a frame buffer that size a few times per second. But it wouldn't be doing any rendering, as you mention later.
Personally I'd shoot for a prototype that was #5 on your options list but eh, I'm an idiot.
No, not at all. I mean, you're not an idiot. I think that's a good idea.
I thought about it last night. There may be an even simpler option.
The Xilinx Spartan 3A(N) Starter Kit is $189 ($199 for 3AN) and it includes a VGA connector and some demos which drive video. There is also a DDR2 chip soldered on the board and some DDR2 controller demos.
The easiest start might be to focus on interfacing the Spartan 3A Starter Kit to an SE/30 in a way that will cause the SE/30 to write to the Spartan 3A as if it is a video device.
My vague understanding from reading random documentation is that *essentially* all you need to provide in a driver for QuickDraw to use a piece of video hardware is essentially just a descriptor block which indicates where in memory the framebuffer is and some attributes describing its pixel/color depth layout.
I think I remember the same thing from reading "Designing Cards and Drivers for " So the first step would be getting the Spartan 3A to interface with the SE/30 PDS slot and provide a firmware thingy (can't remember the name) that tells the Mac that there's a video card here. Then have the Mac write data into the Spartan 3A and use the code from the demos to output that through the VGA port on the Starter Kit board.
Once that is working, one can expand and modify as desired. This has several advantages. Using the resources on the Starter Kit means that there's no need for extra circuit boards beyond something to connect the SE/30 PDS slot to the Spartan 3A Starter Kit FX100 connector. No need to try to implement the DAC or the DDR controller or any of that stuff early on.
Start with something low resolution and shallow bit depth and use the block RAM in the FPGA for storage. Maybe 640 X 480 X 1 bit to start.
I don't know much about FPGAs, but I sort of wonder if you might even find one that could do a 1MB framebuffer internally and not even need an external chip.)
There is 360K of block RAM available on the Spartan 3A included in the Starter Kit. 460K if you don't mind eating up your other resources, which, of course, you can't, not entirely.
But for early experiments, this would work fine. Each bit of color depth for 640 X 480 needs 307,200 bits, or 38,400 bytes. One could implement 640 X 480 X 8 bit video resolution just using the block RAMs in the FPGA.
So the initial challenges would be to
1) Build an interface board from the SE/30 PDS to the Spartan 3A FX100 connector.
2) Program the FPGA to recognize when it is being addressed by the Mac and to simulate a Declaration ROM (hey, I remembered what it is called!) to the Mac.
3) To respond to read and write requests from the Mac to the frame buffer memory described in the declaration ROM.
4) To modify the Starter Kit Demos so that the image output to the VGA port comes from the memory that the Mac is reading and writing.
It doesn't look so bad when laid out like that. Once that's working, more intricate stuff can be added. The trick is getting the first thing working.
All programming boils down to debugging an empty file until it does what you want...
(With a low-enough bandwidth cap I'm sort of wondering if you could dedicate most of the FPGA's pins to the SE/30 interface and use a narrower 8-16 bit interface to the framebuffer.
Hmmm.
The SE/30 data interface is 32 bits wide. The frame buffer might as well be at least that wide. If one cuts the frame buffer from 32 bits to 16 bits, half of the bandwidth is lost and the supported resolutions either go down, or the memory must run faster.
Consider these two cases:
Case 1) The data bus runs through the FPGA
Case 2) The data bus does not run through the FPGA
In Case 1, narrowing the video memory saves FPGA pins. There's a sort of cliff beyond which that doesn't matter. More in a bit.
In Case 2, narrowing the video memory doesn't really save anything.
It's a lot simpler to only support 8 bit color than it is to support 24 bit and 8 bit. But it's not simpler because the memory is narrower. It's simpler because you don't have to provide for a mode where 24 bits go to the DAC per pixel and another mode where only 8 bits go to the DAC per pixel.
So, Case 2 isn't very interesting. If the data bus isn't on the FPGA, the width of the data bus just doesn't affect complexity much.
Let's look at Case 1.
The cliff I mentioned above is when you pass about 150 I/O pins on the FPGA. That's the most you can get out of a non-BGA package. If you need more than 150 I/O pins, you're either using a BGA package, or you're using more than one FPGA.
Let's count the pins.
The Case 1 FPGA must interface with these Address & Control lines:
1) SE/30 PDS slot address and control lines; about 32 + 10 lines, but could be 10 + 10 with some extra chips
2) The video memory address and control lines; 15 - 20 depending on the type of memory
3) The DAC control lines; 6 - 10
4) Other miscellaneous (e.g. Flash for Declaration ROM); 20
So that's about 94 lines for address and control. That leaves 56 for data.
(Note: We could reduce the address and control lines a bit by adding extra logic on the circuit board, for example, use latches to store the address when the Mac is addressing the Flash ROM, then we would save about 16 address lines. But this would cost more and defeat the purpose of putting the data bus on the FPGA. The idea is to keep the component count to a minimum.)
The Case 1 FPGA must interface with these Data lines:
1) SE/30 PDS slot data: 32
2) DAC: 8 for 8 bit color; 24 for 24 bit color
3) Flash ROM: 8
4) Video Memory ?
The number of I/O pins left available for video memory is 56 - (32 + 8 (or 24) + 8 ) = 56 - 48 = 8.
So, maybe we could build a card with 8 bit wide video memory and get it all on an FPGA in a 208 pin QFP package. Let's look at some bandwidths. These are all the minimum theoretical bandwidths just to support the display and ignore refresh and the need of the host computer to access the video memory. All assume 75Hz refresh and 8 bit color depth:
640 X 480 23 MHz
832 X 624 39 MHz
1024 X 768 59 MHz
1280 X 1024 99 MHz
I don't think you can get any of those with cheap FPM or EDO memory. A -60 rating isn't even going to support 16 Mwords/second real transfers. Some of the more expensive SRAM will hit those levels, but it's expensive. One would have to go to Synchronous DRAM (SDRAM), the old PC100, PC133 memory to get up to those speeds, but at this point in time, it's more expensive than DDR2 memory.
And buying individual DDR2 memory chips is more expensive than buying a whole 64 bit wide DIMM.
I could use old slow SRAM in my fifth concept in the earlier post because I was using 32 bits or 64 bits of width. Here, we're only using 8 bits of width, because that's all the pins left on the FPGA.
I guess one could install a DDR2 DIMM and only use 8 bits of the width... That would work.
Except that DDR2 requires some supporting signals to time the signal properly, so those eight bits would need more than 8 I/O pins. Sigh.
You see how tough it is to fit all address, control and data lines into a non-BGA FPGA even if you narrow the video memory to 8 bits?
So, the only case in which narrowing the video memory width really saves you FPGA resources, is when the data bus is on the FPGA and when you stick to 8 bit wide video memory, and that will be either expensive or not feasible -- or you could support 4 bit color and below.
As soon as you go to 16 bit video memory, you've blown your FPGA pin budget and are into BGA packages with higher pin counts. Once you're at that point, you may as well zoom right past 320 and 400 pins and go straight to 484 pins. This gets you 372 I/O pins. More than twice as many as with the 208 pin QFP package.
Since you can clock the FPGA and suitable RAM so much higher than the SE/30 you might be able to get away with a solution as simple as running the framebuffer at effectively twice the speed of the bus interface and using an even/odd cycle for display reads and CPU access.
I'm not sure what you're getting at here.