Tag Archives: i860

ThruView – Software for the DASH!860

With the DASH!860/ShadeMASTER combo came the software package “ThruView” (this is the sales brochure).

Sadly -and usual in those days- it’s protected by one of those nasty dongle keys plugged into the PCs parallel port. If you were into computers in the 80s/90s you surely remember them, most likely full of hate:
They were flaky sometimes, didn’t reliably work with the printer looped through them and there was a 50% chance they refrain from working when upgrading your PC.

Running ThruView

Anyhow, starting ThruView, it greets you with a friendly


Ok. Thanks for that ma’am. Here we are. 25 years later and the last dongle for it probably went the way of the Dodo.

But you wouldn’t be at “the home of real mens hardware” when you wouldn’t do, what a man has to do in this case…
Out went the Disassemblers. I recommend IDA Pro for comfortable work on your recent Windoze workstation and SoftICE to work on the bare metal itself.
Ahh, finally, cracking time again. Missed that during the last years…
Half a day later, Thru-View greets me with this:


Yay. One hurdle taken… here’s the next one: You have to open an image file. In the ubiquitous PICtor format. doh! (So I thought…)


Ok, somewhere I was able to get some sample .PIC files… select that and open the damn thing, click OK and…


…followed by…


As far as I can see, XNIX is loaded correctly. For now I have the suspicion that there are communication issues with the DASH!860 due to my PC workhorse is a ‘modern’ Pentium 1 MMX… and we all know how lazy programmers were back in the days when it came to delay-loops etc..

So next up: Tow the trusty 80486 system out of the basement and check it with that one.

Two days later…

Ok, on my 486-PC I was able to successfully load the XNIX kernel in real-mode (‘x.exe /r’) and using the debug-flag I saw some errors about config-files not found in C:\TVPLUS… wtf? All paths are set in the .cfg file but it seems some are just ignored and hard-coded.
Ok, so I created that folder and copied everything over and called ‘rstub ___tv1’ again… and this time it worked!
So let’s open that PIC file… it reads and reads and:


Ohhhh-kayyyy. So my assumption that ‘.pic’ meant a PICtor file was wrong. Some intense Google’ing later I’ve learned that the file format is the “Biorad PIC“. I could have guessed that before. Those times were the times of proprietary formats. How to get such a file to play around with it?
Luckily others had the same problem. ImageJ seems to be the main tool for converting scientific visuial data, and it has a native support for reading Biorad PICs. But how to create one?
Well, thanks to this tool, you can create it when creating .raw files before using ImageJ. A bit cumbersome – but hey at least something.

…another day later…

Alrighty – that brought me a bit further: As far I can see, ThruView is working! My self-built file was successfully loaded and I was able to play with all modules. Here’s a slideshow, showing the available modules (loader, builder, animator):


While my file loads fine, I wasn’t able to get a picture on the ShadeMASTER VGA output yet. I can hear the relay switching the outputs and my LCD display catches the signal correctly (dimensions as well as refreshes) but it’s just black.

Here’s another “finally!”: Loading my Z-Stack PIC file takes 4.7MB of the DASH’s RAM… changing back from the builder into the loader module I got this error message:


This is a ‘special moment’ for me, as this is the first time that the available RAM of one of my i860 cards was actually filled with meaningful data.
But rest assure: As soon the couple works as supposed the hardware tweaking will begin 😉

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…

Upgrading the NumberSmasher

After a long time, I had a look at my 3 NumberSmashers again. Looking closer, I spotted a difference.
One had a silkscreen print saying “V1.2” while the others were “V1.1”. So why not upgrading the NumberSmasher yourself?!

Step 1

The most obvious fix the V1.2 had was a 47ohm resistor fitted between one pin of the 40MHz oscillator and pin-1 of an IC called “A447-0050-10 “. That’s a “10 tap leading edge delay module” made by Bel Fuse Inc.. Pin 1 takes the input signal and each other pin  adds a delay of 5ns.
So I assume this fix was meant to reduce noise on the delay chip input to make its output cleaner.

Anyhoo, here’s the quick and easy howto. The below picture shows the section of a NumberCruncher V1.1. near the almighty i860. Next to it is the (now empty) socket for the 40MHz oscillator. Next to that you see the 10-pin delay chip which pin-1 already had been cut and slightly bent upwards.
We need a bit of pin-1s leg so when cutting it, be sure to cut it as close to the board as possible!


Now for the next step. Get a 47ohm resistor and shorten its wires to bridge the space between the bent leg of the delay chip and the output pin of the oscillator (see below picture).


To make things perfectly clean, remove the pin remains by flipping the NS860 over and pull the remains with your solder iron and tweezers.

Step 2

I thought this would be a simple fix, too. There are some retrofitted jumper-wires on the back of the NumberSmasher near the ISA connectors.

NS860_patchwiresI’ve color adjusted the photo to make the wires more visible. Colored arrows show start and end of each wire

But taking a look at the chips those jumper-wires are connected, it showed that the two PAL22V10  of the V1.1 board were replaced by two PALCE610H – which is a completely different beast, same number of pins, everything else varies:

max in max out macrocells Specials
PAL22V10 22 20 10
PALCE610H 20 16 16  D, T, J-K or S-R Flip_Flops, counters and large state machines possible

Additionally here’s a side-by-side of the pinouts. This immediately explains the two long jump-wires from pin-1 to pin-13 (red & blue arrows) which connect the two clock inputs.


Here’s the PALCE610 in place:

PALCE610It’s the one at the bottom in the middle (named U93) and one hidden beneath the link-interface board (U-88).

My assumption is, that the PALCE610 has a completely different programming and the jump-wires just support the changes made, i.e routing the outputs of pin3 to input pin2 (green) respectively pin4 to pin 2 (pink) .

Next up: I will get out my Über-Programmer and try reading it – but I have low hopes, as MicroWay normally set the protection fuse on all the GALs/PALs they used.


Wow, that was unexpected. Both PALCE610 hadn’t had the protection fuse set – at least on my retro-fitted V1.1 board. So lo-and-behold, here are the JEDEC files for you to program your own PALCEs!  And because I couldn’t resist, I’ve disassembled the JEDs and added the PALASM code in the archive, too 😀

That said… it’s completely unclear what had been changed from V1.1 to V1.2 (well, U93 being close to the ISA connector gives a hint) and under which circumstances an upgrade is necessary at all.
But if you own a 1.1 and it behaves strange, you should give it a try.

Putting the DSM to use

So after the lengthy description of the DSM cards – how can we make use of them? As said in the previous chapter, they were shipped with an assembler and even an early version of GCC (1.3) so development is pretty straightforward.


First, you have to understand how the cards integrate themselves into an ISA/EISA system. While the three versions (8, 16, 32bit) differ in some areas, the integration is more or less similar:

Each version offers a latch for controlling the card. This means to activate the card by writing bits to that latch to define a memory-window inside the hosts RAM to blend-in the cards dual-ported RAM  and/or resetting it etc.. The latch is accessible through an IO-port set by jumpers on the card (default 0x300).

So for the ISA cards you have to for example write a 0xC2 at that port-adress to reset & activate the card and use the mem-window of 0xDC000-DC7FF. In Turbo-Pascal this would be something like:

port[$300] := $c2;

This gives you a 2K mem-window to exchange data between the DSM and the host (just 1K for the DSM860-8).

The EISA cards obviously use other ports depending on the slot-number, so this would be an example to do the same for am DSM860-32, this time in Turbo-C:

outportb(slot_no * 0x1000 + 0x800, 0xc2); // For slot #2 this would be 0x2800

This would also open a mem-window at 0xDC000, this time up to 0xDCFFF, i.e. 4K long.


As mentioned above, the Host and the DSM-card are communicating through a memory-window of diffenrent sizes, depending on the DSM used. Due to their nature, the memory is looking different though. That said, at least they’re both litte-endian, so no byte-swapping needed.

The 80×86 side

For the hosting PC, memory looks pretty straightforward. 1KB-4KB of RAM somewhere in ‘lower-RAM’, that’s it.
While we don’t use it, it’s worth mentioning that there’s a 2nd memory window called “Common“. This is fixed at a specific address and is shared between all possible cards plugged into one host. I guess you already got it: This enables easy multi-processor communication… and gives a lot of possibilities for f**k-ups.

The i860 side

The memory-mapping on the i860-side is the same for the 16 and 32bit cards, the dual-ported RAM is located at 0xd0040000 (0xC0000000 for the DSM-8).
In any case the i860 memory is linear, 64bit wide and always on a 64-bit boundary. This means you have to read the DP-RAM area differently depending on which card you run your code. Here’s an example of how the DP-RAM looks like on the Host- and i860 side:

Host DP-RAM in DOS ‘debug’
-d dc00:0000
DC00:0000 11 22 33 44 55 66 77 88 ...

which would look like this on the i860 side:

C0000000 - 11 xx xx xx xx xx xx xx 22 xx xx xx xx xx xx xx
C0000010 - 33 xx xx xx xx xx xx xx 44 xx xx xx xx xx xx xx
C0000020 - 55 xx xx xx xx xx xx xx 66 xx xx xx xx xx xx xx
C0000030 - 77 xx xx xx xx xx xx xx 88 xx xx xx xx xx xx xx

D0040000 - 11 22 xx xx xx xx xx xx 33 44 xx xx xx xx xx xx
D0040010 - 55 66 xx xx xx xx xx xx 77 88 xx xx xx xx xx xx

D0040000 - 11 22 33 44 xx xx xx xx 55 66 77 88 xx xx xx xx

So reading and writing from/to the DP-RAM involves some thinking to be done by the programmer. Here are two code-snippets showing the difference between reading the DP-RAM on a DSM860-8 and an DSM860-16. First the ‘8 bit version’:

mov 4*8,r4
ld.b 0(r15),r14  // Load BYTE from DP-RAM
st.b r14,0(r29)  // store it destination
addu 8,r15,r15   // add 8 to read-mem-pointer
addu 1,r29,r29   // add 1 to desitination-mem-pointer
addu -1,r4,r4    // loop-counter
xor r0,r4,r0     // Test Zero
bnc readloop

And the same for the DSM860-16:

mov 2*8,r4
ld.s 0(r15),r14  // Load SHORT (2 Bytes) from DP-RAM
st.s r14,0(r29)  // store it destination
addu 8,r15,r15   // add 8 to read-mem-pointer
addu 2,r29,r29   // add 2(!) to desitination-mem-pointer  (short <> byte)
addu -1,r4,r4    // loop-counter
xor r0,r4,r0     // Test Zero
bnc readloop

Because of reading SHORTs (ld.s) the DSM860-16 version has to loop just 16 times while the 8-bit version has to do that 32 times.
Same applies to writing. You will find an example in the Mandelbrot program (Commented source file).

[This is work-in-progress and will expanded over time]


So here we go, finally some program running showing all the power behind the i860. I took the Mandelbrot example from R.D.Klein and modified it a bit, well quite a bit as it was written for the DSM860-8 and provided CGA output (yuck!).

Like most “external accelerator” programs, there’s one part running on the accelerator (the i860 in this case) and one part running on the host doing useful things with the provided data. In this case we have an i860 assembler code doing the number-crunching on the Mandelbrot algorithm using the i860’s ability of ‘dual instruction-mode‘ and some code done in Trubo-Pascal handling the display and zooming.
The latter was extended to use SVGA (640x480x256) output and providing an interrupt driven timer. [sourcecode package cleanup is still work in progress]

Here are the two running full steam ahead:

Some things worth to mention:

  • The host being used here is a P1 133MHz, a bit unfair comparing that to a 40MHz i860 – OTOH they seem quite comparable when it comes down to Mandelbrot crunching speed.
  • To calculate the Mandelbrot the same speed as it took the Pentium (~15s) I needed five T800-20 according to my benchmarks.
  • To even achieve the 8.2s of the i860 I had to run 9(!) T800-20 in parallel.
  • A i486DX/33 took 66 sec to do the same (8.25 times slower!), while it still took 34s for a i486DX2/66!

So while all that moaning about the bad ‘programmability’ and slow context-changes of the i860 are completely correct, in certain tasks that CPU was indeed a real screamer!

Olivetti CP486

The Olivetti CP486 was “the other” machine on the market which provided an 80486 and an 80860 on the same mainboard. The same board was used in Olivetti machines called LSX-5010 (25MHz) or LSX-5020(33MHz).
Like the Hauppauge 4860, it was an EISA bus system too, had no 2nd level cache but an extra socket for a Weitek 4167 FPU. Again very similar is the use of an huge array of PALs and GALs… and huge is the keyword for its size:  40,5 cm x 34 cm (16″ x 13.4″)!


My CP486 which I’m showing here seemed to have been through very though conditions. It was quite dirty and is of course not working :-/ Mainly due to a missing PAL, I guess (shown in the following picture).
So here’s the lower part of the board (90° tilted for better reading):


At the top the i486, in this case an DX2/50 I had lying around – nicely fitting the 25MHz oscillator to the right of it. At the edge of the photo you can see a bit of another socket. That’s where the optional Weitek FPU would have go (See the picture of the total view).
Next you’ll spot the many PALs around it. And a wild mixture it is! All PALs/GALs on the board are from different manufacturers, years and kinds. Some still featuring labels, most of them peeling off. According to the only documentation I was able to find, “in field” upgrades seemed to happen quite often. The little red arrow indicates the missing PAL at “U82” I talked about before. It should be a 16R4 containing the snoop-control, a vital part of the memory management. Without it, the board is pretty much brain-dead 🙁
Next are 8 slots for PS/2 SIMMs… depending on the BIOS version up to 64MB RAM were usable.

In the low left corner is what made this board special: The i860 socket. The 3 PALs above it are his address decoders… nothing is known about how the two processors shared the RAM.

Which leads us to the other half of the board:


This part is mainly chip-set stuff. At the top left there are the Intel 82358 EBC and 82537 ISP (See my Knowledge-Base article for more info) ICs.
The rest of the action is squeezing into the lower right corner: On top the WD16C552 Serial and Parallel Port Controller. The other two bigger PLCC ICs are EP1800 CPLDs supposedly working as I/O controllers. To their right is a 8742AH handling the PS/2 keyboard and mouse.
Below that there’s the inevitable DALLAS clockchip, a 64kbit EEPROM (probably EISA config) and a 1Mbit 28F010 Flash EPROM for the BIOS. Pretty modern stuff actually.
Naturally I read out the BIOS… it’s completely Olivetti propriety as they always did back in those days (Download available at the end of this page).
Last but not least, the power connector. Again, propriety but I do have the original power supply. Nice big paper weight.

The EVC-1

Like the Hauppauge 4860 (again), the CP486 also offered a special Graphics Card which enabled the i860 to directly write into its video memory, so it could be used as an accelerator.
While Hauppauge went the way of offering a special dedicated slot, Olivetti designed a special EISA Video Card… well, the EVC-1.


While it features a standard EISA slot connector, it does not work in other EISA systems (You get the BIOS boot messages but it then hangs with wire-do chars displayed).

It’s core is a Chips & Technologies 82C452, a mediocre VGA chip. Strangely enough, Olivetti managed to marry this DRAM VGA controller to 1MB VRAM
Still this does make sense if the 82C452 was just meant as a simple/boot VGA controller and the i860 should take over (via EISA DMA) for the heavy lifting graphics stuff. But that’s pure speculation…


So, here‘s the CP486 PDF-document I was able to find in the WWW including my BIOS dump.
If you happen to own a CP486/LSX50x0 I would be happy to hear from you!

Final anecdote: I’m not sure this guy (German forum, Google-Translation here) knew what he was doing when scavenging a complete, fine running LSX-5020 for a boring case-modding stunt. In a few years he will kick his ass for killing a one-of-a-kind machine for a boring mass-market PC.
That’s the same sin many Americans did to their vintage Ferraris when they replaced the somewhat complicated original engine with an off the shelf Ford V8 to make it reliable… and reduced its value to 10%. Sin! Sin I said!

Run Forest, run!

After having figured out the basics, it was time to prove the concept. First, I needed a (simple) program to run on the NumberSmasher. Here it is, reeeeally simple. It’s just an excerpt of the original 77 assembly lines. If you’re interested in the whole thing, it’s here.

The main-loop is just this. Read a byte from the C012 link, add 1 to it and write it back to the C012:

mov    iobase, %r4

  call    getlink        # (watch following delay slot!)
   shl    %r0, %r4, %r16    # mov r4, r16 - save base address

  addu    1, %r16, %r17    # add 1 and move into r17

  call    putlink        # (watch following delay slot!)
   shl    %r0, %r4, %r16    # mov r4, r16 - save base address

  br        loop

What a task for a “Cray on a chip”! 😉 Ok, putting this into the assembler (currently gnu-as on Linux), linking and finally making it a pure binary with ‘objcopy -O binary hb_test.cof hb_test.bin‘ I got this binary.

How do I get it into the NumberSmasher? Again, that required a bit of coding… say Hi to nc_load.exe.
This little tool loads a pure i860-binary, pokes it into the NumberSmashers RAM and optionally starts it afterwards, ie. ‘nc_load hb_test.bin 20 start‘ loads my test program to address 0x14 and starts it from there.
[Having read the previous post, you should know that you could omit the ‘start’ parameter and just poke 20 to address 0 to start the code]

Test, test, one, two, three…

And now the exciting part: Does it work? The easiest way to test this is good ol’ debug again:

C:\> debug
-o 151 41
-i 150

Yay! If this isn’t proving the sense of life, what else!?!? 😉 Ok, what happened here is simple. I wrote 41 to port 151 on which the C012 is listening for input, then I read from port 150 which is the result of adding 1 to the input. Quod erat demonstandum. Program is running successfully!

Be aware that after starting a programm, the NumberSmasher is continously running that code, i.e. peek & poke do not work anymore because the Boot-ROM is out of the game.
You have to reset the NC which is done in classic INMOS-style, i.e. sending a zero to port 0x160. Thats ‘-o 160 0’ in debug. NB: Resetting the NC does not clear its RAM. The previously uploaded program is still available and can be re-started by pokeing the start-address to 0.

Dissection time!

Ok, as I’m probably the last person on this planet fiddling around with the NumberSmasher i860, it was either “help yourself” or bust.

Given the fact that there’s an INMOS C012 on the card I tried my luck with the standard address of 0x150 and checked it with DOS’ crappy old ‘debug’. To my surprise I was able to talk to the C012, so it was very worth to investigate further.
So out went the good ol’ EPROM programmer and the EPROM of the card was dumped into a file.
I have 3 of those boards, two having a label on the EPROM saying “v1.1” and “BOOT_B2”. Both are identical… if you happen to own a NumberSmasher with a different label, get the dumpfile here for comparison.

That was easy, now the harder part: Disassembly. I had to revive my i860 machine language skills again, so it took me 2 days (on and off) to get a full understanding, what’s happening in there.
For those i860 assembly geeks among you, here‘s the fully commented code.

This “BIOS” is actually pretty simple. It’s just what I’d call a “PeekPokeStarter”. The main loop is waiting for a ‘command’ coming in by the way of the C012. This command can be either “0” or “1” as mentioned in the article on the previous page.

“0” means POKE (ie. write) and expects 4 bytes for the address and 4 bytes of data to be written (Both LSB first, Intel-style). So the full command reads: 0 00 00 00 20 78 56 34 12 or “write to address 0x20000000 the value 0x12345678”

So in consequence “1” means PEEK (ie. read) which just needs 4 bytes for the address to be read. The command would then be 1 00 00 00 20 or “read from 0x20000000”. The “BIOS” will then put 4 bytes to the C012 port at 0x150, which requires 4 reads from the PC side getting “78”, “56”, “34” and “12”.

Pretty simple, huh? But how can I start a program after it’s been painstakingly poked into the NumberSmashers RAM? Here’s the trick:

Poking to address 0x00000000 means start from the address given as data. E.g. “write to address 0x00000000 the value 0x20000000” is actually “start from 0x20000000”, or as command-chain: 0 00 00 00 00 00 00 00 20 – so beware of poking to 0!
Also, starting a program seems to disable the EPROM, so communication to the C012 is cut off if the running program isn’t handling this itself.

That’s about it. Nothing more in the “BIOS”… that’s why only 495 bytes(!) of the 8K EPROM are actually used. This simplicity leads to a very simple memory-map:

Base =  0xF8000000
C012-InData = [base] + 0x07
C012-OutData = [base] + 0x0F
C012-InStatus = [base] + 0x17
C012-OutStatus = [base] + 0x1F

Next task: Get a program running on the NumberSmasher.

[11/11/10] Great News…again! It was easier than expected… the first program running on the NumberSmasher-860! So read on in the next post…

Caplin Cybernetics i860/Transputer cards

Caplin Cybernetics (just Caplin for short) was one of those many UK based (London to be exact) companies building Transputer based high-performance systems. Caplin seemed to be specifically concentrating on providing Transputer technology for DEC systems, namely VAXen.

As of now, I do not know much more about Caplin, but I know there are still some former employees around and I’d be happy to learn more about the company as well as the systems I’m going to describe further down.

By a lucky indecent I got my little greedy hands onto 2 different Caplin systems. Both connecting Transputer (networks) to a mighty Intel 80860XP.
While these boards have i860’s on them I’ve put them into this Transputer category, as they were meant as math accelerator for Transputer networks, not the other way round like the DSM860 boards, which used Transputers mainly for networking.

I don’t have any documentation for those boards but I hope to get them working as soon I figured out how to connect to the Transputers, find out more about the memory-mapping and found a way how to read those damn Bipolar-PROMs.

That said, from here everything is just wild speculation, assumption and finger-in-the-air-guessing – If you know more/better: Let me know please!

I’m specifically looking for the document called “Caplin XPR Series Technical Overview”. If you still have a copy or you do know somebody who might: I’d be very happy to hear from you!


The HXI860 seems to be the earlier implementation of a Transputer-to-i860 board. It is a quite late i860 implementation though, featuring the latest incarnation of the i860, the 860XR, successor of the 860XP.

A picture says more than a 1000 words: The HXI860 in full view


Let’s start with the left side of the board. The picture is a bit blurry (sorry) but it’s enough to identify what I’m going to talk about:


Starting on the left there are many blue 2-row pin connectors. This seems like a job for long winter evenings to find out which pin is connecting to what.
Then there are the 3 “golden boys” next to the connectors: From top down those are 1 T800-25 and two C004 linkswitches. Above the T800 there’s 4MB for his own use.
Then there are two FPGAs, one with the AT&T logo (ATT3020) and one more familiar XILINX XC2064, both getting their programming from an Xilinx 1736A PROM.
In the top-right corner the heavy-wight-champion i860XR (40MHz) surrounded by lots of buffers and GALs. The long DIP ICs on the right edge are IDT73210 octal transceivers with parity checking.
Rightmost are the connectors to the DEC Q-Bus… luckily only power & GND are taken from there, so you don’t necessarily need a VAX to use the board.

The right side of the board looks like this:


Ignoring the lurking C004 and Xilinx CPLD the leftmost black square IC is an T222C-17 which most likely controls the initial C004 configuration. He gets his code from two ICT 27CX642 which are quite strange devices: Made like CMOS EPROMS they use differential memory cell techniques to provide bipolar-prom speed. No idea how I will be able to read them out with my standard EPROM programmer.
Also, there’s a “6bit” dip-switch next to the T222 which I was told will be used to configure the link routing… let’s see what I will figure out by try’n’error.
The other four square ICs are 2Kx16 dual-ported RAMs (IDT7133). Four of them makes 64bit… well, that the i860 memory bus interface.
Last but not least there’s a long DIP IC above the DP-RAM… it’s an C012 Transputer link-adapter. So one Transputer link must be connected here, converted into 8-bit parallel. Could it be that they connected the 64-Bit RAM of the i860 via a transputer-link? (shudder)
Ok, and obviously there are 8 SIMM slots for i860 RAM… parity RAM required.


This much bigger board seems to be the successor to the HXI860 and I was told it was the fastest i860 board Intel ever tested. Also this seems to be a prototype and was never officially sold.
It now features a 50MHz i860XR (fastest i860 available), two instead of one T800 but no C004 at all. Also the communication between the Transputer(s) and the i860 seems to be fully memory-mapped and no C012 is involved.

Here’s the full-view:


Let’s go into detail… the “Transputer side” for a start:


The connector at the top-right edge is yet of unknown type.
Below this, there are 2 T805-25, each having 4MB of RAM. Two AM27S33 4Kx4 bipolar PROMs (flanking the RAM to each side) seem to offer the 4K boot-code.
This board, too, has a 6bit dip-switch. Again, no idea yet what it does.

The most space in this picture is used by the much more sophisticated i860-to-Transputer interface, which is so complicated that it needs a diagram for itself (Thanks to Mike B. for beautifying this!):


Eight(!) 4Kx16 IDT7024 dual-ported SRAMs are used to convert the i860’s 64bit bus to the Transputer 32bit bus – most likely they’re part of the “DMA engine”, too.

For doing this you normally only need 4 of them, but as you can see on the above diagram, Caplin chose to use the two T800 independently, so each Transputer has his own 16k SRAM directly connected to the i860.
Then, each Transputer is also connected to a 1MB VRAM bank (consisting of eight HM538123 having 128K word x8 DRAM and 256-word x8 Serial RAM). I was told the serial-side is connected to the Transputer, the parallel-side to the i860. Behind the VRAM is the “DMA engine” most likely the array of XILINX FPGAs you can see on the upper edge of the picture below.

The reason for this “over engineered” design most likely was, that you could use the SRAM for small but very fast read/write operations, while you would use the VRAM for bigger chunks of data.

The lower-edge (“i860 side”) overlaps a bit with the above picture of the “Transputer side”:


Again, like on the HXI860, lots of IDT73210 octal transceivers, the 4 XILINX FPGAs (the “DMA-engine”, also fed by 1736As) and a huge array of GAL/PALs doing the bus-handling.
Then there’s the i860XR (50MHz) hidden under a heatsink.
A bit below is a 16-positions dial – no idea what it does. First thing coming to my mind: RAM timing.
Finally even more buffers connected to 8 SIMM slots (the i860 private RAM, Parity-only again).
The blue connector on the bottom edge is meant to connect to a 2 digit, 7 segment display which I have on a second board I own.

The DSM-860 Series

Based on a public project from Rolf-Dieter Klein and Tobias Thiel (“PC-Karte mit i860”) in the German computer magazine “mc” (2/90 to 7/90), the Munich based company DSM built several i860 boards for the PC/AT which they called the DSM-860 series.
All DSM-860 have one thing in common: They offer a high level of hardware features – no costs were feared. So naturally, those cards were not cheap. But you really got something for your money. All versions featured

  • 4 Transputerlinks for networking multiple cards
  • Connection to the hosts system-bus (ISA/EISA) via dual-ported RAM
  • A 16-bit bus is also available via dual-ported RAM on special connectors giving a throughput speed of 8MByte/s for high-speed connections between several SPC boards.
  • RAM was put on an extra RAM board making the complete SPC-860 a double-card sandwich


The 1st incarnation was the SPC-860, very quickly renamed to DSM-860, an 8-bit ISA card with 4MB RAM (DIL) and 4 10mbps Transputerlinks via four C012’s (polled by the i860 resulting in 740kbps linkspeed).

Here’s a picture from a 1992 ad, with separate RAM card attached:


It did cost 16450 DM including the (GNU) C compiler and assembler.


Next, they released the DSM-860/16 (renaming the DSM-860 into DSM-860/8) being a full fledged 16-bit ISA card. It has a real Transputer (16bit T222, having its own 32K SRAM) for handling the “multiprocessor communication” and is able to support up to 256MB on a sandwiched daughter-board, now using SIMM modules instead of DIL parts.
The Hitachi HD63310 dual-ported RAM, used in the 8-bit version to communicate with the host was replaced by faster Cypress IDT7130 types (“because of the high speed of the 16-bit ISA interface” ;-)), resulting in a peak-rate of 14MByte/s.

Here’s the schematic of the card and its components


This is how it looks in reality… my DSM-860/16:


As you can see, the card is not exceptionally high integrated – even built 1992 there is not a single SMD part used, everything is socketed, only some PALs could be called “custom parts”. But this does not necessarily mean it’s badly designed or build.
If you have a close look (click the picture for a bigger version), you’ll see that every part/socket/jumper on the board is nicely specified in the silk-screen printing. All GALs and the EPROM contents are available in the documentation… which has 426 pages by the way.

Here’s the left side in more detail:


This end of the card is the “external comms” side. Beside the all-mighty i860 you can easily spot the golden Transputer being the communication controller.
To its left, there’s the first dual-ported RAM (1k x 8) connected to the socket for the external bus (Ring-A, located on the edge above). Below that are the two 16k SRAMs -marked MHS- for the Transputer. Then to the right are the two dual-ported RAMs (a 7C131 and a so-called slave 7C141) making the 16-bit connection to the i860’s bus. The rest of the parts are quartz oscillators (5MHz & 40MHz) and drivers/buffers for the buses. On the top edge next to the Ring-connectors you can spot the 4 Transputer links (JP9-12).

The right side is comparably boring:


The boot EPROM, 6 GALs, again two dual-ported RAMs (this time for the ISA-bus connection) and some buffers… well, and 5 LEDs. LEDs are good. 😉
Also, you can see the pin-row connectors at the lower edge and on the left of the photo. That’s the expansion-bus. The lower connector is more or less 1:1 the ISA bus, the left one is a 16-bit bus to the i860. AFAIK, they never offered an expansion for sale.
The last (but not least) interesting thing on this picture is the copyright. Yes, it’s a DSM860/16 from 1992, RDK made it (Rolf-Dieter Klein), DSM in Munich distributed it – but it’s obviously also a rev. 1.6, which means there could be others before or after that one. If you have more informations I would be happy to learn more.


I’m pretty sure there was one more version after this rev.1.6, this b/w picture from a DSM press release about shipping the 250.000th slot-CPU card shows a very changed design. The silkscreen print says “DSM860-OEM/16”, so it’s obviously nothing for the normal market.
Mind the onboard-RAM, the missing comms-section and the high integration (SMD parts all-over) and even an early form of an FPGA from Lattice – my assumption is that this version could be the answer to the Kontron SBC860 showing nearly the same layout:

At least this ‘riddle’ is finally solved. I was able to buy an DSM860-OEM/16..Yay! As assumed, it is a modern (for 1990 standards) version of the DSM860-16 now consisting of just one board, so no more RAM card as described below- and without the Transputer and Ring-A/B stuff.

Here are my pictures of it. First of all, the card in full view:


The right half shows a very high degree of integration compared to its predecessor. All DIL ICs were replaced by SMD parts and lot of logic went into PALs and even an FPGA (The contents of the EPROM is the same as with the other card, minus Transputer handling):


The left half contains the CPU and the RAM. This time only 8 SIMM slots:


The RAM card


This is the 2nd part of every DSM-860 – the RAM card (except the OEM-16). Same dimensions as the SPC itself… i.e. full length. The biggest part of it is consumed by the 16 angled SIMM sockets, obviously interleaved, thus named altering slot-a & b. Only the 8 a-slots are populated on mine.
The rest of the board is used for lots of buffers and drivers, some GALs (doing the mem-mapping) and there’s quite a big copyright… again.


One typical detail of those days is the fact that manufacturers were not very keen on having users doing upgrades themselves. Even this RAM board has standard SIMM sockets and one could simply plug in more SIMMs to expand the RAM you had to change a GAL (the one in the lower left corner with a while label saying “UXM24Wxx” on it). Obviously these GALs are the only ones notdocumented. All I know is that there were 3 GALs available differing in the last two letters of the label:

  • 8B = only a-slots can be used by either 1M or 4M SIMMs giving 8 or 32MB total
  • 16 = both a- and b-slots used with 1M SIMMs = 16MB total
  • 64 = a- and b-slots filled with 1M and/or 4M SIMMs giving 16, 40 or 64MB total.

Because the card as well as the documentation says the maximum supported amount of RAM is 256MB there might be the chance of supporting 16MB SIMMs – I did not try this yet.

Both cards attached together give quite a big and heavy sandwich


It’s obvious that you not only need 2 full-size slots but also guide-rails inside the case to hold the weight of this beast.


This seems to be the king of the SPC hill. Technically it’s pretty much the same as the DSM-860/16 but this time featuring a 32-bit system bus – namely EISA. The EISA bus was a dead-end like IBMs Microchannel but comparably easy to implement and free of license fees.

So the main difference to the DSM-860/16 is the 32-bit wide connection to the hosts bus, visible by the 4 dual-ported RAMs used for a 32-bit wide connection to the EISA slot.

Again, here’s a 1992 magazine ad showing a probably early version of the card as the marking says “DSMß860-32” (mind the beta) and the year “1991”:


Compared to that, my version (1.2) does not look that much cluttered – also the Transputer comms part were moved to the left side of the i860 and two more LEDs were added:


So the left side of the card looks pretty identical to the DSM860-16, while the right side has a bit more logic to satisfy the EISA standard, the already mentioned 2 more DP-RAMs, a bigger expansion-bus due to the EISA slot and most important: 2 more LEDs! Did I mention that LEDs are good? 😉


This more detailed picture shows that the DSM860/32 was released the same year as the ISA version. This card is a rev.1.2 – again, if you know more about revisions, I’d be happy to hear from you.
You might have spotted that this card looks a bit shabby. That’s because it was pulled from some universities dumpster. It was missing some components and had some “scars”. The good thing was that none of the GALs were missing and due to the fact that every piece is documented on the card it was easy to replace the missing parts.
On the above picture you can clearly see e.g. the 100nF capacitor C40 below the i860 or the 40MHz OSC. I wish everything would be that well documented.

The Infinity card

This is a rare and mysterious beast. The documentation only touches it very briefly. It’s definitely nothing been built for the average DSM860 user – if something like that existed. For sure it was extremely expensive… and it has LEDs 😀


So at the first look you see 2×3 connectors for 40pin cables – the same used on the DSM860 cards (Ring-A and -B). Then there are a lot of drivers and buffers and a big Lattice pLSI 1032-50 which is a 6000 gates PLD (Programmable Logic Device). A closer look to the board gives more hints – thanks to the DSM (or RDK) habit to print as much info as possible onto the board:


Ok, first information we get is that this is a EINF860M or INFINITY 32Bit Extender. It’s like all other boards (c)1992 by DSM Munich and -as one would expect- designed by Rolf-Dieter Klein (RDK).
The three connectors are labeled ADDR(ess), DATA MSB (Most Significant Byte) and DATA LSB (Least Significant Byte).
The the right of the connectors is an Intel 85C098-20. I think that’s a One-Time-PLD, not 100% sure.

My educated guess is that this card is what the print on it says: A bus extender. Using the 16-Bit bus on the DSM860 cards one can build quite a big parallel computer. But the max. length of the flat-cable to connect each card with the next one is limited. So this card would be connected to other DSM860 cards in the same case (i.e. a 19″ case in a rack) and the extender would then “amplify” the bus-signals to be send over into the next rack full of DSM860 cards.
That said, my fear is, you’ll need two of those cards as the seperation of Adresses and Data (MSB and LSB) is nothing being used on the DSM860 cards. So my next guess is, that the INFINITY communicates over the EISA bus with the other cards and has its own external bus. Again – I’m happy if you contact me if you know more/better!

DSM Software

I’m in the lucky position to own the last offically released software package for the DSM860 cards.
That said, it’s a mishmash of different tools, code and compilers not always compatible with the different boards (860/8, 860/16 and 860/32). Still the sources and specifically the assembler and C compiler may be helpful for a kickstart.
I’ve adjusted the installer to create a single-install instead of the original 3 floppies installation. See the readme.txt file for more details.

Download it here.

And if you’re interested, here is the the source & binaries for my Mandelbrot example.