The collected works of robespierre - Page 8

The exception support in C++ is half-baked, it doesn't allow for exceptions that are continuable.
Specifically, there are two ways to implement an exception system: either the stack is unwound to the point of the exception handler first, losing all inferior context; or the stack is searched for a handler but not unwound. in the latter case, the handler can adjust the signaling context and then tell it to continue. This is how Xerox's Cedar Mesa exceptions worked.
:PI: :O2: :Indigo2IMP: :Indigo2IMP:
I no longer have an Octane, but they would be using 12V Panaflo or Pabst fans. The fans are variable speed and have tach or stall signals, and specific connectors. The assortment of option codes that are available with this grade of fan is pretty amazing.
:PI: :O2: :Indigo2IMP: :Indigo2IMP:
The chances of getting an Arduino to do anything at wire speed are... remote.
:PI: :O2: :Indigo2IMP: :Indigo2IMP:
do any of the R10K/R12K/R14K processors actually implement MDMX? I didn't think so. Those were the SGI SIMD extensions, but their implementations (code named H1 and H2) were cancelled in the shakeup that was happening around Itanic.
:PI: :O2: :Indigo2IMP: :Indigo2IMP:
These drives are not the most reliable. But they are not that advanced either, so repair is possible.
:PI: :O2: :Indigo2IMP: :Indigo2IMP:
there are scripts to do it. since IRIX does not have a loopback mount device, you must create the image as a partition on a hard disk. then unmount it and use it as an input to cdrecord.

if you will only use later IRIX versions, like >5.3, you can just use rockridge. I don't know of any problems using it.

Edited to say except for booting from the disc, of course. and miniroot installs.
:PI: :O2: :Indigo2IMP: :Indigo2IMP:
see viewtopic.php?f=7&t=885
but the original instructions (at sgiaddict.com) are gone, try the internet archive
:PI: :O2: :Indigo2IMP: :Indigo2IMP:
That was very funny :lol:
But in truth, saying "unsigned" is praenimis... it would be a power of two either way.
Numbers are frequently printed in fields of limited size, which can act strangely when they are not wide enough. They can even suddenly turn into something non-numeric, like with the "G" format specifier in Fortran.
:PI: :O2: :Indigo2IMP: :Indigo2IMP:
Turbo Pascal is like a whole different language, without all the extensions Pascal is a lot less useful.
:PI: :O2: :Indigo2IMP: :Indigo2IMP:
I don't know better than anyone else, but SGI made the PI at two factories, one in Mountain View and one in Cortaillod. It would make sense if the sequences were different between them. "E" might also refer to an upgraded E-Module. For comparison, my Swiss PI has a serial of 37000726. Same number of digits, but no E prefix.
In later models, the serial number is the same as the lower 4 bytes of the main MAC address, but that convention wasn't in use for the PI.
:PI: :O2: :Indigo2IMP: :Indigo2IMP:
"Phone home" capability is already included in Performance CoPilot.
:PI: :O2: :Indigo2IMP: :Indigo2IMP:
when your business model is selling $10,000 digital watches, useless $1500 toy computers are child's play.
:PI: :O2: :Indigo2IMP: :Indigo2IMP:
SGI's Virtual-24 technology is hardware-assisted dithering. The Xserver provides a 24-bit DirectColor visual to applications, which can run as if they had a 24-bit graphics device. The GL system dithers that visual using an 8-bit LUT optimized for the colors the application uses.

By contrast, HP's Color Recovery technology also processes the data on the backend, turning the dithering back into an approximation of the original color information. It was only found on the 715's HCRX and the 712's integrated graphics.
:PI: :O2: :Indigo2IMP: :Indigo2IMP:
I don't have an 8-bit Indy to check, but the way to find out is to run xdpyinfo. If you see a 24-bit DirectColor (or TrueColor) visual, then you have the Virtual24 feature.
This feature wasn't specific to Indy, btw. It was also on the 8-bit Indigo. There were no other 8-bit only graphics options.
:PI: :O2: :Indigo2IMP: :Indigo2IMP:
'$0600' is hexadecimal notation. There is no such thing as "little endian notation": endianness is about how numbers are stored in memory, not how they are written.

