The collected works of dexter1 - Page 7

There is nothing arch specific about generic IRIX MIPS-binaries , but it is possible that some binaries depend on specific hardware components, like an EISA bus on the R10K Indigo2 (IP28) or VPro graphics on the Octane (IP30) or the VICE multimedia chip in the O2 (IP32).

What i forgot to say is that there can also be some implicit target platform optimization performed by MIPSPro compilers. Like:


i haven't come across incompatibilities between machines using these specific options, as the man page states.

But even if the CPU is the same between platforms, there are differences in properties like cache misses: on the Indigo2 and O2 an R10000 support only one cache miss, but the Octane and Origin support up to 4 (Info from Ian's site).

In necron2600's hinv the part code for the power supply is listed:


So that is definitely a Cherokee. It's still possible that the Power supply has a fault and doesn't reach its max output.

If the characters in the qt assistant do not display correctly, then it is most likely a font library problem:
My linker information from qt/bin/assistant is:

Can you post yours? This way one can quickly see if the problem lies in a different library version.
Can you start the assistant program remotely on your system and displaying the output on a different system? Are the characters displaying correctly?
What IRIX version are you running btw?

1) Reading up on emulator design from http://www.codeslinger.co.uk/
2) Making a patch set to GemRB latest version with MIPSPro compiler. I'm at 82% done now.
3) Thinking what to do with an MFM RLL disk i found in an old shipping box at work.

Well some stuff aren't quite pointless, but hugely entertaining.

nyef wrote: Planning on writing an emulator, or just interested in how they work?

Mainly interested in the different techniques of emulating CPU's, although my main motivation for reading up is to help make emulating SGI machines a reality. Fortunately, MIPS emulation is relatively straightforward and several emulators already have been written. The hard part is the ASIC's surrounding the core, but that's not different from many other systems.

Aside from the endianness the program requires openGL 1.5 which i am unsure if the VPro Octane/Fuel will support. Older hardware will not be supported by the program because of texture support (I believe Impact+TRAM will only support up to 1.2).
You can fall back to software rendering, but i guess that's a bit pointless on IRIX machines.

It does not have any substantial build environment, just a bare Makefile in source. Which is actually a good thing, so chances you can get it to compile with neko_gcc. Probably a few modifications in os.cpp are necessary to choose the proper defines.
The code is mainly targeted at Linux and Windows machines, so it will require some work.

Devil Master wrote: I've already asked them about this conflicting information, and so far they haven't answered. Where did you find the reference to OpenGL 1.5?

When i ran the Demo program on my laptop, it displayed a few rendering options before the Demo starts. DirectX9, OpenGL, software rendering, stuff like that. OpenGL 1.5 was one of the options. That is why i assumed it ran only on systems supporting openGL 1.5 and up.

And thanks for clarifying openGL version support for Impact, it's been a while since i sat behind my Indigo2 Impact machine.

gijoe77 wrote: Octane MXE had an issue (I'm wondering if this is a shared issue with mplayer as posted in that thread).

Does the MXE by any chance have Texture Ram? I cannot tell from the hinv on the screenshots. It would explain the inability of using texture with MAME and MPlayer

Start with getting the development environment set up. I'm not sure you have built on IRIX before. If not, well, first time for everything You need development foundation and development libraries, and gcc-4.7 from nekoware. If you have MIPSPro 7.4.x try that as well, although getting C++ code built with it these days is a real pain.

Get build tools like gmake to facilitate the build environment. Use nekoware tar or similar which can unpack a compressed tar ball. Sometimes you need to try out several different versions, which is why it's good to have a tar which supports gzip and bzip2.

Then simply start configuring and making.
Make notes of environment variables: put them in a script. Many configure script look for environment flags like CC CFLAGS LDFLAGS AR and more of that. Set them with 'setenv CFLAGS "-O2 -mips4"'

Capture gmake output to a file with 'gmake >& log &' and inspect the log file if the make fails.
If compile fails because of a problem in the code, inspect the offending code, make a copy of the code with a fixed extension like '.save' and try to make improvements and recompile. By doing it this way, you can build a patch file later by making diff's from the files which have a .save extenion.

I know, it's more of a general guideline, but i hope it helps.

Make that Mips sweat!

Working from a supported configuration is your best bet. I usually take old sun configurations because of the endianness: old SPARC processors are bigendian, like MIPS.

There is a c99 compiler with MIPSPro, just 'setenv CC c99' and you're good. Don't forget setting CFLAGS: 'setenv CFLAGS -signed' for instance worked for getting xcircuit to run correctly.

Let us know what problems you encounter.

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 would like to ask if it is a good idea and if there is enough interest to make a separate subforum about emulators.

This subforum should cover running emulators on SGI machines like MAME/MESS, Vice(C64), Stella(VCS2600), UAE(Amiga).
Also development progress of emulators which can emulate MIPS processors and SGI machines like GXEmul, VMIPS, Simos, MESS and Miep should be discussed.

My motivation for this request:
- Recently Axatax made great progress in mame and openGL development, making it a very viable way of playing games on IRIX machines.
- MESS versions 0145 till 0147 has workable Indy support and while not everything is implemented, it's getting close. I'd like to generate momentum to finish this driver, since there is no true emulator around for any of the SGI machines. The Indy is hardwarewise sufficiently documented to make the emulation a success.

Yay's and Nay's are welcome...

ClassicHasClass wrote: I have no objection, I just wonder about the level of interest.

Which is exactly the reason i'm asking this. I don't know. But i rather have a separate subforum dealing with this subject matter than to either post in SGI:Development about MAME on IRIX and then going to Miscellaneous:Other for SGI emulators like MESS

I do have contact with MAME developer Mooglyguy which is now collecting SGI roms to be put into MESS staging by adding skeleton drivers, so my guess is that more roms and skeleton drivers will follow in the coming months. Therefore i have a hunch we will attract other people interested in SGI emulation.

ivelegacy wrote: don't expect to emulate Octane, Fuel, Tezro, etc
the best we can do is within: { Indy/R5K, O2/R5K }

That is not entirely true. GXEmul claims partial O2-R10K emulation, but currently without Crime chipset and AIC7880 SCSI support, since there are no specs.
With Indy+newport emulation also comes R4K Indigo2 emulation with EISA support and XL24 framebuffer. GR3/GU1 cards and Impact subsystem are unsupported, as are R10K CPU's on Indigo2 systems.

Attempts of emulating Octanes, Fuels and other IP35 derivatives is IMO not going to be very fruitful in the foreseeable future since the CPU emulation needs some sort of Binary Translation to attain sufficient processing speed. Dynamic Recompilation will probably not be able to keep up.

Well, by using the Duck test, i agree with Guardian452 about the Raspberry Pi being a PC, since it has all the usual qualities assorted with a PC.
It is of course possible to deploy a RPi by other means, like a remote Wifi spot, or a network device or even a USB to serial device. But then, a PC can similarly be deployed. It just needs more current

On topic, i still use PC's since i develop and test scientific software on a regular basis. Although a lot of HPC jobs can be performed on a cluster, its high speed, large memory capacity and big+fast storage options is still essential in doing my work. I do like laptops to work everywhere i please, but they tend to be less comfortable as a PC. Moreover i tend to not go for expensive models since they are subject to a dangerous environment, i.e. kids with glasses of lemonade and the occasional impact test from a table.

I was referring to the list of Ivelegacy which in his spirit mentioning the SGI workstations capable of running R14K/R16K cpu's. I did not intend to mention emulation of single CPU Octanes, that was simply not my point.

Emulating an Octane includes emulating the graphics subsystem, sound and IO. Since in the current state there is no documentation for either the Impact or VPro graphics subsystem (let alone the heart ASIC), attempts will be limited to console/terminal state for now.

ivelegacy wrote: who cares, chap ? do you know how much effort is required in order to support R10K decently ?

Well, chap, i do know, and i haven't claimed anything in terms of usability of the emulation. I clearly stated "not entirely", so please mind the subleties and nuances, they are there for a reason.

After a scurrying through my old cable box i didn't find any 3W3 cables, but only only came across 13W3-6BNC's, 13W3-DB25 and 5BNC-HD15
If it is not possible to go directly to 3W3-HD15, maybe pick up the IBM cable and get 3 female-female BNC adapters so you can wire 3W3-3BNC-HD15?

guardian452 wrote: ... I would be very happy if there was some sort of virtual SGI that I could use and ran Irix, even an older version like 6.2.

Exactly, that would be awesome: to test software or try out different emulated hardware, but it would also act as a sort of preservation of the technology, since our SGI machines have a finite lifespan. i became weary of reviving old SGI's after one of my Indy's blew a capacitor last september, simply by turning it on.

Even if it ran at Indy R4000PC speeds We can always throw more modern horsepower at it. If target performance around an r4400sc indy with xz graphics on an i5 were possible it would be very neat and maybe even useful.

I'll come back on indy emulation speeds and problems/solutions later in a different post, but your target platform choice is pretty close to some emulators. For now, let me suffice in stating that newport gfx (XL8/24) in combination with an R4600PC@133Mhz would very likely be the first configuration to achieve proper emulation. And reports from MESS developers have stated that by removing debug statements they could achieve full speed on R4600PC CPU emulation.

Since I guess the host would be linux or osx I can see why this discussion is not suitable for irix development forums

Indeed, hence my question for creating a subforum. I'll poke Neko if he thinks it's a good idea.

This sounds very different from running e.g. MAME on an SGI (the other way around). Why is that discussion not suitable for the irix development forums?

Oh it most certainly is suitable. I was just wondering if MAME users and developers are satisfied with the current threads on that forum: If axatax needs help or if there are many requests for adding machines to a particular MAME version, which is happening now, we might need to think about a separate section for them.

Thanks for reporting back the solution.

In reply to your question, yes you can use binaries from lower MIPS architecture set than the mips4 architecture your R14K in the Tezro supports. Binaries with mips3 should be fine. For programs with even lower architecture sets like mips1 and mips2 it is possible that different/older libraries are required for running the program.

Check out the LG2 "Song And Dance" Graphics card on display on top of the Crimson. So neat!

Excellent work, Mike! I will pass the info to our forum-lisp-devotee Hakimoto, he will be most pleased.

I tried to google specific SGI CDROM's and google returns a link to the archive.org entry. So posting links to these entries at archive.org doesn't seem to be a problem, and shouldn't get you into trouble.
You can actually download CDROM images, although i'm not completely sure these images works, i.e. contains all the files and information.

Among them is an IRIX 6.5.6 installation and overlay, 7.3 compiler execution environment, various 3rd party software, various hotmix CD's, 1600SW drivers, basically the works.
Needless to say, i am a bit surprised

Good to see you again Rev.Bubba!
What kind of packaging requirements are there for creating such a system? Will the vanilla tardist system for IRIX be sufficient, or does Ansible have its own way of packaging/distributing software?

As for booting systems via secondary interfaces, that might be an obstacle. Maybe someone else can chime in and provide details about whether this is possible.

viewtopic.php?f=14&t=2480&p=17966&hilit=IP27#p17966 at least list the part numbers for the O2000 nodeboards with R10K@195MHz.

Ditto with Jan-Jaap. I have never seen 195MHz R10k O200's

Okay, reading the backupcentral article in full made me think about your endeavour. So here is me thinking out loud:

First things first, For all Bare Metal install or recovery of IRIX, you either need graphical/keyboard access or serial console. ARCS access via the network is not possible, unless you get some kind of automated basic IRIX install + ssh going and then log on. This might be done via a diskless boot, but then you have to edit nvram variables and run a bootp/tftpd server which guest access, which is inherently insecure unless you can restrict the traffic to a specific subnet or a single machine you can trust.

Also, the Bare Metal section only lists the procedure of doing system install or recovery, which is basically not really different from installing a system via CDROM/tape or remote directory. The only real difference described there is how exactly a recovery works when you have performed a system backup. This is actually neat info, since i must admit in all my years as IRIX admin have never done that myself.

The division of network interfaces is a good idea, so you can do the base install and recovery on default interfaces like ec0/ef0, and when the system is all set switch to a FC or Phobos ethernet interface doing the real stuff. This way you separate installation infrastructure from the live stuff.

I was going to type some more, but i have visitors. TTYL and i will split the post later...

You are indeed correct in the RoboInst server and client software allowing the automated deployment of many IRIX machines over a network, but if i read the techpubs manual on it, it is not true Bare Metal because the RoboInst server needs to contact a client already running IRIX to accept a new sash in the volume header of the root disk and prepare miniroot environment to start installation when the client reboots.

If the client isn't running IRIX or the hard disk has been erased, you have to go Bare Metal by going to the (graphical) console and start the fx partitioning and IRIX installation accross the network 'by hand'.

The neat thing about RoboInst is the support of upgrading IRIX 5.3 clients to 6.5 (if they can handle the new OS and if the disk is big enough). It's just something i had never really considered because the number of SGI workstations in our department didn't exceed twenty, and all Indy's running 5.3 had crappy 1GB Seagate ST51080N Medalist which were too small for IRIX 6.5 and died if you pointed at them.

That most certainly looks like a Calorie-bomb! And you can see that dog thinking "Meh, all those veggies..."

Nekonoko has closed the Paypal Donation action for now, since he gathered sufficient funds to maintain the site. If needed in the future he will accept donations again. Stay tuned.

I wasn't expecting a mips2 binary. How about elfdump?

Rev.Bubba wrote: Is there not any way to handle all the fx partitioning and even a full install via the console port? If so that would be the way to go.

When we install an Origin or Challenge system it's all we have

But of course the trick is to do this from a script. The fx utility has a -s options which accept a text file as a script. This is basically the way RoboInst automates fx by putting the fx script as a subset of the inst miniroot script commands, if i interpret http://techpubs.sgi.com/library/tpl/cgi ... ame=1%20fx correctly.

The rest of inst can be automated in a similar way. The two remaining challenges is to 1) cold reset the machine and 2) direct the firmware to hold off booting from harddisk and stop at the menu.
2) can be achieved with setting either AutoLoad=no in the PROM (or setting bootmode=m on old systems).

