The collected works of dexter1 - Page 9

Then my most likely assessment is that the logic board ate your PSU (again). I feel your pain, but i think it is time to track down a new logic board, since jumpering it to force it to power-on even when your PSU is repaired is suspect in itself.

I don't have a release date on Solid Impact, but found a hint in this old thread

Not sure you patched your system, but patch 1099 and 1157 seem to be required, especially 1099 which is adding support for software texture mapping on the Solid Impact.

In order to make a CHD file from an IRIX installation, it is necessary to hook up the IRIX root drive to a Linux machine and copy the raw data with dd from the drive to a file. Then invoke chdman. The MESS 0145 syntax is:


in our case that should be:


Where CHS are the numbers for the actual disk geometry and 512 is the sector size.

Actually you beat me to it i tried to make an IRIX 6.2 and 6.5.22 CHD of an Indy R5K with XL24 with the SCSI2SD emulator. it uses an SD card to emulate a harddisk, which obsoletes the use of an actual SCSI card inside a modern PC. Obtaining the IRIX disk image is simply a matter of dd'ing the SD card contents to a file.

Inspirational and very recognisable:
I almost went the same road when i was offered an Onyx1 Terminator Rack to pick up from an old data center and install in my Condo. When i decided to actually have it, i called the company, only to find out that they had scrapped the entire machine just two weeks before by cutting it up into pieces ... completely ...

Pontus wrote: Are the files on the ftp recordings? I assume the file is in a ROM somewhere in the computers. Has anyone ventured into that territory?

The sounds from the Indigo2 R10000, O2 and Octane are most likely recordings, because they switched to a generating algoritm for the tunes in the later workstations and hence you can't find the raw PCM recording in the PROM, because it used too much space.

Previously the boot sounds were recorded in 32kbit ADPCM like in the Indy/Indigo2 and Indigo1 and PI and you can extract them bit by bit in a PROM image. I have managed to do that a long time ago and i have an archive on my home machine.

Also look at http://www.nekochan.net/weblog/archives ... logos.html and http://www.nekochan.net/weblog/archives ... oot-l.html

EDIT: Found it in my archives: I extracted the boot and shutdown and GFX fail tunes from the Indy, Indigo2 and Octane, and i recorded the PI boot tune from the Magnum-card audio output.

I also found a snippet from Doug Cook which i cannot find online, so i reproduce it here:

Van:Doug Cook ( [email protected] ) Search Result 3
Onderwerp:Re: How to get the Boot Tune...

Discussies:comp.sys.sgi.misc View: Complete Thread (9 articles)
Datum:1995/05/26 Original Format


In article <[email protected]>, [email protected] writes:
> NNTP-Posting-Host: arvak.ifi.uio.no
> In-reply-to: [email protected] 's message of 26 May 1995 06:36:22 GMT
>
> In article <[email protected]> [email protected] (Doug Cook) writes:
> > Don't bother with the microphone -- your Indy has a digital output,
> > which I believe is fired up even for the boot tune. You can record
> > straight to DAT or onto another Indy and get the audio signal
> > bit-for-bit, then convert to any format your heart desires. I will warn
> > you, however, that the boot tune is ADPCM-compressed, so the sound
> > quality is not as good as it might otherwise be. PROM space is

> > expensive.
>
> Hah! I don't buy that. You stuffed that boot tune into it, didn't you?

All two seconds of it, at 32kHz, ADPCM-compressed. And when the PROM ran out of
space, the boot tune was the first thing to go; for example, the Power Indigo2
no longer has a sampled boot tune; it synthesizes one from scratch using
real-time physical modeling (albeit a very simple model).

-Doug



Doug Cook, [email protected] Silicon Graphics, Inc.

You seem to compile the code with the default optimization flag and not with any optimization or debug flag. Try to recreate the SIGSEGV by adding -g to CXXFLAGS.

I hardly believe the SIGSEGV is inside the Z80 emulator switch/case block, it must be something further up the chain stack.

diegel wrote: I also build a ff3.5 depending on tgcware instead of nekoware. It crashes in exactly the same way Dexter experienced many years ago. Since this problem occurs with gcc and mipspro and also with nekoware and tgcware, we can be quite sure this is not a problem of the compiler or any of the dependencies. The earliest ff3.1 beta releases also crashes in the same way,

