Tag Archives: RISC

MIPS 2030 – Home Improvements

This is the last post about improvements for the MIPS RS2030 – but it will be open-ended and updated as time/project goes by.

After the resurrection of this little workstation I still wasn’t totally satisfied. As said, the console is a strange 2/3 box and obviously running in an unaccelerated slow-scrolling graphics mode – every 80286 PC console is faster.
So for starters, I switched to a remote session. Luckily the network-setup was, while yet primitive, very easy. Definitely sufficient for telnet and ftp – remember, we’re roughly in the year 1990 and the world is pretty much black-hat-free… and so is my LAN, so I don’t care.

The X marks the spot!

Hey, we have a mighty frame-buffer, made for 1280x1024x8 pixels, so what’s more natural than running X-Window?!
MIPS actually sold “RISCWindows” separately for mucho $$$. It was an “optimized” X11R4… well, while the frame-buffer (i.e. no acceleration) isn’t anything special I really wonder what had been optimized?

Time for “real men™”, let’s install X11! And just because we can, we pick X11R5 because it fits the time around 1992. Around then I did the same for a SPARCStation 1… memoriiiiiiiies.

So I downloaded the X11R5 sources and very soon some new behaviors kicked in. A 16MHz machine is not the fastest kid on the block. Combined with the RS2030 lame I/O performance file decompression is a drag. So it’s actually much faster to copy an uncompressed tarball over the slow 10mbps line than having a smaller file transferred quickly and then let the 2030 chew on it forever (ah, and there’s no gzip out of the box – you’d have to gunzip & compress it on another machine before).
After the 200MB were moved over I was delighted to find a mips.cf config file being part of the source. Let’s have a check:

make World BOOTSTRAPCFLAGS="Mips" >& world.log

gave an instant error… the crappy RISCos sh does not know about redirection of every output into one file  😐 So I had to make sure it’s using csh… and while were at it: You have to switch the system to BSD mode (vs. System V). This can be done by putting /usr/bsd43/bin into your $PATH before anything else.

Traps and hints

Many makes later I wondered why make always remade all objects.  Reading Imakefile and many Makefiles did not light a bulb. Then there it was –facepalm– all source-files hat a creation date of 2018 because I unzipped and compress‘ed them on my Mac. And while the tools and libs on RISCos aren’t Y2k aware, the filesystem sure is. Doh!
Memo to myself: Touch all source files once before running make! Remember, we’re in 1999 on this system. This is important because a full make of X11R5 takes 6hrs on the RS2030!

Every now and then the Mips cc barfed on some code. From old newsgroup posts I learned that nobody were able to compile R5 out-of-the-box. And nobody who managed it was kind enough to post their changes. So I had to reinvent the wheel…
During this journey I stumbled across a more recent “graphics driver” source from MIPS (ddx in X11-lingo) which I incorporated into the sources – and fixed the bugs which it introduced…

One day (and night) later, the black screen of my RS2030 flickered into white, then grey and… taadaa:

X11R5 as vanilla as it gets, runing the classic twm window-manager. The lower xterm shows hwconf, the grandfather of IRIX’ hinv.
Currently I’m fighting with fvwm – this would be a good window-manager given it’s about the same size as twm but much more versatile.

My complete X11R5 build is available as tarball here – 90MB, ~300MB decompressed. Better have a big hard-drive 😉
Un-tar to/usr/src, make sure your date is set beyond that of the files in the archive. The archive is ‘un-cleaned’, i.e. all binaries and objects are still there. This way you can just call make install to install this build onto your system – or make adjustments to sources without having to wait half a day for the compile run to finish.
Again, you will need a RISCos 4.5x system – it does not make any sense on any other system than a MIPS box!

Make yourself even more comfortable

Many years of Linux and other grown-up UNICES make using RISCos very…. tedious. The standard shell is IMHO a serious pain… the supplied csh makes life better but still, it could be better.

