The collected works of dexter1 - Page 8

Please refrain from posting or uploading ROM's or disk images on the forum. Also do not link to ROM collections, torrents and warez sites. If you do not abide by these rules, your post will be moderated.

Hi marmotta,

I have diskperf data from an Indy here: viewtopic.php?p=1578

When you scroll down you can see i record data transfer up to about 8.5 MB/sec which is close to the 10MB/sec transfer speed limit of the SCSI bus on the Indy.
Can you post the diskperf data from that fujitsu drive on the Indy? Also the type and model of that disk would be handy.

It might be that your drive needs to be jumpered for Single Ended mode. Also the disklabel has options you can set which affect speed like write buffering and native command queueing, although for simple data reads and writes the latter is not so important.

jmc wrote: How are these supported in Irix, i.E. what software can these be used with? Seen them 15 years ago at Max Planck Institute for molecular biology, but how about Maya, etc.?

They can be accessed as additional X input devices. The application needs extra code to read the device status and act accordingly. There is a bit of info in http://techpubs.sgi.com/library/tpl/cgi ... =7%20input

in eoe.sw.optinput there are drivers and additional example programs to help you test and adapt existing code.
It would be neat to have a list of applications supporting dial+buttons or the spacemouse, but i don't know of any, beside of old molecular viewer programs late 90's

I suppose you have read viewtopic.php?t=217

Before you start looking for that particular jumper: please be careful with pulling out the mainboard, you will risk zapping it if it is still on mains. What i always do is turn it off, then unplug the cable and wait for at least half an hour before you do anything. This way you let the Power Supply capacitors lose their charge.

If the jumper is not set and the machine still powers on when on mains try to enter the console, either with monitor and keyboard or a serial connection and reset the firmware environment with 'resetenv'

I changed the wiki to reflect this. Let me know if it needs more work.

seclorum wrote: Okay, so .. I'm a bit confused. Should I follow the wiki info, or .. not .. if not .. why not? Coz it would probably be wise to update the wiki .. and I'm willing to test the changes if you can point out to me what is correct/incorrect.

Yesterday i changed the Wiki, so it now shows the correct pinout as Pentium suggested.

That is most unfortunate.

The biggest problem is whether the PSU is at fault or the logic board, since if the system is dead how can you tell if it is one or the other? The PSU apparently gives the correct voltages apart from the yellow wires but other than hooking up to a scope and comparing it with a known good working PSU, it's hard to figure out if the PSU is flaky in itself.

What's the story on the logic board? Any dark traces or burnt components?
And did you do any modifications to the PSU, like replacing the fan?

The easiest approach is to source a known working O2 and start swapping components. I would first make sure that the logic board isn't at fault by inserting it into a working machine.

Strange, when installing new hardware the system usually triggers an automatic configuration of the unix kernel, and will switch to that kernel after reboot. It seems that the system did reconfigure the kernel, but did not switch the kernel, which you had to force manually.

I've looked it up in http://techpubs.sgi.com/library/tpl/cgi ... /ch10.html :
Apparently an /etc/autoconfig -f will kick the system into making a new kernel which suits your current hardware configuration.

Congratulations on your purple box! Looks like an Internal CDROM, those trays were rare.

Sorry for not replying sooner, necron2600. I had another look last week and the problems at 82% was in GUIScript.cpp which basically boils down to include header hell. The solution is to compile the offending code with the -E option and sift through the output. That took a bit of time...

I did some more work on the code today and i patched it up to the point that gemrb and its plugins compile. The SDL plugin gets stuck with gettimeofday() so i have to revisit the #include <sys/time.h> fix i did for that.

Here is the patch file for gemrb-0.8.3.1
It's probably my ugliest patch file i have ever made sofar. Feel free to mock it

I'll get around to building something useful in the coming days. I'm still not sure if there are endian issues. Also no idea how to test this. Pointers are welcome.

