The collected works of ShadeOfBlue - Page 1

Happy new year! :santa:
0ctane wrote: Also, can one "span" monitors rather than have individual displays?

Yes, it's called 'xinerama'.
To enable it, just do a 'chkconfig xinerama on' and reboot, if I remember correctly...
themacosxflies wrote: said by the bunch of pc users, -cough- pc gamers

Don't listen to them, they have no clue whatsoever.

Here are the some of the differences between OpenGL and DirectX:
OpenGL is portable, DirectX is only available on M$ Windblows.
OpenGL can emulate the features that are not available in hardware, while DirectX cannot.
OpenGL has accumulation buffers, DirectX doesn't.

OpenGL is easier to learn than DirectX and the code is much easier to read and understand.

John Carmack (a programmer at id software) said this:
I have been using OpenGL for about six months now, and I have been very impressed by the design of the API, and especially it's ease of use. A month ago, I ported Quake to OpenGL. It was an extremely pleasant experience. It didn't take long, the code was clean and simple, and it gave me a great testbed to rapidly try out new research ideas.

I started porting glquake to Direct-3D IM with the intent of learning the API and doing a fair comparison.

Well, I have learned enough about it. I'm not going to finish the port. I have better things to do with my time.


Direct-3D IM is a horribly broken API. It inflicts great pain and suffering on the programmers using it, without returning any significant advantages. I don't think there is ANY market segment that D3D is apropriate for, OpenGL seems to work just fine for everything from Quake to Softimage. There is no good technical reason for the existance of D3D.

Though that was a long time ago (1996), but I think that some of the points he makes are still valid.

I'm sure that DirectX has it's own good points, but claiming that OpenGL totally sucks is just plain stupid and the person who said that obviously hasn't used it and is just trying to "defend" M$ products or start a flame war.

I wonder why does SGI use OpenGL on all their workstations and their high-end visualization systems if it totally sucks ;)

The amount of video ram has nothing to do with OpenGL or DirectX.
As for the "crappy graphics", that's the designer's and graphics card's problem, not OpenGL's.
themacosxflies wrote: sure my friend, but you know, windows and pcs are the best thing out there, so people on Apple, SGI, Sun... have nothing to do, they are so intelligent and we kinda morons. :D

Indeed, if your computer isn't the latest and greatest 3 GHz overclocked PeeCee with Windoze, water cooling and neon lighting installed in the translucent plastic case, you're absolutely brainless :)

It's kind of sad, though, seeing all those people supporting M$/Intel without even trying the better alternatives first...
Oh well...
vegac wrote: For the Carmack quote, that was referring to Direct3d 5 (I think) back when there was Immediate mode and retained mode, and neither was good for everything...since then direct3d's structure has become infinitely nicer.

I've googled up some sample code, for both D3D 5 and 8, and I must say, that the code written for D3D 8 is much cleaner, but still more complex than OpenGL's (for some things), though that's probably because I'm more used to OpenGL.

And well, to finish this off simply: As a game developer, it doesn't matter what API I'm using, nor does it matter what language I'm programming in, they all work the same in the end, they all have benefits and drawbacks, and if people are wasting time worrying about language and api, who's worrying about the game?

Indeed. It doesn't matter what you use, as long as the final result is what you (and the customers) want. :)
Hmm... let's see...

I've got a nice business-card sized badge with a picture of some white icy mountains, the sea and a fiery torus rolling on the water towards the mountains. There's the cube logo along with the writing "SiliconGraphics Computer Systems" in the lower-right corner and "See what's possible" is written above the mountains.
On the other side of the badge, there's a small circuit with a blinking red light that's between the letters P and S of the word "possible" in the writing.

I also have some brochures about Indy, Indigo2 and the Indy Webforce model.
As for the clothing... I have two T-shirts with a picture of an Indigo2 on the back and one with an O2. (Both have the cube logo, too :) )
Omega_Trion wrote: I just got a sun 13w3 to vga adapter for my sony lcd that worked on my O2, but I get ano signal from my octane. any ideas on this? thanks