So here’s a (growing) archive of tools I was able to compile or dig out somewhere in the depths of the web. As soon as I got gcc working reliably this archive should grow faster providing more improvements:

  • Mosaic (2.4 & 2.7b4)
  • amd
  • color_ls
  • elm
  • fvwm (2.0.42 – prebuilt for RISCWindows, does not run with “my” X11R5 compile)
  • gcc.2.7.2 & lib
  • htadm
  • htimage
  • httpd
  • in.cfingerd
  • in.pop3d
  • libfpvm3
  • libgpvm3
  • libpvm3
  • lsof
  • make (3.75)
  • nslookup
  • perl (5.004b)
  • pgp
  • pvm
  • pvm_gstat
  • pvmd3
  • pvmgs
  • sendmail (8.9.0)
  • ssh (etc. see the archive README)
  • wu-ftpd (2.4)
  • xpm (3.4g)

You can download the above mentioned binaries as tarball over here. Please mind, they’re totally useless if you don’t have a MIPS RISCos 4.x machine.

Hardware mods

There’s not much to mod here – especially given that replacement parts are hard to get in case something went wrong.

I tried to replace the very loud fan inside the power supply. But this did not work out as well as it did e.g. with my Sun Blade 150.
This is mainly due to the fact that this single fan not only cools the PSU but the whole system and thus needs quite some static-pressure which simply can’t delivered by standard PC fans.
If interested, read more about cooling vintage workstations in this post.

MIPS RS2030 – the resurrection

As mentioned in the first MIPS RS2030 post, I’ve got mine off ePay around 2004 and after some testing its life was about slowly moving through my basement waiting for it resurrection…

Hardware

The long way into the light

So, in 2004 the RS2030 wasn’t in the best condition: No front bezel, no hard-drive and a flakey DALLAS clock-chip. There were 8MB of SIPP modules plugged in and luckily it came with the original keyboard, a monitor cable and two QIC tapes from 1989 containing RISCos 4.10.
I fiddled around with it for a bit, still having a 21″ CRT on my desk, happily connecting to the BNC cable and the tapes were still readable but I wasn’t able to get things booting without a tiny bit of documentation. At least I added 8 more 1MB SIPPs for small money to fill it to the brim.

This changed 2012, when I got in contact with Julien Noël, who ran no-l.org (wayback-machine link) which pretty well described how to install RISCos. Well, he had a MIPS Magnum 4000 and used a bootp() server, but it described a lot of things I was desperately needing for my resurrection.
Some mails flew back and forth, a BNC-to-VGA adapter was build and little RS2030 saw some daylight again. Sadly my QIC tape-drive disintegrated over the last years and its pressure rollers turned into sticky goo – and I figured this out, when the goo slowly crawled into my precious tapes. Yikes!  😥
I cleaned the tapes as good as possible and everything went back into the darkness of “Zee Vault™” again. I think it was the next month, when Julian sent me a tarball containing RISCos 4.52 tape images. I saved them in a safe place and moved on…

Now or never!

This year (2018) I had more time at hand than usual and plenty of it went into some of my Macs and a comparably vintage SGI Personal IRIS.
During my fight practicing with installing IRIX 5.3 onto a clean drive I felt like prepared for an even older MIPS box. This time it had to be done! I got myself a new-old-stock QIC drive, 2 still sealed QIC-150 tapes and moved everything in front of my LG TFT display, which is able to handle sync-on-green signals.
Let’s check if it’s still alive at all – flick the switch, a noisy fan starts blowing and ~45sec and some beeps later the RS2030 is back in business:

Yes, the console looks strange. It just uses 2/3 of the screen and has a frame around it. The green tint is due to my way too long video cable.

Ok, there are many “FAILED” messages but it found all RAM and the ROM monitor (aka BIOS) prompt is happily blinking. Woohoo! I left it running/idling like this for a while just to make sure the power-supply stays stable.
After half an hour I moved on. The fails of the NVRAM and Counter/Timer test showed that the DALLAS DS1287 clock-chip finally went flat. The failed SCSI Master Test gave me a bigger shiver…

The clock-chip was quickly removed, the ram content saved, cut-open and enhanced with an external 3V button cell. It’s a common drill for all vintage hardware enthusiasts. I think this is the mother of all clock-chip modding posts.
Luckily the SCSI Master Test went away with the modded DS1287. Phew… while I had my beloved EPROM programmer at hand, I also saved the four 27c512 EPROMs and some Googling actually brought up a  more recent version than mine: v4.30 from Jul. 1989 vs. 4.32 from Jan.1991. You can download the binary images here. The most useful difference I found is the added ‘sprobe‘ command, listing all SCSI devices found.

