All comments about this FAQ and suggestions for additions or deletions
should be sent to the current maintainer,
Nickolai Zeldovich.

Disclaimer

"This FAQ (and the mentioned files) is presented with no warranties or
guarantees of ANY KIND including correctness or fitness for any particular
purpose. The author(s) of this document have attempted to verify
correctness of the data contained herein; however, slip-ups can and do
happen. If you use this data, you do so at your own risk."

This FAQ is Copyright (C) 1999 by Nickolai Zeldovich and is freely
available as a service to the Internet Community. No part of this
document may be published or sold in any form by any means, including
print, electronic storage, magnetic or optical media, and database,
without the explicit, written permission of Nickolai Zeldovich.

The guide is formatted using nroff. To get an ASCII version of the guide,
replace the "send guide" with "send guide.txt".

When you get an official patch, it includes something like
patch_{m68,a88}k_yymm_notes,
which are descriptions of the patches up to the month mm in year yy.

You'll read something like this:

"These notes describe the software patches for m68k Domain Systems. This
patch kit includes patches released since July, 1992 for SR10.x versions of
the Domain/OS operating system and for SR10-based optional products. When
one of these patches requires installation of another patch released prior
to July, 1992, we also include and document that patch." (from NOTES)

Be careful to note which patches supercede another.

The SSB is the Domain/OS Software Status Bulletin. According to the SSB:

"This Software Status Bulletin (SSB) documents known problems in the
DOMAIN/OS software product line. The SSB is derived from Known Problem
Reports which results from Service Requests (SR) submitted by users of these
products. The SSB is provided as a benefit of Hewlette- Packard's Account
Management Support, Response Center Support, Software Materials
Subscription, and Software Notification Service.

"Not all SRs submitted to HP are listed in the SSB. Ones which involve
problems which cannot be duplicated, requests for enhancements and
misunderstandings about an application or a feature are not listed in the
SSB. When a new software release is made for the product line, all problems
that were corrected in that release are removed from the SSB.

"Please note that all defects fixed in SR10.4 and related releases have
been removed from the SSB and published in the Domain OS Software Release
Bulletin (SRB) available on the SR10.4 media as
/install/doc/apollo/os.v.10.4__release_notes_bulletin

Now HP offers access to their patches at http://us.external.hp.com/
where you can browse and/or download their patches. The instructions for
getting the patches are a bit wrong. While they say they will send you a
wbak image of the file you will need to rbak, they actually send you a
shell script which you need to run in order for it to uncompress itself.

There used to be an archive ftp://ftp.eb.ele.tue.nl and info server at
the Eindhoven University of Technology, maintained by Willem Jan Withagen
(wjw@ebh.eb.ele.tue.nl). This site no longer exists; a large part of the
archive is now available from
ftp://maths.usyd.edu.au/mirror/ftp.eb.ele.tue.nl:pub:apollo/.

Some terminology: A "screen" is like an X window or a DM pad. It's a
view into one or more files that's individually resizable and movable around
your display. On a dumb vt100 you can only have one screen, although you
might have multiple emacs windows. With the DM or X you can have multiple
screens, each with (possibly) multiple windows.

Here are the choices for emacs on Domain/OS, as I see it.

First, if you just want to make the DM look a bit like emacs, there are
keydefs somewhere to do that. I'm not sure where. There is also an elisp
package called x-apollo.el that makes your emacs look more like the DM.

If you want an emacs lookalike that's easier to build and lighter weight
than the real thing, but isn't extensible (doesn't have elisp), look at
jove. It only runs on vt100-like devices, so is single-screen. There is
a version for Domain/OS on archive.umich.edu.

If you want the real thing, you really need gnu emacs or one of its
descendants. The grandfather of these is probably gnu emacs 18. It's been
around a long time and is stable, and will run in a DM pad using gpr, on a
vt100 connected via tty or pty, or in an X window. It is single-screen
only. It is available from the usual gnu ftp sites, but as distributed by
gnu it's configured for sr9.7 and won't dump. If you want to run emacs 18
you should look at the special Apollo version put together by Leonard N.
Zubkoff, available for ftp from lucid.com.