Sun has wired some things differently than SGI - sync signals, IIRC, which is why it won't work. :(
You can, however, break some specific pins off the adapter (can't remember which, do a search on google groups :) ) and it should work then.

You can also try the adapter from UltraSpec that I've mentioned, that one works perfectly here.

amigo wrote: I've tried my Octane2 with V6 on Samsung SyncMaster 191T which does SOG. It did show those stripes and Auto button mostly gets rid of them but what I've also done is compile my own .vfo file to match the parameters for the LCD so I think it makes it better

Neat! I'll try it here... :)
*wanders off searching for a VFC manual*
I would recommend the book "The C Programming Language" by Kernighan&Ritchie, it is written in a clear and understandable language (it does assume you have some general knowledge of programming, though), not to mention it was written by the people who created C, so you can't go wrong with this one. :)
After your read it, I'd suggest you get a book which describes ANSI C (K&R C is a bit outdated these days). Even if you should decide to learn just ANSI C, the K&R book is still a very good intro to C programming.
You should then look at other people's programs and try to understand what they do, maybe modify a few lines here and there, that should give you some general idea how things work.

As for C++, the book by Bjarne Stroustrup is good, but it is a bit hard to read, as it was pointed out before.
If your bookstore has such books, I'd suggest you browse through different books and choose the one you like the most. :)
You can take a look at sysmp(2), especially the MP_SAGET and MP_SAGET1 commands.
Flags like MPSA_SINFO [for processor loads, etc.] and MPSA_RMINFO [memory info] are probably something you're looking for.

If you're also interested in getting some detailed data about the devices in the system (something like hinv), you can take a look at getinvent(3).

I have made a short ~85 line program in C that demonstrates the use of sysmp for getting some trivial memory info and per processor loads. I can also dig up some code that uses getinvent to show some simple info about the system.
I can post the source here, if anyone is interested. :)

Otherwise, PCP is great for getting all sorts of data about the system; if I'm not mistaken it even has a C library, so you can call it directly from your app.
OK, here's that sysmp code I wrote some time ago. It's nothing fancy, just reads the data.
If I remember correctly, the loads are in CPU time (ie. they tell you how much time in total has the CPU spent in user, kernel, idle, ... state), but don't take my word for it - you should probably check some manpages first :) .

Code: Select all

#include <stdio.h>
#include <string.h>  /* for memset(), strerror()  */
#include <unistd.h>  /* for exit(), getpagesize() */

#include <sys/types.h>
#include <sys/sysmp.h>
#include <sys/sysinfo.h>

#include <errno.h>

/* Convert pages to kb */
#define p2kb(pages) ((((uint64_t) pages) * pagesize) >> 10)

/* Automatically set in init() */
static int pagesize = 4096;
static int numproc  = 1;

/* Structs for holding our info */
static struct sysinfo si;
static struct rminfo  mi;