There’s a nice thing all computers should (still) have. A 7-segment display next to the EPROMs giving you some idea of the systems status while booting. Also pictured the modded clockchip.

I found an older post of somebody desperately looking for a keyboard. While it looks like an XT-keyboard and weights like an IBM model M, it seems to be somewhat special. As said, I’m lucky to gave gotten mine together with the RC2030.

This was the last step: Check the drives. Find a proper SCSI hard-drive and externally connect my new tape-drive.
Having learned from my “tape disaster” in 2012 I carefully checked my tapes before putting them into my precious new tape-drive. And yes, they had a problem: The the slack retention belt was worn out and lost its elasticity…. resulting in, well, slack. To fix this you need a new(er) tape as ‘belt-donor’ and then do some tape-DJ’ing.

As I wasn’t able to find 2 reliable donor tapes, I decided to not dump the RISCos 4.10 tapes and move on…

Software

It’s getting serious: I took my two best blank QIC tapes and copied the RISCos 4.52 tape-images onto them using Linux on my retro-server (which one day deserves a post for itself). That was the easy part…

Let the game begin

Using Juliens recipe the initial boot from the tapes went smooth. Well, at least for 90’s measurement. Times were different, so it’s definitely not slap in some DVD/USB-stick and let the BIOS do the rest – choose some packages to be installed and baaam!, OS installed.
This is the drill (theoretically):

  • Use the minimal boot command of the ROM Monitor to boot a stand-alone shell (‘sash‘) from the 3rd block of the tape.
  • This sash knows filesystems, so you can use it to temporarily copy a mini-root system from tape block #4 into the swap-partition
  • Then load the RISCos kernel from tape telling him where to find the mini-root filesystem.
  • Finally this kernel loads a full-blown shell which then is able to execute the install script (‘inst’).

But if you’re not owning an original hard-drive you have to format/partition yours first. In this case you have to “boot” the MIPS format tool. It’s the grandfather of SGI IRIX’ fx, just even more basic.
Very 
basic. And confusing. Out of the box, it “knows” 13 hard-drive models, of which 8 aren’t even SCSI. And all of them are very, very, very obsolete. Here’s the printout:

Option #13 gave me some hope… “other” means you can add your own drive – if you have these specs at hand:

Well, I guess you don’t. Neither did I. So I wasted spent 2 days to figure out how to get a partition scheme and whatever else is needed by RISCos onto my disk.
To spare you this experience, bad ideas are:

  • Use the IRIX’ fx tool
  • Use gParted
  • experiment with those wiredo specs

The solution is -as most of the time- simple. Choose some SCSI disk from the menu, answer all questions but deny formatting, so it will write all partitions and the so-called volume header (a partition containing sash and stuff). The tool ‘prtvtoc’ (PRinT Volume Table Of Content) will then show you something like this:

After that you can boot sash, miniroot und finally start ‘inst’. Again a very simple installation tool which creates the EFS filesystem and copies all packages onto the hard-drive. Time for a break… tapes are slow and it’ll take ~2hrs.

So tonight I’m gonna party like it’s nineteen ninety-nine

When that’s done, you have to reboot and your MIPS will boot like a proper workstation… back in the days. It takes some minutes and it greets you with a simple ‘sh’ prompt.

To make your life a bit easier quickly enter ‘chsh’ to switch into ‘csh’ which is a bit more modern.
From there have fun exploring your new, old system. Ah, and don’t forget: RISCos is not year 2000 aware. So set the clock to something before December 1999 😉

Don’t miss the next chapter: Home improvement… making things a bit more convenient.

The MIPS RS2030

Intro: The sleeping beauty

Well, the MIPS RS2030 isn’t really a beauty – but it slept quite a while in my basement. Actually, it’s a mediocre UNIX workstation at best… but there are many things about it, making it a special piece of my collection – and as an returning reader of GeekDot you may know I have a soft spot for those whacky things from back then… and as often with my posts, this one will be the most detailed you’ll be able to find. The RS2030 is yet another lonely system.
Well, if you look like this, you’re not the hottest thing in the Workstation-Discotheque 😉

First things first

