SGI: Hardware

Single CPU SGI with easiest to fool RAM limit?

Most single processor SGI workstations have the limit of 1GB RAM (except the Fuel with 4GB).

What (64 bit) single processor board do you think would need less modifications (mainly in number of chips and ASICs) in order to support a larger number of RAM GBs? Possible candidates I think would be the Crimson and the Indigo2, but I don't know how complex is their respective memory logic. The O2 cannot run a 64bit OS, so it doesn't count, just like the Indy.

And now... do you think IRIX would be able to use 8GB RAM on a Crimson or Indigo2 if you had such a modified board?
cesss wrote: Most single processor SGI workstations have the limit of 1GB RAM (except the Fuel with 4GB).

What (64 bit) single processor board do you think would need less modifications (mainly in number of chips and ASICs) in order to support a larger number of RAM GBs?

Least modifications would be a single CPU Octane2: zero 8-)

cesss wrote: Possible candidates I think would be the Crimson and the Indigo2, but I don't know how complex is their respective memory logic.

The concept of 8GB RAM in a system with a 100 or 150MHz CPU and a 10MB/s SCSI bus (or was it 5MB/s sync? can't be bothered to look it up atm.) is ... ahem .. interesting :?

cesss wrote: And now... do you think IRIX would be able to use 8GB RAM on a Crimson or Indigo2 if you had such a modified board?

No.

It's physically possible yo install 1.5GB of RAM in an Indigo2 R10000, but if you install more than 1GB it won't boot because something else is mapped into that region of the address space. I tried it myself and it doesn't work.

So, not only would you have to modify the hardware in an incompatible way (new IPxx number), you would have to change the OS as well. While you're at it, you might as well upgrade the SCSI bus, network interface and a few other things. This has been done already and it's called the Octane :mrgreen:

Your best bet would probably be to butcher an Octane and mod it into the Indigo2 chassis. If you dare do this with a Crimson I'll come over and kill you myself ;)

Another, more interesting angle would be to replace the RAM chips of O3K class DIMMs. They are mostly like normal DIMMs: DDR memory, SPD chip etc. but different form factor. Replace the RAM chips and reprogram the SPD to create 4GB RAM kits. Who wants 16GB in their Tezro? I do 8-)
To accentuate the special identity of the IRIS 4D/70, Silicon Graphics' designers selected a new color palette. The machine's coating blends dark grey, raspberry and beige colors into a pleasing harmony. ( IRIS 4D/70 Superworkstation Technical Report )
cesss wrote: What (64 bit) single processor board do you think would need less modifications (mainly in number of chips and ASICs) in order to support a larger number of RAM GBs? Possible candidates I think would be the Crimson and the Indigo2, but I don't know how complex is their respective memory logic. The O2 cannot run a 64bit OS, so it doesn't count, just like the Indy.


This can't be achieved on R8K/R10K Indigo2. The memory controller chip could theoretically allow for a huge amount of memory in the last bank, but then physical memory would overlap the fast mode/slow mode cache logic, which addresses are also decoded by the memory controller.

The O2 which you dismiss so quickly, could, with minor changes to the CRIME chip to either support more than 8 banks, or (probably easier to do) more than 128MB per bank. With a modified CRIME, an O2 could use up to 3GB of memory; with even more changes to CRIME, it could allow for more than 32 address lines and thus even more physical memory.

cess wrote: And now... do you think IRIX would be able to use 8GB RAM on a Crimson or Indigo2 if you had such a modified board?

It will likely require changes to be aware of the chip changes as well.
:Indigo: R4000 :Indigo: R4000 :Indigo: R4000 :Indigo2: R4400 :Indigo2IMP: R4400 :Indigo2: R8000 :Indigo2IMP: R10000 :Indy: R4000PC :Indy: R4000SC :Indy: R4600 :Indy: R5000SC :O2: R5000 :O2: RM7000 :Octane: 2xR10000 :Octane: R12000 :O200: 2xR12000 :O200: - :O200: 2x2xR10000 :Fuel: R16000 :O3x0: 4xR16000 :A350:
among more than 150 machines : Apollo, Data General, Digital, HP, IBM, MIPS before SGI , Motorola, NeXT, SGI, Solbourne, Sun...
The purpose of this question was having a glance at the feasibility of having a substantial amount of RAM on a (future) emulated SGI. The Indy and Indigo2 drivers in MESS are not dropped, they're still work in progress, and most (if not all) of their hardware is documented (except for graphics, only XL is documented). The MESS developers didn't give up in this attempt, and they hope to have it working in the future.

OTOH, the Octane is a different monster: I don't think XBow and HEART are documented (although there's an experimental version of Linux for Octane which I believe accesses XBow/HEART, but I don't think this hardware is known in detail enough to be emulated).