void init(void) {
/* Get page size */
pagesize = getpagesize(); /* Alternatively, one could use sysmp(MP_PGSIZE) */

/* Get the number of processors in the system */
numproc  = sysmp(MP_NPROCS);

/* Clear the structs */
memset(&si, 0, sizeof(struct sysinfo));
memset(&mi, 0, sizeof(struct rminfo));

void display_data(void) {
register int i, ret;

printf("%d CPU(s); Page size = %d bytes\n", numproc, pagesize);

/* Get memory info into the [mi] struct */
ret = sysmp(MP_SAGET, MPSA_RMINFO, &mi, sizeof(struct rminfo));

/* Bail out on error */
if (ret != 0) {
fprintf(stderr, "sysmp(MP_SAGET, MPSA_RMINFO) returned %d\n", ret);
fprintf(stderr, "ERROR: %s\n", strerror(errno));

printf("Memory: %d MB free, %d MB used;  %d MB total\n",
(unsigned int)(p2kb(mi.freemem) / 1024),
(unsigned int)((p2kb(mi.physmem) - p2kb(mi.freemem)) / 1024),
(unsigned int)(p2kb(mi.physmem) / 1024)

* Show loads for every processor
*   If you want to get the combined loads for all processors in the system,
*   just use MP_SAGET instead of MP_SAGET1 and remove the last parameter.
for (i = 0; i < numproc; i++) {
/* Get info for processor [i] into the [si] struct */
ret = sysmp(MP_SAGET1, MPSA_SINFO, &si, sizeof(struct sysinfo), i);

/* Bail out on error */
if (ret != 0) {
"sysmp(MP_SAGET1, MPSA_SINFO) returned %d for processor %d\n",
ret, i);
fprintf(stderr, "ERROR: %s\n", strerror(errno));

printf("CPU%d: %ld user, %ld kern, %ld sxbrk, %ld intr, %ld idle, %ld wait\n",
i, si.cpu[CPU_USER], si.cpu[CPU_KERNEL], si.cpu[CPU_SXBRK],
si.cpu[CPU_INTR], si.cpu[CPU_IDLE], si.cpu[CPU_WAIT]

int main(int argc, char *argv[]) {

return 0;

It should give an output similar to this:

Code: Select all

2 CPU(s); Page size = 16384 bytes
Memory: 1104 MB free, 431 MB used;  1536 MB total
CPU0: 282134 user, 26628 kern, 0 sxbrk, 2928 intr, 2024597 idle, 3504 wait
CPU1: 86504 user, 21074 kern, 0 sxbrk, 1404 intr, 2228580 idle, 2201 wait

Hope that will be of some use to your project :)

EDIT: Just wanted to add this: to get percentages, you will probably have to gather the data for all processors, usleep() for some time (like maybe half a second, or a second), gather the loads again and compute the percentages from that.
At least that seems to be what `top` and the like do.
If this is an LCD you're having problems with, then you might want to check if it has some sort of "Auto adjust" button or menu option.
Something similar to what you described seems to be quite common with LCDs connected via the analog port and the auto adjust fixes it almost always (use it more than once if it doesn't do the job the first time).

I have to do this once in a while with my LCD which is also connected to an Octane (MXE) and after that everything works fine. :)
dkedrowitsch wrote:
How do I figure out what to adjust the order of the libraries to?

Move "-lgen" after "-lGL" and it should work.
I've successfully made Impressario recognize my Xerox Phaser 6120, which is also a networked printer. The whole process was easier than I had imagined :)

First, you'll have to get the right PPD file for your printer -- usually you can download them from the manufacturer's site (Xerox has them in the Linux driver package and they're also included on the CD that comes with the printer).

Then read the document here to get an idea on how to install the PPD.

After you do that, go to Toolchest->System->Printer Manager, click the Add button and simply follow the instructions.
You can configure the printer options by clicking on the printer in the Printer Manager and clicking on the Options... button.

You can test if everything works by starting the Icon Catalog, going to the Printing tab and double-clicking on PrintStatus. Then just select Printer->Send Test Page.
If everything works, you'll be able to print from any program that supports it.

Note that Impressario only works nicely with PostScript printers, you'll need CUPS for printing to a non-PostScript printer.
tbcpp wrote:
Is there a (free) program that will allow me to display the video-in fullscreen?

Yes, it's called 'bigvideoin' and you can get its sources here .
It seems to work fine here (Safari 3.0.4) ...

. -> no leading spaces
. -> 2 spaces
. -> 4
. -> 8
. -> 16

What browser are you using? It's possible it doesn't have support for the CSS white-space property or that it in some way alters the text you enter.
According to this document (thanks, Ian!), the SSN (system serial number) located in the NVRAM of the brick's L1 controller has to be set to L0000000 for the brick to obtain a new SSN from the neighbouring bricks.

SGI doc #108-0240-002 wrote: When an R brick needs to be added to a system or moved to a different system, SGI
authorized personnel can clear the SSN that is stored in the L1 controller’s NVRAM.

To clear the SSN, SGI authorized personnel use a temporary authenticator generation
software program, which is located on a secure Web server that can be accessed via
WebSAFE (use your SGI login and password). Using the brick serial number, this software
generates an authenticator (four alphanumeric fields [total of 18 characters]) that is based
on the brick public key and the current date and time.

The SGI authorized personnel input this authenticator into the L1 controller
validation/serial number change software. The L1 controller software compares the
authenticator to the brick public key. When the authenticator matches the brick public key
and it has not expired, the L1 controller software clears the brick SSN. When the
authenticator does not match the public key or if the authenticator has expired, the L1
controller software does not change the SSN.

However, according to the same document, the L1 controller's NVRAM chip is socketed, so if the SSN is stored in cleartext, it could be rewritten without much trouble, hypothetically speaking.
2ndadamdick wrote: I remember reading about a back door into clearing - has anybody heard of this ??

Yes, but it seems this refers to the generated authenticator from the other document: wrote: Use serial <str> <str> <str> <str> to reassign the SSN for a brick. The variable <str> <str> <str> <str> is the value of a security key that is provided only to SGI employees.

Use serial security on to enable the SSN security.

SAQ wrote: Hopefully they'll release the codes when the O(3*10^X) series hits end-of-support and they won't make any more money from service.

*fingers crossed*
nekonoko wrote: I'll bet the Altix series uses the same codes so the EOL may be a long time in coming.

I just checked the Altix docs on Techpubs -- you're right:
serial <str> <str> <str> <str>

Erases and reassigns the device's SSN. The variable <str> <str> <str> <str> is the value of a security key that is provided only to SGI employees.

This document also has an explanation of the "serial security on" command:
Enables the system serial number (SSN) security. When this feature is enabled, it will not allow bricks or enclosures to power up if their SSN does not match those of neighboring bricks or enclosures. To change the SSN on a brick or enclosure, you need a key that can be obtained through a service request to SGI.

It seems this particular command doesn't need any special keys, so if you could do "serial security off", the bricks would boot normally (although they would probably whine about the mismatched SSN).
I'm probably being too optimistic here :)
Hello everyone,

Here's a 300-line script I hacked together tonight to make it easier to download individual Nekoware packages with their dependencies.
It's not particularly pretty and it's for tcsh (what was I thinking...), but it works :)

Sample interaction:

Code: Select all

[[email protected]:~]# search auto
Matching packages: autoconf automake
[[email protected]:~]# show autoconf
Package: autoconf
Filename:  neko_autoconf-2.60.tardist
Version :  2
MD5sum  :  95bea378566353e6837d5d6e03f54c10
Deps    :  m4,perl
[[email protected]:~]# get autoconf automake
Downloading package: autoconf ...
######################################################################## 100.0%
Checking dependencies for 'autoconf' ...
Downloading package: perl ...
######################################################################## 100.0%
Downloading package: m4 ...
######################################################################## 100.0%
Downloading package: automake ...
######################################################################## 100.0%
[[email protected]:~]# unpack-swmgr
Unpacking neko_autoconf-2.60.tardist ...
Unpacking neko_automake-1.9.6.tardist ...
Unpacking neko_m4-1.4.6.tardist ...
Unpacking neko_perl-5.8.8.tardist ...
[Software Manager launches]
[[email protected]:~]# clean
Are you sure you want to remove /tmp/nekopkg-workdir [y/n]? y
Removing /tmp/nekopkg-workdir ...

It also has an 'update' operation, which should check for new versions of already installed packages & download them. I haven't had the chance of testing this yet, but it should work :)
EDIT: The update function now works.

Here's the script ( last updated 2011-02-07 ):
gzipped script file (version 0.9.3)
(2.77 KiB) Downloaded 142 times

Installation instructions:

Code: Select all

# gunzip
# chmod +x
# mv /usr/nekoware/bin/

Note 1: You may have to re-open the shell for it to accept without the full path.
Note 2: If you place the script somewhere else, make sure you change the NEKOPKG variable in it!

The script requires the neko_curl package (if you prefer, you can use neko_wget by editing the script).
Run without arguments to see usage information.

I have used it to install packages on my new Origin and that's pretty much all the testing I've done -- treat this as a beta release and please report any bugs here.

Now I'm off to bed, good night...
Sure, go ahead. :)

I haven't done tcsh scripting in a long time as well, so there's probably a better way of doing some of the things in the script (however, it runs reasonably fast, so this shouldn't be a problem).

If you need any help with the nastier parts, feel free to send me a PM or post here :)
Fixed the 'update' function today, the updated script is available in the first post of this thread.
Neat. Thanks for sharing the pictures!
This happens during the 'update' operation, correct?

I've found that the first error you mentioned appears when there are two packages with the same name but different versions installed on the system. The simplest workaround would be to delete the older package if you don't need it :)

I haven't been able to replicate the second error yet. It is probably related to the one above.

Thanks for reporting the bugs! When I have the time, I'll add some extra error checking and modify the code that generates the list of installed packages to ignore duplicates.
Extra error checking added, updated version of the script is available in the original post .

Please try it again -- the "if: Expression syntax" error should be fixed and the "file_deps_ver" case should report a more detailed error this time instead of breaking.

I've also added a new command 'list', which lists all available packages.
Some other minor quirks have also been dealt with.

Bug reports and other suggestions are welcome. :)
jan-jaap wrote: Nothing that mundane ;)

I believe there's an IOC3 on it, the IO chip from the IO6 of an O2k. The keyboard/mouse/network ports aren't wired. Is that wasteful? You betcha ... But at least they didn't need to write a new driver.

But it does have a 16550 UART chip as well: :?

mapesdhs wrote:

Code: Select all

- TL16PIR552PH F-41A5RDW

The datasheet for this one says it has dual 16550 UARTs + parallel port.

Perhaps the IOC3 chip is just a bridge.
I can give it a try on my 16CPU Origin tomorrow (hope the rainy weather continues :) ).

Also, on MIPS (and other properly designed architectures), 64-bit apps actually run *slower* than 32-bit ones, so compile for 64-bit only if your app uses more than 2GB of memory.
The "" consistently uses only one CPU, the time used for that test is about 82 seconds (on a 16P 400MHz O3k, compiled with the defaults [and MIPSpro 7.4.4]: "-DEFAULT:abi=n32:isa=mips4:proc=r12k" and the "-O2" from the Makefile).

The other command uses about 10-12 CPUs and is still running :)

