Yes, Atari used these on: Battle Zone, Red Barron, Tempest, Star Wars, Empire Strikes Back, and I, Robot. That last one has a custom rasterizer chip and AFAICT was the only system to pair what was effectively a GPU with an 8-bit processor (MC 6809). The thing is, by the time the last 3 were produced it probably would have been technically better/simpler to use a 68K for the 3D transforms.
I used to work with the guy who designed the hardware, Dave Sherman. Man, he had a lot of insider stories about the glory days of Atari!
Anyway, there was no depth buffer. As I recall, the geometry was all pre-split in a way such that occlusion could be handled by sorting at the polygon level instead of the pixel level.
I also seem to recall the native screen resolution was 256x240, but they used one extra bit per pixel that could be used to stretch a given pixel by 1/2 a pixel resolution, effectively giving 512x240. There were situations where the trick didn't work, but 98% of the time it worked well.
>> they used one extra bit per pixel that could be used to stretch a given pixel by 1/2 a pixel resolution, effectively giving 512x240
While reading about the reverse engineering by emulator authors. There was an extra bit in the frame buffer that no one seemed to find the use for. That should be reasonably easy to verify from schematics given a heads up.
That may also explain why some of the YouTube videos look so bad around the edges compared to the real thing. They are probably recorded from MAME and dont account for that bit if that's really what it does.
It also seems like that could only effect the right edges of polygons.
There are 2 frame buffers and I believe one is used for scan out and the other is only written to, then they swap roles. So no z-buffer and no reading back pixels.
It has a bit more detail about the pixel format. Unlike what I said, it was 6b color index and one bit for video timing (what I was calling 1/2 pixel stretch). In essence it conveys whether the right edge of a given scanline is best represented by a transition in the middle of a pixel. That works great for most cases, but would not work well when edges from two different triangles intersection (if they weren't actually sharing the exact same edge, if you know what I mean).
This site has schemtics: http://www.ionpool.net/arcade/irobot/manuals.html
Page 17 shows the 7th bit, called "RAWHALF", which gets buffered to become "PXSPLIT", and that signal is used to fiddle the clock which is sampling the raw pixel index. I didn't dig enough to know exactly what this means, but that is the place to look.
I was wondering why they didn't use that hardware for more 3D games. Looking at some of the emulator documentation, it seems the playfield was drawn by a function running on the Mathbox (co-processor) which would be really hard for most people to program. It was 4-5 years before they produced another 3D game with rasterized polygons using completely different hardware.
I took a look at the Star Wars arcade video game schematics, and I don't see any Am2901 chips (unless they obfuscated it really well).
The schematic is interesting if you're into that sort of thing. They use two 6809 processors (one for sound effects). There's also a complex matrix processor built out of TTL chips. It does serial multiplication and division using latches and shift registers and adders and so forth. Then there's a bunch more circuitry to generate the analog signals to produce vectors on the screen. It's like a whole different world compared to how this would be implemented now.
Yeah, the 74181 was a bit earlier, but what's interesting is that bit-slice is a generic building block technology. For example, the VAX 11/780 used '181s, but the compatible 11/730 used 2901s. It's all about how the control microcode is written.
The '181 evolved into the 74281 and 74481 with more functions. Then TI jumped to the 74as888 line, which is an 8-bit slice. There are also things like the IDT 49c402, which is basically 4 x 2901 + a 2902 on a single chip.
I have the official AMD design handbooks still with me. It's been in the basement for over 30 years. I remember calling AMD and requesting the handbooks when doing my master's in CS as my major was microprogramming. The ALU (the 2901 described here) came with a whole family of chips - essentially everything you need to make a CPU.
When you get done with that and want your mind blown, check out the micro-sequence controllers and compliments like the am29803 branch control unit (hardware 'case' statements) and am29811 next address unit (hardware state machine support).
I've always wanted to play with one of these, ever since I heard about them as a kid back in the 80s. Always found the idea fascinating that one could put together one's own processor out of pieces.
Bit-Slice Design: Controllers and ALUs by Donnamaie E. White
Bit-Slice Microprocessor Design by John Mick and James Brick