Category Archives: Intel 80860

Intel 80860 Hardware

Myriad DASH!860

April 25, 2016 Axel 2 Comments

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.

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:

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…

The ShadeMASTER

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.

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

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:

[real]kernel=C:\TVPLUS\kernelstub=C:\TVPLUS\rstub.exestartup=C:\TVPLUS\startup.rmxtranslate={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…

Myriad Dash860

ThruView – Software for the DASH!860

April 30, 2016 Axel Leave a comment

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

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 😉

Intel 80860, Olivetti CP486

Olivetti LSX 5010

October 27, 2020 Axel 6 Comments

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.