Source patches to build this version (but not executables) are available
from archive.umich.edu.

Gnu emacs 19 runs in multiple X screens (gnu emacs calls them "frames") or
on a tty. I don't think it will run in a DM pad, but I could be wrong; I
think the code is still there to do this. It requires patches to run on
Domain/OS. Some patches are available from archive.umich.edu, but gnu
emacs 19 is a moving target, so check on comp.sys.apollo before trying to
build, and please share your experiences with us. It is available from the
usual gnu ftp sites.

Epoch runs in multiple X screens, and can have a single shared minibuffer or
separate minibuffers attached to each screen. It won't run in a DM pad or
on a tty. It is currently being merged into lemacs (see below) and is no
longer maintained. The last version is 4.2. It requires no patches to run
on Domain/OS and is available by ftp from cs.uiuc.edu.

Lucid emacs (lemacs) runs in multiple X screens. For a description, see the
file ftp://lucid.com/pub/lemacs/README. Lemacs
will not run on a tty. It requires an ANSI C compiler to build and will not run unmodified on
Domain/OS. It may be possible to apply part or all of the epoch or emacs
19 patches (available from archive.umich.edu) to get it to work. If you do
this, please let me know. Lemacs is available by ftp from
lucid.com, cs.uiuc.edu, and
liasun3.epfl.ch.

GDB 4.12 will work on Apollo's with a small patch. This version of GDB
reads Apollo native debugging information, so you do not need to compile
our programs with GCC and GAS to use GDB. GDB is massively faster
in all respects than the Apollo debuggers DDE and DBX. GDB 4.12 has
been tested on SR10.4 under BSD4.3. The patch and instructions on
compiling are available via anonymous FTP from
ftp://ftp.wfu.edu/usenet/apollo/src/gdb4.12-apollo.gz

Versions of GCC, GAS and GDB for Apollo are now available from
ftp://archive.umich.edu, http://pisa.citi.umich.edu, and
gopher://gopher.archive.merit.net:7055/11/apollo in the files gdb+gas.tar.gz
and gcc-2.4.5.tar.gz. These versions support Apollo's native DST
information. GDB is version 4.12 and GAS is version 2.2. gdb+gas will need
to be compiled with a previous version of GCC. You should compile (and
install) gdb+gas before compiling gcc, otherwise gcc will fail in stage 2.
The steps to get going are (roughly):

Unpack the tar.gz files

cd gdb+gas

./configure

make

cp gdb/gdb /usr/local/bin/gdb

cp gas/as.new /usr/local/bin/as

cd ../gcc-2.4.5

./configure m68k-apollo-bsd

run the patch-apollo-includes script (from README.apollo)

make "LANGUAGES = c"

make stage1

make "CC=stage1/xgcc -Bstage1/" "CFLAGS=-g -O"

make stage2

make "CC=stage2/xgcc -Bstage2/" "CFLAGS=-g -O"

make compare (to verify it all went OK)

make install

Note that these versions are not compatible with Chak Kolli's stabs in COFF
patches.

( 7/28/94, Troy Rollo <troy@cbme.unsw.EDU.AU> )

A set of patches for the GNU assembler, C compiler, and debugger are
available by FTP from hoffman.rstnu.bcm.tmc.edu (128.249.31.10)
in /pub/gnu. It is also reachable by WWW at http://hoffman.rstnu.bcm.tmc.edu/
These add some Apollo language extensions to GCC. They have been tested on
a DN4500 running SR10.3.5 using the BSD environment. They use the GNU
"stabs" format debugging records rather than the Apollo format.

[ Jim Rees has voiced concerns that this
distribution format might violate the GNU public license. If you have
updated information on GCC/GDB/GAS for the Apollo, please contact me.
I'm particularly interested in the latest versions supported for the
Apollo as well as its stability/compatibility/etc. -- David K. Ahn ]

I believe large drives are supported from SR10.4.1 only. I do not think you
can get older INVOLs to talk to the drive. Even at SR10.4.1 you may need a
425t, instead of the DN2500, to be able to use them.

My own story: I had a Quantum PD425iS (420MB) in a 425t running 10.4 (and
earlier probably 10.2). I wanted to replace this by a Quantum 2100S
(2100MB), but failed with the same type of error you got until I installed
SR10.4.1. Curiously, /systest/ssr_util/scsi_info reported both disks to be
SCSI-2. Around the same time I also wanted to install a Seagate ST5660N
(540MB, also SCSI-2) into another, previously diskless, 425t, and only
succeeded at SR10.4.1.

Note that between SR10.4 and SR10.4.1, only the sau11 and sau12 versions of
'EX INVOL' (/sau*/invol) have changed; the online version /etc/invol did not
change between SR10.4 and SR10.4.1. I cannot readily check older INVOLs. At
SR10.4.1:

>>>> Anyone have any experience using a Seagate 31200N SCSI drive on an
>>>> Apollo DN2500?
>>> What version of the OS are you running?
>> No, the DN2500 was/is a SCSI based machine. It does not use ESDI drives
>> like the DN{345}xxx series machines. The OS rev is irrelevant (as
>> long as it supports sau9).
> I know the 2500 is SCSI basedd, but that doesn't explain the problme.
> Perhaps the change mode call relies on some support not present in
> earlier release of the OS, perhaps not.

I am sure the OS version is relevant here. I had two disks, a Quantum 2100S
(2GB) and a Seagate ST5660N (540MB), which I had to install into 425t's. I
did not seem to have much luck with them, with almost exactly the symptoms
the original poster described. I also tried to change the disks to SCSI-1
with mts, without luck; anyway, one of the target machines already had a
disk, which /systest/ssr_util/scsi_info claimed to be SCSI-2 (Quantum
PD425iS 420MB, to be replaced by the 2GB disk), so this could not have been
the problem. Another Apollo user said I might need to get upgraded boot
PROMs to support larger disks. But then, I upgraded to SR10.4.1 (from
SR10.4), and everything worked like a charm! (My memory is somewhat vague, I
am not sure if someone suggested to upgrade, or if it was just a temporal
coincidence.)

In summary, it seems to me that large SCSI disk are (better? only?)
supported since SR10.4.1. I would suggest to upgrade to SR10.4.1 and then
try again.

(25/11/96, Paul Szabo <szabo_p@maths.usyd.edu.au> )

I read in the FAQ that you couldn't have both the FLOPPY and the SCSI
Cartridge drive active on the WD7000 controller. This is demonstrably
false for my 3500 which is runing Domain/OS 10.3.5.15, but it also works
in DEX.

... I currently have the 3500 with the WD7000 installed and jumpered
according to the "jumper" program and it reads and writes to the non-scsi
floppy and the SCSI cartridge drive just fine. (I haven't tried both at
the same time, but I don't see why this wouldn't work.)

It is rumoured, that the OEM version lacks audio grabbing functionality,
but at the moment ;-) there is no support for this under DomainOS
anyway.

I decided to buy the 6x speed plextor drive with caddy back in 1996,
because the spec claimes support of High Sierra (HFS) and ISO9660 Format
with Rock Ridge Extension as well as UNIX-compatibility
("512 byte per sector for workstation use" is advertized).

Maybe 512-Byte-Blocks are only neccessairy for native filesystems on
bootable CD-ROMs, which HP didnt offer for Domain/OS - but for HP-UX,
see /install/doc/apollo/os.v.10.4__notes:

<--- snip --->3.6 Changes to HP Series 6100 Model 700/S CD-ROM User's Guide
<--- deleted --->
Table 1-2 shows the minimum Boot ROM revisions required if you
want to boot software from the CD-ROM drive. Hewlett-Packard does
not suport bootable systems on Domain, but certain third parties
or Independant Software Vendors (ISVs) may provide bootable
software on a CD-ROM disc. Use the information in Table 1-2 if
you have a bootable CD-ROM disc from one of these vendors. Note
that the CD-ROM drive can only boot to the systems that are
listed in Table 1-2.
<--- snip --->
Unfortunately I have none of these Manuals to check Table 1-2:

There are some drives with 2048 only and some others with 2048/512 bytes
data block size available - so i recommend to look for the latter ones.

Plextor drives support HP-UX, so if you decide to install HP-UX on 4xx
- but why should you? ;-) - you may be able to boot from those drives.

I am starting the daemons xpager and cdfsd (besides llbd and rpcd)
at boot time at the machine whith the local CD-ROM drive as explained
in the OS release notes /install/doc/apollo/os.v.10.4__notes, see
chapter 1.4.3.1 Changes in CD-ROM Drive Usage at SR10.4
and 1.7.3 External Pager Daemon.

But we run DomainOS - so i enabled node owners protection policy:$ /etc/lprotect -protect owners
and each user or group member with w-rights on
`node_data/etc/node_owners
(trust the user) can mount and unmount CDs - and the CD-filesystem is
available through DDS as well as via NFS for non-Domain boxes.
(try this with UNIX - on HP-UX i'm still wrestling with this RPC-based
pfsd/pfs_mountd-stuff, remember patches PHCO_12652 and PHCO_15453 %-|)

Use the /etc/cdmntsuppl to set/get rights and ISO9660's RockRidge
name conversion - UNIX-like is -l for upper-2-lowercase-conversion
and removal of trailing dots without extensions and -m to suppress
name;# version numbers.

If you are brave enough to code, read /usr/apollo/man/mana/cd_?*.a,
than inlcude /apollo/include/cdrom.h and link against
/$(SYSTYPE)/usr/lib/isp_m68k/libcdrom.a

Dan <root@juno106.demon.co.uk> reports that he got the circuit from
monitor-sync.ps
to work with his HP/Sony 98754A HiRes monitor. He says:

I built the circuit detailed and discovered after a lot of messing
around that there is an error on the diagram!! The pinout on
the 74LS02 is incorrect. Pins 2 and 3 are the NOR gate inputs
and pin 1 is the output!

I used a 10K preset for the bias control.

Make sure you remember to connect pin 7 to ground on both chips
and pin 14 to a clean 5 volt rail.

Having built the circuit make sure your PC is running in 1280 by
1024 with a NON INTERLACED frame rate of 60Hz. These monitors
are very good quality - an equivalent would cost you a heck of a
lot of money even thesedays but sadly the frame rate is just a
little too low for a totally flicker free picture :-( - but still
its very good!

[ Maintainer's note: Another solution is to buy a fixed frequency video
card, sold by a number of vendors, such as Software Integrators, Inc.,
or Mirage (see section 7.1). ]

Are there any uses for anything else from an Apollo?

The Case/Power supply can be adapted to hold a PC in a relatively easy
fashion.... If you have a desoldering machine; you may find a use for the
memory chips on the cards... If you had a Disk then it could be potentially
useful (either MFM or ESDI depending on the disk). The disk controllers are
not useful... The ethernet cards are simply 3c505's with an Apollo boot prom
which can be removed... The token ring cards are useless for non-apollo work
as far as I can tell...

( 2/15/94, Herb Peyerl <hpeyerl@novatel.cuc.ab.ca> )

The 98751A is a Lo-res color, 1024 x 768, 47.7khz/60Hz. These monitors are
fixed frequency, 47.7khz~50.5khz. I don't know of any PC brand graphics
cards that support these monitors.

( 3/25/94, Steven Gaudet <sjg@world.std.com> )

I have a 98751A HP/Apollo monitor and it works well in Windows using a card
called "PCI-48". It's got the TSENG ET4000 chip set on it. I bought it
with the monitor from Data Station.
My understanding it that it was custom built card to drive this fixed
frequency montior.

( 1/14/97, Jim Kownacki <kanak@telerama.lm.com> )

I don't know much about VGA, but I thought that you just selected a pixel
clock from some small set of available clocks that usually run from 28 MHz
on up to 85 or so, then you could set the length of scan lines and sync
pulses to any number of pixel clocks. That would imply that you can use any
monitor at all, within limits, as long as you know the timings it will sync
to. Exact timings are available in the monitor-info file in the apollo archives
at archive.umich.edu. The 1024x800 color monitor has a horizontal display
interval of about 15 usec, so that means a pixel clock around 70 MHz.

You would have to combine the sync somehow, since the Apollo monitors want
it composite with video on the green channel, and VGA supplies it
separately, but that should be easy to do with a few diodes and maybe a
transistor or two.

( 3/25/94, Jim Rees <Jim.Rees@umich.edu> )

I still have not succeeeded in finding a card supported by XFree86 that will
work with the Apollo 1280x1024 color monitors, but I did get some
information recently that might be of assistance to people (hopefully the
next version of XFree86 will be usable).

The 1280x1024x8 graphics card can be used in a PC with Windows 3.1.

Specifically, the Apollo card is a special version of the Matrox PG-1281
called the PG-1281/AP. I called Matrox and one of the technical folks
there told me that the standard PG-1281 Windows 3.1 drivers should work,
but it would need a special parameter file with the video parameters.
He created the files for me, and this morning I was able to get the card
and monitor running in a PC. I wouldn't say the card is particulary fast,
but it definitely does work as a second monitor for Windows on a PC that
has a monochrome display. If anyone else wants to do this, I'm sure I can
pass along the information and code, since the drivers were available for
public download.

( 7/28/94, Leonard N. Zubkoff <lnz@dandelion.com> )

[ Maintainer's note: The drivers are available by anonymous FTP from
ftp://archive.umich.edu under the file 'pg1281ap.zip' ]

> I'm attempting to run an Apollo color 1280x1024 monitor off my PC using
> XFree. I've got the hardware connection fairly stable, but am having
> problems with setting up an XFree video mode.

This monitor is a Matsushita J2P36X. To drive it at 1280x1024 you'll need
a dot clock of 125 MHz. If your VGA card won't do this, you may have to
tear into the monitor's sweep circuitry, since it's not a multi-sync design.

Here are the timing numbers you'll need for your Xconfig file. If you get
this to work, please send me your Xconfig.

There are actually two versions of this monitor, one with a 68Hz vertical
refresh rate and the other with 70Hz. Here are Xconfig mode lines for both
of them (these have been tested with my STB Pegasus VL):

I bought a 3C505 board from 3Com instead of Apollo because I'm not
interested in doing diskless booting over the ethernet. I know it's missing
a prom for doing that. I've set the jumpers as described in the
/systest/ssr_util/jumpers program with no luck.

Correct, however all the original poster said was that self tests couldn't
find the board. I'm assuming that he's referring to the self tests that
run when powering up in normal mode (or when the appropriate prom command
is it "te" ?) is entered. If this is the ONLY time the board can't be
found, it's because of the lack of the boot prom (self test code is stored
in there). Run "ex config" and remove it's knowledge of the ethernet board
so it won't try to test it. The OS should find it ok (and nothing was said
in the original mail about whether the OS could or could not find it, I
assume that it could (it should!) ).

( 2/15/94, Carl Heinzl <carl@Cayman.COM> )

We [MV Technical Sales] sell the
ethernet adapter for the Apollo DNXXXX series machines with the proper
boot prom and everything. I'm the one that bought stock 3C505 cards and
dup'd the PROM off an existing card and programmed it onto a new prom
for the stock cards. They work great.