Tag Archives: MIPS

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:

Right behind the frame-buffer you’ll find the 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

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 (coming soon):
RC2030 – The resurrection.

Digging deeper into the highRISC

After 7 years mainly doing research on Transputers and the i860, I had the feeling it’s time to do some more digging into the highRISC card.
If you have read my initial post about the miroHIGHRISC (and the Tiger) you remember the undocumented 20pin socket on the card (pictured in the upper right corner):


Let’s have another look at the “UART port” again:

The pinout (the connector is rotated 90¬į counter clock-wise):

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

Reading a bit of the BIOS’ disassembly, I stumbled across routines to talk to an UART. ¬†A¬†very common (D)UART of those days was the SCN2681. If you take a look at this chips specs, they perfectly fit to the signals provided at the HIGRISCs UART-port!

Here’s its pinout with the corresponding pins marked:


A2-A5 are used for A0-A3 on the 2681 and the only pin not directly represented is A23 which might be used to decode. Also, it nicely reveals that CPU INT2 is used for the UART.

The LR33000 datasheet tells me that there’s an 4MB IO-area starting at 0x1E000000 reaching up to 0x1EFFFFFF- most likely the 2681 will live there… and the corresponding signal called /IOSEL is available on the UART-port (and will perfectly help as chip-select decoder). Tadaa!

So after the UART we need to get the RX/TX signals to a higher level, i.e. the +/-15V of RS232 – this is the call for our old friend MAX232.

[current bread-board experiments sadly didn’t yield into ‘instant success(tm)’… I’m missing out something – need more time to investigate]

Bootcode / BIOS

The LR330xx CPU also has an /EPSEL EPROM select signal, indicating it’s accessing an EPROM expected to start at 0x1F000000 and ends at 0x1FFFFFFF (4MB right below the IO-area).
Using this knowledge and knowing that the MIPS standard boot-vector is at 0x1FC00000, it’s easy to feed the ROM-dump I did some years ago into the disassembler with the correct start address to do his job.

We need to get an understanding of this bootcode first, so that we can get an idea of “what is where” (e.g. ISA bus, UART etc) and later upload our own code and use those addresses.
Just to stick my head a bit into the clouds, the aim is to first port a then common MIPS monitor-program called ‘PMON’ and use that to run some sort of¬†őľLinux. But that’s probably another handful of years ahead…
PMON was a good source of information, because it’s originally written by LSI, supporting all the LSI eval-boards. Lo and behold, some of them had a 2681 UART, too… located at 0xBE000000, which is extensively used in my BIOS disassembly¬† ūüėČ
I have a certain feeling that miro borrowed some design ideas from the LSI Pocket Rocket¬†evaluation board (don’t Google it, it’s a mythic being – if you have documentation, mail me!).

So this is the 2681 memory-map then:

#define BASE_2681 0xbe000000
#define SRA_2681 ((1*4)+BASE_2681) // 0xbe000004 status register 
#define THRA_2681 ((3*4)+BASE_2681) // 0xbe00000C Rx/Tx holding register 
#define ACR_2681 ((4*4)+BASE_2681) // 0xbe000010 Aux contrl. register 
#define ISR_2681 ((5*4)+BASE_2681) // 0xbe000014 interrupt state register 
#define CTU_2681 ((6*4)+BASE_2681) // 0xbe000018 Counter timer upper 
#define CTL_2681 ((7*4)+BASE_2681) // 0xbe00001C counter timer lower 
#define START_2681 ((14*4)+BASE_2681) // 0xbe000038 start timer 
#define STOP_2681 ((15*4)+BASE_2681) // 0xbe00003C stoptimer

Using those addresses we should easily identify the comms routines.

Something happens at 0xBE800000 which seems not UART related. So that’s probably the reason why A23 is available on the connector. That way we can ignore access to that address by OR’ing it with /IOSEL to create a /CS.

The DOS side of things

The tool to load a MIPS executable into the HIGHRISC is called DL.EXE. Loading the test-program prints this to the console:

miroHIGHRISC download program. V 1.00
(c) miro Computer Products AG , Germany

CONFIG: I/O-register-address: 0x368 
CONFIG: DRAM - base-address : 0xD000 
CONFIG: DRAM - size : 8 MB
CONFIG: TIGER - RAM - size : 8 MB

Resetcount = 87340

Loading test.zor
text : start=0x80030000 size=0x52c0
data : start=0x800352c0 size=0x520
bss : start=0x800357e0 size=0x150
entry : 0x800301a0
TIGER comm.address : 0x3ffd00
max_used_address : 0x35930 
real_DRAM : 0x800000 
Heapsize : 0x7CA6D0

test.zor sucessfully downloaded.

This gives us valuable information. The DOS-side uses the IO port 0x368 and has a memory window of 16K from  0xD000 to D3FF.
MIPS programs are loaded to 0x80030000 and the 16K seems to be mapped to 0x003FFD00, just 128K below the 4MB boundary of the LR33k address space.

As usual – this is heavily work-in-progress. So this post will be edited while making any new progress. TBC…


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

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

Technical facts:

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

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

Here’s the HighRisc in its full glory:


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

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

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

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

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


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


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


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


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

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


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

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

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