Proper coding skills, Diegel! Are you referring to that Bus Error i got when runing Firefox 3.5 some years ago?

Back then i couldn't get my head around as to where the problem was. Good to see that it is not glib/gtk but most likely the actual ff3.5 C++ source. If i remember properly, it has something to do with a misaligned cast of a structure, which is usually the case when Bus Error's occur on IRIX/MIPSPro platforms. See the xcircuit thread for a recent example, and that one was relatively easy (int <-> bool)

I must warn you though, this one is particularly hard to debug.

jimmer wrote: Unfortunately, this bug is all Chinese to me...

MIPS N32 firefox's bus error problem and solution: https://www.youtube.com/watch?v=lnSojgPg5kc

This leads to: http://r0bertz.blogspot.nl/2009/04/mips-n32-firefox-in-acid3-test.html

Which leads to https://groups.google.com/forum/#!msg/loongson-dev/xgCC2ukKygU/FB1_ge3l_OMJ

Which leads to a patch http://code.openhub.net/file?fid=NjowB5niPqOXxkL0xlgWIH41MZY&cid=1d9defo44NY&s=

And that is not Chinese and actually very very interesting!!! Not sure we can use this for Firefox 3.x in IRIX, but now i understand the code a bit better.

You, sir Jimmer, got yourself a free beer!

Thanks Diegel. Since this is all from 2009 it makes sense that much of this has already been part of the ff3.x code.
I'll try to look into it when i have some more time.

skywriter wrote: When I think of my SkyWriter, I think "THIS is SGI, and THIS is the box I will go out in", when I have it converted into a coffin.

Well, you could make it your permanent residence if you're, let's say, immortal and have fangs. But then you'll be locked up by day and at night all you would see are Linux blinkenlights

It feels like we're back in '93!

Well, they can have my stack of Indy's for even half that listed price. Bring it on

Send Neko a PM, only he can do that.

Hi Leo, and welcome

If you abide by our forum rules, which is stated in red above i.e. no trade of pirated and/or commercial software offerings, you may post SGI and related parts for sale (or trade).

Let's look at the Readme:


So it clearly states that it is a superset of previous 5.3 Indigo2 Impact patches, but it can only be installed on IRIX 5.3 All Indigo2 Impact (1022585737) so check if you actually have that. You probably need to check eoe.sw.base for its version number.

