The collected works of dexter1 - Page 6

I've attached a patch file for xcircuit 3.4.3. It replaces pressmode declarations from Boolean to int
xcircuit-3.4.3.patch
(2.75 KiB) Downloaded 12 times
:Crimson: :PI: :Indigo: :O2: :Indy: :Indigo2: :Indigo2IMP: :O200: :O2000: :Onyx2:
Gentlemen, gentlemen, please remain ontopic. I know, it isn't easy with all the images in this thread :)

If you want to delve deeper into this subject matter let me know and i'll split the thread.
:Crimson: :PI: :Indigo: :O2: :Indy: :Indigo2: :Indigo2IMP: :O200: :O2000: :Onyx2:
uunix wrote: FORTRAN = Phillips G700 Programming Cartridge 37 9 ?

Oh, you mean this piece of trash? :
Image

I'm afraid it included only BASIC and Z80 machine code, no Fortran alas. Plus you had to be a buddhist Monk for the oodles of patience it required to program anything.

Ontopic, it looks like a serious nice job. I taught myself Z80 and 8086 machine code back in 1982, and got Fortran77 in University together with Pascal. Only old farts with grey hair can apply!!
:Crimson: :PI: :Indigo: :O2: :Indy: :Indigo2: :Indigo2IMP: :O200: :O2000: :Onyx2:
Because of the recent development posts in Maxwell, I have split the topic. Maxwell development is now in viewtopic.php?f=15&t=16730190
:Crimson: :PI: :Indigo: :O2: :Indy: :Indigo2: :Indigo2IMP: :O200: :O2000: :Onyx2:
Few comment again, since i don't have opportunity to send a xcircuit window on the o200 from work to home:

- I realized the .Xdefaults file is actually for the Xw version of xcircuit, but nobody uses that since the xcircuit developer mentioned code problems with Xw, i.e. it is shite.
- With Phase Change you mean the library display/non-display? I've reread the entire post and i think you mean the ibrary display bug being the cause of 3.6.41 not working correctly.

If you now have two versions side-by-side, one without the bug and the other with the bug, do a version diff. That way you can easily check differences. Most likely code changes in canvas refresh or mouse event handling might be the culprit.
:Crimson: :PI: :Indigo: :O2: :Indy: :Indigo2: :Indigo2IMP: :O200: :O2000: :Onyx2:
hamei wrote: We've kinda wandered off-topic :P


We have indeed.

Since i'm the OP, i would like to reiterate that discussions about 'x is better than y' are not helping the cause of developing software for IRIX. Yes we need some discernible difference between similar packages, but we need code that is doing the job, which also means that sometimes it is a good idea NOT to port specific code to IRIX, simply because the OS surrounding the program or even the machine itself is not up for today's infrastructure.

Let alone the fact that the hardware is unmaintained and abandoned by SGI, so running mission critical with IRIX machines is basically not a smart thing.
Fortunately, Ian and Doug and enthusiasts and others are still out there and help keeping stuff running. Kudos to them.

To get back on track. I've toyed with the idea for making a list of compile errors and how to deal with them. From the recent xcircuit discussion, i've realized that many problems in porting software comes from not reading or not interpreting the compilers error messages correctly. Getting a handle on compiler errors is vital in porting code that is correct and does what it is supposed to do.

Also and this is much more concerning: People's code skills are not what it used to be ten years ago. I've noticed this on new people joining the University. It is what it is.

Let's continue with getting stuff going. Keep testing and keep reporting. The Maxwell and xcircuit threads are proof that we can do it.
:Crimson: :PI: :Indigo: :O2: :Indy: :Indigo2: :Indigo2IMP: :O200: :O2000: :Onyx2:
Found it (I think) but i need people to test this, since it's late and i have to bike home in the rain.

I've looked at all the data in Hamei's post and the introduction of "suspend" in 3.6.41 struck a nerve a few days ago, because i remembered i got several warnings during compile of the more recent 3.8.78.

I also couldn't build 3.6.4x since it cannot find the function/command "unsetenv" at runtime. Strange, since it did work last week. I have more issues with the 3.6 branch since it wants to include /usr/lib and pollute my linker with o32 libraries :(