Oh, that sounds like a good deal, since the SCSI-IDE adapters are uncommon and are being sold for prices well over 50 euro. Well, i admit, it was a few years ago when i last bought one.

The only downside to that adapter is that its SCSI connector is a 68-pin and according to Jan-Jaap, the Fuel has a 50-pin specially for the DVD-ROM connection. If the AEC-7722 can be forced to do narrow SCSI and if you can get a 68 to 50 pin converter, you can hook it up and check if it's working.
The AEC-7722 manual does state that the adapter doesn't perform SCSI to IDE conversion for control commands, so some functions like DVD-burning (if the drive is capable of that) probably doesn't work.

Hi Fu,

I've rejoined last oktober and i haven't experienced your described behavior, but then my email hasn't changed. I'll send you a test PM to make sure that that is working.

With verify bits you mean identifying the hardware and testing its individual components?

First do a hinv -vm so you can write down the individual part numbers and revisions of the components.
Then you can do a general hardware test, by booting into the PROM and selecting Diagnostics. You need a recent IRIX installation CD overlay containing the diagnostic tools.

There probably is more info on Ian's site regarding specific tests, especially graphics hardware.

What is exactly on that disk you boot from? Did you try that boot disk on the Entry R4K as well? Did it boot there?

I would suggest to get a transceiver and start over from scratch. 'resetenv' in the PROM and get a IRIX 6.2 or 6.5 installation underway.

In this article (dutch) it is mentioned that the Tavolga company aims this products at government facilities and industries who for security reasons do not want to rely on american or asian hardware products.

The use is probably limited to desktop/client systems, though nothing is stopping them from making a server version. Not sure if the processor has to be redesigned for 64 bits for that, since you need Physical Address Extension for accesing memory beyond 4GB.

And hey, it runs Debian

Necro thread, i apologize.

I have a R5K180 Indy and was wondering if one can transplant from a Nidec power supply the PCB with volume control LED and power/reset button into an otherwise working Sony PSU. I believe the PCB is connected solely to the Indy MB by means of the black connector. I do not have a Nidec at hand, but i'm not sure the PCB has the same mount and utility holes on it and will fit in the Sony with enough clearance.

Otherwise i have to find a two color LED and some time to solder it in without my kids interfering and bugging me about "that little blue computer, which makes cool sounds!"

Good read, brings back old openGL stuff when i was doing ffmpeg optimization with SGIX_PIXELTEX stuff

Since IRIX 6.5.22 is end of the line for all R4K systems and the Indy R5K and Indigo2 R8K/R10K and the Onyx1 and Challenge S/M/L/XL, most people tend to go for that release, and since as mentioned it is easily found, most people have it.

Like josehill mentioned, there are only a few special cases when one would go for 6.5.21: Off the top of my head it's keyboard and mouse support for the O200 linked to a Gigachannel with a SI/SE GFX card, which makes it a working graphics system, be it a noisy one.

According to a post on the mamedev website , the MAME (and MESS) open source license are now OSI-compliant and FSF-approved which makes it officially free and opensource software.

We can create, modify and distribute MAME/MESS binaries as long as the GPL-2.0+ license and source are being provided.


Wokka Wokka!

The posts are still focused on MIPS desktops, but if one would compare these against other (ARM) architectures, i would suggest making a new topic discussing this.

EDIT: topic split from viewtopic.php?f=8&t=16730474

And don't worry fu

I love indy's, but since one of my Indy's mainboard bit the dust last september 2015 i have come to the conclusion that it's time to finish the indy emulation in MESS.

Over the past few months i've researched if the SGI Indy emulation in MESS is usable and if there is a real possibility of getting this driver into a complete working state.
This means that the machine should be capable of running IRIX in some form or flavor straight from a disk image or installed via CDROM up to running the desktop.
The CPU emulated should of course match a real CPU-option inside an indy.