Apart from this i can't tell you anything more, since i'm unable to test it (don't have an Indigo2 R4K Impact system)

This actually makes for a good conversation of relative value of SGI systems and the above mentioned O2 in particular and if dealing in SGI hardware remains a worthwhile business, but i don't think a "for sale" topic is suited for it.

Could you continue this discussion in a different topic, please?

Um, how is this even remotely possible that i have completely forgotten about this:

viewtopic.php?f=14&t=9659 lists a hinv for one of my systems:

I actually have two dual R10K195MHz nodeboards inside my old O2000

Are these the ones you're looking for, Doug? (Still need to test and see if they function at all...)

Edit: Wild thought: Maybe it's possible to bundle several node boards into one shipment. Let's PM about it.

Thanks for the update Noth, i'll inform Hakimoto that he now can get proper UAE/AMIX emulation on his Clevo Laptop with Ubuntu

The forum topic was removed upon Moderator request because it violated forum rules and guidelines. Locking thread.

uunix wrote:

fu wrote: you don’t really need aja tv (unless you are editing for 8h/day at least) but it should provide a live view of what’s cooking through the card.

Ahh.. bugger.. I was only planning on 7 hours a day, looks like I'll bin in then, it's no good to me.

A purple shirt! Say it loud and wear it proud...

PS: Who is Kjaer?

Thank you for contacting DVS and obtaining the software.
I've added some code tags to your post to make the listing scrollable and less bulky.

So did they confirm that sdio sdk2.7p28 is the latest (beta) release of the software?

fx is a tool for partitioning and formatting the disks, not a tool to start a miniroot stand alone shell and clear the password on your system.

Oh, i see that Majix is referring to fx for the reset password procedure via the debug method. It is easier to boot sash over the network and edit the passwd file.

If you have a bootp/tftp server set up, you can start the miniroot from the PROM menu by clicking on the second option "Install system software" (or press "2"). Then you need to enter the ip address of the bootp/tftp server and the location where the stand/sash.64 is located.

Once the miniroot environment is up, go to Admin and start a chroot environment. Then you can edit the password file /etc/passwd with vi.

I always use http://www.ifora.org/sgi/ but this might be a rehash of above information.

EDIT: Make sure you have set the netaddr environment variable correctly in the PROM.

Just saw this on Heise.de . The MOnSter 6502 project
The explanation by the maker: https://youtu.be/73h4cjTeX44
Very cool

Urgh, means i have to get my gear re-sorted for some nekoware development magic

Above all, some dedicated time to do this would be awesome. I have transferred many systems to my home address, I just need to choose the system and get the proper tools installed.

Could you give us some details on the installation: Did you install IRIX by means of a guide, and if so, which one? And did you use CD media or an install server?

The Fuel should not take a lot of time installing IRIX. Maybe the drive has issues. Perhaps perform a drive test with fx to rule that out.

Is there anything else the Fuel moans about? Fan/temperature problems?

uunix wrote:

FlasBurn wrote: But I use the 3 Overlay disks of 6.5.22,

Can someone Confirm that 6.5.22 is compatible?

I cannot recall the earliest IRIX version.

smj's system ran 6.5.18 when he purchased it, see viewtopic.php?f=14&t=16724549
Moreover, the wiki states that the Fuel is supported by IRIX versions 6.5.17 and up so it definitely should be possible to install it with 6.5.22 media.

Maybe start with doing an IDE? I'm not sure if anything useful can be observed from it, but it could reveal a hardware issue.

If you have 6.5.22 CDROM media you can start the Diagnostics by inserting the first overlay CD in the CDROM drive, then pressing <esc> when starting the Fuel and in the firmware screen, select "Run Diagnostics"

Did you try PM'ing PymbleSoftware? He is still active...

Plus the code is now version 3.07, so maybe a new version is possible

Nooo, you have one? Awesome! The system is in a dark grey tint and i happen to like that color variation very much, since i owe an Indigo2 dark grey front flap on my R8K frankenstation.

BTW, pics please

uunix wrote: What is this? http://www.ebay.co.uk/itm/SGI-550-Workstation-Arrows-F1-livery-fully-working-/122181014777?hash=item1c728e54f9:g:4h8AAOSwZJBX~-t1
Just a bit of cosmetic dust?

That, and an MLA+1600SW in stylish Orange will make the system twice as fast! Possibly more when you rub it in wax...

I'm waiting for a Dutchie to pick up this auction, because Orange, man...

lynx wrote: hey guys, gemrb dev here.

I've amended and merge about half of Dexter's patch and this is what remains:
http://sprunge.us/TPJi?diff

So four things:
1. The mentioned time hacks, which seem more like something to be changed in your libc?
2. Unfinished changes I don't fully understand, since I have no way of testing:
- why the token change?
- why are only some str(n)icmp calls problematic and why? We define them to be the same everywhere but on windows.
- what tripped you up in Holder.h?

It'd be great if someone took git HEAD for a spin and report any other problems. For a trivial test just run with -c gemrb/tests/minimal/test.cfg . There's also one that pops up a window and loads a game, but we apparently don't ship a config (set GameType=demo): demo/data .

Btw, the code should already be endian-safe.

Hello Lynx,

Thanks for coming here and looking into my patch. I'm currently installing and preparing my gemRB environment on a spare O2, since i have decided to rebuild part of our Nekoware distribution on my current workstations at home. My former gemRB dev machine, a O200 at work, is down for the moment so it will take me a bit of time to set everything up and start again.

I'll be back with some more info as soon as i have a compile in progress.

I hope this is not ruining your weekend, Jan-Jaap?

Thanks for the info. Currently my office does a pretty good job of murdering me and what's left of my spare time is dumped into holiday celebrations.
What Cmake did you use for the gemRB source?

Holy cow, That is some material to sift through!

I have my O2 installed with neko_python-2.7.3 neko_sdl-1.2.13 and a fresh cmake 2.8.12.2 prepped for compiling gemRB this evening, so i'll start producing some stuff this week.

I've started gemrb-0.8.4 compile on my O2 and found a solution for the Holder.h problem

lynx wrote: hey guys, gemrb dev here.
- what tripped you up in Holder.h?

Well, basically this:


TLDR:
cc-1367 CC ERROR "A pointer to an incomplete class type is not allowed."
Initially i didn't know how to proceed, so i commented the problematic functions out. But working on this error message proved fruitful after a couple of hours. The problem lies with the definition of Symbol in gemrb/core/Interface.h :


MIPSPro has its own way of instantiating templates. On occasions where people use forward declaration for classes and then trying to use them with templates produces compiler errors. This is because for template instantiation the class SymbolMgr is different from the class in the header file i.e. it won't see the class definition in the header file.

There are compiler options for remedying this, but why use forward declaration in the first place?
IIRC these are only needed for circular dependencies in class definitions. If it is not needed then don't use it.

I've re-enabled the headers by this diff:


and solved the compile problem.

lynx wrote: If you don't want to use git, use the tarball from this url, so you'll have the latest changes:
https://github.com/gemrb/gemrb/archive/master.zip

I've committed a modified version of your diff — it's safe only for the cases from the first ifdef. Thanks!

Thanks Lynx, i know git/mercurial so i've cloned the latest changeset. It does compile more cleanly with MIPSPro, although there are some IRIX mishaps which needs to be fixed manually.

Just giving you the heads up, i have solved all problems and compiled gemRB-0.8.4 with MIPSPro 7.4.4 on my O2 with 6.5.22m. Used vanilla tarball with my own patches, but i can give a diff of my patches to the git version. My first patch was way off especially the stricmp which proved to be a header booboo, so i hope the git version can be cleaned up if all those substitutions are committed.

There were some minor details with including Python c99-style headers and a nasty bug in /usr/include/unistd.h in combination with MIPSPro C++ compiler which makes compiling kind of a challenge. Nothing unsolvable, but i was stumped for a few days.

And oh yeah, attempted tp play Baldur's Gate II Demo windowed on that O2 (R5K@180MHz). It does work, but man that's slow.

I will wrap up the patch, show it here with a screenshot and something resembling a package.

Well done Foetz. Not having any spare time to play with my XP1000's but kudos for a rare piece of utility.

necron2600 wrote: Awesome Dexter!
I cant wait! hurry hurry!
I know this plays decently on a 400mhz UltraSPARC (Solaris) so Im hoping the same with a >400mhz SGI..

I've jumped the gun a bit of stating that i've solved all problems, sorry for that. There are many issues still needing to be resolved, but i do have played the game on my O2, and if it is not crashing, it works \o/


I've completed the nekoware package for gemrb version 0.8.4 and uploaded it to nekoware current. A direct link is ftp://ftp.nekochan.net/pub/downloads/Ne ... .4.tardist

It installs in /usr/nekoware and dependencies are moderate, but you'll need at least:
This is beta software because there are crashes and bugs. Beware!

Below are three files necessary for the compilation with MIPSPro 7.4.4m on a O2 with 6.5.22m. I've tried with gcc 4.7.1, but cmake complains about pthread headers, so i stuck with MIPSPro.
You need the latest cmake 2.8 version. I've made a cmake 2.8.12.2 myself in /usr/local and used that, since the neko_cmake versions are too old.

Release notes for the tardist :
patch to 0.8.4 source :
cmake cache file since it has a hard time finding python :
For compiling with git HEAD i've made a patch as well
gemrb-git.patch :

strlcpy :
This C string function is an extension to the standard library and appears on many (BSD-like) systems. IRIX header files only has it in /usr/include/internal/string_core.h, however MIPSPro C++ doesn't see it possibly due to header bugs or not including C headers in C++ mode.
So it's best to predefine the header in the source, which i did.

/usr/include/unistd.h is a C header and the timeval struct is there as a stub, because its proper definition is in /usr/include/sys/time.h
When MIPSPro C++ compiler includes both it breaks on the stub, i believe it was in GUIScript.cpp when this popped up. The way to go for now is to hack the system unistd.h:

This is probably needed for other code-projects.

The Demo Baldur's Gate zipfile doesn't work correctly, see the release notes. If someone has an idea, cfg file or hack, let us know in here.

I've included my config file :

I got Baldur's Gate 2 : Shadows of Ahn and Throne of Bhaal fom GoG source. You need to install it on a linux system with wine and copy over the entire directory to an IRIX system. Then fill in the path in the BG2.cfg file and start gemrb with:


Inventory in ToB of my char:


There are still several problems with the program on IRIX, see the release notes. Doing a debug session with CVD (IRIX visual debugger) reveals thread issues with SDL and SIGSEGV's in certain malloc calls and new calls. This needs more testing and researching, possibly valgrinding the engine to look for leaks.

Happy New Year!

Thanks necro for giving it a spin. What audio backend are you using?

In Linux there are some memory leaks when using SDL, I'm not sure if the segfaults are from SDL or gemrb.
I'm curious if you can attempt a Debug version build with MIPSPro. This way you can pinpoint the segfaults and call stack in BG1 (don't have it btw) so Lynx can take a look at it.