MIPS… Even if you have just a dim knowledge about processor history, this name will ring a bell… Founded in 1982 MIPS created the first commercially available RISC CPU and until 1992, they were system manufacturers, too.
The RS2030 had many “firsts”: It was one of their first models, featuring their first CPU, the R2000, and somewhat paved their way into the market while immediately hurting MIPS’ reputation… more about that later. And last but not least, the used OS was one of the first 32-bit operating systems (1985) for RISC-based workstation-class computers.

So here are the specs:

  • Insane 12 (VAX)MIPS squeezed out of an 16.6MHz R2000 CPU and R2010 FPU. 32KB external Cache should speed things up a bit…
  • Up to 16MB (yes, that’s the max) RAM
  • 10Mbps ethernet… that’s 10base2 or an AUI transceiver.
  • 4MB/s synchronous SCSI interface (internal space for one 3.5″ HD)
  • Two RS232 ports controlled by an NEC V50.
  • Optional monochrome or color frame-buffer
  • Optional 3.5″ floppy drive

Just for the record: There was a 2nd model called RC2030, which only differed by not having the frame-buffer. It was sold as server… that’s why the put the “C” in the name. Errr, no, it’s… not… logical. So I’ll forget about this and move on.

The official brochure pictured all these parts like this:

Nice, but missing the power-supply and stuff… in reality, my RS2030 looks like this from the top:

Yeah, I’m missing the the hard-drive carrier – but the same goes for the front bezel, so what the heck… OTOH I have the mighty color frame-buffer, which you can see to the right of the huge power-supply in the middle. It is capable of 1280x1024x8bits/pixel at 60Hz. Here it is in more detail:

Here’s my mainboard having the PSU and frame-buffer removed, revealing the glorious R2000 and his math-bro’ R2010 as well as the V50 “I/O processor” and 4 mysterious MIPS custom chips :

Right behind where the frame-buffer sat, above the CPU/FPU you’ll find the L2 caches and RAM slots. These are SIPP modules and the maximum supported are 16x1MB.
Back in 1989 that was many… not much, but enough for a serious workstation:

Looking closely you’ll notice the cut cables for the 2nd fan (wasn’t me!). A small but very loud one meant to cool the RAM and most important the CPU/FPU underneath the frame-buffer.
Because I currently run the RS2030 without lid, it’s OK. But after some hours it gets quite hot in that region.

To the left of the power-supply (which has another very loud fan) are supposed two carriers for the hard-drive and the floppy-drive. Both were absent when I got this little beast.
Underneath the drives are the ethernet and SCSI controllers as well as the 4 EPROMs containing the “BIOS”, aka monitor.
Like all workstations back then, the RS2030 boots into a monitor, a basic software which gives you some means of setup and options to boot from HD, tape or network. More about this in the next chapter about setting things up.

To round things up, here’s the back side – connectors are from left-to-right:
Keyboard (DIN), 10base2 & AUI ethernet, SCSI, one parallel, two serial connectors and on top the frame-buffer. Mind the uncommon “0W3” RGB connector.

The OS with the many names

Finally, the RS2030 -like all MIPS workstations- ran a strange flavour of UNIX called UMIPS or MIPS OS or RISC/os or RISCos (not to be confused with Acorn Ltd.’s RiscOS)… all tree names/notations are used randomly across documents and mails from those times. So Googling stuff is a drag, 99% of the hits are Acorns RiscOS pages.
It seems MIPS’ operating system started out as UMIPS (UnixMIPS) and settled to RISCos around 1990.
As said, in 1992 MIPS gave up making computers… and was sold to Silicon Graphics (SGI). And playing around with early IRIX versions you smell RISCos all over the place – it’s definitely the mother (or father) of IRIX.

Anyhow, like other Unices of those times, RISCos is hard to get used to it as it misses all those comfortable things we got used to in these Linux days. No bash, no editor but vi etc… To make things short, here’s the Wikipedia roundup:
RISC/os was based largely on UNIX System V with additions from 4.3BSD UNIX, ported to the MIPS architecture. It was a “dual-universe” operating system, meaning that it had separate, switchable runtime environments providing compatibility with either System V Release 3 or 4.3BSD.

Rant, rant, rant…

As said in the beginning, the RS2030 wasn’t quite the showpiece for MIPS. During my research I came across many disgruntled posts about this and other MIPS machine(s).
It actually seems that the RS2030 wasn’t even designed by MIPS but taken over from some other company (my assumption is ‘Integrated Solutions Inc.’ given the marking on the frame-buffer) to fill a gap. Here’s the gist featuring replies by someone who obviously worked for MIPS back then:

>>Between the sloppy I/O implementation (the RS2030 was designed by a
>>now-defunct-or-nearly-so workstation company, whose design Mips had to finish
>>to allow the delivery on a large contract; the bozos who did the box used an
>>off-the-shelf NEC V50 chip for I/O and programmed it poorly, causing lame
>>serial and SCSI performance where simply using the R2000 would have worked
>>better), the lack of expandability and the proprietary memory modules…

The options at the time were:
a) Walk away from a deal for a few thousand systems, a large percentage at the time of Mips’ total base
b) Manufacture only the few thousand systems, and make little or no money on each because of economy-of-scale issues
c) Build and announce the 2030, and keep going on the next generation (albeit somewhat delayed)

(a) and (b) would have resulted in no Mips workstation product at all
that year, which would have been dramatically worse for the company.
The strategic direction at the time was to expect most serial i/o to
come in from terminal servers (this was subsequently modified somewhat).
In addition, issues of SCSI performance did not become apparent and reproduceable from quite some time after product launch.

>Surely MIPS could at least provide new ROMs for the V50? Or did the
>bozos solder them in?
There are some reliability fixes available. As for performance, let’s
face it: nobody’s going to spend money to improve the performance of a
system, at no return, years after it has been dropped from the product
line.

Wow, so it was deliver something mediocre and move-on quickly to create something better. IMHO not the best way to build a good reputation.
This probably led to comments like this:

Unfortunately, computers made by MIPS Co. were ill-engineered products. They were error-prone. From my limited experiences, they easily got broken. We had many broken RC2030s (early times RISC desktop with sloooooow R2000, codenamed “Jupiter”) and many broken RC3230s.
We stock them unwillingly and dumped eventually with disappointments.

Does this make me turning away from this poor little, mediocre thing. Not a bit! It’s an important piece of IT history – and because this is GeekDot, I will make it work for its money.

So follow me to the next chapter: RC2030 – The resurrection.

Weitek Abacus FPU

This is the first post on GeekDot about a single IC. While I did a lot of writing about ICs, mainly CPUs and FPUs, back in the BBS days (German) I stopped doing so after that and concentrated on collecting them during the following years – a true love never dies 😉
The Weitek Abacus FPUs were always special, exotic and unaffordable for the most of us. Today they additionally got a touch of a mythic being, especially as 386/486 boards featuring the special  WEITEK socket are dying out fast. Not mentioning the Abacus FPU itself.

Recently I had a mail conversation about the Abacuses and because they’re are memory mapped, I thought they might actually fit quite good into the range of my other accelerator post as the DSM860 or all those Transputer cards.

I wasn’t planning to go into all the details about the Abacus models 3167 and 4167 and went looking for a handy Wikipedia link.
To my surprise that article is pretty general and just briefly touches all product ever made by WEITEK.
So, the best source of technical information about these FPUs is the highly recommendable posting “copro16a.txt“, written by Norbert Juffa in 1994.
I’d call it the most comprehensive write-up about FPUs until that date. Because you’ll never know what happens to external links, here’s the (shortened) part about the Weitek chips:

The architecture of the Weitek chips differs significantly from the 80x87.
Strictly speaking, the Weitek Abacus 3167 and 4167 are not coprocessors in that they do not transparently extend the CPU architecture; rather, they could be described as highly-specialized, memory-mapped IO devices. But as the term "coprocessor" has been traditionally used for these chips, they will
be referred to as such here.

The Weitek coprocessors have a RISC-like architecture which has been tuned for maximum performance. Only a small instruction set has been implemented in the chip, but each instruction executes at a very high speed (usually only a few clock cycles each). [...] 
In contrast to the 80x87 family, the Weitek Abacus does not support a double extended format, has no built-in transcendental functions, and does not support denormals. The resources required to implement such features have instead been devoted to implement the basic arithmetic operations as fast as possible.

