The collected works of cesss

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!!

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

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

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: http://forums.nekochan.net/viewtopic.php?p=7387166#p7387166
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.