necron2600 wrote: Where (or what CD?) can I find dbx in order to debug an app or core file? Right now I can only use gdb.. not sure if that works well with MIPSpro compiled code?

dbx is part of the ProDev Workshop 2.9.x CD. It's separate from the Compiler Execution Environment CD's

Your compiled version has working sound for me:
In the cfg file:
AudioDriver = sdlaudio
I did try with it set to none, but nothing changed as far as the seg faults.

This is the first thing i do when i get unexpected program crashes or interruptions: disable any optional module or plugin option. This way i can eliminate SDL from the Y-U-NO-RUN equation.

Thanks to your latest diffs.. I can compile gemrb with MIPSPro without all the crazyness I was getting before.
My compiled version does not have sound though. But it still crashes in the same spots.
Regarding my compiling.. I am not sure how you are able to compile yours without the last diff I added to this thread?
In particular in the very begining:

[octane]:/storage/packaging-PENDING/gemrb-mipspro/gemrb-dexter/git-head/gemrb/build $ gmake
Scanning dependencies of target gemrb_core
[ 0%] Building CXX object gemrb/core/CMakeFiles/gemrb_core.dir/ActorMgr.cpp.o
[ 1%] Building CXX object gemrb/core/CMakeFiles/gemrb_core.dir/Ambient.cpp.o
cc-1293 CC: ERROR File = /storage/packaging-PENDING/gemrb-mipspro/gemrb-dexter/git-head/gemrb/gemrb/includes/Predicates.h, Line = 51
Pure specifier ("= 0") is allowed only on virtual functions.