The O2 hardware was also mostly emulated in gxemul (except for Crime graphics). Anyway, I tend to believe that if you've a full machine emulated except the graphics, patching IRIX so that graphics commands are sent to a patched gfx lib which in turn uses the host OpenGL implementation shouldn't be too difficult.

Back to the point, it seems that all SGIs which seem feasible to be emulated someday, have their RAM limited to 1GB in the best case.
cesss wrote: I don't think XBow and HEART are documented (although there's an experimental version of Linux for Octane which I believe accesses XBow/HEART, but I don't think this hardware is known in detail enough to be emulated).

The only source of information about these widgets are the IRIX system header files. This gives enough knowledge to be able to eventually emulate Linux or OpenBSD running or Octane or Origin, but definitely not enough to be able to run IRIX.
:Indigo: R4000 :Indigo: R4000 :Indigo: R4000 :Indigo2: R4400 :Indigo2IMP: R4400 :Indigo2: R8000 :Indigo2IMP: R10000 :Indy: R4000PC :Indy: R4000SC :Indy: R4600 :Indy: R5000SC :O2: R5000 :O2: RM7000 :Octane: 2xR10000 :Octane: R12000 :O200: 2xR12000 :O200: - :O200: 2x2xR10000 :Fuel: R16000 :O3x0: 4xR16000 :A350:
among more than 150 machines : Apollo, Data General, Digital, HP, IBM, MIPS before SGI , Motorola, NeXT, SGI, Solbourne, Sun...
miod wrote:
cess wrote: And now... do you think IRIX would be able to use 8GB RAM on a Crimson or Indigo2 if you had such a modified board?

It will likely require changes to be aware of the chip changes as well.


You're talking machines from the mid '90s, when 32MB was considered pretty big (and 64MB was in the way-out-there-expensive workstation level stuff). IP28 was, let's face it, a hack job to get R10k onto the desktop fast (just as Crimson was a hack job to get R4k into production fast). The followup archs (Indigo2, Everest for R4k, Octane, Origin for R10k) made pretty much full use of the chip capabilities at the time. O2 was kind of a hybrid animal, originally built to use the R5k and later hacked for R10k.

To answer your question: Like Jan-Jaap said, Octane for R10k desktop. If a Crimson fits your definition, get a Reality Station or iStation (single processor Onyx with R4k/Reality or R10k/IR). Remember, when these were built the memory densities just weren't there to get huge memory on the desktop - Everest had 16 or 64MB SIMMS (but up to 6 or 8-way interleave), and Origin200/2000 maxed out at 256MB per DIMM. During most of the 90s you just couldn't fit enough memory in a desktop case to make large memory support necessary.
"Brakes??? What Brakes???"

:Indigo: :Octane: :Indigo2: :Indigo2IMP: :Indy: :PI: :O3x0: :ChallengeL: :O2000R: (single-CM)
miod wrote: The O2 which you dismiss so quickly, could, with minor changes to the CRIME chip to either support more than 8 banks, or (probably easier to do) more than 128MB per bank. With a modified CRIME, an O2 could use up to 3GB of memory;

A 1 ghz dualcore O2 with 3 GB of memory ... 'scuse me, I have to go change my undies ...
"all the leaves are brown and the sky is grey ..."
hamei wrote: A 1 ghz dualcore O2 with 3 GB of memory
That would be someting - an O2 powerful enough to be slow in real time. ;)
***********************************************************************
Welcome to ARMLand - 0/0x0d00
running...(sherwood-root 0607201829)
* InfiniteReality/Reality Software, IRIX 6.5 Release *
***********************************************************************
This is quite interesting topic, and quite intesting question. I'm intersted also in emulating sgi mips/irix, and when i have time i'm doing a lot of research and learning about from the available documentation and existing projects.

If you take for example one simple scale from 1 - 1000, where 1 is the first step in the process of writing some immaginary sgi/irix emulator, and step 1000 is a fully functional one, where all functionalities that you are emulating are working like expected 99% of the time - the moment when you will start to concern about the amount of available RAM - will possibly be - step 1001.

Then, if step 1 is today, make the step 1000, five to ten years later in time, and even that is optimistic. When you will be starting with the immaginary step 1001, you should have learned already everything about MC1 - the heart of Indigo/Indy class machine, demuxes, gio bus, dma and interrupt mappings and maskings. .. and so on and so on. .. that task with that knowledge in that time scale will take possibly few months.

One interesting trivia for the end... from the moment you press the power button of your favoured sgi machine to the moment you see the login screen, there are aprox. half billion (500 000 000) instructions executed this to happen :) and there you are, only at the doors of the endless irix univerese. ..