Anyway because of the grumpy behavior of my o200 today, i list some "suspend" compiler warnings here:

Code: Select all

cc-1183 c99: WARNING File = events.c, Line = 516
An unsigned integer is being compared to zero.

if (xobjs.suspend >= 0) return;

And many many more. This was from 3.6.41, but 3.8.78 is also littered with those. Interesting to see that exactly the introduction of the suspend field in 3.6.41 in the xobjs struct causes the "phase change".

So what type is xobjs.suspend ? Answer is in xcircuit.h somewhere at the end:

Code: Select all

u_short      new_changes;
char         suspend;        /* suspend graphics updates if TRUE */
short        numlibs;
short        pages;

A char. Erm is it signed or unsigned? After some googling i found in http://unix.derkeiler.com/Newsgroups/co ... /0424.html

Dr. David Kirkby wrote:
> Erik Max Francis wrote:
>
>>"Dr. David Kirkby" wrote:
>>
>>
>>>char foo;
>>>
>>>is asking for trouble, if you hope to put negative numbers in foo.
>>
>>Indeed. The Standard leaves it unspecified whether an unadorned char is
>>signed or unsigned.
>
>
> I've just confirmed that AIX and IRIX declare it unsigned, whereas
> Solaris, Linux, AIX, HP-UX, Tru64, NetBSD, OpenBSD all declare it
> signed. Although I've not had chance to fix the problem yet, I think
> that explains why my program for computing the properties of
> transmission lines
> http://atlc.sourceforge.net/
> works on Solaris, Linux, AIX, HP-UX, Tru64, NetBSD, OpenBSD, but not
> on AIX or IRIX.
>
> At least fixing it should not be too hard - just needs a bit of time.

I don't have an SGI system handy to check the proper flag but both the
MIPSPro C and GNU-C compilers on Irix have a flag to cause all chars not
explicitly declared as unsigned to be signed. I ran into the same
problem when I ported a package from Intel/Linux to Irix.


Wow, a compiler option to make char behave as being signed? Let's see what "man c99" has to say:

Code: Select all

-signed     Causes values of type char to be treated as if they had
type signed char (which can affect the result of integer
promotions), but the values of CHAR_MIN and CHAR_MAX are
not affected.  The default is to treat values of type char
as if they had type unsigned char.

Thus, does CFLAGS need '-signed' as extra option? Is it that simple?
So if i set that and recompile xcircuit 3.8.78, will i see the library again?



Affirmative. I also see the grid :)
:Crimson: :PI: :Indigo: :O2: :Indy: :Indigo2: :Indigo2IMP: :O200: :O2000: :Onyx2:
Locking thread
:Crimson: :PI: :Indigo: :O2: :Indy: :Indigo2: :Indigo2IMP: :O200: :O2000: :Onyx2:
Like your room, it's small though :o

Just thinking out loud, would it be easy to make pictures of furniture and create textures that way?
:Crimson: :PI: :Indigo: :O2: :Indy: :Indigo2: :Indigo2IMP: :O200: :O2000: :Onyx2:
Vishnu, can you specify where you got the source from? I have found two archives on the internet: a maxwellwp.tar.gz and a maxwell-0.5.3-src.tar.gz
Both archives require substantial reworking for dependency entries in directories, amongst other things. I'm curious if we can get this running without too much hacking. You've already spent a lot of work on it and i think you are close to a working program. I have read through the old Maxwell thread, a true enjoyment for a software hacker :)
:Crimson: :PI: :Indigo: :O2: :Indy: :Indigo2: :Indigo2IMP: :O200: :O2000: :Onyx2:
Thanks Vishnu for this question!

Since i was the person locking the thread, allow me to reply.

The thread about the Paris attacks was a moment for people to express their thoughts and feelings about the incident. I fully sympathize with the people stating their sadness and disgust about this act of violence.
Because threads like these have a lot of emotion expressed, there is always a danger that things derail into verbal fights, anger, Godwin's Law and proof of extraterrestrials. Keeping a close eye on the thread and issuing warnings is one of the instruments we moderators have. I hope that people posting on this forum understand the need for open, constructive discussion, common sense and keeping moderator activity to a minimum.

