The collected works of recondas - Page 19

The command "serial all" run against an L1 command prompt will return lots of interesting info, including the part number of your graphics board ( there's an example of a Fuel L1 "serial all" in this post ). Depending on your PROM revision you may be able to get similar info from a PROM hinv if you include the -m (manufacturer) switch in the PROM command string (see man prom for details on syntax).

030-1726-00x is the V12 jackpot - 030-1725-00x or 030-1826-00x are V10s.

If you aren't already familiar with the Fuel's L1 controller, normally it can be accessed with a serial terminal connected to the 9-pin serial header on the system board. There's a photo showing the (not immediately obvious) location of the L1 port and some basic terminal configuration parameters in this post.

Never had a reason to switch KVM focus while in the PROM, so I can't offer any person experience on the issue. IRIX only recognizes a very limited (and somewhat proprietary) subset of the USB standard , so it's possible USB support in the PROM firmware might not get past keyboards and mice (and like hot swapped USB gizmos even less). I wouldn't abandon hope until I'd tried it with IRIX running.

So that's where your O350s went.

I have a Mac Pro 2,1, which has some similarities to your Xserve 1,1: I'm very happy with the MP 2,1, with eight 3GHz core and 32GB of memory it more than fills my needs for photo editing/management. No experience with vSphere - I run OS X 10.7 (the last officially support OS X release for the MP 2.1), but I the system is set up to dual-boot W7 (via BootCamp) and I also run W7 and Linux as VMs (using VMWare Fusion).

The MP 2,1 and your Xs 1,1 both can hold up to eight 4GB 667Mhz PC-5300 FB-DIMMs, for a total of 32GB. If you need the stuff with Apple-approved heat sinks, the going price for 32GB is likely to hurt your feelings .

In spite of the loss of cooling surface provided by the Apple-approved FB-DIMMs, I've found it is possible to run non-apple FB-DIMMs. Not sure about the Xserve, but by default the fans in the MP run at very low speeds. That probably works well with in an as-sold config, but since I was working with a fairly max'd system, I opted to increase the minimum fan speeds from the default 600 RPM range to 1200 RPM (I'm using Temperature Monitor to monitor the MP's temperature sensors, and smcFanControl to adjust fan speeds. Apple-approved FB-DIMMs in 512MB sizes can usually be had cheaply, so you could also pick up some of those and move the apple-approved heat sinks onto the non-apple memory.

With the tweaked fan speeds it's been running 24/7 for a couple of months with 32GB of not-approved-by-apple memory. With a little patience I was able to acquire the 24GB/six 4GB FB-DIMMs needed to bring my MP up to 32GB (it came to me with two 4GB FB-DIMMs already in place) - for a less than the going rate for 8GB (one pair) of the the apple-approved FB-DIMMs . If you decide to keep it, I think the Xserve 1,1 should make a more than capable server

Worked well here too. I'll second the vote to move neko_pango-1.14.10 to /current.

I'd agree with hamei to try Ian's IRIX 6.5 Install Guide (if you have a failed install I'd suggest you implicitly include the 'Clearing Old Data Prior to Installation').

Ditto on hamei's suggestion to make sure the PROM is correctly linked to your new boot files. When installing IRIX on a new-to-me box, I usually do a 'resetenv' at the PROM command line, followed by a 'printenv' to make sure things look ok.

I'd diverge from hamei's recommendation to stick with IRIX 6.5.20. You won't be able to run nekoware unless you're at least at 6.5.21 , and with your IP35 system I would recommend the latest version of IRIX you can access. While a default install of a post 6.5.21 version of IRIX does loose some of the classic IRIX utilities hamei mentions, you also gain support for some of the IP35 hardware that was added post 6.5.20 - and you once IRIX is up and running you can install most of the missing classic utilities.

Think it could be realted to the Aten KVM being set in USB Hub emulation mode?

When the Fuel was connected to the iogear model 1764 KVM (which doesn't offer USB hub emulation) I never experienced extraneous mice entries in ioconfig or usb_hid reattach errors.

Don't currently have a Fuel set up to allow additional testing, but do have a Tezro and Onyx350 sharing dual monitors and a USB keyboard and mouse via a Gefen 2x2 DVI DL Switcher/KVM. The The Tezro and O350 are same IP35 hardware family as the Fuel; all three share the similarity of having PS/2 and USB ports. The Gefen 2x2 KVM also doesn't offer USB hub emulation, and there there haven't been any usb_hid reattach errors or extraneous mice with either the Tezro or Onyx 350: Could (or have) you tried the Aten KVM without USB Hub emulation enabled?

Not exactly (or maybe not even remotely) what you meant, but it is possible to re-install/re-link Acrobat 4.05/dpsnx and have something better than the meager versions of ghostscript (gsview and xpdf) that SGI inserted in place of the original Display Postscript system (tho most of the time I use the version of xpdf that you added to nekoware).
For reference (and to absolve 6.5.22 from blame), the original DPS went missing at IRIX 6.5.23: Quoted from the IRIX 6.5.30 Update Guide (if you've got a minute there's some other interesting stuff in there too).

The easiest way to re-link Adobe's dpsnx.agent is to let the install script do it for you - as suggested by yoben (scroll down a ways into the link):
I'm guessing you're already tried and are way ahead of me on this..... but it looks like a version of Adobe's Helvetica (and a few others) are installed along with DPNXBasic. Was the ability to access/use those fonts fubar'd by the removal of DPS too?

FWIW, I copied the adobe font files found in /usr/adobe/DPSNXBasic_2.1.1/psres/fonts/* into a folder in /usr/nekoware/etc/fonts/ and added a pointer in /usr/nekoware/etc/fonts/local.conf ( along with the other fonts suggested by Canavan ). Doesn't do much for the the larger font issue in general, but it might help to make the occasional web page easier on the eyes.

That's a pretty impressive collection of CDs. Thanks for taking the time and effort to add the info to the wiki.

Can I ask why you located your articles (and a separate table of contents) inside your 'User Page? Your contributions would be easier for other users of the wiki to locate if it were added to the existing/similar Media Product Number article . Ditto for your "Legalize Model Number" page, which could be added to the SGI Model Numbers article .

If you have an un-used, under-used, or extra VPro DCD and are in need of a Fuel V12, drop me a PM.

The Fuel V12 can be used in any SGI system with a graphics-capable XIO-2 slot, including the Tezro and nearly all Origin 350s (as long as it currently has processors and PCI slots).

EDIT: A trade has been arranged - thanks for looking.

The whole story of the change-a-V10-into-a-V12 hack is in this thread: viewtopic.php?f=3&t=16720976

bitcpy, yours is indeed a *very* interesting post.

Like j-j mentions, the topic was left open ended because no one seemed to have the knowledge needed to successfully modify the firmware so that the extra 96MB of memory present on a 030-1826-00x V10 could be used...... or at least no one admitted to having the knowledge.

If someone has figured it out in order to make a few bucks representing $25 V10s as $250 V12s, wonder when they'll get ambitious enough to try floating an 1826 V10 through a rework station to see if they can shoehorn on 256 or 512MB of memory (since later versions of the IRIX kernel already have the hardware definitions for both).

So if someone has figured out the alchemy needed to make V12s out of V10s, I wonder how many more are out there? If you have a semi recently acquired Fuel or V12 for a Fuel, you might want to take a close look at the part number/description in an hinv -vm.

bitcpy, could you run "l1cmd eeprom" as root and post the results - details in this thread: viewtopic.php?f=3&t=16725883

If it'd be less trouble, you can acquire the same info by via serial terminal - just run "eeprom" at an L1 command prompt.

Let's wait until you've got something to report from the person you got it from. If he disavows any knowledge about how that particular feat was accomplished there still won't be a resolution to the original thread.

Ergo, if I idolize something I invented it?

If that's the case vast numbers of the fairer sex need to see me for a right-to-use permit.

While you're in there I'd take a close look at the XIO module latching hardware, and check to make sure the chassis or XIO carrier didn't get tweaked somewhere in a previous life. Unless you are very large (and the floor very weak), if the compression connectors are bad enough to generate connection errors from heavy footsteps it seems plausible you'd also see the occasional XIO error during non-seismic use.

As long as you cleared the POD logs (and the hardware list stored within), you might try rebooting the L1 controller (on the odd chance it wasn't during your recent hardware update).

The L1 is live as long as power is connected to the Fuel. Shut down IRIX and run "reboot_l1" at an L1 Command prompt, or completely disconnect power for a short period. viewtopic.php?f=10&t=16726401

Firewire video won't use any of the classic IRIX video tools (e.g. Media Recorder and videod, et al) that you may have experienced on your Indy. Instead FW video use DM10 specific ML video libraries - which aren't included with a default install of the DM10 software package.

After you install the DM10 software package (see below for more on that subject), the DM10, IIDC and AV/C man pages will give you a better idea of which protocols are supported, the software tools provided, and some (basic) hints are to how they're used. Don't mean to bury you in tech notes, but they give the best clues as to what's need to get all the software bits you'll need to get FW video working. None of the DM10 related man pages are available through TechPubs, so I've quoted them here:
As mentioned earlier, if you do a "Default Installation" of the DM10 software package, you *won't* get the IIDC and AV/C software . To get around that select the "Custom Installation ..." tab, open the drop arrows next each of the DM10 selections and manually select ALL of the subsystems, including/especially the DM10 Dev stuff. That sould give you the IIDC and AV/C source code samples nekonoko mentioned using ( read down starting here . The acv_vidtogfx or iidc_vidtogfx executables sound like a reasonable place to start testing your FW cameras. To do much more than that, or take advantage of the avc_vidtomemory/iidc_vidtomemory program stubs you'll likely have to code your own app.
There weren't any release notes included with the DM10 1.1 package , but the release notes for the previous version (DM10 1.0.1) mention: There are some notes on installing the DM10 software in this post .

If you have the chance to try it out please let us know what you discover.

According to the manual, the base DVI port and the DVI ports on the DCD are an either/or situation (which along with the bandwidth restrictions of the V12, is why you don't find any factory-provided 3@ display formats). http://techpubs.sgi.com/library/tpl/cgi ... /ch03.html

As a follow up to the previous subject; if you were able to reboot your L1, was there any change in how your graphics board appeared ineither a "serial all" or hinv -vm?

Slow day over in irc.nekochan?

Are you really gonna make us reread the entire topic just to see who you quoted (or did you accidentally leave the attribution off)?

Adaptec apparently released a number of PCI firewire boards, including several different variants using the 4300 moniker. If a photo might help narrow the Adaptec end of the search, this AFW-4300B worked for me: Though, like hamei, every FW board with a TI chip set that I've run across has also worked.

Considering the other issues you seem to be having with your Fuel I'm sort of surprised you'd channel your peer support into a lengthy discussion on a question that for all intensive purposes has already been answered.

The 2@ display formats SGI provides for use with DCD equipped V12s provide a little more insight into hamei's references from TechPubs: 2@ DCD formats are built from two display fields, each of which has half refresh rate and the resolution of the original target display image, with the result being a single logical image that spans monitors connected to both of the DVI ports on the DCD. The base DVI port still receives the original signal, but because the DCD is hardwired to split that very same image into matching left and right halves, the base image and spanned logical image will always be the same. You probably aren't seeing the limitations the DCD imposes on the base DVI port because you haven't loaded one of the DCD-intended 2@ formats.

Once you load one of the 2@ formats intended for use with the DCD, you'll likely discover that the alternating half-field/half-refresh rate images formatted for display across a two monitors aren't very pleasing to the eye if viewed on a single monitor connected to the base display port - especially if the connected monitor is a CRT (an LCD panel probably won't sync to the half-refresh-rate display signal). The DCD is SGI's end-run around the size limitations imposed by the design of the both the Octane and Fuel/IP35 versions of the V12. In the case of your Fuel's V12 the base display port is single link DVI. The single link DVI standard calls for a maximum pixel clock frequency of 165 MHz , which is why SGI doesn't provide (non-DCD) V12 display formats larger than 1920x1200@60Hz (and the limitations on the pixel clock on the Octane/13W3 V12 are pretty much the same).

The DCD is able to provide for a larger logical image by splitting the image into two smaller halves, each with a lower refresh rate. That's also why there are two DVI connectors on the DCD - the logic on the DCD PCB intercepts the display signal directed to the base DVI port, and sends half to each of the ports on the DCD.

As jan-jaap has already mentioned, it looks like the DCD offers a least a little more magic than the Gefen or Connspot units. The recommended-by-Discreet Gefen DVI splitter unit got mentioned in a thread a few years back and the question came up as to whether the Gefen unit could directly replace a DCD. Discreet mentions the specific Gefen unit by name in their Tezro set up manual: To satisfy my own curiosity I contacted Gefen and was advised the HDTV Splitter Distribution Amplifier split a single DVI signal into two identical (mirrored) copies. I haven't contacted Connspot, but a web search gave a pretty strong impression it was a lower cost functional clone of the Gefen unit.

Sorry for the malapropism. Sometimes it's hard to teach an old dog new tricks, but I'll see if I can't do better next time.

With a few very minor tweaks (to suite my personal sense of gui-style), I tried, liked, recommend the hamei/jimmer userChrome collaboration.

diegel's neko-firexox3.0.19 is still going strong - after several months of regular use (on several different systems) I have yet to experience a crash.

A vote of thanks to all the above.

The offer still stands.....

For IRIX? Not that I know of, but as hamei so lyrically suggests, they do (freely) exist for OSX, Windows or Linux.

If you don't have something that'd run one of the EDID extractors, perhaps a friend with a suitable laptop could offer a few minutes of assistance. My experience so far has been with OSX; extracting EDID info with SwitchResX was a very short and simple process.

Or if you'd like to leave an indelible mark on the IRIX world, the source code for read-edid is available here . I'm not source-code or compiler qualified, but have seen enough mentions of other hardware oriented open-source tools get shot down in flames that I won't be surprised to hear the source isn't IRIX or SGI hardware compatible.

Depending on your monitor it might prove to be a tight fit. You might also want to obtain EDID info for your monitor - it might prove to be helpful.

The maximum pixel clock for MGRAS graphics is 160MHz. I tried to create a 1920x1080_60 MGRAS format using the VFC block sync script with the MGRAS chip and board definition files. The default timing used by VFC at 1920x1080_60 exceeded the MGRAS 160MHz pixel clock ceiling and produced a "no format created" error:

Not knowing anything specific about your monitor, I used CVT to generate a generic 1920x1080_60 modeline with VESA standard timing (likely very similar to what the VFC Block Sync tool produces). That resulted a too-high-for-MGRAS pixel clock of 173MHz: If all else fails, and *if* your monitor will support a format with reduced blanking , you may still be able to get around the 160MHz pixel clock limitation by creating a format with reduced blanking. Here's another 1920x1080_60 CVT modeline, asking for reduced blanking lowers the pixel clock to 138.5MHz: VFOs with reduced blanking haven't always been successful, so perhaps the EDID info will show that right out of the box your monitor uses a pixel clock lower than 160MHz at 1920x1080_60.

Same Fuel error message discussed in this topic:
viewtopic.php?f=3&t=16723070

Added a Dual-Channel Display (DCD) Option board to both V12s.... ...and also updated the hinv (and other info) in the original post in this thread .

Currently running a virtual 3200x2400 desktop (using OpenGL MultiPipe ) with four 19" 1600x1200 LCD panels in an Ergotron DS100 Quad Display mount .

In spite of what gfxinfo seems to imply, one 3200x2400 desktop (if you can zoom in enough to read it, gfxinfo is running in the open window): I elected to use OpenGL Multipipe with SGI Xinerama as the X Proxy Layer . OpenGL MP run by itself uses its own xserver (Xdmx). Xdmx works to transparently allow OpenGL visuals on both pipes/all four monitors, while Xinerama (without OGL MP) only allows OpenGL to run on the primary pipe (the primary pipe being two-DCD-connected displays in my case).

Running OpenGL MP with Xinerama as the X proxy layer is a decent compromise - and I can still take advantage of OGL MP by calling OGL apps from the command line with the "omprun" command. That will let me take my time to import the parts of my current desktop environment into Xdmx, which in as-installed configuration provides only a single winterm and a Toolchest. Here's the SGI Cube run on the Xinerama-managed desktop, called from the command line with 'omprun': Without OpenGL MultiPipe only the half of the SGI Cube displayed on the primary pipe/pair of monitors would be visible - the half of the OGL window on the secondary pipe/pair of monitors would be black. Just went and took a pretty close look and wasn't able to find any evidence of tearing. I wonder if you might be seeing it because the 2@1920x2400 config we set up for your T221 is probably a couple of notches north of the intended capabilities of a single V12/DCD?

Didn't mean to upset east-west detente..... I swear this is solely for peaceful domestic purposes and not as an escalation of the sino-american graphics race.

Thanks! Not currently, but I might try it if I ever pickup another 1920x1200 IPS panel - the DVI port on the one I have is connected elsewhere.

The image appears on the adjacent monitor as soon as it touches the edge of the LCD panel, so none of the visible image is actually blocked by the monitor frame. I haven't tried it yet but you can set up the displays to have a user defined amount of overlap, so that x number of pixels are displayed on both panels at the same time.
The OGL MP Release Notes obliquely touch on the intra-pipe synchronization:
So it looks like I'm probably getting some software sync from the default software buffering. I still have the 75-ohm BNC cabling that linked the 'swap ready' and 'genlock' ports when the Compositor was connected. Next time I shut down I'll reconnect/re-enable and try omprun with the -nosync switch to see what if connecting the hardware swap-ready/genlock/sync makes any noticeable difference.

Compared to how gfxinfo shows the display configuration with xinerama enabled, Xdmx is a little more savvy about the size of vitrual display. I was poking around in the log files created while I was testing Xdmx and noticed this:
Tried the Performer Town Demo as an easily accessible test of how the Xinerama/omprun combo handle an OGL app run full-screen (both V12s/all four panels):

I also shot a brief video of the demo auto-running in perfly mode - if there's anyone who hasn't already seen the Performer Town Demo in motion I can post a copy on youtube.

What's the specs on your target Octane? Because it was designed for use in Octanes with Impact Graphics (when RAM max'd out at 2GB), it has issues if more than 2GB of memory are installed, and there's been a mention that it wouldn't work in an Octane with an R14 CPU.

Having said that, I had a lot of fun with one I used to have . The Cosmo2 (a.k.a. Octane Compression Option ) has the advantage of offering professional quality *analog* video.... ....while the PVO provides uncompressed web-cam quality video. Another potential advantage over the PVO is while the factory intended the Cosmo2 for use with Impact (SI,SE, SSI SSE, MXI, MXE) graphics, it can be made to work in some Octanes with VPro Graphics .

http://www.futuretech.blinkenlights.nl/prisa/

*Never* experienced anything even remotely similar on any of the DCD equipped systems here - the Tezro and Octane2 running 2@1600x1200 and now the O350 running double 2@1600x1200.

Sounds like either the T221 is having difficulty syncing to the signal, or the V12/DCD is having trouble consistently generating it. The quick-n-dirty fix might be to treat the O350 like an O2 and *never* turn it off/restart the graphics sync process from scratch. A more involved solution might be to try some incremental changes in your 2@ refresh rate.... or better yet, put graphics in another O350 and spread that 3840x2400 graphics feed across four stripes instead of two.

Somebody buy the man a cigar.

I mentioned that as one possible reason why I'm not seeing the tearing when I cross the DCD or pipe boundary, but if you want to try, you could skip xinerama and try pure OGL MP/Xdmx set up, or better-yet-put-graphics-in-another-O350......

I think lend-lease to china ended when you were just a wee lad, but there's an unloved O350 sitting in the rack with hamei written on the toe tag (and you won't have to worry about past-due fees with that one).

If it walks and talks like a duck.... Sure sounds and looks like something in the vfo-V12-DCD-monitor conglomerate is half a notch off plumb.
The boot-time-prom behavior is normal - neither has any knowledge of the 2@ format magic IRIX performs on the DCD. Maybe, but there was the issue of VFC going into danger-will-robinson-mode when the format has a screen height greater than 2048 pixels . Which is why I was thinkin' four heads might be better than two - won't eliminate the-greater-than-2048 issue, but cutting the horizontal resolution in half might ease the the strain of your single V12/DCD livin' on the bleeding edge.
Angry howling all night? Sounds like your fan club is made up of CEOs and MBAs. ...it's as big as the promise, the promise of a coming day. If he's gonna bear the weight of the Southern Cross you better tell sherwood to bring the *big* suitcase.

Looks good to me, especially since you have MXE graphics.

Never had a Cosmo2 and a PVO at the same time, so I don't have much in the way of personal experience to offer there.

SGI provided a flex cable link to connect the Cosmo2/Compression Option board to the Impact-graphics era Octane Digital Video board (which in turn connect to the Impact graphics board with flex cables). The PVO seems to be missing the connection headers (for the flex cables from the Cosmo2/Compression Option), so linking thier functions wouldn't appear to be an supported-by-SGI solution.

Turned more than a few TechPubs references to Octane Digital/Compression Video cohabitation, but didn't see any for a PVO/Cosmo2 hookup. Here's the install guide for the Octane Digital Video board (including mentions of how to install it with the Cosmo2/Compression Option), and a mention from the release notes for impactvideo :
I'm not saying they won't work if installed at the same time (independently or in collectively), or that you might not be able to make it work in a fashion similar to how the Cosmo2 was made to work with the equally unsupported-by-SGI VPro graphics. See my lack-of-experience disclaimer above ... though I'd suspect if you're gonna send compressed video on the fly, whatever is running the web cam/video display on the other end will need to know what to do with it.

Sherwood or not, you aren't completely Helpless. There are plenty of Big birds flying across the sky.

You'd just have to tote your own jumbo-sized suitcase.

Yep

Looks like it's digressed into an opportunity for hamei and I to play In-Line Jeopardy with Famous Songwriters of the 60's..... but you're more than welcome to join either endeavor.

BTW, how's the Firewire stuff going with your Fuel? I've been looking around for up an iSight to try with the pseudo dm10.