When it finishes, I will try to get the first test to run on all CPUs (will probably require setting the number of threads to 64 or somesuch).
joerg wrote:
ShadeOfBlue wrote: I can give it a try on my 16CPU Origin tomorrow (hope the rainy weather continues :) )...

You have a watercooled origin? :P


These things are like little furnaces, the room heats up by 4°C in an hour. Excellent to have in winter, not so much when it's 35°C outside :)

Anyhow, the weather is favorable, I shall power it up and open the balcony, expect results soon :)
The long test took 1935 seconds and used 11 CPUs in average.

I re-did the short test with 32 threads: 9.3 seconds, ~9 CPUs.
The program dumps core at 40+ threads :?
Trace/BPT/RangeErr/DivZero/Ovflow trap (core dumped)
Martin Steen wrote:
It looks like IRIX does not start all CPUs when a thread is running to short.

You could try forcing each thread to its own CPU with pthread_setrunon_np() .
hamei wrote:
But isn't the operating system's scheduler normally better at this than letting every program arbitrarily decide what resources it wants to use ?

Normally yes and it does that here too, but it takes the scheduler too long to figure it out (since this program's threads process work in short bursts), so providing it with a hint could possibly improve the performance.

I usually use OpenMP for threading in such programs and it starts using all available CPUs almost instantly. It's also much simpler than writing your own code to do the threading, but then again, I'm just lazy :)
legalize wrote:
How far back does OpenMP support go in IRIX?