Unfortunately in the Paris thread i felt the need to intervene and diffuse the build-up of political laden posts. I locked the thread. If i was too terse by not stating any decision i apologise. I thought it was clear after the warning post i stated in that thread. Apparently it was not.

The issue is that there are not that many moderators and thus we rely on reports of other forum members. For me, moderation is something i do "on the side" since i am here because of my experience and appreciation of IRIX and SGI machines.
After i resurfaced in oktober i naturally discussed my moderator status with Nekonoko via PM and how the forum is the same/different from previous days. Moderator-wise it's relatively quiet, so it's not a full time job. Which means i can spend more time to hacking software for IRIX, excellent!
Which also means, a moderator forum would see few traffic.

Regarding your comment about the Paris attack being a world event: I don't want to sound condescending but since everybody has their own opinion about the definition of a world event, a discussion is largely moot. If it really is a world event, you most likely would be doing something else than browsing the forum. On the flipside, if all world events would be discussed here, we would have a daytime job weeding through posts. So we have to strike a balance, but we have to post it with common sense in mind.

There are other forums and means of communication about these matters. Please use them!

As a moderator i am always willing to discuss and explain forum matters via PM, with users and other moderators.
In the end Nekonoko has final say in these matters.

I hope i made things a little bit clearer. Please contact me if i missed something.
:Crimson: :PI: :Indigo: :O2: :Indy: :Indigo2: :Indigo2IMP: :O200: :O2000: :Onyx2:
You are missing a libstdc++ from tcgware's gcc build, see viewtopic.php?f=15&t=16727919#p7377642 in the first page of the thread.

It looks like this needs proper repackaging into nekoware. I'll look into it and see if i can get a decent build with MIPSPro and fix the endianness
I might want to try 0.168 but even on my linux systems a build takes hours and the resulting binary is more than 100 MB

EDIT: oh, it is already over 125 MB itself :o
:Crimson: :PI: :Indigo: :O2: :Indy: :Indigo2: :Indigo2IMP: :O200: :O2000: :Onyx2:
necron2600 wrote: Thanks for all your work on this!


Nonono, Axatax_ did all the hard work :) I was merely around to help you.

Mame is a bit of a pet-project after i initially discovered it in 1999. We had Xmame and Xmess back then. I helped building the nekoware port.
:Crimson: :PI: :Indigo: :O2: :Indy: :Indigo2: :Indigo2IMP: :O200: :O2000: :Onyx2:
Hi Icebalm, and congratulations on acquiring your new red friend!

It is possible to contribute to nekoware with the gcc compiler, although C++ programs made by one compiler cannot be mixed with C++-libraries made by the other, due to name mangling issues. but mixing with C-libraries should be okay. When developing software and building the packages, i recommend to mark the packages as neko_gcc_<package>-<version#>.tardist or neko_<package>_gcc_<version#>.tardist to distinguish them from the MIPSPro compiled packages.

There are quite a few people who contribute a lot to nekoware and otherware. Feel free to browse around, try out some software and get to know your Fuel better. If you encounter problems, post them here so we can try to fix them.
:Crimson: :PI: :Indigo: :O2: :Indy: :Indigo2: :Indigo2IMP: :O200: :O2000: :Onyx2:
ivelegacy wrote: been an angel all year
* * * so hurry down * * *
the chimney on 25 night


santagirl.png
santagirl.png (328 KiB) Viewed 258 times
:Crimson: :PI: :Indigo: :O2: :Indy: :Indigo2: :Indigo2IMP: :O200: :O2000: :Onyx2:
uunix wrote: I have a software library sealed, part number 013-2478-012 REV A


Wiki time! http://www.nekochan.net/wiki/User:Legal ... rt_Numbers
Actually not listed but Legalize states that the 013- numbers are used for box sets of IRIX releases.

