This isn't so much a FAQ as a list of problems and oddities I've run into with my PERQ-3 (an ICL 3300 Graphics Workstation). It's an attempt to provide some useful information on the machine and to fill the gaps left by the other FAQs.
Just about everything, really... The PERQ-1 and 2 had CPUs constructed from discrete logic, whereas the PERQ 3 is based on the standard 68020 CPU and 68881 FPU combination. The PERQ 3 also runs PNX 300, which is ICL's version of Unix System V R2, whereas PERQ 1s and 2s ran POS (the PERQ Operating System) with a version of PNX based on Seventh Edition Unix as an alternative.
The system unit is 150mm wide, 530mm deep and 330mm tall. It's
a bit like a rather deep 'mini-tower' case as seen on (around?) PC clones.
The monitor is a 21 inch black and white affair. It's 500mm tall, 500mm
wide and 400mm deep. The mouse is slightly odd by modern standards - it's
a sort of squarish block slightly taller and somewhat shorter than a
PC mouse. The three buttons are on the front rather than the top face, and
the ball is steel rather than rubber or plastic.
Some photos are now available.
(I said it was a trivial FAQ...) The PERQ 3 can turn itself off and on - the circuit diagram for this is quite interesting. The mains power is switched via a relay, so you must have the battery connected to power the switching circuitry. You then press the push button on the side of the monitor base - this will cause the fans to start, and the boot up process should commence...
Nothing, honest. The PERQ 3 has a boot process designed to make you think it's broken - it's rather odd. The pattern is the monitor/graphics processor test - it'll go away in a second. Then the machine will appear to thrash the disk for ages, after displaying the 'Graphics Microcode v7.2.0' banner. This is just loading the microcode and kernel, and it takes a while.
This is the Diagnostic Display System (yes, really!). It counts up as the PERQ performs various self tests and boots up. You can also run a wider range of tests, controlled by DIP switches on the CPU board. As the documentation says:
If you are working from the display information,
make sure the DDS is in place.
Code Meaning DEAD What it says! Couldn't find a stack area for the boot program. 0010 MPU 0011 Static Memory 0012 Main Memory 0013 Video Memory 0014 Pager 0015 Graphics Processor 0016 Floating Point Processor 0017 SCSI 0018 DMA 0019 OMTI Board (SCSI-to-HD/FD interface) 001A RS232 (remote comms) 001B RS232 (local comms) 001C OSLAN (ethernet) 001D Real Time Clock 001E CPU Board Data ROM 001F Memory Board Data ROM 0020 DDS Board OSLAN Address ROM
I can't find anything after this, but observation suggests
0213 during microcode loading 0000 after successful UNIX boot
The tests and display are rather more detailed if you set the switches to test mode rather than normal (system) mode.
I'm told it should be 'Pee-nicks'.
All this information is guesswork - I haven't got it working yet...
First, the (allegedly) simple method: procure a null modem cable, connect it
between the PERQ and the PC. Set up uucp software at each end. Transfer
files as needed.
Actually, you may find it easier to just use cat to transfer data
across the serial line. I have a couple of nasty shell scripts which
use shell archives to transfer files and cope with the fact that I
seem to intermittently lose a kilobyte or so from large transfers. I could
be persuaded to part with them if you really want them...
In theory, you should be able to use the ethernet connection. You'll
need a transciever to connect to the PERQ, a PC network card, a length
of thin ethernet cable, two BNC T-pieces, and two terminators. The
hardware side is easy - software is likely to be tricky :-)
The trouble is that the PERQ doesn't speak TCP/IP. It knows something
called the Newcastle Connection (slogan: Unixes of the World Unite!),
but I can't find any details that would allow me to implement this
under Linux, for example... If you get this option working, I'd like to
hear about it!
These are Tony Duell's hints on how to do this. They're quite long and detailed, so they're on another page.
On my machine, there are some demonstration programs which load some static images (logos, maps, technical drawings). However, they seem to tend to cause crashes - mostly the machine just locks up, but I got a kernel panic once... Your mileage may vary, naturally. I'm running a 0.J(A) version kernel.
Like all Unix boxes, the PERQ 3 has to be shutdown correctly. As root:
# cd / # shutdown 0 ... wait for INIT: SINGLE USER MODE ... # byeThe BYE command will sync the discs and power the PERQ down automatically. I think this is impressive, but then I'm easily amused.
If the real time clock information is corrupted (if the battery is removed, for example) the PERQ 3 will refuse to boot from the hard drive! Hopefully you have a copy of the stand-alone disk utilities floppy (sadu). You can boot with this and set the clock (to GMT). The PERQ should then boot normally again.
I recently came across the following interesting document... It's a technical description of the innards of the PERQ 3. Unfortunately, it's a little cryptic without schematics...
There is a connector at the back which gives you access to the SCSI bus. Unfortunately PNX doesn't appear to have devices to access new SCSI devices: there is no obvious pattern to the device numbers, so it looks as if they didn't allow for this possibility.
Can anybody think of anything else to add? (Obviously yes, but what else?)
to be continued...