While the 80x87 coprocessors perform all internal calculations in double extended precision and therefore have about the same performance for single and double-precision calculations, the Weitek features explicit single and double-precision operations. For applications that require only single-precision operations, the Weitek can therefore provide very high performance, as single-precision operations are about twice as fast as their double-precision counterparts. Also, since the Weitek Abacus has more registers than the 80x87 coprocessors (31 versus 8), values can be kept in registers more often and have to be loaded from memory less frequently. This also leads to performance gains.
[...]

To the main CPU, the Weitek Abacus appears as a 64 KB block of memory starting at physical address 0C0000000h. Each address in this range corresponds to a coprocessor instruction. Accessing a specified memory location within this block with a MOV instruction causes the corresponding Weitek instruction to be executed. (The instructions have been cleverly assigned to memory locations in such a way that loads to consecutive coprocessor registers can make use of the 386/486 MOVS string instruction.)
This memory-mapped interface is much faster than the IO-oriented protocol that is used to couple the CPU to an 80287 or 80387 coprocessor. The Weitek's memory block can actually be assigned to any logical address using the MMU (memory management unit) in the 386/486's protected and virtual modes. This also means that the Weitek Abacus *cannot* be used in the real mode of those processors, since their physical starting address (0C0000000h) is not within the 1 MByte address range and the MMU is inoperable in real mode. However, DOS programs can make use of the Weitek by using a DOS extender or a memory manager (such as QEMM or EMM386) that runs in protected/virtual mode itself and can therefore map the Weitek's memory block to any desired location in the 1 MByte address range.

Typically the FS segment register is then set up to point to the Weitek's memory block. On the 80486, this technique has severe drawbacks, as using the FS: prefix takes an additional clock cycle, thereby nearly halving the performance of the 4167. Most DOS-based compilers exhibit this problem, so the only way around it is to code in assembly language.

Ok, so we have a good idea how the Abacuses work and how they can be used. … but what’s the story behind the company?

This is a ‘web found’ © by antiquetech.com
“Founded by Chi-Shin Wang, Edmund Sun, and Godfrey Fong (President and CEO) in 1981 in San Jose. All founders immigrated from China.
Weitek specialized in high-performance digital semiconductor components and systems for the computer and workstation industries. Weitek floating point units have been used with Inmos Transputers (Floating Point System T-series Hypercube, 1986), National Semiconductor NS32032’s (Encore Multimax, 1986), and Intel 386’s (1988). The 2048 was used in the Thinking Machines Corporations CM-2 Connection Machine. Weitek produced floating point processors for HP. HP allowed to Weitek to use it’s facilities to make chip for themselves and for their competition.”

When dramatically loosing ground to the 486DX2 Weitek moved away from the x86 platform and concentrated on SPARC CPU and FPUs as well as MIPS FPUs. That worked quite well for some time and in the 90s they finally moved into the frame buffer and graphics accelerator business. Their POWER P9000/P9100 models were quite successful but lost when players like S3 and ATI started to flex muscles.

Specs

So from our (PC-compatible) perspective there are two models of interest: The 3167 and the 4167. Basically they only differ in the bus protocol to either the Intel 386 or 486.
If you need more detailed data, I make the original specs available here for the 3167 and 4167 as PDF.
Both Abacuses clocked up to 33MHz. Especially the 4167-33MHz is very hard to find these days. That said, it might be possible to overclock a 25MHz version to 33MHz providing sufficient cooling. I found this press snippet where WEITEK proactively promoted overclocking a 33MHz to 50MHz by using a peltier element made by ICECAP – so when overclocking that by 51%, the 32% from 25 to 33MHz should be an issue:

WEITEK and ICECAP announce 33MHz version of Abacus 4167

Ram Ganapathi Mar 30 1992, 02:57 pm
WEITEK and ICECAP announce 33MHz version of Abacus 4167

Weitek Corporation and ICECAP Technologies announced today that users of 50MHz Intel 80486-based personal computers can realize a 50% performance increase for numeric-intensive applications by combining the 33 MHz version of Weitek’s Abacus 4167 math coprocessor with the ICECAP thermal management device. Superior system performance is achieved without degrading system reliability.

Using it

Applications that took advantage of the Weitek Abacus were scarce. AutoShade, Autodesk Renderman, 3-D Studio were the most prominent to use a Weitek coprocessor.
If you happen to own one, you might actually use or at least test it… so here’s the official test-suite from Weitek. It contains these tools

  • DOS TSR to update the BIOS for Abacus support (if missing)
  • A test tool wich checks for an Abacus presence using INT 11h BIOS calls.
  • A diagnose tool
  • 2 demos: A side-by-side Mandelbrot benchmark (yay!) and rendering a phong shaded beach ball
  • Abacus macros for using it natively in your cool assembly code