On Ebay http://www.ebay.com/itm/like/2816753383 ... rmvSB=true we learn that it's IRIX 6.5.12 release. Makes sense since the last three digits are 012
:Crimson: :PI: :Indigo: :O2: :Indy: :Indigo2: :Indigo2IMP: :O200: :O2000: :Onyx2:
ivelegacy wrote: so if the worst comes to the worst: php a fractal of bad design , perhaps the worst ever.

A riveting read! Excellent breakdown of why people should not learn or code PHP. Back in 2003 friends already dissuaded me from programming that turd since they had "issues" with it, and even with Zend fixing stuff it's not really pleasant. (built PhP with threading and using it on a non-threaded apache? Goodbye to two days on debugging that flaw :( )

I deployed several applications on my webserver at work: PDF document server, Email frontend (Horde /Imp) and Calendars (WebCalendar), all PHP with modifications or homebrew.
Handed over to server department and other coworkers 5 years ago, and been running from their support pleads ever since.
:Crimson: :PI: :Indigo: :O2: :Indy: :Indigo2: :Indigo2IMP: :O200: :O2000: :Onyx2:
vishnu wrote: Wings3D is written in Erlang! 8-)

We have a thread for Wings3D and Erlang back in the days: viewtopic.php?f=11&t=1709
:Crimson: :PI: :Indigo: :O2: :Indy: :Indigo2: :Indigo2IMP: :O200: :O2000: :Onyx2:
Ok, let us know if we can help. Holiday season is upon us and we all have some free time available.
:Crimson: :PI: :Indigo: :O2: :Indy: :Indigo2: :Indigo2IMP: :O200: :O2000: :Onyx2:
Whoa, that does seem like a restructuring/slimming-down of the techpubs site.
How should we do this? It is no use for dozens of people to hammer the site, since we don't know for sure if the new page will host the old stuff.

I have a copy anno 2005 with IRIX 5.3/6.2/6.3/6.4/6.5. That is about 1 GB. Jan-Jaap, how big is the current techpubs IRIX stuff?
:Crimson: :PI: :Indigo: :O2: :Indy: :Indigo2: :Indigo2IMP: :O200: :O2000: :Onyx2:
Well done Icebalm. I hope somebody can test it with a gnome/gtk application. Any hints on what you are trying to build?
:Crimson: :PI: :Indigo: :O2: :Indy: :Indigo2: :Indigo2IMP: :O200: :O2000: :Onyx2:
Hm, i went ahead and did the techpubs download today. All categories, minus the windows/nt section. I did all the download using your old script with some minor modifications (added *.tgz) and addition of the linux stuff. So my total is:

Code: Select all

> du -sk techpubs.sgi.com/
2324068   techpubs.sgi.com/

That's quite a bit less than what i expected from your tally. Any chance that the duplicate files on your server can account for this? Or did you do a -m in wget?

EDIT: i am missing IRIX 5.3 , 6.2 and 6.3 in my download. That explains atleast partially the difference...

NOTE: i am going to redo it with added FAQ and relnotes. The manpages as you say are redundant since they are included in the OS distribution media anyway.
:Crimson: :PI: :Indigo: :O2: :Indy: :Indigo2: :Indigo2IMP: :O200: :O2000: :Onyx2:
I'm trying to get hold of MooglyGuy, he's somewhere on the MameWorld forum. I hope he has an archive of that site.

I do have a few PROM images back when i extracted bootlogo's and boottunes from the firmware.
Alternatively they can be dumped from the console with a console program which supports console logging, like minicom. But then we need to find a person with a working R4400@250MHz and a serial cable to do it.

My PROM image of the Indigo2 is alas a -005 from '93 and i have a '94 -006 sitting in a dormant, stripped Indigo2.
:Crimson: :PI: :Indigo: :O2: :Indy: :Indigo2: :Indigo2IMP: :O200: :O2000: :Onyx2:
This is from /usr/include/internal/stdarg_core.h, redirected form /usr/include/CC/cstdarg

Code: Select all

/* Define the va_list type: */
__SGI_LIBC_BEGIN_NAMESPACE_STD
#ifndef _VA_LIST_%)
#define _VA_LIST_
typedef char *va_list;
#endif /* !_VA_LIST_ */

