Hamby wrote:

Were there ever any ISA 3D accelerator cards? Even the original Voodoo was PCI, iirc.

Interestingly the 3dfx guys considered whether to make Voodoo compatible with ISA/VLB but chose to break with the past and support PCI only. Saw this in a great video, worth a watch:

https://www.youtube.com/watch?v=3MghYhf-GhU

@SteveC @Jo22
Yes thanks. Matrox ftp does have PG-XXXX files, which I already had, but can't find anything on SM-XXXX series (iirc thats why I contacted Matrox UK). I may have to revisit this as a summer project this year.

Here are some low-res images (dug out of my piccyes folder, cards are in storage somewhere) of the early ISA '3D accelerator' cards. The model number relates to the max screen resolution supported by said card.

SM-640 (IBM PGC compatible, unknown how this is actually implemented)... NOT MINE (found on vcf iirc) !!

SM-1024 (TMS320 PCB is from SM-1281, memory looks to be the same amount as 1024 rather than 1280(1)).

PG-1281 (TMS34010), max res is 1280 (the 1 in the 1281 means it was later a rev to PG-1280)

I don't have any of my Iris Vision (and its MCA not 'thread relevant ISA' anyhows). If anyone wants higher res (ya know, to see the chip numbers in 'all), next oppotunity I get, I'll dig them out and take some better snaps.

The Virtuality VR system used ISA based 3D video cards. The entire system was on a 14-slot ISA backplane

http://wiki.skullspace.ca/index.php/Virtuality_SU2000

The Serpent Rider wrote:

For gaming? No. VESA local bus had at least one: http://old.vgamuseum.info/benchmarks/1208-cre … laster-vlb.html

I have one of these in the original box 😀

dirkmirk wrote:

The photos dont work anymore but I'll always remember when Vets found a boxed version of the Matrox Impression, only supported 3 games.

Bought these (retro) hardware today

http://old.vgamuseum.info/home/1172-matrox-im … ession-isa.html

Pictures fixed in the original thread.

Some screenshots of the supported games here: Re: 3D Accelerated Games List (Proprietary APIs - No 3DFX/Direct3D)

Some mid 90s arcade systems had 3d isa cards. They weren't truly ISA. Just physically ISA.

PDAisAok wrote:

The Virtuality VR system used ISA based 3D video cards. The entire system was on a 14-slot ISA backplane

That's interesting.
I knew of Virtuality because I was an Amiga user at the time, and the first generation Virtuality systems were powered by Amigas, so it was a hot topic in Amiga magazines, and among friends etc.
I never knew there was a second generation based on PCs.
According to Wikipedia, they were introduced in 1994, and use Motorola processors (not specific graphics processors it seems, but general purpose): https://en.wikipedia.org/wiki/Virtuality_%28gaming%29

TIGA programming manuals are available.....see no problem here - have some onsite...for example...
TMS340 Family C Source Debugger User’s Guide - tiga_spvu021a_sourcedebugger.pdf
TMS340 Graphics Library - tiga_spvu027_graphicslibrary.pdf
TMS34010 User's Guide - tms34010userguide_88.pdf
All of them at http://vgamuseum.info/images/doc/texas_instruments/

Biggest problem is that tiga cards needed loaded resident drivers and since each card was unique (different memory sizes), you need to find drivers just for your card.....

One more ISA 3D-board not mentioned yet ist the SPEA Fire board, featuring the intel i860 RISC processor. The board was availiable as a 3D add on board or as a daugterboard for the SPEA-FGA TIGA boards, together building the FGA-860. Both variants are full size ISA boards featuring up to 4 MB RAM for the i860 additional to the VRAM used as display buffer. For the TIGA boards mentioned above: AFAIK these were only 2D accelerators that were overcome by the bunch of windows accelerator boards showing up shortly after the time TIGA was introduced. The Irisvision is 3D for sure, but the MCA-version was only supported by RS/6000 Unix boxes and never made it to the IBM PS/2 PC-line. Not sure if the datapath QPC series featuring an AM29000 CPU were 2D or 3D, as I never really installed one of these boards in a system (mainly du to the lacking an SMB-connector monitor cable at this time).
eisapc

Number Nine had a demo showing some capabilities of the TIGA chipset. I captured it in 2011: https://www.youtube.com/watch?v=U9HkUA9REHc
I have still two fully functional cards, however never started programming for it. Though since the DSP is fully programmable it is very likely that some simple on chip '3D engine' is possible.

spiroyster wrote on 2018-02-05, 14:32:

@SteveC @Jo22 Yes thanks. Matrox ftp does have PG-XXXX files, which I already had, but can't find anything on SM-XXXX series (ii […]
Show full quote

@SteveC @Jo22
Yes thanks. Matrox ftp does have PG-XXXX files, which I already had, but can't find anything on SM-XXXX series (iirc thats why I contacted Matrox UK). I may have to revisit this as a summer project this year.

Here are some low-res images (dug out of my piccyes folder, cards are in storage somewhere) of the early ISA '3D accelerator' cards. The model number relates to the max screen resolution supported by said card.

SM-640 (IBM PGC compatible, unknown how this is actually implemented)... NOT MINE (found on vcf iirc) !!
SM-640A_4.jpg

Neat, so there were some 8-bit PC 3D accelerators out there, or at least that one.

I don't think there were any historical examples of 8-bit PC/XT slot compatible 3D accelerator or coprocessor boards actually posted in this thread:
8 bit 3D card