When I find the time to pull out my Weitek-PC, I’ll post pictures of the demos… feel free to comment if you feel I’ve been missing out something.

The PPC Parsytecs

Well, because I’ve been asked every now and then… I’ll briefly touch the “Post-Transputer era” of Parsytec and thier PPC products in this Post.
No, I don’t own any of those, and they only run/ran Parsytecs very own PARIX OS, so I’m not of much help when it comes to revive your system.  As often said, I don’t like to see Transputers being degraded to communication processors. So this is just for completeness and might help to identify your brand new dumpster-dive finding:

The missing link: PowerTRAM 601

These are the only Parsytec products which truly and directly bridge ‘old-world tech’ (i.e. INMOS) with ‘new-world tech’.
The PowerTRAM – available from 1994 to ca. 1996 – was a size-4 TRAM featuring an 80MHz 601 PowerPC which is memory-mapped into a 25Mhz T425 memory.

The Front has all the glamour. In the lower left corner you can spot the T425 in a QFP package, above it is a MACH FPGA most likely containing the glue logic.
The remaining space is used by the mighty PPC601 hidden under a huge heat-sink and a fan (the 80MHz version was the fastest 601 fabricated using a 0.6 µm CMOS process and ran quite hot) as well as two PS/2 SIMM slots for its RAM.


[Pictures courtesy by J. Snowdon]

The rightmost third of backside is populated with 1MB of RAM for the Transputer and the classic logic to connect it (mainly latches).
The left two thirds are used up by quite some transceivers. Namely six ABT1852 18-bit bus transceivers (the square ones) which most likely connect the Transputer and PPC busses as well as covert the latter 3.6V level to the the T425 5 volts.

The “other x’plorer”

Well, yes, there was another x’plorer in existence. As with the GC-system, Parsytec later offered the “PowerXplorer”- you may guessed it already: It used the cluster from the PPC601 powered GC systems.
Interestingly enough there seem to be 2 versions in existence. At least the German computer magazine c’t reported in May 1994 that there’s a 2 CPU and a 4 CPU PowerXplorer… and featured the two below images as a proof.
Maybe the 2-CPU model was a beta-model or even using early PPC604’s? At least it features SIMM sockets vs. the soldered RAM used in the 4 CPU version.

   p_xplorer4cpup_xplorer2cpu

If you’re really-really interested in that model, here’s a big (Click to zoom) picture of the PPC cluster board. I’ve marked the important parts for easier finding.

powerXplorerBoard

TPM-MPC

The TPM-MPC  (Transputer Processing Module – Multi Processing Card) is basically a single CPU version of the PowerXplorer. So one T425 is handling the link communications and, depending on the revision, a 100, 133 or 200MHz 604e PPC is doing the number-crunching.

This is a Revision 1 TMP, far left in red frame you can spot a T800 Transputer with its RAM – in the green frame is the PPC604 and soldered 16MB of EDO RAM:

TPM_rev1

A somewhat different version (can’t spot a Rev making) providing 32MB RAM to a 100MHz PPC604 and having the glue-logic between the 2 CPUs shuffled around a bit compared to the previous version:

TPM_rev1_5

The Rev.2 model features SIMM sockets for the EDO RAM and has a slightly different layout.

TPM-MPC_total

The Transputer part on this one is a T425 (who needs a FPU for just doing data-shifting?!) with 1MB RAM, framed in red between the 2 SIMM sockets, marked with blue arrows:

TPM-MPC_right

The PPC side (heatsink removed) including some drivers and the 3.3V supply.

TPM-MPC_left

Independent of the revision, TPMs went into a TPM-Box. A simple, steel box with a power-supply, two fans and a backplane for 4 TPMs. This is it from the front (grille removed):

TPM_box_front

…and the even less impressive back.

TPM_box_back

As some ePay auctions mention “taken from RVSI 5700 SYSTEM” I assume the main usage for TPMs were optical analysis/inspection systems which Parsytec built when turning their backs to super-computing.