__SGI_LIBC_END_NAMESPACE_STD
In other words, it is there, but it does need proper preprocessing. I'm using 7.4.4m and C-style headers are still not properly supported which necessitates me to use odd options in CXXFLAGS.
I do get somewhere in gemrb 0.8.3.1 : i reach 15% with an error in:

Code: Select all

cc-1132 CC: ERROR File = /usr/people/everdij/gemrb/gemrb-0.8.3.1/gemrb/core/Game.cpp, Line = 1886
The class "std::vector<GemRB::Injured, std::allocator<GemRB::Injured>>" has no
member "at".

restingSpell.caster->DirectlyCastSpell(wholeparty.at(spelltarget).character, restingSpell.resref, 0, 1, true);
which is strange since wholeparty is a std::vector<Injured> template and std::vector does have the .at() class function. So this needs weeding through code.

For peeps wondering what setenv i used:

Code: Select all

setenv CC cc
setenv CXX CC
setenv CFLAGS '-O2 -mips4 -woff 1174 -signed'
setenv CPPFLAGS '-I/usr/nekoware/include'
setenv LDFLAGS '-L/usr/nekoware/lib'
setenv LIBS '-lm'
setenv PERL /usr/nekoware/bin/perl
setenv SDLDIR /usr/nekoware
setenv CXXFLAGS '-O2 -mips4 -woff 1110,1171,1201,1355,1460,3201,3625,3649 -LANG:std=off -LANG:libc_in_namespace_std=off'
and two hacks in neko_cmake modules in /usr/nekoware/share/cmake-2.6/Modules

Code: Select all

--- FindSDL.cmake.save  Mon Dec 14 22:39:37 2015
+++ FindSDL.cmake       Mon Dec 14 22:40:36 2015
@@ -59,6 +59,7 @@
PATHS
~/Library/Frameworks
/Library/Frameworks
+  /usr/nekoware/include/SDL
/usr/local/include/SDL
/usr/include/SDL
/usr/local/include/SDL12

--- FindThreads.cmake.save      Mon Dec 14 22:28:57 2015
+++ FindThreads.cmake   Mon Dec 14 22:29:17 2015
@@ -11,9 +11,9 @@
SET(Threads_FOUND FALSE)

# Do we have sproc?
-IF(CMAKE_SYSTEM MATCHES IRIX)
-  CHECK_INCLUDE_FILES("sys/types.h;sys/prctl.h"  CMAKE_HAVE_SPROC_H)
-ENDIF(CMAKE_SYSTEM MATCHES IRIX)
+#IF(CMAKE_SYSTEM MATCHES IRIX)
+#  CHECK_INCLUDE_FILES("sys/types.h;sys/prctl.h"  CMAKE_HAVE_SPROC_H)
+#ENDIF(CMAKE_SYSTEM MATCHES IRIX)

IF(CMAKE_HAVE_SPROC_H)
# We have sproc
Since if it finds sproc, it ignores pthreads alltogether which in modern day code is certainly not what you want.

So it definitely needs some work, we're not there yet.
:Crimson: :PI: :Indigo: :O2: :Indy: :Indigo2: :Indigo2IMP: :O200: :O2000: :Onyx2:
Yeah indeed, Thanks for that tip! By adding (or moving) a C++ header above the C-headers (<cmath>,<cstring>) most undefined type-errors disappear. I found the same fix on an old thread.

This fix also enables me dropping the -LANG:libc_in_namespace_std option in CXXFLAGS since it broke std::vector::at() : it turns out that std::vector does have ::at() as per c++03 standard which MIPSPro supports. Yay.

However i got this:

Code: Select all

cc-1132 CC: ERROR File = /usr/people/everdij/gemrb/gemrb-0.8.3.1/gemrb/core/Interface.cpp, Line = 2384
The class "std::map<GemRB::ResRef, GemRB::Font *, std::less<GemRB::ResRef>,
std::allocator<GemRB::Font *>>" has no member "at".

return fonts.at(ResRef);
^

