Tag Archives: graphics

TIGA – The basic stuff

Welcome to the TIGA basics page! The fist post in my little TIGA chapter.
You probably came here because you just got (or plan to buy) a cool, shiny TIGA card and like put it to some use. Or you’ve read about it and found out, that the Web is pretty thin on that matter… Anyway, you came to the right place!

Let’s check some points fist…


Well, if you have a card already, great, you’re set.

There were/are different versions around. The early cards used the first implementation of the graphics controller called TMS34010  which was clocked up to 60MHz (amazingly high!). For example TIs very own “TIGA Star”:

Later models used the advanced TMS34020 which started at 33MHz up to a max of 40 but had faster instruction cycle times, a faster memory interface and a twice as big instruction cache (512 bytes. Yes, bytes). Additionally the ‘020 supports the rare TM34082 floating point co-processor (actually even more than one) to speed up 3D calculation. I’m not aware of a Tool using that…

One of the first ‘020 cards was probably the Diamond from TI, which even features a socket for the FPU:

My weapon of choice is the mighty Miro TIGER:

Every TMS340 has its own RAM to run “programs” in. Depending on the model this starts at 1MB and can sometimes expanded up to 17MB. Better cards used SIMM to do this, but there were some models which used  proprietary RAM modules which are nearly impossible to come by these days.
Next the TMS340 needs VRAM, the memory holding the graphics itself. Again, depending on the model, this might vary from 1 to 4MB resulting in different max resolutions. IMHO just 1MB doesn’t do a TIGA card justice. That is just enough for 640×480 in 24bit…
Finally, as TIGA was not a standard CGA/EGA/VGA replacement, you’ll need some way of displaying the DOS text/graphics output. TIGA was always meant as an additional display mostly using a 2nd high-resolution screen, so TIGA cards either run in parallel to an existing VGA card or it also features a (mostly simple) VGA controller for this.
Very sophisticated cards like the above miroTIGER gave many options for this. It features a small VGA part (a Cirrus Logic CL-GD540 and 256K of DRAM) to make a 2nd card unnecessary or could disable that to use a 2nd card of your choice for a two-screen-solution or offered to loop-though the signal of an existing VGA card and automatically switch between them for a single-screen-setup.


So if you consider buying a TIGA card, go for a TMS34020 with SIMM sockets. It should have at least 1MB RAM and 2MB of VRAM. A SPEA Graphiti FGA is a good example for this minimum config.
While DRAM isn’t that important, the more VRAM you have, the better. Having a VGA controller on board might be desirable if you’re tight on slots – but to my knowledge the best VGA controller ever used on-board  was an ET4000. So it’s more or less a matter of taste.


Actually this is the more important point on your list. While yes, TIGA is a standard, it contains certain proprietary parts, called the CD, GM and EXTPRIMS you’ll need to get your card going. The reason for this is the driver which is more a layer model looking like this (listed bottom-up):

