The collected works of cesss

The SimOS site seems to have been down for a time ( )
R-ten-K wrote:


¿Do they have any product capable of running IRIX like SimOS?
Is there any package with the source code of DR1 and DR2?
R-ten-K wrote:
I guess my joke was lame. The guys behind simos were the team which started vmware.

I didn't know this. Don't worry! :D
winchester wrote:
If it is running virtualised IRIX you are after, why not start a nice little open source project starting off with Virtual Box sources?

It would be a really interesting project indeed, but I believe it wouldn't be legal to use it unless the host hardware is SGI. Even if the user owns an SGI computer, it's not legal to install IRIX outside of the computer that IRIX was shipped with.
I'd like to turn my R5000 O2 into an ultra-silent machine. My idea is to use an SSD, and also, if possible, replace the PSU by something _really_ quiet. The R5K O2 has no fans inside, but I guess the PSU fan is needed for keeping the machine healthy, so I guess I cannot put a fanless PSU here.

Basically, I'd like to have an O2 which is so silent that you cannot tell if it's on or off. Something like a Macbook Air, for example.

Do you have any suggestion for the PSU? I've searched for silent PSUs, but didn't arrive to a conclusion (not to mention I've no idea if I could mount a third-party PSU on the O2, or how)

Regarding the SSD, I've read some threads on this forum, with posters saying successful use of SSD on IRIX via conversion boards. Is there some preferable choice over other?

Last, but not least, for USB mass storage, do you think this NAS device will work on IRIX? :
Did you take some care because of the different air flow from the original fan, like Ian said? (just asking, mine is a 180MHz R5K but I push CRIME graphics quite a lot!!)

Also, people who has installed SSDs on IRIX, can an SSD be the only disk (and of course be bootable) on an O2? Reading some threads, I seem to read you've to tweak drivers or something to make the SSD bootable, so I'm not sure if my wish is feasible...
cesss wrote:
Basically, I'd like to have an O2 which is so silent that you cannot tell if it's on or off. Something like a Macbook Air, for example.
In a quiet room you can still hear an MBA and even in a noisy room you can hear the MBA when it is encoding media or playing a game. There is no such thing as a 'silent' computer fan unless it is in a different room :idea:

The fan in the MBA only operates when needed. Most of the times it's off. And, even when it's at full speed, you hear it but it doesn't generate a "pitch", but just air flowing, similar to a white noise sound, which doesn't hurt. Moreover, whenever I've turned off any SGI in the past, no matter the model, I realized how much noise it was generating: my ears always experienced the typical pitch you get when you exit a pub or disco with loud music. This never happens with the MBA or most Macs: in the worst case you notice a low noise fan turning off, but you don't get that "peace experience" you notice when turning off an SGI.

Anyway, from what I'm reading, I think it might be easier to finish the Indy emulator in MESS and run it on a silent computer, than doing this silent O2 project, which might be not only expensive, but also requiring some tweaking.
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?
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.
maxxi.desktop wrote: As per my agreement with SGI, MaXX can ONLY run on Linux intel . This is the main reason why I couldn't release the source for 5Dwm for example. But again, I am reopening the communication channel with them... will see :)

Reopening the communication? Do you mean there's still anybody at SGI who ever heard of IndigoMagic? If affirmative, it's really sick that they won't take any measure for allowing future IRIX development within community driven projects (like support us by releasing specification docs or parts of source code not covered by third parties licensing), but on the other hand they'll sue you if you mimic IndigoMagic without a license agreement. I've just one word for this behavior: they're sick.
hamei wrote:
cesss wrote: If affirmative, it's really sick that they won't take any measure for allowing future IRIX development within community driven projects (like support us by releasing specification docs or parts of source code not covered by third parties licensing), but on the other hand they'll sue you if you mimic IndigoMagic without a license agreement. I've just one word for this behavior: they're sick.

Actually, no. Actually, you are the one who is sick. It's theirs, not yours.

How about if I move into your house ? Free ? Maybe take over one or two bedrooms and the bathroom ? I'll let you use the kitchen once in a while if you ask nicely ...

What's with people these days ?

Ownership of a good isn't the factor that determines sickness: Eating a shoe is sick even if you own it. And it's even more sick if you deny that your shoe exists while you continue eating it.
It would be so great if there was an IndigoMagic-themed OpenMotif available in source code...
Are there any known details on programming the ASICs responsible for managing the CPUs in multiprocessor SGIs? I mean, details from an OS-development point of view (ie: ASIC commands needed to create a new process on a certain CPU, or for scheduling each CPU, etc...).

I don't mind if the details are for Challenge, for the Octane, or for NUMA or later MP boxes.

The purpose is that I feel curious about the protocol of commands used by SGI for controlling MP systems. I'm beginning a pet project which needs (simple) MP and maybe I could get some inspiration from older SGI designs...
ivelegacy wrote: good question, I do not have an answer, but I can say OpenBSD and Linux has SMP for IP30

Thanks, I forgot this. I'll take a look at the source. Thanks a lot too for the pointers towards DASH documentation to everybody who contributed.
Using OpenMotif (now renamed to Motif-2.3.4 and under LGPL) for running old X11/Motif applications, I've become quite bored of the boring default fonts and sizes provided by standard Motif. Widgets are very small, fonts look amateurish, and it really looks far from professional.

Yes, I know MaXX isn't open source, and that standard Motif doesn't provide theming, but... OTOH it should be possible to exactly match IndigoMagic fonts and widget sizes by correctly defining Motif resources (sure, there wouldn't be round borders, nor red ticks on toggle buttons, nor any other of the IndigoMagic candy, but... I believe it could look quite professional, or at least vastly improved if compared to the standard Motif look).

Has anybody tried something like this? Do you have any good-looking Motif resources file at hand?

NOTE: I'm assuming not running under IRIX (otherwise I know how to enable IM-look via the famous couple of Motif resources).
Does the MaXX-SGI license prevent others from shipping applications with themes that exactly match the SGI widgets on systems where MaXX is not installed? For example, if the GTK themes were a perfect match of the Motif SGI widgets (they aren't but let's suppose they were), would it be prohibited to include such theme within an application package?
Thanks a lot for the fonts hints!!

Man... it is impressive what you can accomplish with X11 resources!! :shock:

After quite a lot of trial & error, measuring colors, pixel sizes, and pixel distances on the screen, I've arrived to a setting of X resources which shockingly resembles the original SGI look 'n' feel. I've tried to match the colors, pixel sizes and distances of all widgets (except the dials and perhaps other very rarely used widgets).

The "size" of a widget with SGI look 'n' feel isn't straightforward to measure because IM adds a 1-pixel dark border around widgets (which cannot be done with standard Motif), so when in doubt on whether to consider or not the dark border in the size, I used the choice of whatever looked aesthetically "more correct".

As you may notice in the .Xdefaults file, I had to make XmScrollbars 2 pixels larger when they belong to an XmScrolledWindow. I don't know the reason, but they have to be 2 pixels larger in order to have the same size as the other ones.

If you have XmScale widgets, make their XmNscaleHeight or XmNscaleWidth to be 15 pixels (don't set both, set only the proper one depending on whether the XmScale is vertical or horizontal, respectively.

If you have togglebuttons or pushbuttons with icons (pixmaps) instead of text, make them have a 3-pixel marginHeight and marginWidth.

This is with standard Motif 2.3.4 (now LGPLed). No modifications to the original source code. It's very shocking that you can get so close to the SGI look without modifying a single line of Motif.

Please, if you achieve greater accuracy by retouching these resources, post the modifications, .

Also note that it should be straightforward to use other SGI color schemes. I used the Indigo Magic default because it's the one you always remember with romanticism 8-)

The .Xdefaults file (in order to use it for a given application, just replace "NEdit" with the application class name)

Code: Select all

! These are valid for all applications (replace "NEdit" with the proper application class)
NEdit*menuBar*XmPushButton.marginHeight: 2
NEdit*menuBar*XmPushButton.marginWidth: 9
NEdit*menuBar*XmCascadeButton.marginHeight: 2
NEdit*menuBar*XmCascadeButton.marginWidth: 9
NEdit*menuBar*XmToggleButton.marginHeight: 2
NEdit*menuBar*XmToggleButton.marginWidth: 9
NEdit*menuBar.marginHeight: 0
NEdit*optionPane*marginHeight: 0
NEdit*optionPane*marginWidth: 0
NEdit*XmPushButton*marginHeight: 6
NEdit*XmPushButton*marginWidth: 6
NEdit*XmPushButtonGadget*marginHeight: 6
NEdit*XmPushButtonGadget*marginWidth: 6
NEdit*XmToggleButton*indicatorOn: XmINDICATOR_CHECK_BOX
NEdit*XmToggleButton*indicatorSize: 16
NEdit*XmToggleButtonGadget*indicatorOn: XmINDICATOR_CHECK_BOX
NEdit*XmToggleButtonGadget*indicatorSize: 16
NEdit*XmScrollBar*sliderMark: XmTHUMB_MARK
NEdit*XmScrollBar*width: 20
NEdit*XmScrollBar*height: 20
NEdit*XmScrolledWindow.XmScrollBar.width: 22
NEdit*XmScrolledWindow.XmScrollBar.height: 22
NEdit*XmScrolledWindow.XmScrollBar.highlightThickness: 0
NEdit*XmScrolledWindow.spacing: 0
NEdit*XmScale*highlightThickness: 1
NEdit*XmList*highlightThickness: 0
NEdit*XmList.listMarginWidth: 3
NEdit*XmList.listSpacing: 2
NEdit*XmCascadeButton*fontList: -*-helvetica-bold-o-normal-*-14-*-*-*-*-*-iso8859-1
NEdit*XmMenuShell*fontList: -*-helvetica-bold-o-normal-*-14-*-*-*-*-*-iso8859-1
NEdit*fontList: -*-helvetica-medium-r-normal-*-14-*-*-*-*-*-iso8859-1
NEdit*XmLabel*fontList: -*-helvetica-bold-r-normal-*-14-*-*-*-*-*-iso8859-1
NEdit*XmLabelGadget*fontList: -*-helvetica-bold-r-normal-*-14-*-*-*-*-*-iso8859-1
NEdit*XmScale*fontList: -*-helvetica-bold-r-normal-*-14-*-*-*-*-*-iso8859-1
NEdit*foreground: #000000
NEdit*highlightColor: #000000
NEdit*background: #c1c1c1
NEdit*XmMenuShell*background: #c1c1c1
NEdit*XmPushButton*background: #999999
NEdit*XmPushButton*topShadowColor: #e6e6e6
NEdit*XmPushButton*bottomShadowColor: #4c4c4c
NEdit*XmPushButtonGadget*background: #999999
NEdit*XmPushButtonGadget*topShadowColor: #e6e6e6
NEdit*XmPushButtonGadget*bottomShadowColor: #4c4c4c
NEdit*XmCascadeButtonGadget*background: #999999
NEdit*XmCascadeButtonGadget*topShadowColor: #e6e6e6
NEdit*XmCascadeButtonGadget*bottomShadowColor: #4c4c4c
NEdit*XmList*background: #999999
NEdit*XmScrollBar*background: #999999
NEdit*XmScrollBar*troughColor: #999999
NEdit*XmScrollBar*topShadowColor: #e6e6e6
NEdit*XmScrollBar*bottomShadowColor: #4c4c4c
NEdit*XmScale*troughColor: #999999
NEdit*XmTextField*background: #b98e8e
NEdit*XmText*background: #b98e8e
! These are NEdit-specific
NEdit*statsLine.background: #c1c1c1
NEdit*statsLine.foreground: #000000
NEdit.main.pane.scrolledW.text.background: white
NEdit.main.pane.scrolledW.text.popup_popupMenu.popupMenu.background: #c1c1c1
NEdit*replaceDialog*XmPushButton.marginWidth:   6
NEdit*pane.sashHeight: 11
NEdit*pane.sashWidth: 11
NEdit*text.selectionArrayCount: 3
NEdit*text.background: #b98e8e
NEdit*text.foreground: #000000
NEdit*highlightBackground: red
NEdit*highlightForeground: black
NEdit*XmText.translations: #override \
Ctrl~Alt~Meta<KeyPress>v: paste-clipboard()\n\
Ctrl~Alt~Meta<KeyPress>c: copy-clipboard()\n\
Ctrl~Alt~Meta<KeyPress>x: cut-clipboard()\n
maxxi.desktop wrote: if there are Motif(standard not SGI Motif) based theme, hum i guess it's fine. GTK+ is different because the look & feel mimic SGI's Motif. I would suggest to use MaXX's themes and add the MaXX's license and copyright. this way you are covered.

See what I was able to get -without any modification to the original Motif- here:
Certainly I'd love to use MaXX for developing apps, but Linux is just a planet for me... I live in several planets right now, cannot be tied to any of them :(
Edited the previous post, to include some fixes and enhancements that I found today. Now, as you can see in the updated screenshot, scrollbars have a more accurate width, and they have the 3-line thumb mark too (I didn't know, but standard Motif supports that feature out of the box). I've also fixed all inaccuracies that I was aware of. Now, all the Motif apps I tried render "reasonably" exact (in terms of sizes and colors) in standard Motif compared to a real SGI.
dexter1 wrote: Well done cesss!

I had to go far back for people reporting something similar. I have found a post by squeen listing his nedit .Xdefaults file viewtopic.php?f=15&p=43500
But can't verify directly if this matches yours, since my nedit on Ubuntu 15.10 segfaults when installing from universe. I think that segfault is a hint :)

I think the .Xdefaults from that ancient thread assumes running on IRIX, because it doesn't specify IM colors and widget sizes, and sets "sgimode", which isn't understood by standard Motif.

Anyway, it's important to note that my effort is targeted to all Motif applications. I used NEdit as an example for the screenshot, but some of the resources have no effect on NEdit. In fact I didn't tune the settings with NEdit, but with other Motif demos for which I had real IRIX screenshots with IndigoMagic look enabled.

In my tests with several Motif demos, this resource set provides a +/- 1 pixel accuracy (in positions and sizes) comparing standard Motif (on XQuartz), with IndigoMagic Motif running on a real IRIX workstation. Exact pixel accuracy isn't possible because of the dark border which SGI Motif adds in all widgets, which can't be done with standard Motif (and if you emulate it by making the widget larger, you're losing positions accuracy too).

One place which isn't pixel accurate is the width of option menus. Their height is pixel exact, but their width isn't. I know how to fix it (it depends on the width of the pushbutton childs in the pop-up menu, but I was more interested in the height than in the width. I left it as an exercise for the future.

Also, maybe accelerators and menu entries doesn't have a 100% exact horizontal margin, because I tested and measured the vertical space between menu entries, but not between entries and the menu border.

Regarding your NEdit segfault in Ubuntu, I don't trust any Motif (nor Xt) stuff that comes from Linux, because, honestly, X11 on Linux is GTK only, which means that Motif and Xt are almost never tested by distro packagers.

My advice is to download Motif 2.3.4, and compile it. Then download NEdit and compile it too, with Motif 2.3.4. I've never found any problem getting NEdit that way.
jimmer wrote: Just as an aside, Nedit ignores a _lot_ of the Xresources mechanism and has many Xresrouces hardcoded. I ripped out a bunch of them in the latest Nedit to make it be a bit more sensitive to the sgiMode and IMD schemes thing. Never made a patch though.

Yes, that's true, but it's only a problem when running on IRIX. If a resource is defined in your .Xdefaults, NEdit honors it even if it has a hardcoded default for it. When running on IRIX, the sgiMode resources values come from somewhere that has lower priority that the NEdit hardcoded values. But if they were in .Xdefaults, NEdit would honor them. So, this issue isn't a problem with the resource set above... NEdit does honor it.

One interesting fact is that SGI defines default Motif resources in /usr/lib/X11/schemes/Base/ ...but their purpose is a great mystery for me: in the comments it seems to imply that such resources are related to sgiMode, but, however, if you use them, you don't get sgiMode sizes and positions. For example, you get smaller pushbuttons, separations in menu entries are wrong, etc, etc... Almost none of those resources is actually used with such values when you enable sgiMode in an application. So, what are they used for? No idea.

BTW, I just updated the set again, with minor fixes: I was setting the XmLabel and XmLabelGadget margins to zero, but this was to compensate for wrong positions coming from changing highlightThickness globally, and these zero margins in labels were causing flickering in file dialogs, so it's obvious that SGI didn't set them to zero. I just removed the highlightThickness global modification, so the label margins are left with their default values, and the flickering in file dialogs is gone.