It had OpenMP from at least MIPSpro 7.2 onwards, with support for OMP 2.0 added in 7.4, but even before that, SGI's compilers had special #pragma's for parallelization and the OpenMP spec was partially based on those, IIRC :)
Have you tried using a timebase corrector?
I finally got some hobby time this afternoon and wrote a small program which displays the temperature, uptime and self-test status of SCSI drives. It can also issue self-tests.

I've tested it on only one drive, so it may not work everywhere -- let me know if something breaks :)

Example usage:

Code: Select all

> sudo ./scsimon /dev/scsi/sc0d1l0
Inquiry response:       [SEAGATE ST336752LC      0004]
Current temperature:    55C/131F
Maximum temperature:    65C/149F
Drive uptime (total):   524 minutes (= 0d 8h 44m)
Next internal test in:  120 minutes
Self-test data (newest first):
0: at: 8h      type: bg extended       result: completed OK
1: at: 6h      type: bg extended       result: completed OK
2: at: 5h      type: bg short          result: completed OK
3: at: 5h      type: bg short          result: aborted (SEND DIAG.)
4: at: 0h      type: bg short          result: completed OK
5: at: 0h      type: bg short          result: completed OK

gzipped mips3 binary
(8.74 KiB) Downloaded 75 times

  • Unpack the program: "gunzip scsimon.gz"
  • Make it executable: "chmod +x scsimon"
  • Place it anywhere you like

You must run this program as root.

Compiled with MIPSpro 7.4.4m: "cc -O2 -mips3 -o scsimon scsimon.c"

Source code (IRIX only):
source code
(10.32 KiB) Downloaded 69 times

Current version: 1.2

Enjoy :)
Thanks for testing it :)

I see my 2nd generation 15k drive runs much hotter than the newer-gen ones.

As for the missing self-test data, it was either cleared or the drive was never instructed to perform a self-test. There is a command which tells it to do that, I'll see if I can implement it.

Seagate drives also store the number of hours they've been powered up (in total), the next version of the program will be able to read that as well :)
Update : the new version also displays drive uptime and can trigger self-tests (use the -t option, e.g. "-t short" for a short self-test, you can also use the short notation "-ts" instead)
It can be downloaded from the original post.

Only background self tests ("short" and "extended") plus "abort" are supported.

The temperature readings are currently sourced from the drive's temperature log page, but it appears not all drives have that. There's a second "Informational Exceptions" log page, which also has temperature data, but the program doesn't look at that right now :)
I'll get to it tomorrow.