What Might Have Been

In total, the Antic Cyber graphics software pushed the limitations of the Atari ST well beyond what the engineers at Atari would have deemed reasonable. Atari Corporation was not a nimble or particularly aggressive computer developer, and they completely failed to evolve the Atari ST platform in a timely fashion. By the time Atari produced a computer with a faster microprocessor, the Antic developers had moved on and Atari itself was well on its way to oblivion. They had their chances to create a computer with a math coprocessor and better graphics hardware, but none was forthcoming within a reasonable timeframe for Gary Yost, et al.

Despite the stagnation of Atari’s hardware, Antic developers did perform some interesting experiments.

Material editor interface

Light configuration

512-color material renderings

Boris Tsikanovsky had made the entire ST color palette available through Spectrum 512, so logically, Tom Hudson experimented with implementing more advanced rendering techniques for CAD-3D. The result, which never got beyond the prototype stage, was a materials editor that could render smooth-shaded spheres with 24-bit color controls, transparency, texture maps and bump maps, all using Spectrum display code. Tom elaborates:

I was not terribly happy that Atari had not introduced any kind of math coprocessor, even though one had been promised for some time. Rendering times were very slow when using the Z-buffer rendering mode. I was also bemoaning the lack of more than 16 colors, something that was really holding us back.

Boris Tsikanovsky’s “Spectrum” technology, which provided 512 color capability, promised to help us out in the color department, and in fact I had a prototype materials editor running on the Atari that used the technology... Boris provided us with the code necessary to display the colors and it looked much better than the 16-color display. Unfortunately, the computations necessary to display the shaded spheres brought the ST to a crawl! I was dying to get the advanced rendering capability into the software, but without more computing power it wasn't going to be practical.

That’s when we started looking elsewhere.

Probably the biggest change was that we were originally looking at developing our next-generation software on the Apple computers. In fact, Gary had sent me a list of the various Apple hardware that we'd need to get going on the project and we were on the verge of ordering it when Gary told me about the newest technology on the horizon: The PC VGA video card!

This card, Gary said, would put 256 (!) colors on the screen at once in 320x200 resolution, the mode we had been using with 16 colors on the Atari. I remember thinking that this would be paradise. In addition, the 80386-based computers could be equipped with math coprocessors; something I knew was going to be vital. Gary also pointed out that the PC market was going to be much larger than the Apple market, which was an important consideration for a niche product like ours.

I have to say at this point that Gary was incredible at being able to look into the future and see what was going to happen. He pointed out that VGA cards were new, but by the time our PC product was ready to ship, every computer sold would be equipped with one. He was absolutely right.

And when I got my 386-20 PC and ported my prototype materials editor code over to it, the rendering times were about 15 times faster than the ST.

The basic rendering technology in that prototype materials editor—minus the Spectrum 512 code—ended up in 3D Studio Release 1.

Mark Kimball went even further: he designed and built his own graphics framebuffer for the ST that could display a 512 x 512 pixel image in 24-bit color. Mark explains:

Mark Kimball’s custom display adapter for the ST

It used a Texas Instruments 34020 video processor chip and interfaced to the ST using the internal expansion bus. The 34010 was a nice chip because it integrated the video output function (H & V sync) with DRAM refresh and image processing capabilities... To test the thing, I had to build my own socket for the ST video monitor (see arrow). The devices that are on the daughter card (sticking up vertically from the main board) are the DRAM chips and miscellaneous buffer IC’s. I took this photo on March 1, 2002. I haven't tried to run the old card yet, but unless it’s been “zapped” it should run OK.

... To demo the thing I used a bunch of true color images I generated using a home-brew ray tracing program. The ray-tracer, in turn, was written in a combination of assembly language and C, and used fixed-point math for all the ray tracer calculations (for speed). I used an enhanced version of Tom’s CAD-3D file format, with additional information about each object (like surface condition, reflectivity, transmissivity) tacked onto the end of the CAD-3D info. Since it was an experimental program, I had fun adding things like procedurally-defined surfaces, where a user-provided subroutine could run whenever a procedurally-defined object was “hit” by the ray being traced.

The combination of display adapter and ray tracer produced some nice images...for that time, anyway. I believe that Tom had left the ST community before I did the display adapter.