Application using TIGA (e.g. AutoCAD)
application specific extensions (also *.ALM/*.RLM file)
extended primitives (EXTPRIMS.RLM/*.ALM)
Graphics Manager (e.g. tigagm.out)
Communication Driver (tigacd.exe)


The 3 yellow(ish) levels are card-dependent, so without them, you’re lost and your shiny TIGA card just makes a nice paperweight.
The lowest level is the Communications Driver, or CD for short, is 100% hardware dependent –  It is always supplied by the cards manufacturer and, well, handles the low-level communication and resides in the PC (upper-)memory.
Above that sits the Graphics Manager (GM)- this is the “real thing™”, the core or kernel of TIGA – which is the firsts thing being loaded into the cards own DRAM.
On top of the Graphics Manager sits another layer belonging to the package provided by the card manufacturer and loaded into the cards RAM, the Extended Primitives Library called EXTPRIMS.RLM in 99% of all cases. This contains all the drawing routines for primitives e.g. boxes, circles but also printing text etc. The file extension ‘RLM’ stands for relocatable load modules while ALM means absolute load modules. RLM’s are loaded and linked at run time, ALM’s are linked in advance for a fixed configuration and later at run time just loaded onto the TIGA card.

Here’s another illustration to show the layer model separated by memory regions:

With these 3 layers loaded, your TIGA card is ready to rock and awaiting commands from your application. Let’s take AutoCAD as an example – it’s probably the best example anyway as TIGA was mainly used for CAD.
It will not only load the TIGA driver but probably also some extensions provided by your cards manufacturer. So for example the miroTIGER came with a 3D-Viewer called “MulitVIEW”, ELSA provided a tool called ELSAVIEW with their Gemini cards etc.. All those tools loaded some extra code into the cards RAM (that’s the light blue layer).
All the extension tools I saw up to now didn’t require more than 200KB RAM. The TIGA core itself is at ~100KB, so for most basic stuff 1MB might suffice at first – but of course some of those tools need extra RAM for holding data so my assumption is that 2MB are a good bet to start with.


All that said, be aware that were two main versions of the TIGA kernel – V1.x and V2.x which have slight differences in programming. Again, it depends on the model of your card which TIGA version is supported. As far as I know, V2.x (2.2 being the latest) requires a TMS34020.
ALM’s were a unique feature of TIGA V1.1 and should no longer be used with TIGA V2.0. Generally, V1.x programs do not run (properly) on a V2.x CD/GM combo.


First, most likely there might be something to setup on your card. DIP switches for example or jumpers. At least you need to know/set the base-IO address of your card. Lucky are those who have a manual 😉
Next, as this is DOS-land, there are some things to set-up in your config files. As usual with DOS, you have to set an environment variable in your AUTOEXEC.BAT:

SET TIGA=-mC:\TIGA -lC:\TIGA -i0x60

This defines the path(es) to your TIGA modules and libraries as well as the base-IO address, at which your card is communicating. This has to be adjusted to your hardware setting.
Also the base-path to your TIGA files needs to be in the system path.

Then you load your CD and (optionally) GM:


The 1st line is clear – if your config allows, you can load the CD into upper-memory. With the 2nd line you can pre-load the GM into the cards RAM and the -LX parameter makes sure it eXecutes right after that. This step is optional, as well programmed TIGA programs check for the GM and if it’s not loaded, they’ll take care of that.

That’s about it. Yay, your TIGA system is up and running 😀 and you’re ready for some action.

The next post shows how to program your TIGA card and do some graphics…

Myriad DASH!860

This is yet another i860 accelerator card – this time from good ol’ blighty: The Myriad DASH!860 (I’ll call it the Dash from here on) was made by Myriad Solutions Ltd. from Cambridge.


Here’s the copyright in detail:


What I’ve got is actually a double “sandwich” card, i.e.

  • The actual Dash card is one 16bit ISA card featuring the i860 CPU at 25MHz and its RAM consisting of 8 SIMM banks, which is connected to
  • the second ISA card is piggybacked onto the DASH!860 and is actually a graphics card using an INMOS G300 graphics controller and giving room for a maximum of 4MB VRAM – this one is called the “ShadeMASTER”


Mhh, this setup very much reminds me of the SPEA Fire, which uses the same core parts but thanks to its higher SMD integration manages to squeeze everything onto one ISA board.


But let’s start in the good old GeekDot tradition having a closer look at each of the cards.

The Myriad DASH!860

Here’s the left side of the Dash:


Having seen the other i860 accelerator cards, this isn’t that much different: The 64bit wide memory interface of the i860 is fed by 8 SIMM slots, each containing 1MB of RAM.
SMD parts prove that this card is a more modern design…

…while looking at the right side of the Dash shows, that its design is somewhat between the worlds:


Lots of DIL PALs has been used. Also the huge array of 8bit latches and buffers would have probably been replaced by 16bit versions later in time.
The most interesting fact in my eyes is the choice of the CPU… why did they pick the 25MHz model? The quality check on the back says 1993! In that time, 40MHz models where broadly available – maybe this was a cost reduced version of the Dash? Some sources on the web mention a 40MHz version at least.

The long pin-rows on the top- and bottom-edge as well as vertically next to the rightmost SIMM slot are the data/address lines exported to the sandwiched graphics card, called…


Let’s start with the left side of this card:


Most prominent are the 16 VRAM memory ICs in ZIP package. They’re 1Mbit, so we’re looking at a whopping 2MB here.
Looking closer you’ll spot there’s room for another 16 ZIP ICs and more buffers – so the video memory can be upgraded to 4MB fairly easy (adding some more flipflops, too).
The connectors to the Dash card can be identified quite good here, too.


On the right side of the ShadeMASTER there are a lot of PALs again – like with the DASH!860. The golden IC is an INMOS G300 graphics controller and the smaller black PLCC chip is an INMOS G176 CLUT. This one has a 6bit DAC which -theoretically- limits the ShadeMASTER to a max. of 262,144 colors (18bit). With its 2MB it could display 1024×786@16bit, or 1280×1024@8bit. With 4MB that resolution would even possible at 24bit true color…
The two transparent thingies in the top-right corner are relays to switch the video signal, i.e. there are two video (VGA) connectors at the cards edge. One 9pin input for looping in the PCs VGA signal and a 15pin output which is normally looped-through.

No signals are used on the 8bit ISA slot connector. It’s just for fixing the card in place and power-supply.


While the DASH!860 seemed to be sold separately as a “general purpose application accelerator” the combination of both cards was mainly targeted at the medical 3D data visualization market.
My cards came from the Bio-Rad ThruView PLUS package which included the Dash/ShadeMASTER combo with the ThruView software.
I have a copy of the software but it’s copy-protected by a dongle, so I won’t pursue it any further (for now ;-)).
See the next chapter handling that software.

The OS – meet XNIX

What’s more important, and IMHO the most exciting fact about the Dash is the OS they run on it:
They called it XNIX. Yeah, that sounds very UNIXish, doesn’t it. A quick inspection of the kernal file shows its a i860 COFF binary and sports many POSIX calls… I was instantly hooked 😯 .

This is the parameter screen of the loader called “x.exe“:


Obviously, there are different modes to run it, depending the mode DOS is running in. As you can see, “/e” forces the enhanced-mode, while “/r” does the same with real-mode.
So either

A) you boot your DOS into real-mode by un-commenting the
device = emm386.sys
line. But leave himem.sys in there. (This will provide XMS RAM access, which is needed by XNIX)


B) Try running “X.EXE” with the “/r” switch.
It still might not work, as I found this line in the binary-code:
A DASH!860 E or J card is required for ‘real mode’ operation” – most likely a Revision Code.

The most interesting and useful switch is “/d” to get the 2 pages of debug output:



This gives you some crucial information:

  • General resources of your PC
  • Your DASH!860 capabilities
  • The I/O port used (0x160)
  • The shared memory area (0xD0000, 64KB up to 0xEFFFF)
  • Kernal size and location

In [standard] mode, I get this screen afterwards:


That’s a bit puzzling, as it seems to not using XMS RAM.
Also, this shows an evil behavior: “X.EXE” will wipe your “\tmp” and “\usr\tmp” folder… unasked. Yikes!  👿

For now, I have no clear idea, how to load an i860 binary to XNIX. In another paper I found these lines:
“The i860 runs a Unix like operating system called Xnix. This is a Terminate and Stay Resident utility which allows many standard Unix applications to be executed on the i860 whilst the PC is running MSDOS. Xnix sleeps until a Unix development tool or the i860 requires servicing whereupon it wakes up and performs the required service.”

This hints towards a library to be compiled into a DOS executable, which calls XNIX kernel services.
I will have to disassemble some of the ThruView binaries and see, if thera are some calls in there which might support that theory (See the ShadeMASTER chapter below).

Config file

XNIX has a central config file. Having a look into it, it shows this:



The called binaries are 66% clear yet:

  • kernel is XNIX itself – ~200KB in size
  • startup.rmx is the bootstrap code for the real and standard mode.
  • stub (a DOS executable) – not totally sure. An included (compiled) BAT file calls this after “x.exe”, using the ThruView x86 binaries as parameters. Maybe a loader of XNIX/COFF binaries ?

But going through the kernel binary’s strings, there’s much more to configure:

Possible sections:

  • [enhanced]
  • [standard]
  • [real]

Pretty clear, aren’t they? DOS enhanced/real-mode setting and a section valid for both. Then there are plenty keys to fiddle around with:

A20lock= global
HZ= %ld
SMA= %lx (NOTE: Shared Memory Address. Use '/s' for an output)
cache= compaq (From the code: "The option 'cache=compaq' has been superseded by the supplied driver. Use the option: 'cache=c:\usr\860\lib\compaq.drv'")
dashsize= /* Memorysize of the DASH!860*/
dma= %d
himem= /* how much XMS RAM to be used by XNIX */
kernel= %s
startaddr= %x
xargs= %c


Decompiled content of “runtv.exe”:

SM_MODENAME=mode false800x600

c:\tvplus\rstub c:\tvplus\___tv1
c:\tvplus\rstub c:\tvplus\___tvr

Not an elegant way using absolute paths and hiding trivial calls in an .EXE file, but getting over it, this helps to understand the start process in further investigations.

The ShadeMASTER card uses a config-file itself, the provided one is called “mode” and contains:

[mode false800x600]
true_colour=false This is the Kosher one for 35kHz scan rate
hbackporch=120 <-This parameter may require tweaking for centralising
vbackporch=40 the image on some monitors

Many of these keys are very common with most INMOS G3xx devices e.g. the IMS B020.

To be continued…


This is indeed a very rare breed – I was informed that less than a 100 of those were sold. Built in the end of 1992 as “Project Zorro” by the German company miro (bought by Pinnacle in ’97) it took the same line as all the other accelerated graphic cards in those days: Highspeed graphic -mostly TIGA- plus some speedy general purpose CPU. The SPEA cards using Intels i860 were direct competitors for example – I was also told that miro also looked into using the i860 but scrapped that attempt in an early stage in favor for the HIGHRISC.

The Miro HighRisc -or miroHIGHRISC as they wrote it back then- was a full-length 16-bit ISA card containing a MIPS CPU and a maximum of 32MB of RAM.

Technical facts:

  • 33MHz LSI LR33050 CPU which is a R3000 clone including the R3010 FPU minus MMU
  • 1k data- and 4k instruction caches on-die
  • 33 MIPS / 33 MFLOPS
  • 8-32 MB RAM plugged into up to 4 SIMM slots
  • 32 bit bus to connect the miroTIGER graphics card (100MB/s)
  • 2D: 150000 Vectors/s of 10 pixels length
  • 3D: 10000 triangles/s of 100 pixels, flat-shaded
  • 6000 triangles/s of 100 pixels, Gouraud-shaded

miro claimed that the HighRisc would deliver nearly twice the performance of an i860/33 solution with “real-world” applications (namely AutoCAD 12). That has yet to be proven but sounds reasonable given the limitations the i860 had when used as general purpose CPU.

Here’s the HighRisc in its full glory:


Interestingly, there’s next to none information on the Web about this card. Probably due to its high cost (5700DM) and the failing TIGA standard.
Here’s a nice snippet from an interview (in German) from 1999 with the original product manager Frank Pölzl:
Q4. What was your biggest flop?
miroHIGHRISC, a 3D-graphic card with MIPS and TI-Graphic-Processor.

Another tasty detail is that according to a news-snippet from the German magazine c’t (12/99, p.22) this card was developed in cooperation with Silicon Graphics (SGI) which bought MIPS some years before. Maybe this was SGIs first and last attempt to get a foot into the PC market?
Yet another interesting fact: The LSI 33k CPU was later radiation hardened by a company called Synova Inc., rechristened as “Mongoose V” and as such traveled into space several times… even to Pluto!

Here’s the left side of the card in more detail. It contains the CPU and the BIOS (32k EPROM dump available here) lots of 74-logic ICs, GALs and some MACH PLDs.
At the top-left corner of the picture below you see the connector to the miroTIGER, a TIGA graphics card described a bit further down on this page.
Also, there’s  an undocumented 20-pin connector at the upper-right edge of the card. This might be the 16MB/s interface “to connect peripherals like laser printers or repro-devices” as mentioned in the c’t article. Thinking about it – it’s an interface to an UART. This will be a nice project to do further investigation.

The pinout (the connector is rotated 90° clock-wise):

GND  oo  /WR0
D0   oo
D1   oo  /RD
D2   oo  /IOSEL
D3   oo  (unknown)
D4   oo  A2
D5   oo  A3
D6   oo  A4
D7   oo  A5
VCC  oo  A23


The right side of the card is dominated by the 4 SIMM slots which, according to the manual, support up to 8MB each. Also there’s a DIP-switch for setting up the address-range etc.


Even it has nothing to do with MIPS, the accompanying graphics card miroTIGER fits in quite good here. This card was meant to run for itself or accelerated by the above described miroHIGHRISC. This is what it looks like:


Following the TIGA standard it naturally features a TMS34020 graphics processor. This processor has its own RAM to do all the calculations, display-lists and fonts. Because TIGA was completely incompatible to the usual CGA/EGA/VGA standards you had to have such a card installed in parallel to see all the DOS/Windows outputs before switching into TIGA-mode. The normal setup was to have a 2nd high-res (1024×768++) monitor connected to the TIGA card then.
More advanced cards like the miroTIGER also had a VGA chip on-board, which saved you a slot and all the extra hassle. So let’s have a look at the details:


This is the left side of the card. The nice golden chip is of course the TIGA processor. Next to it there’s a National Design V2000 chip – most probably an ASIC doing all the RAM handling and stuff.. accidentally I stumbled across a notion of a “National Design Volante2000” TIGA card. Smell the relation here? So my most recent assumption about this is, that’s a somewhat standard TMS340 glue-chip, licenced by National Design to other TIGA card manufacturers.

The SIMM above is 8MB of RAM for the TMS340. Depending on the PAL (labeled 2004, 2044 or 2084) on the lower edge of the card, one could use 0, 4 or 8MB of RAM.
On the upper left corner is the connector to the miroHIGHRISC card as well as an impressive row of DIP switches.


The right side is mainly occupied by 4MB VRAM for the TMS340 as well as the TI RAMDAC in the upper right corner.
Below is a very simple onboard VGA controller by Cirrus Logic (CL-GD5401 aka Acumos AVGA1) and next to it its puny 256k DRAM – which is the maximum a GD5401 can address by the way :-/

This is a good place to post a big thank you to Peter Huyoff – the wonderful guy who saved my life while doing the ‘research’ on this card.
As you might spot in the picture above, there’s one chip broken… a tiny 74AS74 flip-flop – try to find a single SMD AS74 these days. It’s impossible if you’re not prepared to pay $50 b/c of minimum order fees! And no, an F74 doesn’t do it, it’s still too slow. Been there, done that.

Peter provided me another working miroTIGER for free! That’s the spririt between real men! And Peter is definitely one of them!

The SPEA cards

Between 1990 and 1995 the German multimedia-card manufacturer SPEA was one of the leading companies in this sector (When ATI was comparably small and NVIDIA not even founded).
They offered a wide range of display-cards, from a simple ET4000 up to very expensive CAD/CAM cards using various graphic chips like the TIGA controllers, Hitachi ACRTC, Weitek, S3, 3DLabs and… of course the i860.
Later SPEA was bought by Diamond Multimedia and some employees started their own company to finalize the graphic chip they already started to design when being with SPEA (read more here… article in German, sorry).

Two SPEA cards using the i860 were built. The first was the



This full-size ISA card features a 33MHz i860 with 4MB own RAM as well as 2MB VRAM. An Inmos G364 graphics controller is in charge for creating a picture on the monitor – BTW that’s the last and fastest graphics controller which was manufactured by Inmos.
Theoretically, this card could be called an INMOS B020 on steroids.

As this is “just” a 3D subsystem, a standard VGA was still needed for all 2D stuff. Its video signal was then looped-through the SPEA Fire… just like the Voodoo cards did it some years later.

A recent photo I’ve found on ePay shows, that there was a proprietary memory expansion available, which has to be plugged next to the i860. Probably expanding the RAM to 8MB, which can be considered as an quite serious amount of RAM back in those days.


Interestingly the manual briefly touches the possibility to be programmed with own applications using Intels APX system. Sad enough, the APX is not included on the driver disks and was sold separately for a lot of money.



The FGA860 is the bigger brother of the SPEA Fire. Actually it’s two boards sandwiched together: The one on top is -again- called the Fire-Board. But this time it is designed completely different. There is no RAMDAC or such… just the i860, RAM (16MB) and some custom- and bus-logic.
Behind this, there’s a full-blown TIGA card called FGA-4E, using a TMS34020/32Mhz with 4MB DRAM and 2MB VRAM. Not so usual is the also included VGA part on the FGA-4E. This way you can save an ISA slot for the needed VGA card.

The Fire-Board was available for 5700 German Marks, the FGA-4E added another hefty 10.820 Marks making a total of 16.520 Marks (1990/91 that was about US$ 8000)!
But for that money you got a “graphic subsystem” which was capable of 300.000 2-D vectors/s (10 Pixel long) and amazing 30.000 gouraud-shaded polygons/s (10 × 10 Pixels).
[Back then, that really was amazing… today every mobile phone might be better in 3D. Here are some numbers for comparison/amusement:
3DLabs GLINT 300SX: 500.000/300.000]

Here’s a view from the top… not really much to see. It’s very hard to pry those cards from each other. I guess, they were never intended to be separated again.


If you are in need of the drivers, I make them available here. It’s the IMHO most recent version from August 1994 including an AutoCAD 13 driver update.