I initially thought this was the same error as the one previously, but unfortunately the error is about missing ::at() in std::map. Even worse, this is added in the c++11 standard :( MIPSPro CC compiler version 7.4.4m doesn't support c++11 so that's end of the line.

But before i start crying and drag this code through gcc 4.6 or 4.7, it is however easily fixed in MIPSPro, due to the nature of that specific function:

Code: Select all

Font* Interface::GetFont(const ResRef& ResRef) const
{
if (fonts.find(ResRef) != fonts.end()) {
return fonts.at(ResRef);
}
return NULL;
}

by doing this:

Code: Select all

Font* Interface::GetFont(const ResRef& ResRef) const
{
std::map<GemRB::ResRef,Font *>::const_iterator i = fonts.find(ResRef);
if (i != fonts.end()) {
return i->second;
}
return NULL;
}

Basically i used a map::const_iterator for the fonts class, so i can find the font pointer via the iterator instead of ::at()
There are other solutions on the internet by overloading the ::at() function for std::map and build a small function using one loop, ::find() and an exception handler.

Well, let's hope i do not encounter more c++11 specific language syntax...
:Crimson: :PI: :Indigo: :O2: :Indy: :Indigo2: :Indigo2IMP: :O200: :O2000: :Onyx2:
Hello Dieu,

It looks like Kdevelop is based on qt libraries from the same major version number. If i recall correctly we have qt3 and qt4 libraries built on Nekoware and maybe someone else has a qt package of similar version number.
If you have a development environment installed on your Tezro you can build it yourself.

Do provide more info on exactly what machine you are running and what software you have installed. And your post implies you have tried to build a KDevelop version. So can you tell us what version you tried and what problems you had?
:Crimson: :PI: :Indigo: :O2: :Indy: :Indigo2: :Indigo2IMP: :O200: :O2000: :Onyx2:
dieu wrote: I installed from nekoware qt 4.3, kdevelop, kde* packages and required libraries. So far, i keep doing it but it seems non-stop.

Yup, welcome to dependency hell. Especially large platform backends like KDE comes with a ton of extra library packages which you need to install together with the KDE packages. You picked one of the packages with a very large amount of package dependencies. Just be patient and sit tight and get all required packages downloaded and installed.

I have Tezro IRIX 6.5 with MIPS compiler but don't know what you mean by 'development environment'.

The MIPSPro compiler together with base libraries like libc stdlibc++, include files and assembler and linker is the development environment.

Note: I got kdevelop 3.3.1 tardist from nekoware's obsolete->archive folder (only one). Is version of KDE has to be the same ?
...
Is all versions of KDE packages must be the same ? (such as kdedevelop, kdelibs, kdebases, ...)

This is tricky to answer. The packages on which the base software product (in our case kdevelop) depends upon are listed in the nekoware download page following the package md5sum string. However, there may be several versions of a specific package. Usually you want to get the package of most recent date and highest software release number (number following the package name. For neko_kdevelop-3.3.1.tardist the package name is kdevelop and the release number is 1.
Dependencies are resolved in the software package by that release number, not by the major.minor version number of the package source. It is quite conceivable that kdevelop can run with both kdelibs 3.2.2 and with kdelibs 3.5.1 but the dependency information in kdevelop package will have to decide if it accepts kdelibs 3.2.2 (release number 1) or kdelibs 3.5.1 (release number 2).

Also, i wonder can I compile the source code which is contained inside the tardist ?

The source code tarball in the tardist is the source from which the software in that package is built. We included this for preservation, because many packages come from individual sources on private websites and if the site disappears or the maintainer pulls the source, you couldn't rebuild the package without having a copy in the tardist.
:Crimson: :PI: :Indigo: :O2: :Indy: :Indigo2: :Indigo2IMP: :O200: :O2000: :Onyx2:
Wow, that's a neat project, small enough that it can be worked on in short intervals and first results should be quick.
What i've seen from the viewkit apps i really like, it is simple and looks cool. So i really like the idea of building it with Viewkit.

Your first choices is for what platforms you want to build and run this application. If you want to include Indy's and Indigo2's and Impact Octanes, you need to take into account the fact that these machines don't have hardware texture support. Other than that, as long as you stay within openGL 1.1 boundaries, you're fine. I learned a lot of openGL machine specifics from xscreensaver code and rss-glx, so it is possible to if/else your code to account for specific platforms.

OpenGL and the good old glDrawPixels should be fine, although looking recently into the Indy hardware documentation, they mention that sending one glDrawPixel is very costly DMA-wise since the R4K processor needs to flush the cache for each DMA operation. This is of course not very interesting for the Octane since its hardware can do this much more efficiently, but when writing openGL information on a very atomic scale, it may be faster to write it in blocks or even directly into the framebuffer.

Large images should be okay, though you may break the 2GB barrier, so be prepared to go 64 bit.

Start with an app you can hack around with. Is there a Viewkit demo app which displays images?
:Crimson: :PI: :Indigo: :O2: :Indy: :Indigo2: :Indigo2IMP: :O200: :O2000: :Onyx2:
Merry Christmas and a code-fruitful 2016 to all of you. May it bring more apps and more developers.
:Crimson: :PI: :Indigo: :O2: :Indy: :Indigo2: :Indigo2IMP: :O200: :O2000: :Onyx2:
Good work DaJuice! i like the way you did the joints, smoothing out the inner section.
:Crimson: :PI: :Indigo: :O2: :Indy: :Indigo2: :Indigo2IMP: :O200: :O2000: :Onyx2:
Welcome Seclorum to the hideout of SGI enthusiasts :)

Congratulations on your free Indy! By the looks of it, it has an R5K 150 or 180 MHz processor with secondary cache. About as fast as it can get on this workstation. Indy memory maxes out at 256 MByte. The old disks are probably noisy, so i recommend them to exchange with newer disks. It's not for the higher throughput, since that is limited at 10 Mbyte/sec because of the SCSI bus.
Your graphics is 8 bit XL which is the entry spec.

The indy has cool stuff for its time. A Indycam is very welcome, even if its image quality is low for today's standard. It has analog video input and decent 4 channel audio capabilities.

Try to get some IRIX OS media like irix 6.2 or 6.5. the last IRIX supporting the indy is 6.5.22m.

Browse around and look at what people made for these machines. We still develop applications or port stuff from the Linux world onto our IRIX boxes. You will love the O2's too btw.
:Crimson: :PI: :Indigo: :O2: :Indy: :Indigo2: :Indigo2IMP: :O200: :O2000: :Onyx2:
Only Neko can move stuff from /incoming to /beta and /incoming is not browseable, but if you specify what name it can be found in that folder, we can retrieve it.

PS: I agree with MAME and MESS increasingly becoming a movable target. They have integrated MESS into MAME since 0162, which massively bloats compile time. and i only checked certain old roms like Galaga for compatibility with the latest mame 0168.
You can build subtargets with MAME. You only need to make a driver list and a .lua script for specifying all necessary drivers in your subtarget: cpus, audio, video, machines and buses, and that's a bit of an art. I did manage to succeed in isolating all necessary files, but only after building it for at least a dozen times. :)

There is a lot of development stuff going on right now, especially in the SGI section. MooglyGuy (aka Ryan) is now trying to put in skeleton drivers for old SGI hardware, together with the PROM dumps.
MAME 0169 now has the Indigo R3000 as skeleton driver!
:Crimson: :PI: :Indigo: :O2: :Indy: :Indigo2: :Indigo2IMP: :O200: :O2000: :Onyx2:
Oh, i was OP for this post. Wow, a 12 year necromancy thread :)