Also, the 3DO blaster is neat, but I assume it had all the same restrictions placed on it as the 3DO console. ie software could only be programmed through the proprietary software libraries, compiled and encrypted to the 3DO company's software standards. So no low-level access to hardware or potential for 3rd parties to develop (or port) other APIs to it. So performance was just as bottlenecked as the console and the PC itself just acts as a glorified power supply.

I'm pretty sure even the first wave of 'standard' PCI 3D accelerators had more low-level hardware access than that, as did the other 3D-oriented game consoles, and they needed it to get decent performance. (even on the Playstation, while the GPU side of things fared pretty well with Sony's graphics API, devs still needed to write efficient code to the host CPU and manage the Geometry DSP effectively, which also typically meant some assembly language optimizations added to compiled code, and also the potential for custom in-house or even game specific C compilers to make best use of the R3000A)

Otherwise the 3DO Blaster, even in ISA form should've been able to benefit a great deal from the host PC's CPU working in parallel with the 3DO hardware, potentially relegating the 12.5 MHz ARM 60 primarily to the role of controller/manager of the GPU (or rather, the Cel engine texture/sprite/polygon processor and the geometry DSP) as well as acting as the audio controller.

The PC's CPU could run the entire logic and AI portion of the game engine on its side and offload all of that from the 3DO's rather limited CPU. You could also potentially split the 3D geometry overhead between the PC x86 host CPU and the geometry DSP onboard the card.

The 3DO itself is pretty bandwidth choked with the ARM CPU having no cache and no local ram, but sharing the 2MB of main memory as texture/sprite memory. (the 1MB of dual-port VRAM was used for the framebuffer) Though that also meant that games using very low res textures or lots of untextured, shaded polygons ended up giving the ARM 60 a lot more time to work in RAM, sort of like having a 12.5 MHz 386DX with 2MB of 0WS 80ns DRAM installed along with an AGP style local bus interface to the video card with DMA used to load pixel and texel data and render it to the framebuffer.

The Atari Jaguar has a similar problem, though with an even slower 13.3 MHz 68000, though tricky programmers sometimes worked around that and pushed more than just T&L and polygon set-up rasterization duties on the RISC GPU core at the expense of lots of paging chunks of code into the 4kB local program RAM, since the GPU can't normally execute code from main memory. (as a pure 3D accelerator, the GPU should be handling 3D vertex math as well as handling the rasterization in concert with the blitter, setting up each line of a polygon and sending blitter commands to do flat or gouraud shaded line fills or draw flat or gouraud shaded texture spans, the latter being substantially slower than the former) The GPU is also supposed to be tasked with writing complex object lists for sprite-heavy games using the object processor, but that's a whole other side of the hardware.

Oh and bear in mind the 3DO, like the Saturn and Nvidia NV-1, used forward texture mapping as well as quadrilateral primitives. The latter isn't that unusual (and I believe a number of software renderers natively did quads), but forward texture mapping is a lot more exotic and has some quirks, namely issues with overdraw and both performance hits and rendering artifacts related to that overdraw. In addition to that, you're limited to a 1 texture to 1 quad basis, no applying a texture stretched across a polygon strip or fan, so textures need to be sub-divided appropriately and also pre-processed accordingly. (unless the polygon is a true square or rectangle, you need to draw the source texture as intended in its non-square quad or triangle form and then stretch it out to fill a square or rectangular texture matrix or texture 'stamp', so when rendered it gets skewed back to the intended shape and looks right)

Typical reverse texture mapping has non-linear texel fetches and linear pixel writes, but forward texture mapping has linear texel reads and nonlinear pixel writes.

Rather than rendering spans (lines/rows) of pixels, traversing the raster and making 1 texel fetch per screen pixel, you do a single texel fetch and then spit that out to the screen as many times as needed to fill the scaled/skewed translated area. This mostly works fine when you take a low-res texture and scale/stretch it up, but when you have a texture being shrunk/squished it means you have to over-write pixels (you scan through every texel once and end up writing pixels to the same screen location multiple times) but you also end up corrupting/distorting gouraud shading and translucent blending effects since overlapping pixels end up blended together rather than just the final output pixels being blended with the framebuffer.

There's the additional issue that forward texture mapping is difficult to optimize burst/page-mode writes to the framebuffer and you effectively need a pixel destination cache/buffer to do that. OTOH, the linear texel reads means a texture cache is largely unnecessary. (implementing a tile-deferred rendering scheme with a destination buffer corresponding to a fixed tile size might have been an option for developing that system further ... I wonder if Nvidia's NV2 GPU went that direction)

A render output cache/buffer would also potentially have solved the alpha blending error issue as the blending stage could be applied to the resulting 2D output tile and not during the 3D texture translation and rendering stages. (making heavier use of light maps and avoiding gouraud shading on textured polygons could avoid the distorted lighting effects, too) Applying bilinear filtering to the render output tile would also probably be the way to go there. (doing it in the 3D translation and rendering stage would have the same overdraw blending issues as translucency/alpha blending)

the first wave of 'standard' PCI 3D accelerators had more low-level hardware access than that

Only accelerators with DOS support. Which most didn't had.

Also, the 3DO blaster is neat, but I assume it had all the same restrictions placed on it as the 3DO console.

Obviosly, because it's 3DO console card. To play effing 3DO games on a computer. Everything else would only further broke compatibility, which isn't 100% even between 3DO consoles.

crazy stuff, thx for sharing...!

In Japan there was the NEC PC-FX GA. This like 3do blaster was basically a PC-FX console on a board, however it does have a special 3D polygon producing chip that the stand alone console never got. It even came with 3d dev software in the box for 3d homebrewing. Being Japan, most GAs were C-bus (pc-98), but a standard ISA version was also sold for regular pc combatibles (DOS/V) too.