Indy emulation started to appear in MESS0144u5 by virtue of a coding spree by a user called Arbee and Ryan Holtz (Mooglyguy) in april 2005, as stated here http://rbelmont.mameworld.info/?m=200504
They have published emulation code for the wd33c93 and newport XL graphics as well as the central Indy MC controller and HPC3 peripheral controller.
Because the Indigo2 shares many common features with the Indy, they are now sharing the same driver in MESS.

From MESS0145 to MESS0147 the indy and indigo2 emulation is functional up to and including booting the PROM, displaying graphical output and responding to keyboard input. You can go into prom, print 'hinv' and 'printenv'.

The working emulated systems are:
ip224613 : Indy R4600PC 133MHz, 128MB Memory, 24 bit newport, B6 PROM sept 28 1994
ip225015 : Indy R5000PC 150MHz, 128MB Memory, 24 bit newport, B10 PROM feb 12 1996
ip244415 : Indigo2 R4400PC 150Mhz, 128MB memory, 24 bit newport, B PROM sept 16 1993

ip204415 is a non-working emulation of the R4400PC 150MHz indigo. The console outputs:


There also is no emulation driver for the Indigo1 Entry LG1/LG2 hardware yet.


This is the cool testing stuff so far...

Some notes i've collected:

- MESS swapped the designation for the roms and the Indy/Indigo2 systems: it uses ip22xxyy for the Indy and ip24xxyy for the Indigo2, but the systems true ip hardware/software designations are ip24/ip22 for the Indy and ip22/ip22 for the Indigo2.
- PROM cannot accurately determine the clockspeed and displays 16 MHz for all CPUs.
- All CPU's are being emulated without L2 or Secondary Cache. In MESS the MIPS3 emulation does not seem to have code to support the secondary cache controller for the R4000/R4400 cores. The actual QED R4600/R5000 MIPS designs do support secondary cache but lack hardware control on the die, so this is externally provided via ASICs on the CPU-board for the SC models. AFAIK documentation for these ASICs have not been released, so they cannot be emulated.
- With MESS0148 keyboard input was lost, so interaction with the PROM was not possible. This regression continues up to at least MESS0168. I have not tested MESS0171 yet, but the sgi.cpp and indy_indigo2.cpp code shows no significant changes.

What needs to be done is the following:
- Get w33c93 SCSI DMA back on track so that we can boot with CDROM images again. We probably need to include code for linked lists in w33c93 driver
- Get VDMA on the MC coded. There is a code example in vdma.ps to get people started.
- Add Semaphore registers on the MC
- Keyboard emulation needs to be better
- Check Newport driver state. It should be nearly finished, but maybe there are commands missing.
- Also check if the Newport driver can emulate an XL8 instead of an XL24
- Check Dallas EEPROM save and restore. It should be possible to handle EEPROM settings from a file
- Fix proper initialisation of the MC registers. currently upon power-cycle every register is initialized to zero, but it has a defined state, see mc.ps
- Check/Fix PROM settings for the CPU, it can be read by the MC so it should be correct.
- Need some form of HAL2 device support, otherwise we have no sound on the emulated Indy/Indigo2
- VINO and the INDYCAM ae not supported. VINO is documented, but you need a PC/machine with video in signal, and the INDYCAM interface has no documentation.
- Need CHD images from an Indy with R4600PC or R5000PC XL24 IRIX 5.3 6.2 or 6.5 installation. Should not be too difficult to make, if you have the exact hardware/PROM/GFX combination.
- Also need CHD image of an Indigo2 R4400 XL IRIX 5.3 6.2 or 6.5 installation. Should be doable but Indigo2 XL cards are uncommon.

Well, i'll start with VDMA. I'll let you know in what millennium i will finish

Sources:
https://www.linux-mips.org/wiki/Indy
http://www.progettosnaps.net/mess/repository/
/usr/include/sys from a recent IRIX 6.5 install.

Well, it is always good to buy or get your hands on an SGI, full stop.