$0600 is simply 6*16^2 or 1536. You can enter numbers in either base to the assembler, it doesn't care. Usually the syntax is #42 for decimal constants or #$2A for hexadecimal constants. When using unix or C tools, the syntax usually is 42 for decimal, or 0x2A for hexadecimal. You aren't likely to find much C software on a 6502, although compilers did exist for the Apple ][ and others.

Pages are a virtual memory concept. I can't think of too many 6502s that implement virtual memory, but that doesn't mean they aren't out there.
:PI: :O2: :Indigo2IMP: :Indigo2IMP:
All you are doing with -depth 24 is making the default visual be a 24-bit deep one. Applications don't simply use the default visual, they use the visual they were written to use. So this does not affect most programs.
:PI: :O2: :Indigo2IMP: :Indigo2IMP:
vishnu wrote: Well written applications do the legwork to find the best visual that's available on the hardware they're running on, and use that

Yes, but we're talking SGI here. Of course every visual is supported, and several that X doesn't understand to boot (thinking of 12- and 16-bit color components here). It's the ability to use multiple colormaps of different sizes (including weird stuff like 12-bit indexed, and 8 bit DirectColor) on the screen at the same time that distinguishes these designs.
:PI: :O2: :Indigo2IMP: :Indigo2IMP:
What is the card in the bottom slot? It looks like a wallwart DC connector!
:PI: :O2: :Indigo2IMP: :Indigo2IMP:
you must be kidding; I haven't any knowledge on this issue.
:PI: :O2: :Indigo2IMP: :Indigo2IMP:
As an update to the subject of old floppy disks going unreadable, there is also a failure mode where the floppy media gets detached from the hub. The hub has two pieces that are glued together around the media, and if it lets go, the drive can no longer track the media.
:PI: :O2: :Indigo2IMP: :Indigo2IMP:
vishnu wrote: Vector Electronics used to make an EISA prototyping board...

That board in the picture is either PCI or MCA, but definitely not EISA!
:PI: :O2: :Indigo2IMP: :Indigo2IMP:
for backing up tapes you need to understand the tape format pretty thoroughly... is it fixed or variable block size? TK50 can use both on the same tape, although normally it won't let you change the setting for partial writes.
how do you plan to preserve file marks? normally when you use dd(1), the transfer will terminate at each file mark. but this may be something different than what you think of as a "file". and dd doesn't actually know anything about end-of-tape signaling, which presents a problem.
:PI: :O2: :Indigo2IMP: :Indigo2IMP:
IMO anything from Evans+Sutherland is interesting.
:PI: :O2: :Indigo2IMP: :Indigo2IMP:
guardian452 wrote: It was either upgraded or at some point the top hat or back panel was replaced because the nameplate says VGX but the top hat says RealityEngine. My transpotting skills aren't what they used to be, I can't tell just by looking at the cardcage anymore. (guessing realityengine based on the 2RMs and DG in RE positions with the similar-to-RE2 style frontplane)

It's RE. The pictures on Photobucket show a GE8, DG2, RM4, and RM4T.
:PI: :O2: :Indigo2IMP: :Indigo2IMP:
If that's an Extreme, does it mean Extreme gfx exists for Indigo GIO32?
:PI: :O2: :Indigo2IMP: :Indigo2IMP:
vishnu wrote: Yes but the guy who created Cedar Mesa exceptions said, at the C++ standardization meeting in 1991, “termination is preferred over resumption; this is not a matter of opinion but a matter of years of experience. Resumption is seductive, but not valid.”


I didn't say the people behind it were necessarily in the right ballpark.
What you're quoting shows a very serious confusion about what an exception system is for (which Stroustrop unfortunately labored under also): all it is, is a control transfer mechanism. It is sometimes convenient to use the exception system for error handling, but that really has nothing to do with how it should be designed.
So no, there is no problem with using exceptions that can be continued. What you usually would like to do is continue from a point before the exception was taken, but after the handler. When the stack is unwound to the handler first, there's no way to do that.

An easy use example would be a debugger that exists as a library. When the program encounters an exception, the handler from the library is given control and can print out or record the context that took the exception. When it's decided what to do (maybe the method had = when it should have ==) corrective steps can be taken and the method re-entered. As it stands users need to use external programs for debugging, which has many problems. Another example is logging. The debugger library could be replaced with a logging library that handles the same exceptions.
:PI: :O2: :Indigo2IMP: :Indigo2IMP:
(I realize this is an old thread, is there a more recent one about your Crimson?)

I had a 4D/70 that did the same thing, it went pop 30 seconds after powering up. The smell of electrolyte was very strong in that area for weeks. I took the power supply out (it was an ACDC brand) and took it apart but there was no obvious damage that I could see. The ACDC supply is not modular and disassembly beyond a certain point looked hopeless.

I traded the machine for an O2 R10K, which to me was a great deal. I don't know how it's doing now...

(edited to note that it was a 4D/70, not 4D/80)
:PI: :O2: :Indigo2IMP: :Indigo2IMP:
I would look for Houdini Master, SoftImage 4.0, Lightwave 5.6, and Maya 6.5... they should all work on that machine.
:PI: :O2: :Indigo2IMP: :Indigo2IMP:
You aren't kidding! Flat colored triangles and rectangles, and solid color lines only! It has a pattern capability, but no direct support for line stippling.

the IRIS did hardware lighting, shaded polys, depth cueing, triangle strips, and retained mode. I believe the PGA was only really a solution for CAD applications, whereas the IRIS was much better for all sorts of visualization.
:PI: :O2: :Indigo2IMP: :Indigo2IMP:
The things you really need, still work just as well on an Octane as they do on an i7. So the hot-to-go racy latest stuff is nice for the speed but it isn't essential. I type pretty slow anyhow.


I have an i7 mac, because you need something super fast to use the web these days. Does it actually feel fast?
Nope. It leaks so much memory that it starts swapping when you type , eventually lagging minutes behind to finish echoing back a couple of sentences of typed input. There is even a race condition in the interface that will sometimes scramble your input if you type ahead of the system. It's a dog.
:PI: :O2: :Indigo2IMP: :Indigo2IMP:
searching "Sun 320-1256" brings up results mentioning the JavaStation, which did indeed use PS/2 peripherals.
:PI: :O2: :Indigo2IMP: :Indigo2IMP:
zmttoxics: have your eyes checked. the keyboard in the pictures looks different from a Type 5 in almost every way.

xenu: The Type 5 was also available in 'US' layout, and a couple dozen other national layouts. But here the 'UNIX' layout seemed to be the most common.
:PI: :O2: :Indigo2IMP: :Indigo2IMP:
All versions of 6.5.x will say 6.5 when you do 'uname -a'. On IRIX you need to do 'uname -aR' to see the version that is installed. (It does that because the history of IRIX was that releases were always just as major.minor, so scripts that parsed `uname -a` expected that same pattern. But 6.5 started quarterly releases and needed some way to number them.)

If you get a blank screen when X starts, the display mode may be incompatible with your system or monitor. You can use "setmon -x <mode>" from the single-user runlevel (which is reached by giving the "single" command to the PROM Monitor) to save a display mode for all future X starts.
:PI: :O2: :Indigo2IMP: :Indigo2IMP:
ISP-supplied gateway + unpatched 1990s Unix = pwned in minutes.
:PI: :O2: :Indigo2IMP: :Indigo2IMP:
Looks like it could be an internal DEC development. Pretty exotic: 2048x2048 resolution?
:PI: :O2: :Indigo2IMP: :Indigo2IMP:
If your image file is correct for all the tracks that contain data, isn't fixing it up to the proper length just a small matter of programming?
:PI: :O2: :Indigo2IMP: :Indigo2IMP:
escimo wrote: "• Two serial-port connectors • For VR peripherals"


That makes a bit more sense, thanks.
For actually outputting to a VTR, it isn't enough to just have a rs422 port spitting out deck commands. The video output from the computer needs to be locked to the tape. So building the serial ports into the graphics card would be one way to achieve that.

(See the DiaQuest history at http://www.diaquest.com/AboutUs/history.html for more on SGI and VTRs)
:PI: :O2: :Indigo2IMP: :Indigo2IMP:
OpenGenera 2.0 is based on Genera 8.5, not 8.4.
The emulated environment does not implement the Symbolics native file system. There are also other missing features.

The present market value of an Ivory machine like the OP's is around $5000, which seems to me to be the last word on whether it is "a preferable configuration".
:PI: :O2: :Indigo2IMP: :Indigo2IMP:
I'm not 100% positive, but I think that the hard disk will have either a directory of hidden files (representing FEP files), or an additional partition that contains a FEP file system. I last used a MacIvory many years ago, so I don't remember which it was. There is also software on the Mac HFS side called "Breath of Life" and "Life Support".

Symbolics had a "different" way of doing file management, that had multiple layers (like an OSI model for files!)
At the lowest level there was a "simple" file system for the FEP that had coarsely allocated files in a flat (no directories) namespace. Their sizes cannot change. These would be boot drivers and scripts, virtual memory areas, "worlds" or "bands" which are full system images, and LMFS areas. The LMFS was the high-level filesystem with journalling, versioning, soft delete, etc. It could use multiple FEP files on multiple drives to store a single directory tree. Think of AdvFS domains.

On the Ivory there was no FEP, but the idea of a simple executive for booting was kept, and the processor runs in a "FEP Mode" when it starts. The dedicated workstations used 1280-byte sectors, to match the VM page size, but the embedded cards like the UX and MacIvory used a compromise to fit into the host's native block size, at the expense of some wasted space.
:PI: :O2: :Indigo2IMP: :Indigo2IMP:
The lusers' guide:
http://bitsavers.informatik.uni-stuttga ... _Guide.pdf

I was going to say that the FEP0: is not really a partition name, Genera refers to it as a "Host slot". Host can be physical or logical, there is a complex table of mappings. So it's like a label that tells the system how to access a file, and even how to parse the pathname. From the manual (page 908) it looks like there is a dedicated partition (or several), but I wasn't 100% sure. I do know that on the UX400 ("Solstice") there is no separate partition.

71271.1417 (a CompuServe ID) is the guy who took over the sales and support operation when Symbolics was liquidated. He's been selling manuals and hardware on eBay for 17 years or so. Prices have been going up: I'm not sure that he's going to get $2500 for a MacIvory II, but it's possible. The MacIvory II is about a third the speed of the III, both from the slower Ivory chip and the slow main memory over the NuBus.

(edited from "a quarter the speed" as I remembered, to "a third" which is straight from the horse's mouth)
:PI: :O2: :Indigo2IMP: :Indigo2IMP: