Category Archives: Intel 80860

Intel 80860 Hardware

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.

Myriad_DASH860_total

Here’s the copyright in detail:

Myriad_Copyright

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”

Myriad_Shademaster_total

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.

Hardware

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:

Myriad_DASH860_left

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:

Myriad_DASH860_right

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…

The ShadeMASTER

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

Myriad_Shademaster_left

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.

Myriad_Shademaster_right

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.

Software

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“:

myriad_xnix

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)

or

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:

X01

X02

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:

SCREEN01

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:

[real]
kernel=C:\TVPLUS\kernel
stub=C:\TVPLUS\rstub.exe
startup=C:\TVPLUS\startup.rmx
translate={txt;doc}
bus=

end

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:

387faults=
A20lock= global
Break=
HZ= %ld
SMA= %lx (NOTE: Shared Memory Address. Use '/s' for an output)
SysRq=
^C=
addressing=
bus=
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'")
checksum=
comms=
dashsize= /* Memorysize of the DASH!860*/
debug=
diskcache=
dma= %d
environ=
exe860=
extended=
fixA20=
floppy=
himem= /* how much XMS RAM to be used by XNIX */
hirestimer=
ioaddr=
kernel= %s
membot=
meminstalled=
memtop=
real=
reloadkernel=
shadow=
startaddr= %x
startup=
stderr=
stub=
tmpdir=
translate=
video=
watchdog=
window=
xargs= %c

ShadeMASTER

Decompiled content of “runtv.exe”:

SM_MODENAME=mode false800x600
SM_MODEFILE=C:\TVPLUS\MODE
XCNF=C:\TVPLUS\XNIX.CNF

c:\tvplus\x/r/q
c:\tvplus\rstub c:\tvplus\___tv1
c:\tvplus\rstub c:\tvplus\___tvr
c:\tvplus\x/u/q

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
line_length=1138
hresolution=800
vresolution=1200
hsync=142
vsync=4
hbackporch=120 <-This parameter may require tweaking for centralising
vbackporch=40 the image on some monitors
transfer_delay=18
clock=5
mem_init=1006
short_display=76
broad_pulse=130
sync_to_VGA=true
set_G300_sync=true
eight_not_six=true
overlay_mode=0
overlay_mask=0xff
palette=1
pixel_mask=0xff
line_start=0
top_of_screen=0
interrupt=false
vga_palette=false
shadow=false
delay=0x600

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

To be continued…

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

TV_no_dongle

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:

TV_loading

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…)

ThruView_startup

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

TV_badexec

…followed by…

TV_init_failed

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:

TV_invalid_pic

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 visual 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):

TV_screens

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:

TV_outOfMem

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 😉

Olivetti LSX 5010

Years ago I got that broken Olivetti CP486 board (the predecessor of the LSX 5010 and 5020 family) – one of the two ever made i486/i860 combo Mainboards (the other one was the 4860 by Hauppauge). Well because it was broken, missing important parts and I felt like I’m the only one on the planet having such system I dumped it.

There’s life out there!

Now I learned there are at least two LSX 5010 owners left on this planet and one of them contacted me, primarily asking for an i860… well, long story short:
His LSX 5010 was broken, too, but complete! We agreed on a deal: I try to fix it (plus an i860) and he’ll give me a system out of his collection.

Some days later I had everything I’d call a good-to-go system:

The grey box with an LCD display is the “console”, giving you POST information, a speaker and some buttons. Next to it the huge power-supply and in the slots you can spot the EVC-1 graphics card an my trusty ISA/PCI POST card…

Let there be light

Booting the system just the console showed a “CMOS Periodic Int Error“. Doing a warm-boot it replaced by a „Base 128k Ram Error“.
Additionally it behaved somehow flaky, booting  into different states every now and then:

These three Errors were solvable:

  • Flaky behavior: Replacing all caps – this always helps. Believe me. The system booted into a reproducible state after this.
  • CMOS error: The dreaded DALLAS CMOS clock-chip… we all know the drill. Its battery is empty and EISA systems heavily rely on a working CMOS storage. So it got an external battery surgery.
  • RAM error: That was a bit tricky. The LSX’es need parity RAM. One SIMM per bank. Max. mem is 16MB – I only have 16MB+ SIMMs. So I had to get small parity PS/2 SIMMs. 2x4MB did it.

Booting the system now, the console greeted me with

  • „Console Passed“
  • „P.O.D. Running“ (That’s the Power On Diagnostic)

…and then „Non-Maskable Int. Error“. Dammit! This can have many reasons, most of the time it’s RAM (parity). But in my case, it’s been different…

That was a fun one (actually two):
The trace to the i486 processor NMI-pin (B15) was scratched and needed repairs. But it still kept throwing that error. Why-oh-why?!?! After a whole day of digging I had a severe facepalm-moment:

The owner replaced the CPU by an 80486SX because he was under the assumption the LSX 5010 was an SX system. But it wasn’t. It’s a 80486DX @ 25Mhz system (while the 5020 is 33MHz).
And while everybody is claiming the SX is just a DX minus FPU… it is not a 100% drop-in replacement!
While the DX’es have their NMI-pin at B15 the SXes have it located at A15 (where DXes have IGNEE) and B15 is not-connected. Doh! (Checkout the pinout here)

So replacing the SX by one of my 486DX  we finally got a full boot! Tadaa:

Those stripes came from the EVC-1, which definitely also had its problems. So checking its board with my microscope I came about this:

Uhhh…. a cracked diode (D14) connected to address-line A0 to the video RAM. That explains the lines quite well.
When the new DA5 (BAR43S) diodes arrived I replaced the broken one, fired up the LSX 5010:
Looking good, booting into the EISA CMOS setup and while editing the config I could watch the picture disintegrating by every keystroke. More and more garbage was displayed, columns disappearing until it was all black.
The EVC-1 literally died in action in front of my eyes 🙁

I’m not sure what happened here. The fixed address-line can’t be responsible for this. All ICs still get their clean 5 volts. I suspect that one or more of the many old PALs (some of them even bipolar) died…

Ride on…

Anyhow, plugging in my ET4000 workhorse I was able to resume the setup. EISA systems always need a setup tool to tell them all the features of their Mainboard as well as the cards being installed. Luckily the owner had the basic tools at hand… you’re screwed without them.
So this is the one for the LSX booting:

After that’s been done I ran the diagnostic tool – in German just for the fun of it (You can spot all those “OKs”, right?)

But wait a second! Isn’t there something missing?
You’re right… here you go:

The mighty i860 RISC processor… and it is detected just fine: “Pass” 🙂

But does it work, too?

Yes it does! Hooray… mission accomplished!

Downloads

As usual, here are the dumps of the BIOS, Config EPROM and CMOS.
Additionally, you’ll find the floppy images of the config- and diagnostic tools in this archive.

Conclusion

The LSX 5010 is very much like the Hauppauge 4860 a fragile system to work with.
If the unusual configuration of EISA systems weren’t enough, the use of the many, many, many proprietary ICs (i.e. GALs and PALs) make them prone to aging and hard to fix.
They were bespoke designs, limited in their compatibility – Olivetti lists about 30 cards (VGA, SCSI, most of them multi-RS232) officially working – and most importantly need specific parts like the console and software.
Without the proper EISA config tool you always get at least error messages. Without drivers for the i860 you will not be able to use that and it’s just a heating-element inside your computers case.

Those (server) systems were meant to run as-is. Pretty much like a SUN, HP or SGI server of the same period. You can pick from like 2-3 devices to add and that’s pretty much it. They were not designed as an average PeeCee running Doom.