bool operator()(PT param) const=0;

I have to add 'variable' before bool and it compiles..

Say what? I never saw that before. Are you sure you have all patches installed for MIPSPro and your IRIX version? My list of patches is:

This is from my R4K Challenge S, but should be very similar to my O2's since i run all with 6.5.22m/7.4.4m
Pay special attention to patches 5329 and 7076 which fixes headers. This was originally patch 4605 but initially i incorrectly installed it in tandem with the MIPSPro 7.4 . SGI recommends to install the base compiler products first, then exit swmgr/inst and then re-open the patch folder(s) and inst will select the default set applicable for your system. This is to avoid partial patching of header files (could be that SGI incorrectly set the installation order on these patches)

however almost every compile item gives a WARNING:
function "GemRB::VoidCallback::operator()()" is hidden by
"GemRB::Callback<T>::operator()" -- virtual function override
intended?

virtual bool operator()(T target)=0;

So not sure on the impact of that...

Got that warning as well. operator()(T) is a virtual bool template constructor, which means that classes derived from this should either implement their own constructor if the virtual constructor is private (or even protected) but apart from that no clue. Maybe Lynx knows.

gdb on the core file (gemrb compiled with debug -g )
I am not sure if gdb can work properly with mipspro compiled code??

No, get dbx. GCC and MIPSPro use different name mangling in C++, so i doubt if this will work. Ah you said it already:

I am not able to run gdb to execute gemrb.. give an unknown signal error early on loading a few plugins.

Something else:

Noticing these are all within ResourceManager?
We are modding ResourceManager.h (as per our diffs) ..
in particular to include or not include ResourceSource.h for SGI due to no SFINAE

That patch is absolutely required because of the incorrect forward declaration which aborts the compilation of ResourceManager.cpp. I suspect this also prevents compiling this on windows unless the header is explicitely set.
It could be that there genuinely is a problem in ResourceManager.cpp but Lynx should have a look at that. Maybe he knows offhand if there are problems in the code.

BTW i added some code inlining to your previous post in order to making it more readable.