The collected works of robespierre - Page 14

Congratulations!
You will need to get a regular PS/2 keyboard and 3-button PS/2 mouse, or you could run it headless through the serial console. There have been reports in the past that some cheaper PS/2 keyboards don't work: I think this is an issue with Scan Code Set 3, which is part of the PS/2 keyboard protocol but not actually used by PCs.

fu wrote: i’m looking for one to pack a credit-card-size router/wifi/vpn/sftp/cardav server.

PC Engines APU.1D running pfSense. All industry-standard hardware, no special drivers needed. It is slightly bigger than a credit card...

-the raspberry pi has the most dedicated/helpful community and they actually develop drivers for the tiny thing.

As a router?? ethernet performance is horrible

-there’s a gazillion of other makes/names, they all run some bastardized version of lunix and most likely they won't be fun for anyone who cannot write his own driver.

Some are running mainline distributions. It depends on cluefulness of the vendor.
This one is $9 and runs Debian (no ethernet though, but it's the same situation with RPi, you are forced to stuff ethernet through USB)

i can do all of the router/wifi/vpn/sftp/cardav server with openwrt on my router and i was once able to install irix on the crybaby o2 in half an hour but no i cannot write my own device driver.

I don't really see the issue. All the pico-computers come with functioning linux systems or can run standard installs. If you were trying to do this on an ESP8266 or Tiny I could see how you'd have a problem.

64-bit integer math can be an advantage for some programs, and the x86-64 instruction set is more regular, which helps optimization.
For example, you can compute an offset into a >4GB file without gyrations (and even do it in regular C code).

ivelegacy wrote: mini epiphany cluster, 4 Parallella boards stacked on MPI

I was pretty much beside myself laughing when Andreas showed off his 10x Parallella "supercomputer" in 2014. That's right kids, just take a pile of boards and hook them up to a Netgear switch, and you've got yourself a supercomputer!
Just when you thought you could wash the taste of "Beowulf" out of your ears! I even heard it "smokes" a Cray!

Extra irony because his chip/board does have low-latency interconnect/fabric. But even the inventor can't figure out how to make it work in small-scale MMP or ccNUMA is pretty damning.

An addendum to the remarks about the Canon SX and print resolution:
One printer improved the resolution of the SX engine to 400x400 dpi: the NeXT Laser Printer. It seems that many small design changes were needed to achieve this, with the result that only a few parts are directly exchangeable between it and all other SX printers.
Are there any other NeXT owners here?

which USB-serial adaptor? Do you have experience with serial consoles?
A serial cable for a modem is wired straight thru, pin 2 to pin 2, etc. This is called "DTE to DCE". It will never work on a console port.
A serial *console* cable is wired "DTE to DTE", pin 2 to pin 3, etc.
You need an adaptor that uses full RS-232C voltages; the most common USB adaptors today are only of use for attaching 3.3V microcontrollers like Arduinos.
If you're not seeing any output it sounds like one of the above problems. If you see garbled output you need to change the line speed, I don't know the Octane's default but 9600 or 19200 are likely.

It could be as simple as the system changing to a stereo display mode. Stereo modes run at up to 150 Hz, which is outside the range of typical monitors. You need the root password to get any further.

It's hard to know just what you mean by "the plastic screw things", but the Octane cards are not connected merely by being pushed in. The levers must be present and actuated in to make a connection.

Only one kind of right shift?

I thought you already had that covered with "bit.rotate", but maybe I didn't grasp the intent.
I mean that if you only have one type of right shift, it can't accommodate both logical and arithmetic forms.


vs


P.S. it can also be useful to have "arithmetic left shift" depending on how condition codes and traps are architected. If you can always test overflow after a shift you don't need it.
The other approach is to have "arithmetic shift" and "logical shift" opcodes with a signed (or excess represented, because you don't want to waste a bit for zero) distance. Depending on addressing modes this can allow for both immediate or register distance operand.

POWER has very good shift instructions, with rlwmi you can implement multi-precision shifts in a tight loop.

The Octane2 is physically the same as the Octane, but it has the latest XBOW (crossbar switch on the frontplane) and power supply. Some late production Octanes have these as well, with the only difference being the color of the skins.
The graphics options are not the same: only machines with the latest crossbar and PSU (like an Octane2) can be used with VPro graphics. This was the default graphics for Octane2. When VPro is installed, the rear panel looks a bit different:

There are three notable differences. First, the VPro XIO carrier has actuator handles in a different position. Second, the "Cherokee" PSU has a silver colored handle. Third, the processor or "node" board is usually a late model with a silver handle, which means it can support up to 8 GB of RAM.

Most "USB to PS2 adapters" don't actually contain any electronics. They rely on the keyboard or mouse detecting something (like power on the wrong pin) and switching to PS2 mode. They only work with the keyboard or mouse they were sold with.

What hardware is in your machine? IRIX 5.3 All Impact doesn't support the 250MHz IP22 or any R8000 or R10000 machines.

The Octane doesn't have a system ID EPROM. I haven't heard of the system ID being lost, at least it's not likely to happen yet.
I don't think ioconfig has anything to do with your mouse problem. The PS2 mouse controller is always part of the system and configured whether you have a mouse attached, or not.

I "obtained" an irix 6.5 disk. I decided to put it in, and hit install software. it started a copying progress bar, and soon as it finished, screen when "out of range" while the HDD was still loading stuff.

The software installation procedure is not graphical at all. It's been a while, but I believe that the installation kernel (the "miniroot") uses the standard 1280x1024@60 resolution. Many SGI displays are fixed-frequency at that rate.
The classic reference for Indys is http://www.nekochan.net/reputable/indytech.html ; I found there that the Indy starts its graphics at 1024x768@60, which is a little surprising. You have to set the prom variable "monitor" to h in order to make the machine start up using high resolution, which makes it different from every other machine. What happens when IRIX 6.5 (or its miniroot) starts is it resets the resolution to a stored value set with the setmon command.

Something about your "VGA circuit" comments smelled strange to me, so I searched for "viewsonic E70 specifications" and saw repeated reference to a "flicker-free 1024x768 refresh rate". Eventually I found the manual which only confirms a few resolutions, including 1024x768@75 and 85, and 1280x1024@60. This means that 1280x1024@72 Hz, which is a common SGI resolution, is not supported by the monitor. Evidently that is what is being selected when you start IRIX. The other monitor you mentioned at the beginning of the thread doesn't support it either.

I think SGI is a little bit too advanced for what I am willing to get into, and it doesnt appear its going to be an easy fix.

From everything that you have said, it now appears certain that it would work as intended if you simply used a better monitor. In hindsight it's ridiculous that such a thing take 3 years to be said.

Nice. Have you upgraded your DSP memory?
I know that simms were manufactured and sold during the late '90s (by CCRMA?). You can even find prints (but not gerbers) for them online.
At some point I want to do a run and it would be useful to know whether there is any demand.

Another seldom discussed issue that can cause problems are the Monitor ID pins inside the 13W3 port. SGI used more than one incompatible definition for these pins (as did Sun): this frequently frustrates people using 13W3->DE15 cables from the internet. The real solution would be DIP switches integrated into the cable, as you see in adapters like the Griffin Mac Sync Adapter.

PCMCIA static memory cards had a write-protect signal, but it only was a flag to the host controller to block writes to certain segments based on the Card Information Structure; it was not a hardware enable. The larger flash cards are seen as I/O devices (ATA disks), not memory; so the place to look would be the ATA specification. It appears that there is a PROTECT command in ATA. Some mSATA disks also have the function on a pin.

full-size SD cards have a write protect notch that moves an optional switch in the socket. This is purely advisory: if the host driver ignores the switch GPIO input, writes can still occur. there is a set of commands that can be sent from the host to make the card read-only.

Cutting the ATA write strobe line will not work, since this is used for sending parameters and commands to the drive. ATA disks seldom have any means to prevent writes, which is the reason that expensive adaptors exist for the forensics industry that block writes to the disk. Sometimes a flash module has this same ability: this one calls it "virtual writes". The card performs write commands to its buffers but never saves the buffers to the media.
http://www.mouser.com/catalog/specsheets/apsdm.pdf

The CF specification defines pins for "Write Enable" and "Write Protect", but they do not do what you think. WP is a card output used for bus state signaling. /WE is ignored in True IDE mode. See here:
http://rumkin.com/reference/aquapad/media/cfspc3_0.pdf

What might work is putting a switch in the WP line of a CF-to-PC Card adaptor, used in PC Card Memory mode. If the host controller respects that signal, it will refuse writes to regions the CIS says are write maskable.

Several users have mirrored the manuals: viewtopic.php?f=6&t=16730047&p=7388031

Now that SGI has taken them offline, it may be time to talk about hosting them.

"data sync mark error" sounds like the formatting is corrupt. You may be able to fix it by low-level formatting, but the drive may be physically faulty. I'm more surprised that there is even an error message for such a low level problem.
It's possible to reset the root password without any external help, but it's an exercise in persistence.

I remembered that there was a scan of some old schematics and films from the '90s. Looks like it was done at SFSU and not Stanford.
I just saw your reverse-engineered pictures too http://www.nextcomputers.org/forums/viewtopic.php?t=876
It doesn't seem like that project ever happened; a bunch of onlookers discussing super basic electronics knowledge and nobody actually saying how much they would pay. You can't crowdsource anything without purchase commitments.

It's set up the same was as recondas's O350 , with InfinitePerformance graphics, which is V12.
The 1 GHz R16000 is physically bigger and won't fit the Fuel V12 card when the node has 4 CPUs, only 2.

Yes, Impact-ready Indigo2 is downwards compatible with all previous Indigo2 options. Remember that:
1. When no cards that use the Impact power headers (white box) are installed, the blue power cable should be docked to the side of the PSU so it remains properly terminated
2. multiple GIO64 cards may need to be installed in different positions since the GIO64 slots are arranged differently on MGRAS than on FullHouse
3. You need to reinstall IRIX to get the drivers and microcode for the graphics card. The easiest way is probably to use swmgr with command-line options that explicitly install those and avoid changing anything else. (see the man pages for the "skip_rqs", -m, -X, and -Y flags)

But please note that IRIX 5.3 does not support the 250 MHz CPU (or others with 2MB L2 cache), you need to install patches before it will work.

Try installing patchSG0002605

Remember you need to be root to run inst.

IRIX 6.5.22 supports all machines with R4000 or higher processors, except the Crimson.
Your CDROM drive needs the capability to switch to 512 byte sectors. What drive is it?

Any progress?
I found a site that has pictures of the internals of many types of keyboards: http://deskthority.net
Once you know what the switch type is called (look at the stem shape on the key cap too) it will be much easier to source a replacement.
I 'd also feel better knowing that there isn't a corroding "CMOS" battery inside.

I don't know; if I'm lucky I will have time to test this on my identical machine.

any particular reason for the Yokogawa? They have some complicated trigger modes and pass/fail tests, but pretty low sampling rates.

IP6 has SGI pinout serial ports, you will need to make a cable
compare the third arrangement at serial(7)

I know. I researched them a few years ago, but they are uncommon outside Japan.

Hello tooR,
Sorry if this has already been answered, but did you disassemble the whole PROM? With IDA Pro or similar?
Is your listing available?

Yes, incompetents are everywhere. Don't get me started on the messages that ask me to "enter your security questions, to keep your account secure"...

200 MSa/s is only when half of the channels are used. Yokogawa estimates this gives you 80 MHz single-shot bandwidth.
Anyway, if you do get one, make sure it has the /F1 option. It adds a still very desirable smart trigger capability.

"How dare you steal and take credit for my work (that I stole and took credit from my graduate student) ?"

very cool, foetz. do you think performance on the Indigo2 would be better or worse using IRIX 6.2/MIPS3?

I'd expect a renderer to use FPRs heavily and the separate register file would help.

Those are the same item, and it failed to meet the reserve price both times.
I'm not surprised: if you can see that a seller has unrealistic expectations (based on astronomical figures on other items) you're less likely to grit your teeth and make your best offer.

The MacIvory I was also slower and less capable. It's less common but I don't think that makes it more desirable.

3D demos using GL or OpenGL won't run remotely without support on the remote server (either DGL, which is exclusively for IRIX; or GLX, which would need to be compiled in to the XServer). Performance for any kind of moving images over remote display is pretty slow. Remember that the machine running the client needs to take more of its (limited) cycles to create the packets and send them, even if the server side is fast.