SuperVidel Graphics

Shiuming Lai interviews Henrik Gild of Nature, the Swedish dynamic duo behind the next most exciting CT60 thing after CT60 itself

Shiuming: First of all, let's start with something slightly off-topic: we were expecting some new pictures of the current status of the SuperVidel card, but you've also sent us a very interesting extra, do tell us more.

Henrik: We grew tired of the lousy cartridge port of all our three Falcons, which crippled the EtherNEC very efficiently to 5 KB/s. Therefore we designed the EtherNat in about three weeks which I think is a personal record. This won't delay the SuperVidel, don't you worry. I got two weeks spare time at work, of which three days were put into very efficient routing of the EtherNat. Therefore it's completely routed now, as you will see from the picture! I just need to simulate a bit, which probably leads to some small adjustments.

Then we'll produce a prototype to see that it works, and then all who want some faster networking for their CT60 Falcon may buy their boards from us. While waiting for the prototype I'll continue routing the SuperVidel at work, until I'm assigned some new project to work on. Hopefully I'll get all of next week for that!

Shiuming: Now getting back on track - what gave you the motivation to develop a graphics card for the Falcon? Was it an idea you had before the CT60?

Henrik: The idea was born a few months after the design of the CT60 was started by Rodolphe, but the idea had to mature almost a year before we even began designing the board. First we thought that we could use the SDRAM of the CT60 for graphics memory, but our calculations later showed that the bandwidth wouldn't be enough. So we threw in our own SDRAM, which later was upgraded to DDR SDRAM. Currently we're aiming at 128 MB DDR SDRAM running at 166 MHz (DDR333), yielding a theoretical maximum bandwidth of 2,700 MB/s.

Shiuming: You guys were previously known for Falcon software, particularly games. Hardware seems to be a new direction, have you always been interested in hardware? It seems like you have suddenly developed a lot of hardware design knowledge.

Henrik: When looking back at our Atari history, it looks like we've continually dug deeper and deeper into what makes our Atari work. We started out with coding BASIC (STOS) at the age of 12, leaving some half-finished games and one finished game behind. At the age of 13-14 we tried understanding the assembly listings of Peter Molyneux in ST Format. When we got syntax errors on all our assembly instructions that we entered, we gave up. A year later we discovered that those errors came from the fact that we had typed the instructions in the left-most column (where the labels are supposed to be)! No wonder Devpac complained...

That was an important turning point. Soon we had included some assembly code into our STOS programs, which made parts of the code 35 times faster! At the age of 15 we managed to write our first assembly-only program that uses the blitter for displaying a picture on the screen. Can you imagine our joy when it actually worked?! After that came among other things Reeking Rubber and Aces High. 19 years old we both began studying computer engineering at Chalmers University of Technology. I settled for a Bachelor's degree, while Torbjörn went for a Master's degree. Frankly I didn't have the marks to enter the Master's degree, after all someone had to do the coding of our games, and all Torbjörn did was studying (Torbjörn: Yeah, right!). But thanks to my choice of the Bachelor's degree I got a job at Volvo Technology right after school. When Torbjörn finished his studies two years later, the tide had turned and it was very hard to find a job. Currently he's starting up his own business together with two friends, and he has been developing VHDL code for almost a year and a half now. The skills he has acquired by doing so will be very useful in the SuperVidel project.

At Chalmers we both chose the courses that were dealing the most with hardware. This meant that Torbjörn was writing VHDL code, while I built a small 8-bit computer based on the Motorola 6809, though I didn't get to design any PCB. Since we began the SuperVidel project we've been improving our skills in these areas. I was completely new to designing PCBs when we started working on the SuperVidel two years ago, but since then I've designed six boards, five at home and one at work, all with increasing complexity but also quality. I've been following a steep learning curve during these two years, which I think has been possible only because I'm very interested in doing hardware for the Atari community. The board I designed at work is a four-layer board, and I got to do the entire schematics, layout, and routing of the board. The senior engineer I worked with was very satisfied with the results.

The EtherNat board is also four layers, and I think it's an important checkpoint to complete this board before trying to finish the SuperVidel, to gain the necessary experience of dealing with manufacturing firms and issues related to this.

Shiuming: Please explain the special parts of the SuperVidel design, technical specifications, changes in design and the things that made it possible.

Henrik: First we had four DDR SDRAM chips in the TSSOP package (pins along two sides of the chip), but this turned out to be too hard to route, so we removed two of them. Then the simulation software complained about several tracks being too long when having such fast signal rise/fall times as the DDR memory has (less than 1 ns). Therefore we switched to the BGA package (pins below the chip), which is much smaller. This means that we may place the memory chips closer to the FPGA, so that the simulation looks much better. Also since the BGA packages are much smaller we may place four of them on the board again.

While I was doing these changes, I also wanted to try auto-routing the board to get it finished faster. But even though I spent a lot of time setting up the auto-router, the results were poor, and in the end I decided to route it manually. These changes are the reason why the screen-shot of the SuperVidel looks like a big step backwards. But even though the DAC and all the capacitors have been unrouted, it won't take much time to redo this, since the correct pins of the FPGA have already been chosen. What's taking time is the process of routing some signals to the FPGA, then unrouting them again to move the signals to better situated pins of the FPGA, and then routing at the new position.

Shiuming: There is no DVI output on the design. What steps have you taken to ensure a high analogue output quality? Considering the extended resolutions, the signal must be as clean as possible, especially at high refresh rates. I remember the Milan's bundled S3 graphics card severely lacked sharpness and purity when the refresh rate was increased much above 60 Hz.

Henrik: The DAC test board was designed to visually test the picture quality, but we haven't measured anything yet. We do have problems with the picture quality because there is something fishy with the DAC board. This is very strange because I've designed three boards in total with this DAC and the first one has perfect picture quality, while the latter two don't... I've contacted Analog Devices, who makes the DAC chip, and they asked me to send my schematics and PCB documents to them. So now I'm awaiting their answer, which will hopefully solve the problems and help me avoid the same mistakes on the SuperVidel. That would have been much more costly.

Shiuming: Previous graphics upgrade solutions for the ST onwards have been based on making bridge boards for existing ISA or PCI graphics cards. Clearly your design is far more sophisticated and integrated than a simple bridge logic board with plug-in device card, but what made you decide to develop your own complete graphics core rather than using an off-the-shelf design from ATI or Nvidia, for example? Is it purely the quantity involved, or are there issues with documentation, too? My own observations suggest that users tend to have difficulty tracking down suitable graphics cards, as they are often obsolete models.

Henrik: There are a few things that made us settle for this solution:

Making a bridge board, which would also have required an FPGA, would have been almost as expensive as making the SuperVidel. And on top of that the user would have to buy a graphics card.
A "real" graphics card from ATI or Nvidia would certainly be faster than ours at certain aspects, especially at 3D. But you'd need a Pentium 2 GHz to use its full potential. If you've run 3D benchmark programs on PCs which differ at CPU speed but with the same graphics card, you'll know that the graphics card isn't the only bottleneck, the graphics card requires the CPU to do a lot of work, too. Modern graphics cards from ATI or Nvidia usually have a memory bandwidth of at least 6.4 GB/s. The SuperVidel will have 2.7 GB/s (if all goes well). I think this may be considered as something to "grow in" for the Atari computers!
This one is related to point 2: Since we'll implement our own 3D engine, we have the opportunity to let the SuperVidel do much of the work that the CPU would have been required to do, had we chosen an ATI or Nvidia card. For example, we're thinking of implementing a 4x4 matrix multiplier in hardware (the FPGA) on top of the other texture-mapping stuff. This is extremely useful for rotating and translating 3D polygons, and relieves the 060 from this quite heavy task (16 multiplications per polygon).
Keeping the old Videl register set-up, only extending it a little, feels much more like a real Falcon compared to using a PC graphics card. That's part of my personal dream about the Falcon, seeing the Videl go beyond 800x608!

Shiuming: How many layers is the PCB?

Henrik: Six, three for signals and three for power/ground. Usually a six-layer board uses four layers for signals, but we need three power/ground layers because there are so many different voltages involved: 1.2 V (FPGA core), 1.25V (DDR termination and reference), 2.5 V (DDR), 3.3 V (DAC and CT60), 5 V (regulators reference). The grounds have the same amount of variations.

Shiuming: What features of the CT60 are good for SuperVidel? Full 32-bit expansion bus?

Henrik: The 32-bit bus is certainly a must, otherwise moving things on the screen (without the super blitter) would have been very slow.

Shiuming: As far as extended graphics functions are concerned, how will you support developers in making the most of them? Will there be a SuperVidel developer kit with libraries and tools?

Henrik: We will write a very detailed documentation of the hardware registers. If someone wants to make a C-library or assembly source for others to use, they can direct their questions to us when the time comes.

Shiuming: What will be the possibilities for over-clocking SuperVidel? Do you have variable clock generator or socketed oscillator like CT60? Temperature monitoring?

Henrik: We will already run the SuperVidel at the highest possible frequency. Its working frequency will be a derivative of the CT60 clock. We haven't thought of temperature monitoring, because it won't be applicable if the SuperVidel can't be overclocked.

Shiuming: Do you think when you have finished the SuperVidel that you will once again have time to devote to finishing some of your game projects?

Henrik: Hopefully. I'm dreaming of seeing Reeking Rubber in glorious 640x480 30-bit, fully texture-mapped and running smoothly on the CT60+SuperVidel! But I think we'll be locked up for updating the FPGA contents for a while, making the super blitter faster and faster for example.

Shiuming: Tell us some of the design challenges you have faced and how you overcame them.

Henrik: Well, the whole thing has been a big collection of design challenges, some tougher than others. The biggest one is getting the DDR memory routed, but I feel that I'm very well on my way with that. If you have a look at the current SuperVidel screen-shot, you'll see that the only thing routed on that board is half of the left DDR chip. But I'm very pleased with the result, because there is plenty of room for routing the other half. Then I only have to copy this for the other three DDR chips!

Making the schematic part for the FPGA was a big one too. Since it has 456 pins, it took three days just to enter all the names of the pins and putting them at the right position.

Another big design challenge was how to get the picture out to the chassis of the Falcon. You wouldn't want to have a thick monitor cable running inside your Falcon, so I designed a small flat cable so the VGA connector may be mounted on the back of the Falcon as usual. This cable has 16 positions where the R, G, B, and sync. signals run. Between the R, G, and B signals there are ground leads to maintain 70 ohm impedance. This according to the manufacturer, that states that a G-S-G (ground-signal-ground) configuration will yield 70 ohm impedance for the signal. This should have been 75 ohm, but this was the closest we could get. I'm quite proud of this invention, because it works!

Shiuming: G-S-G, now that I seriously like. I certainly look forward to the results, and I know exactly where to find one of the first SuperVidels to enter the UK for closer inspection...

shiuming@myatari.net

MyAtari magazine - Feature #11, June 2004