As for 1) most older workstations just cold reset when you powercycle by either pressing the button or pull and reconnect the plug.
Origin and some Onyx2 systems have a serial console and separate L1 or MSC port, or sometimes a combined L1 console. With the L1 or MSC you can cold reset the machine. See http://techpubs.sgi.com/library/dynaweb ... /ch05.html for a SGI solution of remotely managing consoles and L1's which they named "SGIConsole"

Fuels and Tezro's should have something similar.

Most of this is from reading docs, so please don't take my word as gospel, since i only have experience with Origin 200's.

Can you give us a hinv -vm please?

ivelegacy wrote:

serafina wrote: I've got some Phobos G160 Fast Ethernet cards for Indigo2 still sealed in their original packages.

do you still have G160 ?

Carlo,the thread you're replying to is 4 years old and Serafina hasn't been online for 3.5 years. I suggest trying to email or PM him. If there is no reply, you can always try "Hardware Wanted..." section to find an alternative source for G160 cards.

MrWeedster wrote: There was a page describing how to build one ( http://rshockley.dyndns.org/indigo.htm ), but its dead.

Does anybody have a backup of the above site?

I have a backup, but unfortunately it is incomplete since i am missing the keyboard.hex and mouse.hex file.
Here it is:

He was paid per hour, since all he typed was "39.37" (=100/2.54) over and over again lrn2macro, sheesh.
Any chance this is not copyrighted to put it on the dailywtf?

That is sweet: Since this now looks complete, it begs to be put in the Wiki! Adding on my todo list...

Oh that explains, physicists (and beta scientists in general) are such a bunch of cowboys when it comes to hacking code...

Second glance at that code makes me think that nrmm2sub_ is a fortran routine since all arguments are pointers. Figures, since if it's mititary stuff chances are good that it is so ancient it could have been coded on a VAX or something similar.

Third glance made me realize i'm getting older

https://googleonlinesecurity.blogspot.n ... stack.html

This looks like a very serious problem. They say that it is difficult, but possible to remotely exploit machines with this vulnerability. Ouch. Haven't come across a security problem like this in recent years.

Just make sure you update your linux systems today. if there is no libc update, check tomorrow.

vishnu wrote: Slackware doesn't use systemd...

My first Linux system in '93 </misty-eyed>