But seriously, the question is what do you expect from such a system with respect to learning code or modelling? The C language with SDL should be fine to get you started, but modelling depends on what you want and if the hardware and software supports it.

Other good languages to learn on an SGI IRIX system are Python (there is a python3 port) and Fortran. But for C++ we increasingly depend on GNU since the MIPSPro compilers do not support newer language features, like C++11. In that respect, Linux wil more likely be your first choice, since it supports many modern languages.

If you get an Indigo2 like Foetz suggested, get a fairly decent system with at least an R10K and Solid impact GFX. That doesn't have texture support, but should be good for programming and modelling. But if you want to run Debian and Gentoo i am not sure if there is graphic driver support for Impact systems, and getting an old XL24 to get Debian and Gentoo running with X kind of defeats the point of having such a system...

With all due respect, before this turns into a "Linux versus IRIX" debate let me comment on the release of a Linux SQL server by Microsoft.

I think this is a great but also necessary move by Microsoft to gain a foot into the server software market. It strengthens their position in the database sector, but also boosts Linux as server OS choice. Microsoft realizes that they cannot gain any more by selling an OS, so they turn to data information as their biggest asset. And give for free a windows OS which goes many ways of filling that huge data information hunger. Needless to say that i will stick with the Windows 7 systems i currently use.

Uunix is right in that the Linux flavors are confusing and the wrong choice can impact people working environment and businesses. Here at the University of Technology the choice for the Linux installation OS was taken at the top level management in 2008 and they chose ... SuSE Linux Enterprise Desktop. It turned out that they can basically buy off support by signing a contract, thus making maintenance something you can outsource, which is the support management way of getting a successful business model, but a less than satisfactory experience by users, to put it mildly.
Which is why locally maintained Ubuntu/Debian systems are now very popular at the university, because people actually use that on their private laptop systems, and because the SLED image is still at version 11 with the old KDE desktop and not even a decent python 2.7 installation. Clearly a decision which has stalled Linux acceptance at the University for years.

As for SGI and IRIX: the 90's were glorious in getting Origin rack systems to bust High Performance Computing records, and were decent webservers but database wise they weren't big. I am still proud of having run HPC stuff on the TERAS in Amsterdam early 2000 and actually visit that huge beast.

At least look at it on the bright side: Of all the systems in the top 500 HPC clusters, 488 run Linux, 10 run Unix, one mixed OS and one windows SGI has supplied 29 systems and is 4th in the list of hardware providers. They still do something reasonably well...

fu wrote: out for a drink guys, first round’s on me

Chilled cherry beer for me! What's your poison?

Very cool pictures, at least someone is getting sunshine on this planet.

Shiny Fluke bag! With matching colors and all that. My multimeter is a 112, still going strong after all these years. What's yours?

I was expecting a reply from Jirka or Tomvos, since they have first hand experience with the board inside an indy. From their posts i believe/remember that you have to make sure you get the latest firmware and set up the board with id 1 and parity enabled.

I will be getting my SCSI2SD board in the coming days, set up a wiki to document settings and going to test it with other SGI systems. Most older desktops come with the WD33C93 SCSI controller, so what works for the Indy should be fairly generic for Indigo2's and R3K Indigo's.

NOTE: O2's and Octanes have SCA connectors internally: It would be cool to have a SCA to 50pin converter which can be assembled in-line with a SCSI2SD board, mounted on an enclosure which you could fabricate to fit into a regular SCA bracket for the O2 or Octane. If anyone has ideas where to find such a converter we can have a go at this.

Alternatively, the O2 has an external HD68 SCSI connector. If that connector supports termination power, you can possibly run the SCSI2SD board on it. Will look butt-ugly, but then, so do i

Dual core Pentium? How old is that system anyway?