I did have some nice Mead from Hakimoto and we celebrated the birth of 2016 with families in Nijmegen, The Netherlands.
Unfortunately the old emoticons have made way for a newer set :)

And with respect to the value of our machines: The market has become smaller, but being one of the bastions of SGI i'm sure there is enough interest in retaining what machines we still have and wanting the machines we don't have.
:Crimson: :PI: :Indigo: :O2: :Indy: :Indigo2: :Indigo2IMP: :O200: :O2000: :Onyx2:
MrBill wrote: I'm not sure of the capability of this machine. As seen on the picture, ive got it connected to that large 50 inch plasma monitor. I see it has a audio jack, i was unaware the machine had audio capability. Would it be possible to watch video's with sound with this machine? Perhaps Ill keep it connected to that monitor full time and use it for displaying video streams from the security cameras.

Have a look at viewtopic.php?f=5&t=2956&p=22247

Over there you'll find some info and experience from when i got my Crimson and people replying to it. The audio on the IO3B panel is connected to a Philips SAA1099 sound chip. You'll find the chip close to the letters "Sillicon Graphics" on the board.
There is almost no info about this, but it is in theory possible to get sound out of it. Forget stereo CD quality though.

For displaying video streams there were video option boards which let you parse analog video to the framebuffer, but these options are very rare. O2's and Indy can do that more comfortably and that without taking the electrical grid down.