Anyway, used Slackware in the '90's, a brief foray into Redhat on an Alpha, installed openSuSE 9.1 once and since 2005 i only use Ubuntu at work and home, save for the few CentOS machines i see occasionally. It's based on Debian and its huge repository of software with added support for proprietary hardware. Laptops love Ubuntu because of that.

If you like a desktop with openGL compositor, use vanilla Ubuntu. If you're more into a spartan lightweight desktop with XFCE, try Xubuntu. There are some popular flavors of Ubuntu for GNOME lovers, like "Linux Mint".

Email? Thunderbird
Office? LibreOffice
Graphics: Gimp (a la Photoshop), Inkscape (vectors), imageMagick (doing odd stuff), qiv (fast displaying, scaling)
Video? ermmm i used OpenShot for very simple editing, but there are more professional solutions.
IDE? Codeblocks for simple stuff, although a basic editor with support for syntax highlighting like gedit works just fine for me.

And the fun with Linux distro's: U NO LIKE? Nuke it and get something else...

Hi jesse,

From your answers i infer that IRIX 6.2 and IRIX 6.5 up to 6.5.22 supports your machine. But is it possible to give us the result of hinv -v from telnet? Alternatively, you can interrupt the boot proces with <esc> and go the the command line monitor (option 5). There you can also enter hinv -v
Oh, and please enter you location. Your name sounds Dutch and it would be nice to see where you live.

I second Robespierre and Trippynet comments. SGI's and Indy's in particular are reliable machines with great software and have many useful input and output ports. It's just that the peripherals can be a bit of a challenge, like proper serial cabling, keyboards/mice, CD players and last but not least, monitors. A good multisync, multifrequency monitor with the proper 13W3->HD15 cabling can make all the difference.

If however, after all endeavours, you decide to let it go, please post it in the hardware for sale section and mention your location. Maybe there is a fellow SGI enthusiast who is willing to offer you a good deal.

The SCSI disk with id 2 seems to be faulty. Not sure which position is disk id 2 in the Indigo2, but my first guess is the top drive.
Also during boot, it looks for additional scsi disks with ids 1 and 2 on the second scsi controller, which usually attach to the back SCSI connector, so these are missing. At least the root drive seems to be working, and boots IRIX. Congratulations

Resetting password on an IRIX system is a FAQ, and is covered in:
http://www.nekochan.net/wiki/Root_password_removal
http://software.majix.org/irix/admin-password.shtml
http://www.oocities.org/siliconvalley/h ... ssword.htm

If you don't own a second SGI machine, and don't have IRIX media and a CDROM, it is possible to download an image of IRIX install media and try netbooting that image on a Linux machine. IRIX media are found at archive.org
For setting up a Linux system for netbooting IRIX machine, this is a bit of a hassle, but this page describes it:
http://www.ifora.org/sgi/

There is also DINA http://www.nekochan.net/wiki/Using_DINA ... on_of_IRIX

Please keep the conversation on-topic. For off-tangent discussions we have the "Everything Else" forum...

Keyframe wrote: Anyways, thanks for help. I can be proud to say there's an Octane2 with 2xR14Ks @ 600Mhz with V12 and VBOB and 36GB Cheetah now fully operational and working. Sadly, only 2GB of RAM.

That truly is an amazing freebie! Have fun with it, i'm sure you will. Obtaining memory shouldn't be a big problem.

Next, I'll see if I can restore and make operational a purple Indigo2 and find out what graphics it has. This might be a bit of a larger challenge.

If it's a purple Indigo2 chances are good the graphic chipset is from the impact family. Detecting which impact card you have is easy by inspecting the backside:



Whether the high and max impact cards have texture ram can only be inferred by visual inspection.
For pre-impact cards like XZ and Extreme the output ports are the same, so it's best to open up the machine and check.

Note: I don't know if you have opened your Indigo2 before but be careful when opening it! Not knowing the procedure can damage the case.

Does anyone have a decent image of this XL24 Indigo2 graphics board, front and back?

I'm tempted to source one of these for putting it inside an old Indigo2 and installing IRIX 6.2 on that system. With this i can help the MESS emulator developers, since it's the only Indigo2 graphics card we have full documentation of, provided (and i believe it is) it is a Newport gfx implementation on a GIO64 bus, which should be identical both soft- and hardware wise to the Indy 24-bit Newport, with all the REX3/RB2/RO1/VC2/XMAP9 ASIC's

jan-jaap wrote: That's the "single board" graphics card, right?

Correct.

I have one of those, but it's in the attic and there's a desk blocking the path to it ... But if nobody comes up with a photo I'll go digging.

I'm sure there is a geek with a camera somewhere who is willing to spare your back and make a nice snapshot. Let's give it a few days...

EDIT: found some pictures on http://www.ebay.com.my/itm/Lot-of-10-Si ... 1552471738

I have never seen such a good deal as this one: 26 USD for a lot of 10 (which now sell at 100+ each) is...like...amazing? I'm surprised that no-one made an offer...

I don't have details to the 1992 match, but i have found an article which deals with the 1994 rematch on
http://web.archive.org/web/200608290857 ... inook.html

From that article i extracted:

The supercomputer itself stands unobtrusively off to the left of the stage. It belongs to a high-performance line of Silicon Graphics machines prophetically named the "Challenge." It weighs 1200 pounds, and is about the size of a large refrigerator. The box's black exterior offers few clues as to what it contains (16 processors and the cooling apparatus required to keep them from overheating); the only hints are the words " Silicon Graphics Challenge XL " on the front of the unit and, beneath those words, a small liquid-crystal display panel. The Chinook program that the machine is running (or might it be more helpful to think of the program as running the machine?) consists of roughly 50,000 lines of code in the C programming language, together with an enormous data-base of codified checkers-knowledge that has been years in the making.

Note: From the article (it's rather big) i inferred that the Challenge was a new machine for the 1994 match. So by reasoning they must have had a pre-challenge system in 1992, but the only quote i could find was:

Schaeffer also arranged to run Chinook on a new Silicon Graphics multi-processor computer.

So which SGI MP machine was new in 1992? The only multiprocessor systems in SGI at the time were Powerseries, so either a Diehard 4D/440 or a Predator 4D/380 or 480 comes to mind...

Edit: found it, it was a 4D/480. There is a thesis about the chinook program here: http://citeseerx.ist.psu.edu/viewdoc/do ... 1&type=pdf

uunix wrote: I used isoToUSB on a windows machine to create the 14.1 version.

I prefer unetbootin , which only failed once for Ubuntu 15.10, but that was actually canonical's fault. Give that a spin if you're getting nowhere.

Hakimoto and me listening to Dimmu Borgir's "Gateways" . Sweet production skills on that record!

Can you post the errors you get when installing with inst? Since i infer you don't have proper install CD's with the machine, we need to fix this.

EDIT: just crossed my mind that i have a spare Indigo2 R10000 machine with Solid Impact but without powersupply. You can swap the working powersupply into that machine, which is located in Delft. Interested?

I managed to get irix 6.5.22 on an R5K Indy with the SCSI2SD board. It's not particularly snappy, and that first boot is agonizing, but i have good hopes the system will be more usable tonight.

and i may have found a solution to the "SYNC negotiation error".

This is from /var/sysgen/master.d/wd93 :
By setting the first hex from 0xfe to 0xfc it should disable sync negotiation for id 1 on scsi bus 0 (which is the internal bus). Then autoconfig and reboot.

I'll try this out tonight and let you know...

Update: i have disabled sync-enable for my indy with SCSI2SD and there are no more SCSI errors after a reboot. Result!

Love Google translate.

Anyway, the Indy R5000 180 MHz modules may work at 200 MHz, but there could be stability issues. A documented attempt is performed before by changing the clock oscillator: viewtopic.php?t=16720133 . There are more threads toying with this idea.