In retrospect these machines were most famous for their graphics and if you want to occasionally use them nowadays, let them display irixGL and openGL eye-candy.

I've learned a lot of software tricks from my Indigo2, but hardware wise the Crimson remains the most interesting and challenging.
:Crimson: :PI: :Indigo: :O2: :Indy: :Indigo2: :Indigo2IMP: :O200: :O2000: :Onyx2:
MrBill wrote: There is a Y2k issue? A webserver is completely out the window?

There is, yes. The Crimson cannot correctly keep the date after 31st of december 1999 between boots. There is a workaround for that in viewtopic.php?f=10&t=1298

Once applied and booted the Crimson can happily serves files and webcontent and behave normally, even between boots.
:Crimson: :PI: :Indigo: :O2: :Indy: :Indigo2: :Indigo2IMP: :O200: :O2000: :Onyx2:
Why do you think neko_kdevelop 3.3.1 requires Qt 4.5.8?
I just looked into the package and it states:


So neko_qt with a version number of at least 2 will suffice the dependency, which in nekoware/current is neko_qt-3.3.1.tardist

It is possible the kdevelop programs actually depends on qt-4.5.8, but this is considered a packaging error and you should contact the package creator.
:Crimson: :PI: :Indigo: :O2: :Indy: :Indigo2: :Indigo2IMP: :O200: :O2000: :Onyx2:
1.3 Xbow revision is fine for V6 and V8, as stated on Ian's page. But it looks like JackLuminous correctly pointed out that in the install manual it is stated that 2 CPU's are required. So unless someone has a much more clever idea, your best bet is to get a cheap dual R10k@195MHz module and give it a go.
:Crimson: :PI: :Indigo: :O2: :Indy: :Indigo2: :Indigo2IMP: :O200: :O2000: :Onyx2:
I am totally not into football, but if i look at the many scathing AstonVilla meme images on google i suppose winning a game is a good thing, ya? :P
:Crimson: :PI: :Indigo: :O2: :Indy: :Indigo2: :Indigo2IMP: :O200: :O2000: :Onyx2:
That looks exactly like my Onyx2! Unfortunately i misplaced the hinv somewhere, so i'm not sure what i have.
Also i have an Origin2000 sitting on wood since i donated the wheelbase to the Onyx2, but includes a shoehorn for the CADDuo card and an SE with modified bracket.
I do have skins for the O2000, but it's like glass: every part has broken corners and snapped latches and i don't think i will ever put it on again.

As for power usage, it depends on what spec you have. Can't find any info online so it's best to check with a watt meter
:Crimson: :PI: :Indigo: :O2: :Indy: :Indigo2: :Indigo2IMP: :O200: :O2000: :Onyx2:
First, for future forum posts: please edit your last post instead of making new posts correcting typo's and adding information.

Only install neko_qt.3.3.5 since that has qt version 2 and will be picked up by neko_kdevelop

libqt-mt.so is installed by default in /usr/nekoware/qt/lib both for neko_qt-3.3.1 and neko_qt-3.3.5 so please check that. If it is there but not picked up by kdevelop, you might want to add that path to your LD_LIBRARY_PATH environment variable.
:Crimson: :PI: :Indigo: :O2: :Indy: :Indigo2: :Indigo2IMP: :O200: :O2000: :Onyx2: