From mxs46 at k2.scl.cwru.edu  Tue Dec  1 11:02:02 1998
From: mxs46 at k2.scl.cwru.edu (Michael Sokolov)
Date: Mon, 30 Nov 1998 20:02:02 -0500
Subject: System Industries MSCP disk controller problem
Message-ID: <199812010102.UAA21295@skybridge.scl.cwru.edu>

   Dear Ladies and Gentlemen,
   
   I wonder, is anyone here familiar with System Industries (SI) Q-bus MSCP
controllers for ESDI disks? The VAX I'm working has one. It's quad-height
board with connectors for 4 ESDI drives. I couldn't find a model number or
anything like that, but there is a sticker on one of the chips that says
"SYS IND" on it (that's how I deduced that it's SI). The problem I'm having
is that I have no idea how to configure it. It has two DIP switch packs,
one with 4 switches and one with 10. Originally it was configured to be the
secondary disk MSCP controller at 160334. I want it to be the primary one
at 172150. I tried every reasonable switch combination I could think of,
but no luck.
   
   What's even worse is that I can't leave it as secondary either. For some
reason its configuration makes the CPU (KA650) unhappy. When I pull it out,
the CPU passes all power-up tests beautifully. When I put it in, I still
get to the ">>>" prompt eventually, but first I get a load of error
messages from the self-tests. Then when I try to boot from DUB0, it tells
me "DEVASSIGN", suggesting that it doesn't recognize the second disk MSCP
controller at all. All docs I have suggest that 160334 is the correct
address for secondary disk MSCP. It's in the floating address range,
though, so I suspected that it's the side effect of adding or removing
other cards. I tried making the configuration as close to the original as I
could. No luck still. The only card I had to pull out is the secondary
TMSCP (Emulex QT13 9-track tape controller), because it appears totally
toast (the CPU refuses to power up with that infamous 9 when this card is
present). But then secondary TMSCP should be AFTER secondary disk MSCP in
the floating address space, right? I tried some more investigation and by
pure accident I discovered that the SI controller also responds somehow to
160400. What the hell is that address for? Could this be what makes the CPU
unhappy?
   
   Does anyone have any clues? Is anyone here familiar with SI MSCP disk
controllers? TIA for any help.
   
   Sincerely,
   Michael Sokolov
   Cellular phone: 216-217-2579
   ARPA Internet SMTP mail: mxs46 at k2.scl.cwru.edu

Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id OAA12137
	for pups-liszt; Tue, 1 Dec 1998 14:27:04 +1100 (EST)

From SHOPPA at trailing-edge.com  Tue Dec  1 13:24:21 1998
From: SHOPPA at trailing-edge.com (Tim Shoppa)
Date: Mon, 30 Nov 1998 22:24:21 -0500
Subject: System Industries MSCP disk controller problem
Message-ID: <981130222421.2de00129@trailing-edge.com>

>   I wonder, is anyone here familiar with System Industries (SI) Q-bus MSCP
>controllers for ESDI disks? The VAX I'm working has one. It's quad-height
>board with connectors for 4 ESDI drives. I couldn't find a model number or
>anything like that, but there is a sticker on one of the chips that says
>"SYS IND" on it (that's how I deduced that it's SI). The problem I'm having
>is that I have no idea how to configure it. It has two DIP switch packs,
>one with 4 switches and one with 10. Originally it was configured to be the
>secondary disk MSCP controller at 160334. I want it to be the primary one
>at 172150. I tried every reasonable switch combination I could think of,
>but no luck.

This sounds a lot like the Webster WQESD, which was repackaged
and sold by many different folks (Sigma, DSD, Qualogy, American
Digital, etc.)

If it is a repackaged WQESD, SW9 on the 10-switch pack was originally
on, with SW10 and SW5-8 off, to put the CSR at 160334.  
To set it to be 172150, you put SW10 on, and SW5-9 off.

Then again, it might not be a repackaged WQESD, but instead a Dilog
or Emulex.

Is there a 10-pin header on the card edge?  Can you describe the positions
and types of "big chips" on the board?
   
>pure accident I discovered that the SI controller also responds somehow to
>160400. What the hell is that address for? Could this be what makes the CPU
>unhappy?

It might be because you've enabled the on-board PDP-11 bootstrap,
a very big no-no when used in a Microax system.  (This
bootstrap effectively tries to jam code by DMA into main memory,
and can wreak all sorts of havoc on a Microvax.)  Some
other switches also set the interrupt priority, and this being
off can also confuse some tests and OS's.

As to your power-on self-test woes, you're going to have to tell
us what's in the system and what slot it lives in, as well as what
sort of backplane it's all in.

Incidentally, I happen to use a Webster WQESD in my 4.3BSD-Reno
machine, and am very happy with it there.

-- 
 Tim Shoppa                        Email: shoppa at trailing-edge.com
 Trailing Edge Technology          WWW:   http://www.trailing-edge.com/
 7328 Bradley Blvd		   Voice: 301-767-5917
 Bethesda, MD, USA 20817           Fax:   301-767-5927


From wkt at henry.cs.adfa.oz.au  Thu Dec  3 09:18:43 1998
From: wkt at henry.cs.adfa.oz.au (Warren Toomey)
Date: Thu, 3 Dec 1998 10:18:43 +1100 (EST)
Subject: New Apout PDP-11 simulator
Message-ID: <199812022318.KAA27852@henry.cs.adfa.oz.au>

All,
	I've just spent the week tidying up my Apout program. This runs
PDP-11 user-mode programs (specifically 7th Edition binaries), and
translates V7 syscalls to native syscalls.

I've tidied the program up and optimised it a bit too. Over the summer
break (it's summer down here) I want to add floating-point and start
work on emulating 2.11BSD user-mode binaries.

The program runs on FreeBSD 2.2.x and 3.0 systems: porting to other 32-bit
little-endian Unix systems should be relatively easy. Porting to big-endian
systems might be harder :-) I'll have a look at that too.

Anyway, an alpha of the new 2.2 version is at:
	ftp://minnie.cs.adfa.edu.au/pub/PDP-11/Sims/Apout

Cheers,
	Warren

Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id PAA24007
	for pups-liszt; Thu, 3 Dec 1998 15:51:17 +1100 (EST)

From msokolov at harrier.Uznet.NET  Thu Dec  3 14:48:30 1998
From: msokolov at harrier.Uznet.NET (Michael Sokolov)
Date: 3 Dec 1998   04:48:30 GMT
Subject: System Industries MSCP disk controller problem
Message-ID: <199812030448.JAA06898@harrier.Uznet.NET>

   Tim Shoppa <SHOPPA at trailing-edge.com> wrote:
> This sounds a lot like the Webster WQESD, which was repackaged
> and sold by many different folks (Sigma, DSD, Qualogy, American
> Digital, etc.)
   
   Quite possible, since this funny Xerox system has a lot of Sigma
components. The outer box in which the BA23 is mounted is made by Sigma,
the funny way the ESDI drives are mechanically mounted is clearly a Sigma
invention, the card connecting the BA23 backplane to the expansion
backplane in the outer Sigma box is made by Sigma, and so is another
totally unmarked card of unknown purpose (its presence or absence appears
to have absolutely no effect on anything). The system is not 100% Sigma,
though. There also another 2-drive ESDI controller (that's the one that was
at 172150 from the beginning) and a 9-track tape controller, both made by
Emulex (QD21 and QT13, respectively) and both appear toast (I want to get
rid of both).
   
> If it is a repackaged WQESD, SW9 on the 10-switch pack was originally
> on, with SW10 and SW5-8 off, to put the CSR at 160334.
> To set it to be 172150, you put SW10 on, and SW5-9 off.
   
   Before I got your E-mail, SW5 and SW8 were ON and the rest were OFF
(don't remember if it was the original position). I also tried SW10 ON and
the rest OFF. In both cases the effect is exactly the same. At power-up the
CPU screams, but then gives the ">>>" prompt. Trying to read different
locations with the E/P/W command (the Q-bus I/O page is mapped at
0x20000000 in the VAX address space), I see that the card responds somehow
to 160334 and to 160400, but not to 172150. (I know that it's this card and
not something else, since when I pull it out the CPU is happy and no one
responds to these addresses.)
   
> Then again, it might not be a repackaged WQESD, but instead a Dilog
> or Emulex.
   
   I'm 99% sure that it's neither Dilog nor Emulex. I have seen quite a few
Dilog and Emulex cards, and I think I should be able to detect them easily.
   
> Is there a 10-pin header on the card edge?  Can you describe the
> positions and types of "big chips" on the board?
   
   This is a quad-height board. All components are thru-hole and all chips
are in DIP packages. There are no 4-sided chips or surface-mounted
components. Hold it with the component side up, the fingers to the right
and the handles to the left. On the left (handle) side there is a row of
shrouded header connectors. From top to bottom, they are: 10-pin (connected
to something, but purpose unknown), 34-pin (ESDI control and status), 20-
pin (drive 0 data), 20-pin (drive 1 data), 20-pin (drive 2 data). Directly
behind the bottom 20-pin header there is another 20-pin header for drive 3
data. The biggest chip is a 48-pin DIP labeled DP8466AN (National
Semiconductor as far as I can tell), and it's right behind the drive 3 data
connector. There are two AM2901CPCs behind the 34-pin connector. There is
one 28-pin EPROM right about in the center, shifted downward a little. The
ROM size is obscured by the sticker saying "ESDI V2.41 9901-8918 REV.A".
There is a stack of narrow 24-pin DIP chips going from the top of the board
to right above the EPROM. All have stickers, suggesting that they are
programmable. The stickers have different 6-character codes on them, all
starting with "1583". Directly to the right from the last one there is one
more such chip labeled "SYS IND 1583W3".
   
   Actually, I was wrong about there being 2 switch packs. There are 3 of
them, one of 10 and two of 4. The 10-switch one is right above the chip
labeled "SYS IND 1583W3". In the top right corner (right next to row A
fingers) there is a 4-switch pack. All switches are ON. Directly behind it
there is a 16-pin DIP chip labeled "1583I1" (the only chip with a sticker
not mentioned before). At the top of the board directly to the left from
the 10-chip stack there is a 10 MHz oscillator, the only clock on the
board. Directly to the left from it there is the last 4-switch pack. All
switches are ON. Finally, there are 3 LEDs between the top handle and the
10-pin header. The top one is red and the other two are green.
   
> Some
> other switches also set the interrupt priority, and this being
> off can also confuse some tests and OS's.
   
   What's the correct priority for disk MSCP? Should it be different
between primary and secondary?
   
> As to your power-on self-test woes, you're going to have to tell
> us what's in the system and what slot it lives in, as well as what
> sort of backplane it's all in.
   
   The outer box is Sigma. It provides funny mounting for 4 ESDI drives, an
expansion Q-bus backplane, and a big bay for a BA23. The BA23 contains the
CPU, the memory, and all peripherals except the controller in question.
First comes the KA650 CPU. Then two MS650 memory modules. Then DELQA,
DZQ11, TQK50, and the Sigma Q-bus extender card. The latter takes the Q-bus
into the expansion backplane, where the controller in question is the only
device. It's in the expansion backplane instead of the BA23 because that's
where the actual drives are. I have tried pulling the Sigma Q-bus extender
card out and putting the ESDI controller right in the BA23 backplane, but
this didn't change anything, so there is nothing wrong with the Q-bus
expansion.
   
   You know what, I just looked a little closer and noticed that in this
configuration (both 4-switch packs all ON, SW1-9 on the 10-switch pack OFF,
and SW10 ON) the controller responds not only to 160334 and 160400, but to
just about any address in the Q-bus I/O page (except 172150)! No wonder the
CPU screams about it! What the hell is going on? How can it possibly do
this? Is someone trying to port Plug-n-Pray to Q-bus? Is it something like
KFQSA with a separate address for each drive and everything soft-
configured?
   
   Sincerely,
   Michael Sokolov
   Cellular phone: 216-217-2579
   ARPA Internet SMTP mail: msokolov at harrier.Uznet.NET


Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id BAA25817
	for pups-liszt; Fri, 4 Dec 1998 01:27:17 +1100 (EST)

From SHOPPA at trailing-edge.com  Fri Dec  4 00:25:04 1998
From: SHOPPA at trailing-edge.com (Tim Shoppa)
Date: Thu, 3 Dec 1998 9:25:04 -0500
Subject: System Industries MSCP disk controller problem
Message-ID: <981203092504.2de002c1@trailing-edge.com>

>> This sounds a lot like the Webster WQESD, which was repackaged
>> and sold by many different folks (Sigma, DSD, Qualogy, American
>> Digital, etc.)
>   Quite possible, since this funny Xerox system has a lot of Sigma
>components.

I regularly work with "PDP-11 systems" now that don't have a single
DEC component in them.  CPU by Mentec ( http://www.mentec.com/ ), 
disk controller by Andromeda ( http://www.andromedasystems.com/ ),
async and parallel I/O by the Logical Company ( http://www.logical-co.com ),
etc.  What else are commercial developers left to do now that
DEC (after over a decade of trying to) has finally abandoned their
PDP-11 product line?  At least the other companies named are still
doing active support and (at least in Mentec's case) development!

> The outer box in which the BA23 is mounted is made by Sigma,
>...
>though. There also another 2-drive ESDI controller (that's the one that was
>at 172150 from the beginning) and a 9-track tape controller, both made by
>Emulex (QD21 and QT13, respectively) and both appear toast (I want to get
>rid of both).

You might be a bit hasty in casting these off, as you aren't having
the best of luck with the rest of the peripherals, either!
   
>> If it is a repackaged WQESD, SW9 on the 10-switch pack was originally
>> on, with SW10 and SW5-8 off, to put the CSR at 160334.
>> To set it to be 172150, you put SW10 on, and SW5-9 off.
>   Before I got your E-mail, SW5 and SW8 were ON and the rest were OFF
>(don't remember if it was the original position). I also tried SW10 ON and
>the rest OFF. In both cases the effect is exactly the same. At power-up the
>CPU screams, but then gives the ">>>" prompt. Trying to read different
>locations with the E/P/W command (the Q-bus I/O page is mapped at
>0x20000000 in the VAX address space), I see that the card responds somehow
>to 160334 and to 160400, but not to 172150. (I know that it's this card and
>not something else, since when I pull it out the CPU is happy and no one
>responds to these addresses.)
>> Is there a 10-pin header on the card edge?  Can you describe the
>> positions and types of "big chips" on the board?
>   This is a quad-height board. All components are thru-hole and all chips
>are in DIP packages. There are no 4-sided chips or surface-mounted
>components. Hold it with the component side up, the fingers to the right
>and the handles to the left. On the left (handle) side there is a row of
>shrouded header connectors. From top to bottom, they are: 10-pin (connected
>to something, but purpose unknown), 34-pin (ESDI control and status), 20-
>pin (drive 0 data), 20-pin (drive 1 data), 20-pin (drive 2 data). Directly
>behind the bottom 20-pin header there is another 20-pin header for drive 3
>data. The biggest chip is a 48-pin DIP labeled DP8466AN (National
>Semiconductor as far as I can tell), and it's right behind the drive 3 data
>connector. There are two AM2901CPCs behind the 34-pin connector. There is
>one 28-pin EPROM right about in the center, shifted downward a little. The
>ROM size is obscured by the sticker saying "ESDI V2.41 9901-8918 REV.A".

That clinches it - it's a Webster WQESD, running Wombat V2.41.

9901-8918 is evidently the SI part number for the complete system.
It's a bit confusing to go from the SI part number because they all
begin with "9900" or "9901"!
   
>   What's the correct priority for disk MSCP? Should it be different
>between primary and secondary?

A summary of the WQESD switch settings, and the various ways in which
you can invoke Wombat, lives at:

 ftp://sunsite.unc.edu/pub/academic/computer-science/history/pdp-11/hardware

as the file "WQESD.txt".
   
>> As to your power-on self-test woes, you're going to have to tell
>> us what's in the system and what slot it lives in, as well as what
>> sort of backplane it's all in.
   
>   The outer box is Sigma. It provides funny mounting for 4 ESDI drives, an
>expansion Q-bus backplane, and a big bay for a BA23. The BA23 contains the
>CPU, the memory, and all peripherals except the controller in question.
>First comes the KA650 CPU. Then two MS650 memory modules. Then DELQA,
>DZQ11, TQK50, and the Sigma Q-bus extender card. The latter takes the Q-bus
>into the expansion backplane, where the controller in question is the only
>device. It's in the expansion backplane instead of the BA23 because that's
>where the actual drives are. I have tried pulling the Sigma Q-bus extender
>card out and putting the ESDI controller right in the BA23 backplane, but
>this didn't change anything, so there is nothing wrong with the Q-bus
>expansion.

I'm willing to bet that you have severe Q-bus continuity problems,
especially now that you've told us that you have an expansion Q-bus
cabinet and that you've been randomly moving Q-bus cards around.
You have to tell us exactly which slot each card is in, and preferably
the original configuration as well (the Sigma backplanes have different
wirings than the common DEC ones.)

Is the "BA23" indeed a real DEC BA23, and not the Sigma "clone"?
The sigma 5.25" 9-slot backplanes have very different backplane
wirings (and, indeed, putting a DEC dual-wide Microvax CPU into
it will very likely cause damage.)

As a start, work just with the BA23.  Put the CPU in slot 1, with
the two memory boards in slots 2 and 3.  Put the WQESD in slot 4.
Have nothing else plugged in at all - especially not the boards
that jumper the two backplanes together.

Set the DIPswitches on the WQESD as follows:
10-switch pack: Switches 1-2 off, 3 on, 4-9 off, 10 on.
4-switch pack near the edge connector: 1-3 on, 4 off.
4-switch pack near the handles: 1-4 on.

Then try to start up wombat with the following sequence of console commands:

Microvax II:
Halt the processor
U
I
D/P/W 20001F40  20
D/L 20088008 80000002
D/W 20001468 AC
S 400

If this doesn't start Wombat, tell us *exactly* what the error message
produced is.

--    
 Tim Shoppa                        Email: shoppa at trailing-edge.com
 Trailing Edge Technology          WWW:   http://www.trailing-edge.com/
 7328 Bradley Blvd		   Voice: 301-767-5917
 Bethesda, MD, USA 20817           Fax:   301-767-5927


From msokolov at harrier.Uznet.NET  Fri Dec  4 06:08:37 1998
From: msokolov at harrier.Uznet.NET (Michael Sokolov)
Date: 3 Dec 1998   20:08:37 GMT
Subject: System Industries MSCP disk controller problem
Message-ID: <199812032008.BAA08080@harrier.Uznet.NET>

   Dear Tim,
   
   I have just tried configuring the board as you have suggested and it
works! Thanks! You have saved the Project!
   
   When I tried starting WOMBAT, it also worked. However, there are tons of
configuration parameters you can set there. All 4 disks connected to this
controller are already configured and formatted, so for now I'd just leave
it alone and install Ultrix on these disks as they are. For the future,
however, I would really appreciate being able to configure all that stuff.
Do you have a full manual for this controller? Would you mind sending me a
xerox copy?
   
> What else are commercial developers left to do now that
> DEC (after over a decade of trying to) has finally abandoned their
> PDP-11 product line?
   
   What about VAXen? Can you still call 1-800-DIGITAL with a _BIG_ credit
card in hand and order a VAX?
   
> You might be a bit hasty in casting these off, as you aren't having
> the best of luck with the rest of the peripherals, either!
   
   Well, now that the WQESD works and while I'm waiting for the TQK50 (one
very friendly PUPS member is providing me with a working one), I can turn
my attention to these two. Let's start with the 2-drive ESDI one. The
Emulex logo and copyright appear in a lot of places, so there is no problem
with identification. The board is labeled "ASSY QD2110402 REV G", and just
like every other Emulex board I have ever seen, it has a 40-pin chip with
an Emulex SUB-ASSY sticker. In this case it's "QD2110202-00G". Do you know
anything about this board? It has two switch packs, one of 4 and one of 8.
What are the switch settings?
   
   Now let's turn to the 9-track tape controller. Again there is no problem
with identification (straight Emulex). The board is labeled "ASSY
QT1310401-00 REV E" and the 40-pin chip is labeled "QT1310201-02 REV K".
Again it has one 4-switch pack and one 8-switch pack. There is something
seriously wrong with this board, since when it's present in the backplane
the CPU refuses to power up. It stalls at that infamous 9 very early in the
power-up sequence, before any console tests or displays, suggesting that
something is HORRIBLY wrong with Q-bus (maybe a short or something?).
   
   And while we are at it, I have a question about 9-track tape transports
and controllers in general. I often hear about something called Pertec.
What is it? Is it some kind of standard interface that nearly all tape
transports use? It is what this QT13 controller is for? (It has 2 50-lead
connectors.) I remember at CWRU there was a very neat-looking tape
transport called Cipher. It looked EXACTLY like DEC TS05, suggesting that
it's what the TS05 really is. That one also had a two-50-lead-cables
interface as far as I could tell (it was disconnected). It also appeared to
be dual-ported. Does this mean that DEC also used this Pertec interface?
Then why are there different DEC controllers for different DEC 9-track tape
transports (TSV05 for TS05, KLESI for TU81+, etc.)? If they were all Pertec
one controller would fit all, wouldn't it? Or is that some DEC 9-track tape
hardware uses Pertec and other DEC hardware doesn't?
   
   Moving on to the next and last unidentified flying board. This one is a
total mystery. The board is labeled "SIGMA INFORMATION SYSTEMS, INC." and
"ASSY NO 400135 REV A". There are NO microprocessors, ROMs, or any other
LSI chips on the board, only SSI/MSI chips, resistors, and capacitors. It's
a dual-height board. It has 3 8-switch packs. There is one 40-lead shrouded
header connector on the board, and a straight 40-lead ribbon cable connects
it to a bulkhead which has a female 37-lead D-sub connector on the outside.
Any ideas on what in the world is this?
   
> I'm willing to bet that you have severe Q-bus continuity problems,
> especially now that you've told us that you have an expansion Q-bus
> cabinet and that you've been randomly moving Q-bus cards around.
   
   I am perfectly aware of the fact that Q-bus requires grant continuity
and, no, I was NOT moving cards around "randomly". I have them in the order
DEC recommends in all of its manuals. There is no problem with the
expansion backplane either, the WQESD is quite happy sitting there right
now.
   
> Is the "BA23" indeed a real DEC BA23, and not the Sigma "clone"?
   
   A real DEC one, of course. While I have never been a DEC engineer or
anything like that, I have certainly seen and used enough BA23s to tell one
from a third-party box.
   
   The expansion backplane is Sigma, though.
   
> The sigma 5.25" 9-slot backplanes have very different backplane
> wirings (and, indeed, putting a DEC dual-wide Microvax CPU into
> it will very likely cause damage.)
   
   Yes, I know. The yellow sticker on the expansion backplane says:
"CAUTION! Do not install MicroVAX or KDJ11-B series CPUs into this
backplane."
   
   Sincerely,
   Michael Sokolov
   Cellular phone: 216-217-2579
   ARPA Internet SMTP mail: msokolov at harrier.Uznet.NET


Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id IAA27264
	for pups-liszt; Fri, 4 Dec 1998 08:36:51 +1100 (EST)

From djenner at halcyon.com  Fri Dec  4 07:35:51 1998
From: djenner at halcyon.com (David C. Jenner)
Date: Thu, 03 Dec 1998 13:35:51 -0800
Subject: System Industries MSCP disk controller problem
References: <199812032008.BAA08080@harrier.Uznet.NET>
Message-ID: <36670437.966A4527@halcyon.com>

> > The sigma 5.25" 9-slot backplanes have very different backplane
> > wirings (and, indeed, putting a DEC dual-wide Microvax CPU into
> > it will very likely cause damage.)
> 
>    Yes, I know. The yellow sticker on the expansion backplane says:
> "CAUTION! Do not install MicroVAX or KDJ11-B series CPUs into this
> backplane."

I have a box with one of these.  I noticed the bussing appeared to
be non-standard, but exactly what is the problem here?

I also have a couple of Netcom HV1148 backplanes that
appear to be non-standard.  Any experience with these?

What can you do with these backplane?  What sort of Q-Bus system
can you use them in?

Thanks,
Dave

Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id MAA28393
	for pups-liszt; Fri, 4 Dec 1998 12:45:17 +1100 (EST)

From msokolov at harrier.Uznet.NET  Fri Dec  4 11:44:38 1998
From: msokolov at harrier.Uznet.NET (Michael Sokolov)
Date: 4 Dec 1998   01:44:38 GMT
Subject: Emulex QT13 and related questions
Message-ID: <199812040144.GAA08380@harrier.Uznet.NET>

   Dear Tim and other Q-bus gurus,
   
   Emanuel Stiebler has pointed me to a message posted to vmsnet.pdp11 by
Tim a while ago, and there I have found the info on Emulex QT13. Thanks!
   
   Since none of my two non-working TQK50s is currently installed, I have
tried configuring the QT13 as the primary TMSCP controller and plugging it
in. Guess what, this time it powered up without that ugly 9! Nice! I
probably won't do much with it, though, since although I do have a 9-track
tape transport here in my apartment, I want to leave it alone for now. It's
enormous, by far the biggest piece of equipment here, and I don't feel like
playing with it now. Some time later maybe.
   
   This exercise does raise a few questions, though. Suppose some time
later I decided to use this beast. Suppose I wanted to make this QT13 a
secondary TMSCP controller. This and other very similar exercises require
knowing the rules for floating CSR and vector assignments. What can I find
the complete rules for this? My ancient UNIBUS DZ11 manual only lists the
earliest floating devices, no MSCP or DHUs or anything like that. I once
had some MicroVAX manual that included a table for "common configurations",
but I don't have it any more, plus I'm really looking for the complete
rules and not just "common configurations". Any ideas? Of course if I had a
KA655 or a KA660 I would just type "CONFIGURE" at the ">>>" prompt, but I
only have a plain 650 which doesn't have this luxury.
   
   Also looking at the configuration of this QT13 board, I noticed that it
was originally configured for trailing edge strobe. Tim's notes indicate
that this is for Kennedy 9300 only and that the rest should use leading
edge strobe. The tape transport I have here is labeled as CDC KEYSTONE. Is
this another name for Kennedy 9300 or a different beast? Does anyone know
anything about this transport?
   
   Sincerely,
   Michael Sokolov
   Cellular phone: 216-217-2579
   ARPA Internet SMTP mail: msokolov at harrier.Uznet.NET


Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id NAA28457
	for pups-liszt; Fri, 4 Dec 1998 13:14:10 +1100 (EST)

From msokolov at harrier.Uznet.NET  Fri Dec  4 12:13:33 1998
From: msokolov at harrier.Uznet.NET (Michael Sokolov)
Date: 4 Dec 1998   02:13:33 GMT
Subject: System Industries MSCP disk controller problem
Message-ID: <199812040213.HAA08416@harrier.Uznet.NET>

   David C. Jenner <djenner at halcyon.com> wrote:
> I have a box with one of these.  I noticed the bussing appeared to
> be non-standard, but exactly what is the problem here?
   
   I don't think it's non-standard. It's probably just a different
standard. Strictly speaking, there is no such thing as a Q-bus backplane.
There are Q/Q, Q/CD, and other types of Q-bus'ish backplanes. Generally,
you call something a "Q-bus backplane" if it has Q-bus in rows A and B.
Rows C and D may be used for lots of different things. In theory you can
have these rows used for something REALLY weird. Allison J. Parent tells me
that once upon a time you could get a special version of BA11 where rows C
and D were customer-wired, i.e., you could have absolutely anything you
want in there.
   
   In practice, however, there are only two types of row C&D wiring. On
some backplanes you have Q-bus in both A&B and C&D, with the grant
continuity going in a serpentine. Some BA11 versions are like this. Such
backplanes are called Q/Q. On other backplanes Q-bus goes straight down the
A&B rows without ever touching rows C and D. In these backplanes rows C&D
are connected in a daisy chain, i.e., the fingers on the solder side of the
board in slot 1 connect to the fingers on the component side of the board
in slot 2, the fingers on the solder side of the board in slot 2 connect to
the fingers on the component side of the board in slot 3, and so on. This
way immediately adjacent boards can use rows C&D as a totally private
interconnect that has zero effect on or relationship with anything else in
the system, just like an over-the-top cable. The best example of this is
RLV11, although the most common example is MicroVAX II and III memory. Such
backplanes are usually called Q/CD, and the examples are some versions of
BA11 and all BA2xx and BA4xx backplanes.
   
   Finally, there are mixed backplanes that have several Q/CD slots
followed by many Q/Q slots. These are specifically designed for MicroVAXen
and other CPUs using rows C&D as a private memory interconnect. These
backplanes are BA23 (3 Q/CD slots and 5 Q/Q slots) and BA123 (4 Q/CD slots
and 8 Q/Q slots).
   
   Getting back to the Sigma backplanes, the inability to put a MicroVAX
CPU in there suggests that they are Q/Q.
   
   Sincerely,
   Michael Sokolov
   Cellular phone: 216-217-2579
   ARPA Internet SMTP mail: msokolov at harrier.Uznet.NET


Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id QAA29379
	for pups-liszt; Fri, 4 Dec 1998 16:19:44 +1100 (EST)

From wkt at henry.cs.adfa.oz.au  Fri Dec  4 15:21:40 1998
From: wkt at henry.cs.adfa.oz.au (Warren Toomey)
Date: Fri, 4 Dec 1998 16:21:40 +1100 (EST)
Subject: New Apout PDP-11 simulator
In-Reply-To: <19981204154443.E38307@freebie.lemis.com> from Greg Lehey at "Dec 4, 98 03:44:43 pm"
Message-ID: <199812040521.QAA03261@henry.cs.adfa.oz.au>

[greg] Looks good.  When are you going to add support for 2.11BSD? :-)

[warren] I've just started. Emulating all 150+ syscalls is going to take a
   while. I'll try to modify the V7 syscall support for 2.11BSD; that should
   get  most simple programs working. After that, one syscall at a time....
 
[greg] Hmm.  I suppose the networking will cause you the most headaches
       (maybe...  maybe, of course, you can pass them through to FreeBSD
       almost unchanged).  Most of the things I use the PDP 11 for are
       networking (letting people dial in, etc), but I'll certainly try
       things out as soon as you think it would be worthwhile.

I'm thinking sometime early next year for an initial release with
just the `V7' syscalls in the 2.11BSD emulation. As you said, many of
the syscalls will be a pass-thru, with just args and return values to
be mapped.

I'll let the list know as I go...

	Warren

Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id VAA00320
	for pups-liszt; Fri, 4 Dec 1998 21:32:38 +1100 (EST)

From msokolov at harrier.Uznet.NET  Fri Dec  4 20:31:01 1998
From: msokolov at harrier.Uznet.NET (Michael Sokolov)
Date: 4 Dec 1998   10:31:01 GMT
Subject: Some nice progress with hardware and Ultrix in the PUPS archive
Message-ID: <199812041031.PAA09422@harrier.Uznet.NET>

   Dear Ladies and Gentlemen,
   
   Emanuel Stiebler has graciously provided me with a reference to a freely
downloadable copy of the Emulex QD21 manual. Using that manual, I have got
mine configured correctly and ran firmware diagnostics on it. It looks like
the Emulex card is OK, but for some reason it isn't seeing the drive
attached to it. Probably a defective drive reporting not ready or maybe
just a connection problem (the drive is mounted in some very weird way so
that I can't even check the connection, let alone see the jumpers or
anything). Oh well, I'll figure it out later. Right now i have the WQESD
controller configured as the primary one, and it has 4 working 320 MB disks
attached to it, so it should be enough for me to build and release 4.3BSD-
Quasijarus1.
   
   But there is something even more interesting. I got the TK50 to work!
Yay! It turned out that one of the TQK50 boards was working after all, it
was simply being screwed up by the rest of the system standing on its ears.
   
   After I got the VAX to boot from some VMSish tape I have (it boots, asks
for date and time, prints something about some "standalone backup" and
gives me a "$" prompt, but I'm absolutely NULL in VMS, so this doesn't do
me much good), I realized that I couldn't boot from my Ultrix tapes because
there is something wrong with the way I wrote them. I wrote them on a TZ30
(half-height native-SCSI TK50 clone) connected to a 386 with an Adaptec
1520A running FreeBSD booted from a floppy (the 386's big ESDI hard disk is
filled with DOS stuff only). In fact, when I tried reading that tape back
on this very same FreeBSD thing it didn't read! Something is clearly wrong.
   
   As I was thinking about how else can I get correctly written Ultrix
tapes, the following idea sneaked into my mind. The PUPS archive already
contains PDP-11 Ultrix. How about VAX Ultrix? With Warren's permission, I
would be more than happy to upload my VAX Ultrix tape images (I have them
sitting as files on my DOS disk). Once that is done, would someone
volunteer to download them, write them to two TK50 cartridges, and send
them to me? TIA for any help.
   
   Sincerely,
   Michael Sokolov
   Cellular phone: 216-217-2579
   ARPA Internet SMTP mail: msokolov at harrier.Uznet.NET



From wkt at henry.cs.adfa.oz.au  Sat Dec  5 17:27:36 1998
From: wkt at henry.cs.adfa.oz.au (Warren Toomey)
Date: Sat, 5 Dec 1998 18:27:36 +1100 (EST)
Subject: Some nice progress with hardware and Ultrix in the PUPS archive
In-Reply-To: <199812041031.PAA09422@harrier.Uznet.NET> from Michael Sokolov at "Dec 4, 98 10:31:01 am"
Message-ID: <199812050727.SAA04411@henry.cs.adfa.oz.au>

In article by Michael Sokolov:
>    As I was thinking about how else can I get correctly written Ultrix
> tapes, the following idea sneaked into my mind. The PUPS archive already
> contains PDP-11 Ultrix. How about VAX Ultrix? With Warren's permission, I
> would be more than happy to upload my VAX Ultrix tape images (I have them
> sitting as files on my DOS disk). Once that is done, would someone
> volunteer to download them, write them to two TK50 cartridges, and send
> them to me? TIA for any help.

We have to be careful with 3rd party UNIXes. We would have to get approval
from DEC (or whoever they are) to allow us to add their product into the
archive. I did this with V7M and the later Ultrix-11s before DEC got bought
out.

	Warren

Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id BAA04900
	for pups-liszt; Sun, 6 Dec 1998 01:36:15 +1100 (EST)

From SHOPPA at trailing-edge.com  Sun Dec  6 00:33:16 1998
From: SHOPPA at trailing-edge.com (Tim Shoppa)
Date: Sat, 5 Dec 1998 9:33:16 -0500
Subject: System Industries MSCP disk controller problem
Message-ID: <981205093316.2de002c3@trailing-edge.com>

>   I have just tried configuring the board as you have suggested and it
>works! Thanks! You have saved the Project!

"It has to be simple or I can't do it :-)".  In this case (like just
about all), it's a matter of getting rid of unknowns.
   
>   When I tried starting WOMBAT, it also worked. However, there are tons of
>configuration parameters you can set there.

Oh yeah - the Webster controllers are wonderfully configurable.  It's
incredibly useful, as one physical disk can be partitioned up many ways
into "virtual" MSCP units - especially useful for OS's which don't deal
well with large units (or when it's desirable to have many different 
versions of many different OS's on the same disk.)

>Do you have a full manual for this controller? Would you mind sending me a
>xerox copy?

Sure, for the cost of copying and postage.  Or I'd trade you for some
surplus of yours.
   
>   What about VAXen? Can you still call 1-800-DIGITAL with a _BIG_ credit
>card in hand and order a VAX?

Yep - high end 3100 and 4000 units are still available.

(It looks like someone has already pointed you towards the Emulex QD21
and QT13 docs available around the net.)   
   
>   And while we are at it, I have a question about 9-track tape transports
>and controllers in general. I often hear about something called Pertec.
>What is it? Is it some kind of standard interface that nearly all tape
>transports use?

Nearly all non-SCSI, non-proprietary interface tape drives will have
either (or both) Pertec formatted and Pertec unformatted interfaces.

Pertec unformatted drives have three cables; one carries read data, 
another carries write data, and the third carries control signals.  It's
a rather low-level interface - the controller tells the drive to go
forward, then reads or writes data, with the controller responsible
for all the timing.  The controller gets to do the nitty-gritty work
of repositioning and spacing forward and backward over tape marks.

Pertec formatted drives have two 50-pin cables.  It's a higher-level
interface, where the "formatter" does a lot of the nitty-gritty work, and
the controller in the backplane just has to spew out data bytes (or
take them in).

Many times you'll see a Pertec unformatted drive with a formatter bolted
onto it with two 50-pin cables coming out.  (In most cases, a formatter
could control multiple physical drives.)  Other times you'll find
"embedded formatter" drives, where there is no 3-cable unformatted
interface lurking inside.

> It is what this QT13 controller is for? (It has 2 50-lead
>connectors.)

Yep, Pertec formatted.  The QT13 is nice because it'll emulate
either MU: or MS:-type devices.

> I remember at CWRU there was a very neat-looking tape
>transport called Cipher. It looked EXACTLY like DEC TS05, suggesting that
>it's what the TS05 really is.

Yep, a TS05 is a rebadged Cipher F880 (with some slightly-different 
firmware).

> That one also had a two-50-lead-cables
>interface as far as I could tell (it was disconnected). It also appeared to
>be dual-ported.

It probably had 4 50-pin edge connectors, so that multiple drives could
be chained on the same Pertec-formatted-bus.  (There are terminators at
each end of the bus, much like SCSI.)  There's provisions for at least
4 formatters per bus, with each formatter potentially running multiple
drives.

> Does this mean that DEC also used this Pertec interface?

Yep.  Actually, the DEC TS05/TSV05/TU80 controllers are rebadged Dilog boards
(again, with slightly different firmware - for instance a DEC TU80 controller
will only work with TU80 drives or their CDC equivalent, the Keystone.)

>Then why are there different DEC controllers for different DEC 9-track tape
>transports (TSV05 for TS05, KLESI for TU81+, etc.)? If they were all Pertec
>one controller would fit all, wouldn't it? Or is that some DEC 9-track tape
>hardware uses Pertec and other DEC hardware doesn't?

At the guts of most DEC tape drives, you will often find either a Pertec
formatted or unformatted interface.  TU80's and TS(V)05's are simple
Pertec formatted interfaces.  Other times they convert to some other
interface (Massbus, LESI, etc.) before the cables come out to the "real
world".
   
>   Moving on to the next and last unidentified flying board. This one is a
>total mystery. The board is labeled "SIGMA INFORMATION SYSTEMS, INC." and
>"ASSY NO 400135 REV A". There are NO microprocessors, ROMs, or any other
>LSI chips on the board, only SSI/MSI chips, resistors, and capacitors. It's
>a dual-height board. It has 3 8-switch packs. There is one 40-lead shrouded
>header connector on the board, and a straight 40-lead ribbon cable connects
>it to a bulkhead which has a female 37-lead D-sub connector on the outside.
>Any ideas on what in the world is this?

Any chance it's a simple parallel I/O?

Could also be the bus interface for a Sigma and/or DSD MFM drive controller
(if so, it probably emulates RL02's).  The assembly number sounds vaguely
DSD-like.

-- 
 Tim Shoppa                        Email: shoppa at trailing-edge.com
 Trailing Edge Technology          WWW:   http://www.trailing-edge.com/
 7328 Bradley Blvd		   Voice: 301-767-5917
 Bethesda, MD, USA 20817           Fax:   301-767-5927

Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id BAA04942
	for pups-liszt; Sun, 6 Dec 1998 01:44:43 +1100 (EST)

From SHOPPA at trailing-edge.com  Sun Dec  6 00:42:42 1998
From: SHOPPA at trailing-edge.com (Tim Shoppa)
Date: Sat, 5 Dec 1998 9:42:42 -0500
Subject: Some nice progress with hardware and Ultrix in the PUPS archive
Message-ID: <981205094242.2de002c3@trailing-edge.com>

>   As I was thinking about how else can I get correctly written Ultrix
>tapes, the following idea sneaked into my mind. The PUPS archive already
>contains PDP-11 Ultrix. How about VAX Ultrix?

As Warren pointed out, there might be a problem with putting such
tapes on the PUPS archive.  I'd be glad to run off TK50's from images
for you, though I think your earlier idea, about installing from
the miniroot image that's commonly put on 4.2- and 4.3BSD derived
distributions, is a *far* better idea as it avoids using a TK50
tape drive at all.

It's not that tape copies are bad ideas - it's just that TK50's
are so slow.  If you were coming from 9-track or DLT or something
fast, that wouldn't be so bad.

If you can get just about any OS running on your
Q-bus machine, under any CPU - i.e. NetBSD, RT-11, 2.11BSD, RSX,
whatever you might have - then you can just write the miniroot
straight to a "scratch" disk.  You can also write the root
dump and tar savesets straight to another scratch disk, in "raw"
format, if you desire.

-- 
 Tim Shoppa                        Email: shoppa at trailing-edge.com
 Trailing Edge Technology          WWW:   http://www.trailing-edge.com/
 7328 Bradley Blvd                 Voice: 301-767-5917
 Bethesda, MD, USA 20817           Fax:   301-767-5927


From msokolov at harrier.Uznet.NET  Tue Dec  8 02:37:52 1998
From: msokolov at harrier.Uznet.NET (Michael Sokolov)
Date: 7 Dec 1998   16:37:52 GMT
Subject: Some nice progress with hardware and Ultrix in the PUPS archive
Message-ID: <199812071638.VAA15617@harrier.Uznet.NET>

   Dear Tim,
   
   You write:
> I'd be glad to run off TK50's from images
> for you, though I think your earlier idea, about installing from
> the miniroot image that's commonly put on 4.2- and 4.3BSD derived
> distributions, is a *far* better idea as it avoids using a TK50
> tape drive at all.
   
   I will need to boot from a tape at some point in any case. I have to
boot from SOMETHING. Since none of the disks in this machine is bootable, I
have to boot either from a tape or over the network. Since the only two
computers in my apartment are the VAX in question and my DOS machine,
netbooting is not an option. Well, I could attach another disk to the PC,
download FreeBSD, and install it, but this is _WAY_ too much pain. Also
there is no guarantee of success with this approach, since there are all
kinds of traps waiting to catch me. The spare disk I'm talking about may
turn out to be toast, FreeBSD may not like something about this PC, the
DELQA in the VAX may turn out broken, etc., etc., etc. OTOH, the labor
investment in just trying it out is enormous (this PC has a VERY special
configuration, and adding another disk may turn out to be a royal pita,
plus downloading FreeBSD or some other PeeCee UNIX clone over my 14400 BPS
modem is going to be a nightmare). On the other hand, I know that the TK50
boot path is working, since I have been able to boot from some VMSish tape
(see my previous messages), thus all I need is a good Ultrix tape.
   
   Another friendly PUPS member has promised to send me copies of his
Ultrix tapes, so hopefully I'll get something going.
   
> It's not that tape copies are bad ideas - it's just that TK50's
> are so slow.  If you were coming from 9-track or DLT or something
> fast, that wouldn't be so bad.
   
   Are 9-track tapes faster than TK50s? In addition to the TK50 I also have
the CDC Keystone and the QT13 which seems to work after all, but I
_STRONGLY_ doubt that it's going to be any easier. This big beast is very
dirty, it has been exposed to a little rain, and it has been dropped on
concrete pavement a couple times, so before I even try plugging it in, I
would have to perform a very careful cleaning and inspection procedure, and
I currently don't have anywhere near the resources and knowledge needed for
that operation.
   
> If you can get just about any OS running on your
> Q-bus machine, under any CPU - i.e. NetBSD, RT-11, 2.11BSD, RSX,
> whatever you might have - then you can just write the miniroot
> straight to a "scratch" disk.
   
   Again, regardless of what approach I take, I'll need to boot from some
device first. See above.
   
   Sincerely,
   Michael Sokolov
   Cellular phone: 216-217-2579
   ARPA Internet SMTP mail: msokolov at harrier.Uznet.NET


Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id DAA13664
	for pups-liszt; Tue, 8 Dec 1998 03:51:29 +1100 (EST)

From msokolov at harrier.Uznet.NET  Tue Dec  8 02:49:46 1998
From: msokolov at harrier.Uznet.NET (Michael Sokolov)
Date: 7 Dec 1998   16:49:46 GMT
Subject: 9-track tape interfaces
Message-ID: <199812071650.VAA15637@harrier.Uznet.NET>

   Dear Tim,
   
   Your explanation of 9-track tape interfaces is extremely helpful!
Thanks! This area has always been a huge gap in my hardware knowledge.
   
   What I still don't understand is how do all these interfaces handle the
issue of recording density (800 BPI vs. 1600 BPI vs. 6250 BPI). You are
saying that the Pertec unformatted interface is very low-level. Do you mean
that it gives the controller the raw stream from the heads without trying
to separate data and clock bits? It is my understanding (please correct me
if I'm wrong) that the difference between 1600 and 6250 BPI is the data
encoding (PE vs. GCR) and that the actual magnetic density (flux
transitions per inch) is the same. If so, does this mean that a Pertec
unformatted transport can be made 1600 or 6250 BPI at the formatter's
discretion without the transport knowing or caring about the density? I
mean, is it like the ST-506/412 MFM vs. ST-506/412 RLL thing?
   
   And how does the Pertec formatted interface address this issue? In this
case the controller has to tell the transport what density it wants with
the transport being able to accept or deny the request depending on its
capabilities, right?
   
   You write:
> Yep, Pertec formatted.  The QT13 is nice because it'll emulate
> either MU: or MS:-type devices.
   
   This brings me to the following question. Assuming that the Pertec
formatted interface does carry explicit density control information, which
software interface would be a better choice in terms of density control,
TS-11 or TMSCP? It is my understanding that the original UNIBUS TS-11 is a
formatter for Pertec unformatted transports that supports 1600 BPI only,
right? If so, the TS-11 interface doesn't give the OS any control over the
density, does it? If so, what density does the QT13 choose in this mode?
And what about TMSCP? How much control does it give to the OS in terms of
density selection?
   
> Yep, a TS05 is a rebadged Cipher F880 (with some slightly-different
> firmware).
   
   And where does it stand density-wise? According to DEC, TS05 is a 1600
BPI only transport, and as far as I can remember, the Cipher at CWRU had
"1600 BPI" printed on the back somewhere. However, it had a switch on the
front panel labeled "HI DEN" or something like that. What the hell is this?
According to DEC docs, on TS05 this switch is labeled "ENTER" and the docs
call it "reserved".
   
> It probably had 4 50-pin edge connectors [...]
   
   Yes.
   
> [...] so that multiple drives could
> be chained on the same Pertec-formatted-bus.  (There are terminators at
> each end of the bus, much like SCSI.)  There's provisions for at least
> 4 formatters per bus, with each formatter potentially running multiple
> drives.
   
   Huh! I have never thought about it this way.
   
> (again, with slightly different firmware - for instance a DEC TU80
> controller
> will only work with TU80 drives or their CDC equivalent, the Keystone.)
   
   CDC Keystone is exactly what I have here. The interface coming out of
the (incredibly huge) cabinet is Pertec formatted. Does it have a Pertec
unformatted interface lurking inside or not? Which densities does it
support?
   
> TU80's and TS(V)05's are simple
> Pertec formatted interfaces.  Other times they convert to some other
> interface (Massbus, LESI, etc.) before the cables come out to the "real
> world".
   
   Hmm, the only DEC tape transport with LESI I know of is TU81+. Are there
any others? And what about that plus? Has there ever been a TU81 without
the plus? My manuals are at my main VAX farm from which I'm currently away,
but I remember the picture of the TU81+ in there looked similar to the
Keystone I have here. Since you say above that TU80 is Keystone in
disguise, does it mean that TU80, TU81, and TU81+ are all the same beast
with different interface converters tacked on?
   
   And what is LESI anyway? I have heard somewhere that the KLESI
controller can drive more than just a TU81+, so is LESI actually more than
just a tape interface?
   
   Oh, what about that leading edge strobe vs. trailing edge strobe? Your
vmsnet.pdp11 posting with the QT13 switch settings says that Kennedy 9300
uses trailing edge strobe while all others use leading edge strobe. Mine,
however, is set for trailing edge strobe, and it was connected to the
Keystone. Does this mean that the Keystone and Kennedy 9300 are the same
beast, or is it simply that the 9300 is not the only transport using
trailing edge strobe?
   
   Sincerely,
   Michael Sokolov
   Cellular phone: 216-217-2579
   ARPA Internet SMTP mail: msokolov at harrier.Uznet.NET


Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id DAA13678
	for pups-liszt; Tue, 8 Dec 1998 03:51:55 +1100 (EST)

From msokolov at harrier.Uznet.NET  Tue Dec  8 02:51:09 1998
From: msokolov at harrier.Uznet.NET (Michael Sokolov)
Date: 7 Dec 1998   16:51:09 GMT
Subject: Sigma unidentified flying board
Message-ID: <199812071651.VAA15642@harrier.Uznet.NET>

   Dear Tim,
   
   You write:
> Any chance it's a simple parallel I/O?
>
> Could also be the bus interface for a Sigma and/or DSD MFM drive
> controller (if so, it probably emulates RL02's).  The assembly number
> sounds vaguely DSD-like.
   
   From looking at the board I see that the BDMGI and BDMGO fingers are
simply shorted and not connected to any circuitry. This means that the
board is non-DMA, right? If so, it can't emulate RL-11 or any other DEC
disk controller because they are all DMA, right? The BIAKI and BIAKO
fingers ARE connected to some circuitry, though, so at least this board
interrupts, right?
   
   And what's DSD? What MFM controller are you referring to? The "SIGMA
INFORMATION SYSTEMS, INC." label and the assembly number are etched, not
silk-screened, stamped, or stickered, so it suggests that Sigma is the
original designer.
   
   Sincerely,
   Michael Sokolov
   Cellular phone: 216-217-2579
   ARPA Internet SMTP mail: msokolov at harrier.Uznet.NET


Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id FAA14057
	for pups-liszt; Tue, 8 Dec 1998 05:32:10 +1100 (EST)

From rickgc at calweb.com  Tue Dec  8 04:41:59 1998
From: rickgc at calweb.com (Rick Copeland)
Date: Mon, 07 Dec 1998 10:41:59 -0800
Subject: Rugged 1182
Message-ID: <3.0.32.19981207104119.00926100@pop.calweb.com>

Dear PUPS list,

I recently picked up a rack mounted computer that is called a "Rugged
11/82".  One individual I know has suggested that it is a pdp 11/82 is a
ruggedized box.  Has anyone on this list seen one of these.  Is there any
software in the PUPS archive that might run on one of these?

Sincerely,

Rick Copeland

Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id FAA14248
	for pups-liszt; Tue, 8 Dec 1998 05:53:26 +1100 (EST)

From SHOPPA at trailing-edge.com  Tue Dec  8 04:53:01 1998
From: SHOPPA at trailing-edge.com (Tim Shoppa)
Date: Mon, 7 Dec 1998 13:53:01 -0500
Subject: Rugged 1182
Message-ID: <981207135301.2f0000e2@trailing-edge.com>

>I recently picked up a rack mounted computer that is called a "Rugged
>11/82".  One individual I know has suggested that it is a pdp 11/82 is a
>ruggedized box.  Has anyone on this list seen one of these.

I have seen ruggedized 11/83's, as well as "Industrial 11/83"'s, but
it's not clear yet exactly what you have.  The obvious solution
is to look inside and see what Q-bus and/or Unibus boards are present.

>  Is there any
>software in the PUPS archive that might run on one of these?

Some ruggedized PDP-11 systems didn't have a real Q-bus or Unibus backplane
at all, making it very difficult (if not impossible) to use them
with a standard disk controller.  That's why it's vital that you figure
out what exactly is in your machine.

Assuming that the guts are indeed a Q-bus or Unibus KDJ-based CPU,
you'll be able to run 2.11BSD once you get a compatible disk, load,
and console system up and going on it.

-- 
 Tim Shoppa                        Email: shoppa at trailing-edge.com
 Trailing Edge Technology          WWW:   http://www.trailing-edge.com/
 7328 Bradley Blvd		   Voice: 301-767-5917
 Bethesda, MD, USA 20817           Fax:   301-767-5927

Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id GAA14657
	for pups-liszt; Tue, 8 Dec 1998 06:42:52 +1100 (EST)

From SHOPPA at trailing-edge.com  Tue Dec  8 05:42:28 1998
From: SHOPPA at trailing-edge.com (Tim Shoppa)
Date: Mon, 7 Dec 1998 14:42:28 -0500
Subject: 9-track tape interfaces
Message-ID: <981207144228.2f0000e2@trailing-edge.com>

>   Are 9-track tapes faster than TK50s? 

In every reasonable case that I know of, yes.

>In addition to the TK50 I also have
>the CDC Keystone and the QT13 which seems to work after all, but I
>_STRONGLY_ doubt that it's going to be any easier. This big beast is very
>dirty, it has been exposed to a little rain, and it has been dropped on
>concrete pavement a couple times, so before I even try plugging it in, I
>would have to perform a very careful cleaning and inspection procedure, and
>I currently don't have anywhere near the resources and knowledge needed for
>that operation.

You're lucky - there's an incredible scarcity of moving parts on
a TU80/CDC Keystone: two reel motors and a blower are all you've
got.  There's also two metallic "hub" sensors used to sense tape
motion/tension.  Clean these and the heads, load a scratch tape with
write ring, power it up, close the door, make sure the logic is on,
and hit "TEST" followed by "EXECUTE".  It'll go into a self-test mode,
including some maximum-Maytag gymnastics, which will run for 15
minutes or so on a 2400-foot tape.
   
[Unknown Sigma board]
>   From looking at the board I see that the BDMGI and BDMGO fingers are
>simply shorted and not connected to any circuitry. This means that the
>board is non-DMA, right? If so, it can't emulate RL-11 or any other DEC
>disk controller because they are all DMA, right? The BIAKI and BIAKO
>fingers ARE connected to some circuitry, though, so at least this board
>interrupts, right?

Hmm - you said it has a 40-pin connector.  Given that it doesn't
do DMA, I'm guessing that it's either a DLV11-type clone (a single
serial line) or a parallel interface (either a DRV11-C type or a
line-printer driver, possibly either Data Products or Centronics
interface.)
   
>   And what's DSD?

Data Systems Design - they made some disk controller subsystems.

> The "SIGMA
>INFORMATION SYSTEMS, INC." label and the assembly number are etched, not
>silk-screened, stamped, or stickered, so it suggests that Sigma is the
>original designer.

Any obvious buffers (or banks of buffers) near the external connector?  What
are the date codes on the chips?
   
>   What I still don't understand is how do all these interfaces handle the
>issue of recording density (800 BPI vs. 1600 BPI vs. 6250 BPI). You are
>saying that the Pertec unformatted interface is very low-level. Do you mean
>that it gives the controller the raw stream from the heads without trying
>to separate data and clock bits?

At least at 800 and 1600 BPI, the Pertec Unformatted interface does
do the data recovery.  There's a line from the formatter that puts
the drive into either PE (1600 BPI) or NRZI (800 BPI) mode, and some
optional lines that set the thresholds of the analog comparators used
for data recovery.

I'm not too sure about Pertec Unformatted drives at 6250 BPI.

> It is my understanding (please correct me
>if I'm wrong) that the difference between 1600 and 6250 BPI is the data
>encoding (PE vs. GCR) and that the actual magnetic density (flux
>transitions per inch) is the same.

6250 BPI is definitely higher flux density on the tape (in addition to
the different encoding.)

>   And how does the Pertec formatted interface address this issue? In this
>case the controller has to tell the transport what density it wants with
>the transport being able to accept or deny the request depending on its
>capabilities, right?

There are a couple "spare" lines on the Pertec formatted interface
so that the host can tell the formatter such "optional" information.
The interpretation of these spare lines was never perfectly standardized:
sometimes they're used to select 800 vs 1600 or 1600 vs 6250 BPI
operation, other times they're used to put the drive into streaming
vs non-streaming mode, other times it's used to change the speed on
a streaming drive.  The IDEN line was the most commonly used line
on the Pertec formatted interface to choose these options, but some
CDC drives implemented a scheme where density/speed negotiation were
done in a much more complex way.
   
>   This brings me to the following question. Assuming that the Pertec
>formatted interface does carry explicit density control information, which
>software interface would be a better choice in terms of density control,
>TS-11 or TMSCP?

It depends on what your OS's driver is capable of.  In most cases
TMSCP gives you more control.

> It is my understanding that the original UNIBUS TS-11 is a
>formatter for Pertec unformatted transports that supports 1600 BPI only,
>right?

Right.

> If so, the TS-11 interface doesn't give the OS any control over the
>density, does it?

The "official DEC" TS-11 interface didn't.  The DEC TSV05 interface
(which was upward-compatible with the TS11's)
gave the software control over the "high speed" vs "low speed" bit.
And as I pointed out, some drives could be set to interpret this
bit as a density select.  I don't think the ability to set/clear
this bit ever made it into 2.11BSD (looking at the ts driver
code there I don't see it, at least) and I have no idea if it ever
made it to the 4.xBSD's.

> If so, what density does the QT13 choose in this mode?

The QT13 will support either IDEN-style density select or CDC-style
density select, and I believe in MS: mode this choice is made through
the TSV05 speed-select bit.

>And what about TMSCP? How much control does it give to the OS in terms of
>density selection?

TMSCP is much more flexible, and supports at least two different schemes
for selecting and reporting density.  Here's what I've figured out about
possible reported-back density values in the TMSCP packets (as
excerpted from my DUSTAT.MAC):

DENTBL: TBLENT  1       ,<NRZI 800 BPI>
        TBLENT  2       ,<PE 1600 BPI>
        TBLENT  4       ,<GCR 6250 BPI>
        TBLENT  10      ,<Cartridge (TK50)>
        TBLENT  401     ,<NRZI 800 BPI>
        TBLENT  402     ,<PE 1600 BPI>
        TBLENT  404     ,<GCR 6250 BPI>
        TBLENT  420     ,<TU82 special high density>;according to RSTS/E
        TBLENT  1001    ,<Cartridge (TK50)>
        TBLENT  1002    ,<Cartridge (TK70)>
        ;       20xx entries are supposed to be RV80, whatever that is,
        ;            according to RSTS/E sources.

I'm pretty sure that 2.11BSD properly handles TU81 density select
in its TMSCP driver.  (Steve, can you confirm this?  I know you've
made some effort to get write caching to work with TU81's over the
years!)

In any event, remote density selection/reporting is largely a
frill, as any drive/controller combination that I ever used let you
explicitly select it with a physical button or a switch and displayed
the current selection in some useful way on the drive.
   
>> Yep, a TS05 is a rebadged Cipher F880 (with some slightly-different
>> firmware).
>   And where does it stand density-wise? According to DEC, TS05 is a 1600
>BPI only transport, and as far as I can remember, the Cipher at CWRU had
>"1600 BPI" printed on the back somewhere. However, it had a switch on the
>front panel labeled "HI DEN" or something like that. What the hell is this?

Some Cipher's (I think F890's) supported a special 3200 BPI mode.  It
was never in real wide use, but it was supported on some other
manufacturer's drives (some Kennedy 96xx's, for example.)

I know that some F880's had a button that said "HI DEN" but was for
all normal purposes non-functional (I think it did become useful
for selecting diagnostics.)

>   CDC Keystone is exactly what I have here. The interface coming out of
>the (incredibly huge) cabinet is Pertec formatted. Does it have a Pertec
>unformatted interface lurking inside or not? Which densities does it
>support?

1600 BPI only, it's an "embedded-formatter" drive, so there is no
internal Pertec unformatted interface.
   
>   Hmm, the only DEC tape transport with LESI I know of is TU81+. Are there
>any others?

Yep, the RC25 also used the LESI bus.  (LESI="Low End Storage Interconnect".)

> And what about that plus? Has there ever been a TU81 without
>the plus?

Hmm - the non-plus may have been the version without write-caching.
Not real sure.

>Keystone I have here. Since you say above that TU80 is Keystone in
>disguise, does it mean that TU80, TU81, and TU81+ are all the same beast
>with different interface converters tacked on?

They all look similar, and have similar mechanics, but the 81's electronics
can do 6250 BPI, something an 80's can't.
   
>   And what is LESI anyway? I have heard somewhere that the KLESI
>controller can drive more than just a TU81+, so is LESI actually more than
>just a tape interface?

It was CDC's attempt at a SCSI-like universal interface.
   
>   Oh, what about that leading edge strobe vs. trailing edge strobe? Your
>vmsnet.pdp11 posting with the QT13 switch settings says that Kennedy 9300
>uses trailing edge strobe while all others use leading edge strobe. Mine,
>however, is set for trailing edge strobe, and it was connected to the
>Keystone. Does this mean that the Keystone and Kennedy 9300 are the same
>beast, or is it simply that the 9300 is not the only transport using
>trailing edge strobe?

Hmm - some combinations of drives may not be sensitive to this.  (It's
also possibly a misprint in my QT13 manual, as I remember having to
futz with this switch's setting in some cases to get everything to work.)

No, the Keystone and the Kennedy 9300 are not the same beast.  The
Keystone is a cute little streaming tape drive, while the 9300 is
a humongous vacuum-column 125IPS machine.  (I'm sure someone will
now chime in about the days when Univac UniServo drives ruled the
earth...)

-- 
 Tim Shoppa                        Email: shoppa at trailing-edge.com
 Trailing Edge Technology          WWW:   http://www.trailing-edge.com/
 7328 Bradley Blvd		   Voice: 301-767-5917
 Bethesda, MD, USA 20817           Fax:   301-767-5927


From djenner at halcyon.com  Tue Dec  8 06:12:20 1998
From: djenner at halcyon.com (David C. Jenner)
Date: Mon, 07 Dec 1998 12:12:20 -0800
Subject: 9-track tape interfaces
References: <981207144228.2f0000e2@trailing-edge.com>
Message-ID: <366C36A4.7921683A@halcyon.com>

Tim Shoppa wrote:
> 
> A lot, so I snipped it out!
>

As long as this thread is red hot, how about these questions:

I have an M4 Data 9914 tape drive with Pertec and SCSI interfaces.
It will do 800, 1600, 6250.  I want to set up and run 2.11BSD on a
Q-Bus system.

1) I'd rather not spend a lot to get a SCSI interface.  I now have
   Emulex TC02 and Dilog DQ130 Q-Bus controllers.  Is there
   any way these controllers are going to enable 6250 BPI?

2) Is there another Q-Bus, Pertec controller that will do 6250?

3) If I had a Q-Bus SCSI controller, would it enable 6250?

4) (Already asked in thread) Supposing I get the hardware to work
   at 6250, will 2.11BSD handle it?

Thanks,
Dave

Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id HAA15025
	for pups-liszt; Tue, 8 Dec 1998 07:27:55 +1100 (EST)

From SHOPPA at trailing-edge.com  Tue Dec  8 06:27:09 1998
From: SHOPPA at trailing-edge.com (Tim Shoppa)
Date: Mon, 7 Dec 1998 15:27:09 -0500
Subject: 9-track tape interfaces
Message-ID: <981207152709.2f0000e2@trailing-edge.com>

>1) I'd rather not spend a lot to get a SCSI interface.  I now have
>   Emulex TC02 and Dilog DQ130 Q-Bus controllers.  Is there
>   any way these controllers are going to enable 6250 BPI?

Sure - I use them at 6250 BPI all the time.  The controller
doesn't have to know what density the data is at - the formatter
takes care of that.  If you absoultely insist on the computer
being able to switch the drive between 1600 and 6250 BPI modes,
you won't be able to achieve this with a TC02 or DQ130 under 2.11BSD,
but this is purely a frill as you can always select the mode from
the drive's front panel.

One thing you do have to worry about is data rate.  Pertec
formatted interfaces on "fast" buffered modern drives may want to suck
or spew data at rates that are often too fast for a lowly TC02 or
DQ130's capability to push data over the Q-bus.  Most modern Pertec-
formatted drives will let you throttle the rate to something reasonable.
And some more modern Q-bus controllers - like the Dilog DQ152 - have
internal buffers for handling such cases without having to throttle
the drive itself.

>4) (Already asked in thread) Supposing I get the hardware to work
>   at 6250, will 2.11BSD handle it?

Absolutely.  I use a Fuji 2444 and a Storagetek 2925 with a TC02
and 2.11BSD all the time in 6250 BPI mode.  I had to throttle the
data rates on both, but that's not such a big deal.

On the other hand, my Storagetek 2920, which is pretty much a 2925
without the cache option, doesn't let me throttle the data rate
at 6250 mode because there is no effective buffer.  These don't
work with my TC02 on a Q-bus machine, but they do work with a TC13
on a Unibus 11/44 or with a DQ152 on a Q-bus -11.

Also keep in mind that some third-party controllers don't interact
well with the fast polling that the most recent Q-bus CPU's can
do.  For example, my TC02 won't work at all with
a loaned Mentec M100 (roughly comparable with a 11/93) that I have.  
I've never had this problem with 11/83's and slower CPU's.

-- 
 Tim Shoppa                        Email: shoppa at trailing-edge.com
 Trailing Edge Technology          WWW:   http://www.trailing-edge.com/
 7328 Bradley Blvd		   Voice: 301-767-5917
 Bethesda, MD, USA 20817           Fax:   301-767-5927

Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id JAA15470
	for pups-liszt; Tue, 8 Dec 1998 09:40:18 +1100 (EST)

From sms at moe.2bsd.com  Tue Dec  8 08:33:57 1998
From: sms at moe.2bsd.com (Steven M. Schultz)
Date: Mon, 7 Dec 1998 14:33:57 -0800 (PST)
Subject: 9-track tape interfaces
Message-ID: <199812072233.OAA07800@moe.2bsd.com>

Tim -

	Howdy.

> I'm pretty sure that 2.11BSD properly handles TU81 density select
> in its TMSCP driver.  (Steve, can you confirm this?  I know you've
> made some effort to get write caching to work with TU81's over the years!)

	Indeed it does.  However TMSCP only defines 800,1600 and 6250 so
	on the quad density drive I have the 3200 setting must be selected
	manually on the front panel of the tape drive.

	Also the 'enable cache' works fine and makes a dramatic difference
	on a TU81+ attached to an 11/44.  The 'cache enabled' setting is
	sticky across open/close cycles so that you set it once manually
	when the first reel is loaded.  This was done to avoid having to
	modify dump/restore/tar/etc

> In any event, remote density selection/reporting is largely a
> frill, as any drive/controller combination that I ever used let you
> explicitly select it with a physical button or a switch and displayed
> the current selection in some useful way on the drive.

	Quite so.  Eons ago the one Cipher drive supported 800/1600 operation
	but the controller (TM11 clone) did not - you just made sure to
	select the density on the front panel when loading the tape

	Steve

Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id OAA16643
	for pups-liszt; Tue, 8 Dec 1998 14:49:04 +1100 (EST)

From peterc at softway.com.au  Tue Dec  8 13:48:27 1998
From: peterc at softway.com.au (Peter Chubb)
Date: Tue, 8 Dec 1998 14:48:27 +1100 (ADST)
Subject: John Lions
Message-ID: <13932.41355.645423.303757@swarm.sw.oz.au>


     Associate Professor John Lions, who  was instrumental in UNIX's
     acceptance in Australia, and in its popularity (through his two
     books) world wide, died last Saturday morning, after long
     illness.

Peter C



Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id OAA16671
	for pups-liszt; Tue, 8 Dec 1998 14:52:06 +1100 (EST)

From wkt at henry.cs.adfa.oz.au  Tue Dec  8 13:54:59 1998
From: wkt at henry.cs.adfa.oz.au (Warren Toomey)
Date: Tue, 8 Dec 1998 14:54:59 +1100 (EST)
Subject: John Lions
In-Reply-To: <13932.41355.645423.303757@swarm.sw.oz.au> from Peter Chubb at "Dec 8, 98 02:48:27 pm"
Message-ID: <199812080354.OAA09118@henry.cs.adfa.oz.au>

In article by Peter Chubb:
>      Associate Professor John Lions, who  was instrumental in UNIX's
>      acceptance in Australia, and in its popularity (through his two
>      books) world wide, died last Saturday morning, after long
>      illness.

Gee, that's very bad news.

Thanks for the email, Peter.

	Warren

Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id SAA17323
	for pups-liszt; Tue, 8 Dec 1998 18:20:42 +1100 (EST)

From msokolov at harrier.Uznet.NET  Tue Dec  8 17:19:34 1998
From: msokolov at harrier.Uznet.NET (Michael Sokolov)
Date: 8 Dec 1998   07:19:34 GMT
Subject: 9-track tape interfaces
Message-ID: <199812080719.MAA16509@harrier.Uznet.NET>

   Dear Tim,
   
   You write:
> Hmm - you said it has a 40-pin connector.
   
   Yes. A straight flat ribbon cable connects it to the bulkhead, which has
a female 37-lead D-sub connector on the outside.
   
> Any obvious buffers (or banks of buffers) near the external connector?
   
   I have just spent a couple of hours tracing the etches on this board,
and here is what I have found out. One side of the 40-pin connector is all
ground (well, that's pretty obvious). On other side we have the following.
4 pins are permanently connected to pull-up resistors, and one pin is
permanently connected to a pull-down resistor. The other 15 pins are
connected through jumpers so that the user can connect or disconnect them
on an individual basis. Some of these go to different outputs of a 74S241
(dual 4-bit 3-state buffer), some go to a 7437 (unfamiliar with this IC),
and some go to a missing IC.
   
   Both halves of the 74S241 are permanently enabled. All 8 outputs of this
half are connected to different pins on the connector. 7 of them are
connected in the obvious way, but one is also connected to a pull-up
resistor (purpose non-understood, since the 3-state buffer is always
enabled). The jumpers for all 8 are ON. Then there are 3 pins that go to
the 7437. Although 3 pins of the connector are used for this, 4 pins of the
7437 are used. Two of the connector pins go through simple jumpers, and
both are OFF. The third pin is connected to two different 7437 pins through
different jumpers. One of them is ON and the other is OFF. Finally, there
are 4 pins that connect to a missing IC. The jumpers for all 4 are OFF.
   
   Now, does this tell you anything? :-)
   
> What are the date codes on the chips?
   
   The most recent dates are mid-1988.
   
> [Explanation of the mess with host-side density control]
   
   OK, from now on I'll only use the front panel switch for density
selection. :-)
   
> other times they're used to put the drive into streaming
> vs non-streaming mode, other times it's used to change the speed on
> a streaming drive.
   
   Hmm, this is another big gap in my knowledge. What does streaming vs.
non-streaming mean?
   
> The QT13 will support either IDEN-style density select or CDC-style
> density select [...]
   
   How does it determine which one to use? Is there a switch on the board?
   
> Yep, the RC25 also used the LESI bus.  (LESI="Low End Storage
> Interconnect".)
   
   Hmm, so then KLESI can do disk MSCP as well as TMSCP, right? Can it do
both simultaneously or only one at a time?
   
> They all look similar, and have similar mechanics, but the 81's
> electronics can do 6250 BPI, something an 80's can't.
   
   But they are all different CDC Keystones, right? This means that my
Keystone may or may not support 6250 BPI, right? How can I tell?
   
> No, the Keystone and the Kennedy 9300 are not the same beast.  The
> Keystone is a cute little streaming tape drive, while the 9300 is
> a humongous [...]
   
   "Cute little"?!?! I mean, I'm still amazed how I was able to get it
inside my apartment without knocking a couple walls down first! It's
certainly huge compared to the REALLY cute little Cipher we had at CWRU. (I
really miss that Cipher, BTW. Not only is it much smaller, according to
what I have been able to glean from the docs, it's much easier to load
tapes into than the Keystone. But then of course if this Keystone does 6250
BPI I will be much more than happy with it.)
   
   But hey, if the Keystone is a cute little baby, poor CSRG fellows! I
think Kennedy 9300 was their primary machine, and I can just imagine what
it is like if the Keystone is "cute little". Does the 9300 do 6250 BPI?
   
> [...] vacuum-column 125IPS machine.
   
   Yet another gap in my knowledge. I remember seeing the term "vacuum
columns" in the BSD documentation and having no idea what are they. Could
you enlighten me?
   
> (I'm sure someone will
> now chime in about the days when Univac UniServo drives ruled the
> earth...)
   
   Just out of curiosity, what are they?
   
   Sincerely,
   Michael Sokolov
   Cellular phone: 216-217-2579
   ARPA Internet SMTP mail: msokolov at harrier.Uznet.NET


Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id TAA17591
	for pups-liszt; Tue, 8 Dec 1998 19:52:37 +1100 (EST)

From dave at fgh.geac.com.au  Tue Dec  8 18:49:40 1998
From: dave at fgh.geac.com.au (Dave Horsfall)
Date: Tue, 8 Dec 1998 19:49:40 +1100 (EST)
Subject: 9-track tape interfaces
In-Reply-To: <199812080719.MAA16509@harrier.Uznet.NET>
Message-ID: <Pine.GSO.4.03.9812081928170.14240-100000@fgh>

On 8 Dec 1998, Michael Sokolov wrote:

> on an individual basis. Some of these go to different outputs of a 74S241
> (dual 4-bit 3-state buffer), some go to a 7437 (unfamiliar with this IC),

>From my TTL Data Book: Quadruple 2-input positive-NAND buffer (Y=AB bar).
Outputs are 3, 6, 8, 11.  Corresponding inputs are 1/2, 4/5, 9/10, 12/13.
Vcc is 14, GND is 7.

>    Hmm, this is another big gap in my knowledge. What does streaming vs.
> non-streaming mean?

Streaming means that data can be supplied to the tape (or read from) fast
enough to keep it moving, as opposed stop/start (or more likely, stop
backspace start).  Requires double-buffering somewhere.

>    Yet another gap in my knowledge. I remember seeing the term "vacuum
> columns" in the BSD documentation and having no idea what are they. Could
> you enlighten me?

ROTFL :-)  Look at an old Sci-Fi movie some time, in particular the
obligatory IBM tape drives spinning back and forth.  The vacuum columns
were buffers; columns into which bits of the tape were sucked so as to
keep the tape moving past the heads at constant velocity (not sure how
good the clock recovery was in those days) whilst the reels did their
thing.  The column has various pairs of pressure sensors, between which
the tape was kept for that particular mode; if it crept past one hole,
it upset the pressure differential, and the pumps came into play...

Remember, folks; this real-time stuff was *before* micro-chips!  I still
remember looking at the old Cipher (I have the magic codes somewhere, that
allowed it to load with the door open etc) aghast that it had no vacuum
columns, but swing-arms instead...

> > (I'm sure someone will
> > now chime in about the days when Univac UniServo drives ruled the
> > earth...)
>    
>    Just out of curiosity, what are they?

Big BIG tape drives - real Sci-Fi material :-)

-- 
Dave Horsfall VK2KFU  dave at geac.com.au  Ph: +61 2 9978-7493 Fx: +61 2 9978-7422
Geac Computers P/L (FGH Division) 2/57 Christie St, St Leonards 2065, Australia


Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id UAA17635
	for pups-liszt; Tue, 8 Dec 1998 20:06:48 +1100 (EST)

From grog at lemis.com  Tue Dec  8 19:06:34 1998
From: grog at lemis.com (Greg Lehey)
Date: Tue, 8 Dec 1998 19:36:34 +1030
Subject: 9-track tape interfaces
In-Reply-To: <Pine.GSO.4.03.9812081928170.14240-100000@fgh>; from Dave Horsfall on Tue, Dec 08, 1998 at 07:49:40PM +1100
References: <199812080719.MAA16509@harrier.Uznet.NET> <Pine.GSO.4.03.9812081928170.14240-100000@fgh>
Message-ID: <19981208193634.A29025@freebie.lemis.com>

On Tuesday,  8 December 1998 at 19:49:40 +1100, Dave Horsfall wrote:
> On 8 Dec 1998, Michael Sokolov wrote:
>>> (I'm sure someone will now chime in about the days when Univac
>>> UniServo drives ruled the earth...)
>>
>>    Just out of curiosity, what are they?
>
> Big BIG tape drives - real Sci-Fi material :-)

UniServo was UNIVAC's name for all its tape drives, at least as long
as I was involved with them.  They were all vacuum column jobs, but
some were definitely ``cheap'' ones, such as the UniServo 6 and 12,
which were intended for smaller machines.  IIRC the latest ``big''
ones were the UniServo 16 and 20, at least when I was still involved
with UNIVAC.

Greg
--
See complete headers for address, home page and phone numbers
finger grog at lemis.com for PGP public key

Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id BAA18425
	for pups-liszt; Wed, 9 Dec 1998 01:02:41 +1100 (EST)

From dave at fgh.geac.com.au  Tue Dec  8 23:59:53 1998
From: dave at fgh.geac.com.au (Dave Horsfall)
Date: Wed, 9 Dec 1998 00:59:53 +1100 (EST)
Subject: John Lions
In-Reply-To: <Pine.GSO.4.03.9812081523440.10402-100000@fgh>
Message-ID: <Pine.GSO.4.03.9812090031300.14240-100000@fgh>

On Tue, 8 Dec 1998, Dave Horsfall wrote:

> Thanks for letting us know.  Damn...

Sic transit gloria mundi.

Damn.

John, why did you have to die?  You taught me everything that I knew.

Shit.

-- 
Dave Horsfall VK2KFU  dave at geac.com.au  Ph: +61 2 9978-7493 Fx: +61 2 9978-7422
Geac Computers P/L (FGH Division) 2/57 Christie St, St Leonards 2065, Australia


Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id BAA18465
	for pups-liszt; Wed, 9 Dec 1998 01:13:54 +1100 (EST)

From msokolov at harrier.Uznet.NET  Wed Dec  9 00:13:08 1998
From: msokolov at harrier.Uznet.NET (Michael Sokolov)
Date: 8 Dec 1998   14:13:08 GMT
Subject: 9-track tape interfaces
Message-ID: <199812081413.TAA16834@harrier.Uznet.NET>

   Dave Horsfall <dave at fgh.geac.com.au> wrote:
> From my TTL Data Book: Quadruple 2-input positive-NAND buffer (Y=AB bar).
> Outputs are 3, 6, 8, 11.  Corresponding inputs are 1/2, 4/5, 9/10, 12/13.
> Vcc is 14, GND is 7.
   
   Looks trivial, except that the author of the digital design textbook I'm
using has chosen to omit it. :-) Anyway, I have looked at the board again,
and all pins that go to the connector are outputs. This means that at least
in this form, with the U10 chip omitted, there are NO inputs on that
connector, only outputs.
   
   That missing chip could very well have to do with inputs, though. Hmm,
there are 4 lines going to that missing chip, and that sounds like the
number of input lines in some flavor of Centronics. On the output side, 8
pins go to the 74S241 and 3 pins go to the 7437, again suggesting 8-bit
output and some control signals.
   
   All this sounds very much like Centronics or some similar interface.
Figuring out what the host interface is and what do those myriads of
switches and jumpers mean would be harder, though.
   
   Sincerely,
   Michael Sokolov
   Cellular phone: 216-217-2579
   ARPA Internet SMTP mail: msokolov at harrier.Uznet.NET



From dave at fgh.geac.com.au  Thu Dec 10 20:35:19 1998
From: dave at fgh.geac.com.au (Dave Horsfall)
Date: Thu, 10 Dec 1998 21:35:19 +1100 (EST)
Subject: John Lions
Message-ID: <Pine.GSO.4.03.9812102037020.7904-100000@fgh>

It's possible that my incoherent outburst may have offended a few people,
in which case I apologise.  In my defence, I would like to say that Dr.
John Lions was my lecturer at Uni of NSW, and I still remember him saying
that he and Ken Robinson (anyone know how he's doing?) saw this article in
CACM, and were going to write off for it.  Thus from little acorns do
mighty oak trees grow, or however the aphorism goes...

Requiescat In Pace.

PS: In the "2nd Book," look under the "Acknowledgements" section; I helped
him with the NROFF layout (I printed chapters on an LA36 Duckwriter (as we
called them!) to see how they were formatted).

-- 
Dave Horsfall VK2KFU  dave at geac.com.au  Ph: +61 2 9978-7493 Fx: +61 2 9978-7422
Geac Computers P/L (FGH Division) 2/57 Christie St, St Leonards 2065, Australia



From eric at fudge.uchicago.edu  Tue Dec 15 08:17:04 1998
From: eric at fudge.uchicago.edu (Eric Fischer)
Date: Mon, 14 Dec 1998 16:17:04 -0600 (CST)
Subject: nondisclosure clause in SCO license
Message-ID: <199812142217.QAA03614@fudge.uchicago.edu>

Does anyone know how serious SCO is about enforcing the nondisclosure
clause from the Ancient Unix license?  I'm referring to this one:

   8.4 (a) LICENSEE agrees that it shall hold all parts of the
   SOURCE CODE PRODUCTS subject to this Agreement in confidence for
   SCO.  LICENSEE further agrees that should it make such disclosure
   of any or all of such SOURCE CODE PRODUCTS (including methods or
   concepts utilized therein) to anyone to whom such disclosure is
   necessary to the use for which rights are granted hereunder,
   LICENSEE shall appropriately notify each such person to whom any
   such disclosure is made that such disclosure is made in
   confidence and shall be kept in confidence and have each such
   person sign a confidentiality agreement containing restrictions
   on disclosure substantially similar to those set forth herein.

So if I mention to someone that (for instance) the Sixth Edition
version of ed didn't have the "j" command but it was in PWB and the
Seventh Edition, and I know this from reading the source code, are the
SCO police going to come after me?

eric

Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id JAA15475
	for pups-liszt; Tue, 15 Dec 1998 09:23:08 +1100 (EST)

From wkt at henry.cs.adfa.oz.au  Tue Dec 15 08:23:22 1998
From: wkt at henry.cs.adfa.oz.au (Warren Toomey)
Date: Tue, 15 Dec 1998 09:23:22 +1100 (EST)
Subject: nondisclosure clause in SCO license
In-Reply-To: <199812142217.QAA03614@fudge.uchicago.edu> from Eric Fischer at "Dec 14, 98 04:17:04 pm"
Message-ID: <199812142223.JAA04880@henry.cs.adfa.oz.au>

In article by Eric Fischer:
> Does anyone know how serious SCO is about enforcing the nondisclosure
> clause from the Ancient Unix license?  I'm referring to this one:
> 
>    8.4 (a) LICENSEE agrees that it shall hold all parts of the
>    SOURCE CODE PRODUCTS subject to this Agreement in confidence for
>    SCO.  LICENSEE further agrees that should it make such disclosure
>    of any or all of such SOURCE CODE PRODUCTS (including methods or
>    concepts utilized therein) to anyone to whom such disclosure is
>    necessary to the use for which rights are granted hereunder,
>    LICENSEE shall appropriately notify each such person to whom any
>    such disclosure is made that such disclosure is made in
>    confidence and shall be kept in confidence and have each such
>    person sign a confidentiality agreement containing restrictions
>    on disclosure substantially similar to those set forth herein.
> 
> So if I mention to someone that (for instance) the Sixth Edition
> version of ed didn't have the "j" command but it was in PWB and the
> Seventh Edition, and I know this from reading the source code, are the
> SCO police going to come after me?
> 
> eric

I hope not Eric. I'll ask SCO for their impressions, and will pass them
back on to the mailing list.

	Warren

Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id JAA15495
	for pups-liszt; Tue, 15 Dec 1998 09:28:32 +1100 (EST)

From erin at coffee.corliss.net  Tue Dec 15 08:31:14 1998
From: erin at coffee.corliss.net (Erin W. Corliss)
Date: Mon, 14 Dec 1998 14:31:14 -0800 (PST)
Subject: PDP-11/73 problems
Message-ID: <Pine.LNX.3.96.981214140751.32409C-100000@coffee.corliss.net>


I recently bought a PDP-11/73.  It has one RD-52A MFM hard drive that
boots up to RSTS, eight serial ports (besides the console), and what looks
like a SCSI connector on the back (labeled TK25, so I assume this is the
tape drive connector).

I have connected it to my PC and I am able to either boot it up from the
hard drive or start up into the ROM monitor.  Unfortunately, at this point
I can't continue because the PDP won't receive anything through the
console serial port.

Does anybody know if there are any quirks about the serial port on this
machine that would cause this (if, for instance, the PDP-11 required some
sort of handshaking that my PC doesn't do).  Also, there is a block of dip
switches on the CPU card that appear to affect booting and serial port
stuff.  Does anyone know where there is a list of what these switches
control?  Furthermore....  Between the cryptically labeled switch that
chooses monitor or boot mode and the knob that changes the baud rate is a
knob with three settings labeled with an arrow, a talking head, and an
uppercase T with an arrow orbiting it.  What does this knob do?  

Finally, assuming that the UART on the CPU board is fried and the entire
CPU board needs to be replaced before it will work again, what are the
chances I could get someone who has the Unix source code to compile me a
kernel that uses one of the other serial ports as the console?

Thanks in advance for all of the help that I know you people will send me.
8^)

	-- Erin Corliss


Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id JAA15515
	for pups-liszt; Tue, 15 Dec 1998 09:30:03 +1100 (EST)

From wkt at henry.cs.adfa.oz.au  Tue Dec 15 08:30:20 1998
From: wkt at henry.cs.adfa.oz.au (Warren Toomey)
Date: Tue, 15 Dec 1998 09:30:20 +1100 (EST)
Subject: PDP-11/73 problems
In-Reply-To: <Pine.LNX.3.96.981214140751.32409C-100000@coffee.corliss.net> from "Erin W. Corliss" at "Dec 14, 98 02:31:14 pm"
Message-ID: <199812142230.JAA04928@henry.cs.adfa.oz.au>

In article by Erin W. Corliss:
> Finally, assuming that the UART on the CPU board is fried and the entire
> CPU board needs to be replaced before it will work again, what are the
> chances I could get someone who has the Unix source code to compile me a
> kernel that uses one of the other serial ports as the console?
> 	-- Erin Corliss

What version of UNIX are you running on it?

	Warren

Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id KAA15610
	for pups-liszt; Tue, 15 Dec 1998 10:00:16 +1100 (EST)

From SHOPPA at trailing-edge.com  Tue Dec 15 08:59:53 1998
From: SHOPPA at trailing-edge.com (Tim Shoppa)
Date: Mon, 14 Dec 1998 17:59:53 -0500
Subject: PDP-11/73 problems
Message-ID: <981214175953.2f000656@trailing-edge.com>

>I have connected it to my PC and I am able to either boot it up from the
>hard drive or start up into the ROM monitor.  Unfortunately, at this point
>I can't continue because the PDP won't receive anything through the
>console serial port.

Am I correct in assuming that up until RSTS/E is started, the console
serial port seems to work fine?   i.e. you can talk to ODT?

>Does anybody know if there are any quirks about the serial port on this
>machine that would cause this (if, for instance, the PDP-11 required some
>sort of handshaking that my PC doesn't do).

RSTS/E might be picky about parity bits in some cases.  (Heaven knows
that it's incredibly picky about some other things!)

On the other hand, your PC might not be seeing the RTS/CTS (I forget
which one it'll actually be looking for) and this is the reason your
keystrokes never go out.  Or it might not be seeing DSR and refusing
to send keystrokes because of this.  Have you configured your comm 
software for XON/XOFF and *not* hardware flow control?

>  Also, there is a block of dip
>switches on the CPU card that appear to affect booting and serial port
>stuff.  Does anyone know where there is a list of what these switches
>control?

>From a list that John Wilson supplied to me once:

        dip switch near handle

        1       on      disables console terminal (factory use only)
        2-4     off off off     boot auto according to the dialog mode settings
                off off on      boot dev. # 1 in dialog mode settings.
                off on  off     "    "      2 "
                off on  on      "    "      3 "
                on  off off     "    "      4 "
                on  off on      "    "      5 "
                on  on  off     "    "      6 "
                on  on  on      if sw. 1 off, power up into ODT
                                if sw. 1 on , run self-test disg. in a cont loop
        5       off     enters dialog mode on power up
        6-8     on  on  on      38400 baud rate console.
                on  on  off     19200
                on  off on      9600
                on  off off     4800
                off on  on      2400
                off on  off     1200
                off off on      600
                off off off     300

        All of these s/b turned OFF if you have the console patch panel rotary
        switch connected to the cpu.

        rotary switch positions definitions.
        switch pos.s    v               v
        baud rate       auto boot       dialog mode
        38400           0               8
        19200           1               9
        9600            2               10
        4800            3               11
        2400            4               12
        1200            5               13
        600             6               14
        300             7               15

>  Furthermore....  Between the cryptically labeled switch that
>chooses monitor or boot mode and the knob that changes the baud rate is a
>knob with three settings labeled with an arrow, a talking head, and an
>uppercase T with an arrow orbiting it.  What does this knob do?  

It selects power-on mode.  I think arrow means to boot straight from the
default device, talking head means to go to interactive console dialog,
and the T with the circle around it means infinite test loop.

>Finally, assuming that the UART on the CPU board is fried and the entire
>CPU board needs to be replaced before it will work again, what are the
>chances I could get someone who has the Unix source code to compile me a
>kernel that uses one of the other serial ports as the console?

I'm sure it can be done, but I don't know of any that are easily persuaded
to do this!  It'd be far easier to disable your CPU board's console
port and drop in a separate DLV11-type interface.

-- 
 Tim Shoppa                        Email: shoppa at trailing-edge.com
 Trailing Edge Technology          WWW:   http://www.trailing-edge.com/
 7328 Bradley Blvd		   Voice: 301-767-5917
 Bethesda, MD, USA 20817           Fax:   301-767-5927

Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id KAA15820
	for pups-liszt; Tue, 15 Dec 1998 10:44:03 +1100 (EST)

From wkt at henry.cs.adfa.oz.au  Tue Dec 15 09:44:25 1998
From: wkt at henry.cs.adfa.oz.au (Warren Toomey)
Date: Tue, 15 Dec 1998 10:44:25 +1100 (EST)
Subject: Unix History Diagram
Message-ID: <199812142344.KAA05594@henry.cs.adfa.oz.au>

All,

I was thinking of trying to update my `History of UNIX' diagram at
http://minnie.cs.adfa.oz.au/TUHS/Images/unixtimeline.gif, to bring it up
to date and make it more accurate. The current status of my update is at:
	
	http://minnie.cs.adfa.edu.au/Unix_History/

I'm missing details on many of the commercial versions of UNIX:

	+ SunOS/Solaris
	+ SysVR4.x
	+ Ultrix
	+ Xenix
	+ Unixware :-)
	+ BSDI stuff
	+ lots more

If anybody can supply release dates and relationships for systems that I
don't have yet, could you email them to me with a reference where possible.

This is going to be a back-burner project, I'll do a bit here and there, but
hopefully by sometime next year we'll have a large wall-sized family tree
for UNIX.

Cheers,
	Warren

Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id OAA16605
	for pups-liszt; Tue, 15 Dec 1998 14:23:51 +1100 (EST)

From msokolov at harrier.Uznet.NET  Tue Dec 15 13:23:10 1998
From: msokolov at harrier.Uznet.NET (Michael Sokolov)
Date: 15 Dec 1998   03:23:10 GMT
Subject: Unix History Diagram
Message-ID: <199812150323.IAA09225@harrier.Uznet.NET>

   Warren Toomey <wkt at henry.cs.adfa.oz.au> wrote:
> The current status of my update is at:
>
> http://minnie.cs.adfa.edu.au/Unix_History/
   
   I have looked at it. Note that the data files are not hyperlinked. I
don't think this is intentional, is it?
   
   Being the TUHS 4BSD Coordinator :-), I feel obligated to do some work on
the 4bsd data file. Quoting:
   
> 3bsd
>         Name: 3BSD
>         Date: 1980-03
>         Reference: last-mod timestamps in Distributions/ucb/3bsd.tar
>         Successor to 32V
>         Code taken from 2bsd
> #                       virtual memory, page replacement,
> #                       demand paging
>
> 4bsd
>         Name: 4BSD
>         Date: 1980-10
>         Reference: Quarter Century of UNIX by Peter Salus, pg 164
>         Successor to 3bsd
   
   Are you sure that virtual memory appears first in 3BSD? I have always
thought that it's a 4BSD milestone. Page replacement and demand paging
probably go with it.
   
> 4.2bsd
>         Name: 4.2BSD
>         Date: 1983-09
>         Reference: Quarter Century of UNIX by Peter Salus, pg 164
>         Successor to 4.1cbsd
   
   I would add the following comment:
   
> #                       Landmark filesystem change.
> #                       VAX hardware support extended to 11/730.
> #                       Now runs on 11/780, 11/750, 11/730.
   
   Further:
> 4.3bsd
>         Name: 4.3BSD
>         Date: 1986-06
>         Reference: Quarter Century of UNIX by Peter Salus, pg 165
>         Successor to 4.2bsd
   
   I would add:
   
>         Code taken from DEC Ultrix with DEC's blessing
> #                       DNS added to the standard libc
> #                               (no MX records in Sendmail, though).
> #                       Added DEC's VAX 8600 and TMSCP support code
> #                               with DEC's blessing.
> #                       Added kernel-only support for MicroVAX II
> #                               (KA630). Without DEC's help!
> #                               It's unusable, though.
   
   Sorry, I don't know the Ultrix version (don't even know if it's a
release and not some DEC internal code), but it's obviously among the very
first.
   
   Further:
> 4.3tahoe
>         Name: 4.3BSD Tahoe
>         Date: 1988-06
>         Reference: Quarter Century of UNIX by Peter Salus, pg 165
>         Successor to 4.3bsd
   
   I would add:
   
>         Code taken from CCI's 4.2BSD-based vendor release
> #                       tahoe architecture support added.
> #                       VAX hardware support enhancements:
> #                           MicroVAX II (KA630) support made actually
> #                               usable and extended to support QVSS and
> #                               QDSS graphics.
> #                           VAX 8200 support added by Chris Torek.
> #                           New drivers for disk MSCP (U/Q and BI).
> #                       No distribution tapes for VAX ever shipped,
> #                               though.
> #                       MX record support in Sendmail!
   
   Further:
> 4.3reno
>         Name: 4.3BSD Reno
>         Date: 1990-06
>         Reference: Quarter Century of UNIX by Peter Salus, pg 165
>         Successor to 4.3tahoe
   
   I would add:
   
>         Influenced by Sun and DEC vendor systems (NFS and /var)
> #                       experimental hp300 architecture support added.
> #                       MicroVAX support extended to KA650 (MicroVAX III)
> #                               everywhere except the tmscp bootblock.
   
   Back to Warren:
> I'm missing details on many of the commercial versions of UNIX:
>
> + SunOS/Solaris
> [...]
> + Ultrix
   
   I know that SunOS and Ultrix played key roles in the history of BSD
(huge bidirectional exchange of code and ideas between CSRG, Sun, and DEC),
but I don't know anything about versions and such.
   
> + BSDI stuff
   
   Just like 386BSD, FreeBSD, and NetBSD, it's based on Net/2, 4.4BSD-Lite,
and 4.4BSD-Lite2. That's all I know.
   
   Sincerely,
   Michael Sokolov
   Cellular phone: 216-217-2579
   ARPA Internet SMTP mail: msokolov at harrier.Uznet.NET


Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id RAA17068
	for pups-liszt; Tue, 15 Dec 1998 17:11:10 +1100 (EST)

From mckusick at mckusick.com  Tue Dec 15 15:10:48 1998
From: mckusick at mckusick.com (Kirk McKusick)
Date: Mon, 14 Dec 1998 21:10:48 -0800
Subject: Unix History Diagram 
In-Reply-To: Your message of "15 Dec 1998 03:23:10 GMT."
             <199812150323.IAA09225@harrier.Uznet.NET> 
Message-ID: <199812150510.VAA06982@flamingo.McKusick.COM>

	From: Michael Sokolov <msokolov at harrier.Uznet.NET>
	Date: 15 Dec 1998   03:23:10 GMT
	To: pups at minnie.cs.adfa.edu.au
	Subject: Re: Unix History Diagram
	Sender: owner-pups at minnie.cs.adfa.edu.au

	...

	   Are you sure that virtual memory appears first in 3BSD? I have always
	thought that it's a 4BSD milestone. Page replacement and demand paging
	probably go with it.

The first virtual memory release was 3BSD. It's performance was
significantly improved in 4BSD.

	Kirk

Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id SAA17294
	for pups-liszt; Tue, 15 Dec 1998 18:36:33 +1100 (EST)

From grog at lemis.com  Tue Dec 15 17:36:15 1998
From: grog at lemis.com (Greg Lehey)
Date: Tue, 15 Dec 1998 18:06:15 +1030
Subject: Unix History Diagram
In-Reply-To: <199812142344.KAA05594@henry.cs.adfa.oz.au>; from Warren Toomey on Tue, Dec 15, 1998 at 10:44:25AM +1100
References: <199812142344.KAA05594@henry.cs.adfa.oz.au>
Message-ID: <19981215180615.H15815@freebie.lemis.com>

On Tuesday, 15 December 1998 at 10:44:25 +1100, Warren Toomey wrote:
> All,
>
> I was thinking of trying to update my `History of UNIX' diagram at
> http://minnie.cs.adfa.oz.au/TUHS/Images/unixtimeline.gif, to bring it up
> to date and make it more accurate. The current status of my update is at:
>
> 	http://minnie.cs.adfa.edu.au/Unix_History/
>
> I'm missing details on many of the commercial versions of UNIX:
>
>> SunOS/Solaris
>> SysVR4.x
>> Ultrix
>> Xenix
>> Unixware :-)
>> BSDI stuff
>> lots more
>
> If anybody can supply release dates and relationships for systems that I
> don't have yet, could you email them to me with a reference where possible.

OK, I've dragged out some old tapes which may be of some interest:

Tandem NonStop UX for Tandem LXN (68020), effectively System V.2, 10
April 1987.

Tandem NonStop-UX B00 for Tandem LXN (68020), effectively System
V.3.0, dated 22 August 1989.

Tandem NonStop-UX B10 for Tandem LXN (68020), effectively System
V.3.1, dated 20 September 1989.

Consensys UNIX System V.4.2.1.0, in PaCkAgE DaTaStReAm mode (yup,
that's what it says).  I'm not sure how reliable this is, but the
first package has the PSTAMP destiny921114141358, which presumably can
be interpreted as a date; certainly it's plausible.

BSD BSD/386, version 0.3.2.  The tar archive has the date Feb 28 09:18
1992 on the first few files; presumably this is US MST.

Univel Unixware 1.0, also this funny PaCkAgE DaTaStReAm.  This one has
a PSTAMP=SVR4.2 11/02/92.  I'd assume that they really meant 2
November 1992.

I've got a number of old CDs which I haven't looked at yet.  I'd guess
that I have most FreeBSD releases, and we can find the rest.

Greg
--
See complete headers for address, home page and phone numbers
finger grog at lemis.com for PGP public key

Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id AAA18317
	for pups-liszt; Wed, 16 Dec 1998 00:22:36 +1100 (EST)

From kahn at tholian.net  Tue Dec 15 23:20:37 1998
From: kahn at tholian.net (Joey KAHN)
Date: Tue, 15 Dec 1998 08:20:37 -0500
Subject: Unix History Diagram
References: <199812142344.KAA05594@henry.cs.adfa.oz.au> <19981215180615.H15815@freebie.lemis.com>
Message-ID: <36766225.6955995B@tholian.net>


Found this on a sun web page:




SunOS       Solaris     FCS     Comments                       
OpenWindows
----------- -------     ------- ---------------------------    
-----------
3.2
3.3
3.4
3.5
4.0
4.0.2                   Sept 89 (386i Roadrunner)
4.0.3                   May  89 (Sun2, Sun3/3x, Sun4)
4.0.3c                  June 89 (SPARC Sun4c only)
4.0.3 PSR_A             July 89 (SPARC 470/490 only)
4.1                     Mar  90 (3/3x/4/4c except 470/490)
4.1 PSR_A               May  90 (SPARC only for 390/490) 
4.1.1       1.0         Nov  90 (All Sun3/4's)                 
OW2.0/3.0
4.1.1B                  Feb  91 (SPARC only)                   
OW2.0/3.0
4.1.1.1                 July 91 (CTE patches for Sun3/3x)
4.1.1_U1                Nov  91 (Last Sun3/3x release)
4.1.2       1.0.1       Dec  91 (SPARC + Sun4m/600MP Ross)     
OW2.0/3.0
4.1.3       1.1A        Aug  92 (All SPARC+MP,Viking S10)       OW3.0
4.1.3c      1.1C        Nov  93 (LX and Classic only)           OW3.0
4.1.3_U1    1.1.1       Dec  93 (SPARC,LX,Classic/no-sun4d)     OW3.0
4.1.3_U1b   1.1.1B      Feb  94 (SPARC3.5/S10,4mm & all 1.1s)   OW3.0
4.1.4       1.1.2       Sep  94 (SPARC4m [Colorado CPUs]+new
WS)                

5.0         2.0         July 92 (Desktop Sun4c only)            OW3.0
5.1         2.1         Dec  92 (All SPARC/no-1000/2000)        OW3.1
5.2         2.2         May  93 (All SPARC + 1000/2000)         OW3.2
5.3         2.3         Nov  93 (All SPARC + SS10SX)            OW3.3
5.3         2.3 5/94    Mar  94 (SS5-audio & Voyager)           OW3.3
5.3         2.3 8/94    Sep  94 (All SPARC+SSA+S24 fb)
5.4         2.4         Dec  94 (All SPARC + Intel)             OW3.4 
5.4         2.4 3/95    Mar  95 (All SPARC+SSA)                 OW3.4
5.5         2.5         Nov  95 (All SPARC+Fusion-[NO SUN4/SUN4E]+SSA)
OW3.5



All I recall about pre 4.0 was that we were using SunOS 3.5 in '88. I'd
like to think 3.2 came out in '85 or '86--but memory isn't what it used
to be...

More research: first patch in Sun patch library:

	Patch-ID# 100001-01
	Keywords:       cc stack overflow local variable
	Synopsis: C compiler: stack overflow: too many local variables
	Date: 20-Apr-88

	SunOS release:
        	3.4, 3.5


Sun's bug database still contains bug reports going back to 3.2 (heck,
even 2.2 and 1.0) but none of them have dates ;(((

Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id CAA18903
	for pups-liszt; Wed, 16 Dec 1998 02:10:43 +1100 (EST)

From rdkeys at seedlab1.cropsci.ncsu.edu  Wed Dec 16 01:04:11 1998
From: rdkeys at seedlab1.cropsci.ncsu.edu (User Rdkeys Robert D. Keys)
Date: Tue, 15 Dec 1998 10:04:11 -0500 (EST)
Subject: Unix History Diagram
In-Reply-To: <199812142344.KAA05594@henry.cs.adfa.oz.au> from Warren Toomey at "Dec 15, 98 10:44:25 am"
Message-ID: <199812151504.KAA26443@seedlab1.cropsci.ncsu.edu>

> All,
> 
> I was thinking of trying to update my `History of UNIX' diagram at
> http://minnie.cs.adfa.oz.au/TUHS/Images/unixtimeline.gif, to bring it up
> to date and make it more accurate. The current status of my update is at:
> 	
> 	http://minnie.cs.adfa.edu.au/Unix_History/
> 
> I'm missing details on many of the commercial versions of UNIX:
> 
> 	+ SunOS/Solaris
> 	+ SysVR4.x
> 	+ Ultrix
> 	+ Xenix
> 	+ Unixware :-)
> 	+ BSDI stuff
> 	+ lots more

A couple of lesser known BSDish oddities from Big Blue....

Add IBM's AOS.  That was a straight 4.3BSD port dating from 1987 or 1988.
This was the only official port for the RT-PC hardware.

Add IBM's unofficial ``Reno'' port.  That was a somewhere between 4.3/4.4
port dating from 1991 or 1992.   It was apparently done by IBM or IBM
contractors.  It looks very straight 4.4, in appearance.

Add IBM's unoffical ``4.4Lite'' port.  That was a somewhere between 4.4
and the real Lite dating from 1994 or 1995.  It was apparently done by
IBM or IBM contractors, with source trees from two development streams
combined together to resolve developmental divergences.

They all were used on the RT-PC hardware (ROMP Risc processor).

The 4.3 is very nice.  Code size about 75 megs binary.  It runs fine
on a small machine with 8 megs ram and 115 megs HD, or the biggest
RT class machine.  The C compilers are slightly broken, but usually
can be worked around (good old pcc seems the best).

The Reno is fair to good, but missing things like working tape I/O.
You can tar or dump, but no other tape functions work correctly.
Code size about 150 megs binary.  It needs 16M ram and 300mb HD.
I dunno exactly how ``Reno'' it really is.

The 4.4Lite is fair to good, but still missing working tape I/O.
Code size about 300 megs binary.  It needs 16M ram and 300mb HD.
Bloat seems to have set in on this one, since the whole system is
well over 1 gig in size.  It barely will run on two 300mb HD.
The login says it is 4.4Lite and not straight 4.4.  There is no
indication of how pure ``Lite'' it really is.

I dunno anything about how these originated developmentally, but
the AOS seems to be vanilla 4.3BSD and all else may have developed
from that, possibly after the RT line became back-burner stuff.
I would be very interested in any history from anyone on the list
that was around IBM at the time on these.

.......

Add Xenix for the Radio Shack 16B machines on 8 inch floppers.
That seems to date from around 1982 or 1983, although I have
misplaced my disks on that one, and don't have the machine anymore.
I was thinking someone on the list had one of those beasts running?

That is all I can think of offhand to add.....

Bob Keys

p.s.  Anyone got a spare V7ish Xenix they would part with for x86
      hardware?  I would like to try a native suite rather than
      an emulator, if possible.  There were one or two such ports
      I am thinking like Xenix, Microport, or PC-IX maybe?  I just
      missed one a few days ago at out state surplus house, when I
      picked it up, looked at it, set it down, and then someone
      else grabbed it... oh, well....(:+{{.....


Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id FAA19970
	for pups-liszt; Wed, 16 Dec 1998 05:43:04 +1100 (EST)

From rdkeys at seedlab1.cropsci.ncsu.edu  Wed Dec 16 04:36:37 1998
From: rdkeys at seedlab1.cropsci.ncsu.edu (User Rdkeys Robert D. Keys)
Date: Tue, 15 Dec 1998 13:36:37 -0500 (EST)
Subject: Unix History Diagram --- AOS quirks
In-Reply-To: <19981215122947.B11834@rek.tjls.com> from Thor Lancelot Simon at "Dec 15, 98 12:29:47 pm"
Message-ID: <199812151836.NAA26799@seedlab1.cropsci.ncsu.edu>

> > A couple of lesser known BSDish oddities from Big Blue....
> > 
> > Add IBM's AOS.  That was a straight 4.3BSD port dating from 1987 or 1988.
> > This was the only official port for the RT-PC hardware.
> 
> I have a paper about this port which claims that it's in fact tahoe or so,
> and has an independent implementation of mmap().  I'll try to dig it up --
> 
> I think it was in one of the old Waite Group books.

Please do!  I would like to see that.  I did see at one time Tahoe
mentioned, but I did not understand how the IBM ports were related
through that.  There are so few folks around that know anything about
these IBM critters, even on the old RT newsfeed.  Most of the stuff
has become dumpster fodder, sadly, although I had the good fortune
this past week to resurrect two RT's from the dumpster, and get one
up by combining sufficient parts to get it to boot.

What specifically would one look for to exactly differentiate
a vanilla 4.3, from a Tahoe, from a Reno, from a 4.4, from a 4.4Lite,
on non-standard hardware?  The books get somewhat obscure on this
unless running VAXen or HP300's or such.  The RT is a little bit
non-standard.  I was thinking it was a 68000ish machine in IBM's
wrappers, but others have said it was distinctly different from a
68000 based line.  Also, I can't find anyone that was in on the
AOS project enough to know from whence it was originally derived.
The dating seems to be 1987 or 1988.  Was Tahoe around then?
Salus suggests straight 4.3 was June of 1986, and Tahoe was June
of 1988 (Salus, p. 165).  Anyone around CSRG then that remembers
when IBM got what code?  Salus does not mention any IBM AOS stuff,
only the mainframe stuff.  AOS seems to be mostly a sleeper, almost
forgotten in time.

.....

> > Add IBM's unoffical ``4.4Lite'' port.  That was a somewhere between 4.4
> > and the real Lite dating from 1994 or 1995.  It was apparently done by
> > IBM or IBM contractors, with source trees from two development streams
> > combined together to resolve developmental divergences.
> 
> Someone here had a tape of this, yes?

There is a Finnish repository that has some of it relating to the 4.3
port, and one or two other RTish archives.  Try something like jumo.luti.fi,
or jumi.luto.fi, or something like that, but I don't have the url exactly,
and can't find the stick'em note where I ran across it.

Yes, there was an IBM'er that said he had some original tapes.  I was
hoping he would check with someone at IBM to see what the status was.
There was a group at Carnegie-Mellon that had some machines with AOS,
but I don't have any pointers to anyone up there, for sure.  I would
hope the old RT boxes and AOS would fall under the Antique Unix umbrella,
and thus, be amenable to the PUPS archives scope of things.  But, I
am only a newbie voice in the crowd.....

>From what I have found out, there were two install tapes and two boot
floppies.

The main boot floppy is the sautils disk (stand alone utilities).
That then loads a miniroot floppy that does the scripted install.
The scripts don't work unless you have the original tapes, and
the orignal hardware configuration which was a pair of 70mb esdi
drives.  The installation needs to be done manually, instead, if
the hardware differs from that.  It should be a straight 4.3 style
restore process.  I guess they expected only to have dual 70mb
esdi drives in the old RT tower machines, as AOS platforms.

The first tape is the combined root and user dumps to hd0a and hd0g.
The second tape is the source tree dump to hd1g.

> The AOS releases I saw all came with source.  I wish IBM would donate the
> bits they wrote -- much information on ROMP processor bugs, etc. simply
> doesn't exist anywhere else.

That is how I understand it.  There were some manuals for it, but
noone seems to know anything about those anymore, and what info I
have is more sketchy than for sure.  There was also some other machine
called an ``Academic Machine'' that was a siamesed ROMP processor
on a Model 60 PS/2 MCA bus machine.  I have not exactly understood
how that thing actually worked, and noone on the net seems to have
one, although there are two ROMP boards that are reputed to still
exist that plug into the MCA Model 60 PS/2 box.  Apparently the
Model 60 was the terminal/disk IO system and the ROMP board ran
the BSD.

> Patches to fix this circulated widely -- I recall one _very_ late night
> in Bill Cattey's office at Athena waiting for someone in Stockholm to
> send us a patch so we could make some tapes I needed the next morning.

The thing will tar/dump to the tape, but won't retension or erase
correctly.  If you know what that patch was, I would be interested
in it, for sure.  I assume it has to do with something like twiddling
the right hardware ports with the right bit patterns, maybe, to run
the retension and erase functions on the hardware.  I am curious,
though, and wonder if something like the 4.3 mt, which does work,
would work correctly in the Lite suite.  I was of the impression
that there was some binary compatibility between 4.3 and 4.4/4.4-Lite,
but I am not sure.

.....

> > The 4.4Lite is fair to good, but still missing working tape I/O.
> > Code size about 300 megs binary.  It needs 16M ram and 300mb HD.
> > Bloat seems to have set in on this one, since the whole system is
> > well over 1 gig in size.  It barely will run on two 300mb HD.
> > The login says it is 4.4Lite and not straight 4.4.  There is no
> > indication of how pure ``Lite'' it really is.
> 
> Wow, I wonder if it really is "Lite".  Again... I wish IBM would free
> the relevant bits, we've wanted for a long time to make NetBSD run on
> these beasts.  One major obstacle is that nobody at IBM seems to even
> know where the "official" sources are, or who would have authority to
> turn them over.

I have no idea how pure or impure the code is.  I came along so late
in the song and dance act that I don't know enough of the internals
to compare, yet.  So much to learn.....  Years ago I bounced this
off our IBM rep, but went to AIX on the PS/2, instead of the RT BSD.
I did not know very much then, nor now....(:+{{.....

> > I dunno anything about how these originated developmentally, but
> > the AOS seems to be vanilla 4.3BSD and all else may have developed
> > from that, possibly after the RT line became back-burner stuff.
> > I would be very interested in any history from anyone on the list
> > that was around IBM at the time on these.
> 
> Me too.

Who all on the list were IBM'ers in that era that might still remember
enough of this to fill us in?  The history is half the fun, and sure
makes the perspective on the rest more interesting and well rounded.

Anyone on the list actually playing around and running an RT?
I am beginning to feel very lowendian that I am not on a PDP11, VAX,
HP300 or such.....{:+{{...   but, a VAXStation 3500 just appeared
in surplus.... maybe the bidding force will be with me.

Bob Keys


Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id GAA20122
	for pups-liszt; Wed, 16 Dec 1998 06:15:11 +1100 (EST)

From msokolov at harrier.Uznet.NET  Wed Dec 16 05:14:23 1998
From: msokolov at harrier.Uznet.NET (Michael Sokolov)
Date: 15 Dec 1998   19:14:23 GMT
Subject: A program to read tapes in a snap
Message-ID: <199812151914.AAA10682@harrier.Uznet.NET>

Dear PUPS/TUHS members,

While exchanging tapes and tape images with a number of people on this list, I
have mentioned the existence of this program to a number of people, but so far
I haven't given it to anyone. Now I'm posting it to the list for everyone's
benefit. This program can read a tape on a UNIX box without the user having to
know anything about its format. This program automatically determines how many
files are on the tape, what is the record size for each, and whether there are
any oddities such as partial records. It saves each tape file into a separate
disk file and produces a log of everything found on the tape.

It's a simple C program and should compile and run on virtually any UNIX or
UNIX-like system. The original version was written by one guy I met on another
list once and then it was significantly enhanced by me. I include it below as
a uuencoded gzipped tarball.

Sincerely,
Michael Sokolov
Cellular phone: 216-217-2579
ARPA Internet SMTP mail: msokolov at harrier.Uznet.NET

Enclosure: uuencoded cptape.tar.gz:

begin 644 cptape.tar.gz
M'XL("`ZQ=C8``V-P=&%P92YT87(`[5AM4QLW$.:K]2L$-(,-QOC`.!D[ID,(
MM&D)S$#2-YKIB#N=?<-9<N_D&)KPW[N[.OGN'%+:SD`^Y'8FPTE:[<NS;W)>
MBRL91K%<>D#RVNUNI\.7./?:W1W\RSN[M+;D=9YRWNWN[.[NM+>];6)K[R[Q
M]D,:Y6B:&I%POC2^3CO=?^![.PS.'\.>1Z95M at H1>)UE`0]UPOV)$1/)5AD[
M??'#H#86D6II=GYVD'W[C!T<'>]_=SZH;9XR9ME[M6_JP-Y at -=_G]I-O:B>+
M?6DW*_H,G1WNOWQ]^+`Z[JE_K[-=J/^=I\C6WNU6]?\89`N4)U($*1><%I'B
M6DF>CK1I\DDL_$@-N13^R!Y3HXB4T<"?RHE(A)$\B-(K1B="!3S6PR%>,B/D
MA*8R%B;2BHM+/36 at S-=)P-/H+YFV7`,A13+]-WKLB1)C&?`U_&XIM=;DLY%,
M)%.*1RDI-C.]&43#R,#M/Z=2F4C$7$W'ES+A.B06$@1V$3OJK(/O@?2CL8 at 9
M)H9!+V:1&?&VUVCQ-R.9VEL`5B*Y#[@9L"*R(OQIDH`>,!)<-#JY:?$C:*AF
M%*4,.%.MR$I%<*-DP96<D>8F03[3TSC@"O&*XYM,/'#-!5*#CDR3^0$'8."+
M\$ZF*FNU/$ST&(U))$![,I=D#R&DJ.!2T at V1@K at XUK.T-X_"9DSF6!>?IQ/`
M0L1[C!&X^8;#&(/@P$R$=04`?!_YH,SR$EQ-+EO#5I-MP=F62L:FC6""D%D4
MQ[F?=P667*:L6(P60]?+E^:VK]FH"1Y'J4$+`88\K5)[2E;GR<B<IM;7,Z_L
M1']8'??T_]W=;KO0_]O(MMWUJO[_&+2USOBZ:P^;W->3FV*90.%,U972,^4*
M)99J:$9P:8NQU4CY\33`OF""2+=&>X6MT%<F+F_))%$+7.E-ND65#KML-8#B
MA39X\N+M48V>!J at CI#7?@U7Y7J3]3(-4010R!L."#Z71$\/KC3Z3UT8FT!A'
M$.!UV!3)<+Z)K+`5J:")?\&R?JX?U)V_^NW0FM#=>=:I;:WS?1_]IZFF^1C&
M6;W3:/*QN+9X7<;:O[)MI`8$H&(W.3\X?T7GJ6M</^W_ at LW3Z_[8RABWR'`6
M:`2_COT[!*- at A"(N#7+*;O;9T:OC0[Z>'?79!X860@*;R(<XI=%001,D?R^G
M82B3B\R3=WWBG+/$&MRP`57:GI$:D*HG,)\&O+UP`X\@H'#BY?Q&HU&X(IVP
M!"[LQ!?/[M1(\]%'C`!L/$:(ZOW^W)2-C0;_P&K$?'EC9(J#$GAKE#G6K-K\
M`-;X9PZ9];GIP@<94(/DJ>?\SWF;Y*/J"8C427UE_OQ907X\2:290H9X?5I!
MY'%^8\R$XG0)0U:[Y3*&MT!9P6!0T(!'#M&&W8(3,LF/=2KK"%\#3FJX7;0)
M'DF3J0U'CQ,O&4<\\CHR=8^6M_!ODD`@POK*&W!C+)(K&+0P%*%L:2JN/FEO
M3W]7*TT7/[J7?6]LN$4><U)Q:_^@?[G98%!ZAQJ$SQJ7P580DD&4P0%`$D:I
MAB=#((QP[08>:`CHI^E"N,Z2R!BI,`D<J,MWH.IP.'>/MMS_9G'&]_B3N(1(
M,\,5:!Y'\@<US8O0\H29EFR[R5>._KN6.U2EF=R\@$`T=464O!`]S!H(%KV9
M2C?:W6YW;KGE&O!-[_X$0TF?3;!"?G at VS+94LWRIY34-.X6:_323%HIQ>5#H
M!R4CLU#^+!(%D>PY8%<!TW)F8U'B)@E%N,LH.U/S*"S@[A*J$.;:IS'^'W;<
MK_HVR^=B8YLG1I;SL(U?ME'D[:TDR+E0NK=<B$3#EL==@2?AI>+U^K90\S;G
M2IG:]2V>A?:$935]<OKF['#_X/O#E[AKW:)YAB_+.HQ<'WZB),/W=I#ANL_L
M1%[';3?$\-`OS!(WY.@'QH"?O#T^MJ>E$5 at ZL?=H&-QU,9^C',LBWP1GPWAH
M8T";LQ&*KM=]V+//B8(?D!!Q;Z710)`/3X\(WA1^3<#OD[I/*U]`TUN+UWH6
MO;(C[AEB at PT!NH)O>':(:6QZ[NZW[JXUC1IUD3^+AK46HY^Y\/%C]J9!X]!D
M:+$>V>2R&MYIP`L^3%,QQ-JW#[\+^-F7V?F.0((DQKR at 7K#=Z"_J*_B4#6P7
MCA![1?$<=,U6W"A>SBNM/(:+`C-G\SY4<G<AOAB2"^OTNWZ!(R"LP90B?Y.?
M_G'V\O3D^%?HEIE7-*6S&]0NT9]YN8`$>O'9_Q9QI9-CXY6QR<KH,T^Y/I3'
BEW[O5U1111555%%%%5544445551115\?_0UI&$I7`"@``)6Q
`
end


Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id GAA20201
	for pups-liszt; Wed, 16 Dec 1998 06:34:19 +1100 (EST)

From pat at transarc.com  Wed Dec 16 05:34:00 1998
From: pat at transarc.com (Pat Barron)
Date: Tue, 15 Dec 1998 14:34:00 -0500 (EST)
Subject: Unix History Diagram --- AOS quirks
In-Reply-To: <199812151836.NAA26799@seedlab1.cropsci.ncsu.edu>
Message-ID: <Pine.GSO.3.96.981215141724.4474C-100000@smithfield.transarc.com>

On Tue, 15 Dec 1998, User Rdkeys Robert D. Keys wrote:
> [...] The RT is a little bit
> non-standard.  I was thinking it was a 68000ish machine in IBM's
> wrappers, but others have said it was distinctly different from a
> 68000 based line.

No, the ROMP (the RT's CPU) is a RISC CPU.  I have a processor reference
for the C-ROMP (the CMOS version that was on the 6152 Academic
Workstation), but I only have hardcopy.

> Yes, there was an IBM'er that said he had some original tapes.  I was
> hoping he would check with someone at IBM to see what the status was.

That would probably be me.  I'm still looking - I have a call in right now
to someone who might be able to help.

> There was a group at Carnegie-Mellon that had some machines with AOS,
> but I don't have any pointers to anyone up there, for sure.

Best bet would probably be someone at the ITC or the CS department, or the
Andrew Consortium.  Don't really know many of those folks anymore, though,
and not sure if anyone from the right time period is still around.

> [...]  There was also some other machine
> called an ``Academic Machine'' that was a siamesed ROMP processor
> on a Model 60 PS/2 MCA bus machine.  I have not exactly understood
> how that thing actually worked, and noone on the net seems to have
> one, although there are two ROMP boards that are reputed to still
> exist that plug into the MCA Model 60 PS/2 box.  Apparently the
> Model 60 was the terminal/disk IO system and the ROMP board ran
> the BSD.

I have one in my living room....  Yes, your description is pretty much
correct.  The C-ROMP co-processor plugs into the Model 60 (though I don't 
know why it couldn't be used with another type of Microchannel PS/2). The
co-processor card has the C-ROMP CPU, support hardware, and memory.  To
IPL the thing, you run a DOS program on the PS/2 that loads the boot
program into the C-ROMP memory, and twiddles some bits that start the
processor.  The C-ROMP board pretty much takes over the machine, and uses
the PS/2 itself as an I/O processor.

--Pat.





From msokolov at harrier.Uznet.NET  Wed Dec 16 06:04:56 1998
From: msokolov at harrier.Uznet.NET (Michael Sokolov)
Date: 15 Dec 1998   20:04:56 GMT
Subject: Unix History Diagram --- AOS quirks
Message-ID: <199812152005.BAA10743@harrier.Uznet.NET>

   "User Rdkeys Robert D. Keys" <rdkeys at seedlab1.cropsci.ncsu.edu> wrote:
> What specifically would one look for to exactly differentiate
> a vanilla 4.3, from a Tahoe, from a Reno, from a 4.4, from a 4.4Lite,
> on non-standard hardware?
   
   Telling between pre-Reno and post-Reno is trivial. If you see
directories like /usr/ucb, /usr/doc, /usr/man, binaries in /etc and in
/usr/lib, and so on, it's pre-Reno. If you see all docs, manpages, etc.
moved into /usr/share, /usr/ucb gone, no binaries in /etc or in /usr/lib,
strange critters appearing like /sbin, /usr/sbin, /usr/libexec, and
/usr/libdata, it's post-Reno.
   
   Distinguishing between plain-4.3-based and Tahoe-based non-UCB systems
can be tough, and, frankly, pointless. Aside from hardware issues, the
noticeable differences between 4.3 and 4.3-Tahoe are the location of
source-form manpages (/usr/man/man[1-8] on 4.3, /usr/src/man/man[1-8] on
Tahoe), MX record support in Sendmail (present in Tahoe but not in 4.3),
and the Olson timezone implementation, i.e., that big pile of zoneinfo
files (again present in Tahoe but not in 4.3).
   
   The reason exercises like this are pointless is because when some brave
vendor takes BSD sources and tries to make a vendor release from them, they
usually have their own mind about what the system should look like,
different from CSRG's. Vendors often take different pieces from different
systems on a subjective basis. A vendor release can have the feature set of
one system and the look and feel of another. For example, Ultrix V4.0 has
the classical pre-Reno look and feel, but yet is POSIXized to about the
same extent as Reno. Thus the blurb above about telling between pre-Reno
and post-Reno systems refers to the look and feel of a system, not to its
feature set. The plain 4.3 vs. Tahoe distinction doesn't really hold in
vendor systems either. Ultrix V4.0 has MX record support in Sendmail, but
its man mechanism is plain 4.3 vintage. Don't remember if there were
zoneinfo files there or not.
   
   /var also has an interesting story. In the BSD line it appears in Reno,
but it originates in SunOS and Ultrix, systems with pre-Reno look and feel
on which a number of directories were moved from /usr to the newly-created
/var. Thus on 4.3 or 4.3-Tahoe you have /usr/spool/mail, on SunOS and
Ultrix you have /var/spool/mail, and on Reno and later you have /var/mail.
   
   Oh, I forgot to mention that the filesystem format changed slightly and
disk label support was added between 4.3 and 4.3-Tahoe. Again this is
certainly meaningless for vendor systems because they always tweak the
filesystem format themselves and have their own disk label implementations
that are not compatible with the one in Tahoe and later BSD releases.
   
> The dating seems to be 1987 or 1988.  Was Tahoe around then?
   
   The Tahoe tape shipped in the summer of 1988, but of course the work at
CSRG was going all the time.
   
> Salus suggests straight 4.3 was June of 1986, and Tahoe was June
> of 1988 (Salus, p. 165).
   
   Correct.
   
> but, a VAXStation 3500 just appeared
> in surplus.... maybe the bidding force will be with me.
   
   Good luck. 4.3BSD-Quasijarus1 will run like a charm on it. If the force
is really with you, you may even be able to run it with the graphical
console, but if not, it's trivial to pull the QDSS boards out and run the
machine as a standard VAX.
   
   Sincerely,
   Michael Sokolov
   Cellular phone: 216-217-2579
   ARPA Internet SMTP mail: msokolov at harrier.Uznet.NET


Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id HAA20397
	for pups-liszt; Wed, 16 Dec 1998 07:11:43 +1100 (EST)

From rdkeys at seedlab1.cropsci.ncsu.edu  Wed Dec 16 06:05:16 1998
From: rdkeys at seedlab1.cropsci.ncsu.edu (User Rdkeys Robert D. Keys)
Date: Tue, 15 Dec 1998 15:05:16 -0500 (EST)
Subject: Unix History Diagram --- AOS quirks
In-Reply-To: <Pine.GSO.3.96.981215141724.4474C-100000@smithfield.transarc.com> from Pat Barron at "Dec 15, 98 02:34:00 pm"
Message-ID: <199812152005.PAA27002@seedlab1.cropsci.ncsu.edu>

> On Tue, 15 Dec 1998, User Rdkeys Robert D. Keys wrote:
> No, the ROMP (the RT's CPU) is a RISC CPU.

OK.

> > Yes, there was an IBM'er that said he had some original tapes.  I was
> > hoping he would check with someone at IBM to see what the status was.
> 
> That would probably be me.  I'm still looking - I have a call in right now
> to someone who might be able to help.

Oh, now that might be interesting.  Maybe the old AOS BSD will roll again!

> > There was a group at Carnegie-Mellon that had some machines with AOS,
> > but I don't have any pointers to anyone up there, for sure.
> 
> Best bet would probably be someone at the ITC or the CS department, or the
> Andrew Consortium.  Don't really know many of those folks anymore, though,
> and not sure if anyone from the right time period is still around.

All I could find was one more recent fellow that had a ROMP board and
a set of BSD tapes for it, but he had not apparently gotten it running.
Also, most of the original folks seemed to be gone.  Most everyone
I have run into has wanted to run AIX on the RT hardware instead of BSD.
I am beginning to feel like the odd man out if I shun AIX on the RT.

> I have one in my living room....

Gee, that make 3 extant boards and 1 real live machine!  Neato!
Have you had yours up with a BSD?  Anyone for a BSD rolling party?
Sounds like a little interest, maybe?

I wish Blue would donate that to the PUPS archives, yup, yup, yup.
That would be a nice gesture, and ought to be worth some PR brownies
for them.  Technically, would that not fall under the Ancient Unix,
umbrella, anyway?  That would be a legalese mumbo jumbo to sort out,
though, and not my forte.

Bob


Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id IAA20667
	for pups-liszt; Wed, 16 Dec 1998 08:17:30 +1100 (EST)

From rdkeys at seedlab1.cropsci.ncsu.edu  Wed Dec 16 07:10:49 1998
From: rdkeys at seedlab1.cropsci.ncsu.edu (User Rdkeys Robert D. Keys)
Date: Tue, 15 Dec 1998 16:10:49 -0500 (EST)
Subject: Unix History Diagram --- AOS quirks
In-Reply-To: <199812152005.BAA10743@harrier.Uznet.NET> from Michael Sokolov at "Dec 15, 98 08:04:56 pm"
Message-ID: <199812152110.QAA27141@seedlab1.cropsci.ncsu.edu>

>    "User Rdkeys Robert D. Keys" <rdkeys at seedlab1.cropsci.ncsu.edu> wrote:
> > What specifically would one look for to exactly differentiate
> > a vanilla 4.3, from a Tahoe, from a Reno, from a 4.4, from a 4.4Lite,
> > on non-standard hardware?
>    
>    Telling between pre-Reno and post-Reno is trivial.

.....  Lotsa neat info for us lesser newbie types.

My main reason for asking was to try to place the AOS historically.
It is definitely pre-Reno, and the manpages are in user/man/manX
as to source pages.  I was thinking it had timezones, though.
The compiler was still pcc, and a custom Hi-Tech C thing called hc.

>    The reason exercises like this are pointless is because when some brave
> vendor takes BSD sources and tries to make a vendor release from them, they
> usually have their own mind about what the system should look like,
> different from CSRG's.

Granted, but the AOS system felt very unmodified, subjectively.  So,
I was not thinking it was almost Reno, or somewhere close to that.
Knowing anything of the detailed structure helps me to place it
developmentally.

>    Oh, I forgot to mention that the filesystem format changed slightly and
> disk label support was added between 4.3 and 4.3-Tahoe. Again this is
> certainly meaningless for vendor systems because they always tweak the
> filesystem format themselves and have their own disk label implementations
> that are not compatible with the one in Tahoe and later BSD releases.

OK, the AOS seemed to have a disklabel, but of a different format from
later releases.  fsck has a field day if an update to one of the later
after-AOS builds is installed.

What would one use to differentiate the Lite from earlier systems?
The last build was in the 4xx range, and dated 1996, IFF I am remembering
right.  It is running gcc at the 2.5.8 level.  Are there key file system
dates or revision levels that would help to indicate how late it is?

......

> > but, a VAXStation 3500 just appeared
> > in surplus.... maybe the bidding force will be with me.
>    
>    Good luck. 4.3BSD-Quasijarus1 will run like a charm on it. If the force
> is really with you, you may even be able to run it with the graphical
> console, but if not, it's trivial to pull the QDSS boards out and run the
> machine as a standard VAX.

It is so ugly, noone in their normal PCish minds locally should bid on
it.  So, maybe I will have a chance at it in a reasonable sort of way.
The machine is just the main tower box, and nothing else.  It does have
a TK70 tape, but I was unable to open it up on the pallet and see what
was inside.  There were no other bits and pieces with it.  I was thinking
I could run it with a VT100ish terminal of some sort, as a bare-bones
system in the basement.  How would the front/back cover open up, so
I could do a quick spot check and see what actually was inside?
If it has been gutted, I would probably pass, but if it was mostly
there, it might be worth looking at.

>    Sincerely,
>    Michael Sokolov

Thanks!

Bob Keys


Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id JAA20871
	for pups-liszt; Wed, 16 Dec 1998 09:16:32 +1100 (EST)

From wkt at henry.cs.adfa.oz.au  Wed Dec 16 08:17:01 1998
From: wkt at henry.cs.adfa.oz.au (Warren Toomey)
Date: Wed, 16 Dec 1998 09:17:01 +1100 (EST)
Subject: Unix History Diagram
Message-ID: <199812152217.JAA06715@henry.cs.adfa.oz.au>

All,
	Goodness, that was a lot of email :-) I spent the night playing with
the Graphviz tools, and my first drawing of the UNIX family tree is now on
the web page I mentioned yesterday

	http://minnie.cs.adfa.edu.au/Unix_History/

I've fixed the broken HTML so that Lynx will read the pages. I haven't
had a chance to convert all the version/date information that was sent in,
and I probably won't get to it before January.

Mind you, if people convert it into the file format I'm using, and mail it
to me, then it will be included immediately :-)

Anyway, thanks for all the feedback, and I'll get to it eventually.

Cheers,
	Warren


Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id JAA20983
	for pups-liszt; Wed, 16 Dec 1998 09:32:08 +1100 (EST)

From msokolov at harrier.Uznet.NET  Wed Dec 16 08:31:08 1998
From: msokolov at harrier.Uznet.NET (Michael Sokolov)
Date: 15 Dec 1998   22:31:08 GMT
Subject: Unix History Diagram --- AOS quirks
Message-ID: <199812152231.DAA10882@harrier.Uznet.NET>

   "User Rdkeys Robert D. Keys" <rdkeys at seedlab1.cropsci.ncsu.edu> wrote:
> [...] the manpages are in user/man/manX
> as to source pages.
   
   This is definitely plain 4.3 vintage, not Tahoe vintage. This does not
necessarily mean that other parts of the system are straight 4.3, though,
they could easily be Tahoe vintage. What version of Sendmail does it ship
with?
   
> I was thinking it had timezones, though.
   
   Well, every UNIX system has some kind of timezone system, the question
is what kind. On plain 4.3 it just remembers "OK, I'm 8 hours behind
Greenwich" or so. On Tahoe it has a pile of zoneinfo files trying to
describe the timezone and daylight saving time rules for every city in the
world. I think these files are in /etc/zoneinfo, or maybe
/usr/lib/zoneinfo, something like that.
   
> Granted, but the AOS system felt very unmodified, subjectively.  So,
> I was not thinking it was almost Reno, or somewhere close to that.
   
   Well, that's good.
   
> Knowing anything of the detailed structure helps me to place it
> developmentally.
   
   Then why don't you take its source and the sources for 4.3, 4.3-Tahoe,
or whatever you suspect it is, and see for yourself? In my directory on
minnie (Distributions/4bsd) you can find the full sources for 4.3 (both
plain and Rev 2), but unfortunately not for Tahoe (Rick Copeland hasn't
been able to read that part of the Tahoe tape due to media defects).
However, the CSRG Archives CD-ROMs have the full sources for everything,
including Tahoe.
   
> OK, the AOS seemed to have a disklabel, but of a different format from
> later releases.
   
   Is the command actually called disklabel, or is it called something like
format or chpt? (This is how it's called under SunOS and Ultrix,
respectively, and they are indeed incompatible.)
   
> What would one use to differentiate the Lite from earlier systems?
   
   If you are trying to tell between 4.4BSD and 4.4BSD-Lite, don't bother.
If you system boots, it can't be Lite. "Lite" means that there are no
binaries, only sources, and the sources won't build because about one half
of them is deleted. Now, it's true that there had been some changes to the
source tree between the 4.4BSD and 4.4BSD-Lite releases. If you want to see
if these changes have been incorporated into your vendor release, check the
Sendmail version number. For 4.4BSD it's 8.1. For 4.4BSD-Lite it's
8.6.something aka 8.7 Beta Rev something.
   
> It is running gcc at the 2.5.8 level.
   
   Since I generally don't do gcc, I don't know anything about its version
numbers. However, just because it's gcc the system has to belong to Class
3. This is my own classification. Class 1 is True UNIX(R). Everything I
develop under Quasijarus Project will also belong to Class 1. It includes
everything from the original PDP-11 UNIX to 4.3BSD-Tahoe. Class 2 is
4.3BSD-Reno. In some respects it's still True UNIX (the compiler is pcc and
the kernel is 90% pure), but in other respects it's fallen (the directory
hierarchy is turned upside down and the evil spirit of POSIX starts to
creep in). Class 3 is Net/2, 4.4BSD-*, and Free/Net/OpenBSD. These are 100%
fallen (the evil spirit POSIX runs the sinful world, VAX support in the
kernel permanently broken, the compiler is gcc).
   
> The machine is just the main tower box, and nothing else.  It does have
> a TK70 tape [...]
   
   What else do you need? The disks are internal, and you do have a tape
drive. In fact, not just "a" tape drive, but a TK70, one of the best.
Unfortunately it can't write TK50 tapes, but it can read them, and its
native format is 3 times denser than the TK50 one and much faster too.
   
> I was thinking
> I could run it with a VT100ish terminal of some sort [...]
   
   Sure! You say it's badged as a VAXstation, so you'll probably need to
pull two or three boards out to make it use the serial console.
   
> [...] as a bare-bones system [...]
   
   What do you mean "bare-bones"? It's a VAX! What can be more powerful? It
has a KA650 CPU, which is not bad at all (2.8 VUPs), and you can upgrade it
to a KA655 (3.8 VUPs) or KA660 (5 VUPs) with a single board swap (the
memory is the same for all). KA650/655 is already supported by 4.3BSD-Reno
and Ultrix, and will be supported by 4.3BSD-Quasijarus1 as soon as I
release it. KA660 is not supported yet, but it will only take a dozen lines
or so to add this support.
   
> How would the front/back cover open up, so
> I could do a quick spot check and see what actually was inside?
   
   There is nothing interesting in the back. The front door opens
trivially, just push the handle and swing the door open. You'll a 12-slot
backplane with a cover over each slot. The covers are supposed to have
labels on them. Reading them from right to left, you should see the CPU
(KA650-BA), memory (some variant of MS650), Ethernet (DELQA-SA), a disk
controller (probably KDA50 or KFQSA), and the TK70 controller (TQK70). If
all these pieces are there, you are all set! Of course if there is more
stuff there you are even more lucky.
   
   Sincerely,
   Michael Sokolov
   Cellular phone: 216-217-2579
   ARPA Internet SMTP mail: msokolov at harrier.Uznet.NET


Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id KAA21142
	for pups-liszt; Wed, 16 Dec 1998 10:12:56 +1100 (EST)

From rdkeys at seedlab1.cropsci.ncsu.edu  Wed Dec 16 09:06:19 1998
From: rdkeys at seedlab1.cropsci.ncsu.edu (User Rdkeys Robert D. Keys)
Date: Tue, 15 Dec 1998 18:06:19 -0500 (EST)
Subject: VAXen funzies.... (gotta start somewhere).
In-Reply-To: <199812152231.DAA10882@harrier.Uznet.NET> from Michael Sokolov at "Dec 15, 98 10:31:08 pm"
Message-ID: <199812152306.SAA27350@seedlab1.cropsci.ncsu.edu>

> > How would the front/back cover open up, so
> > I could do a quick spot check and see what actually was inside?
>    
>    There is nothing interesting in the back. The front door opens
> trivially, just push the handle and swing the door open. You'll a 12-slot
> backplane with a cover over each slot. The covers are supposed to have
> labels on them. Reading them from right to left, you should see the CPU
> (KA650-BA), memory (some variant of MS650), Ethernet (DELQA-SA), a disk
> controller (probably KDA50 or KFQSA), and the TK70 controller (TQK70). If
> all these pieces are there, you are all set! Of course if there is more
> stuff there you are even more lucky.

This one does not have a handle that I can find.  There is a sliding
door over the tape drive, and then a plastic key sticks out the front
of the panel kind of like the keylock on a pc.  If that key is the
handle, then, I will open it up tomorrow when I visit surplus again
to pick up a postscript printer, and see what is there.  If that key
is not the handle, then it was not obvious what was on that side of
the box that should be the ``handle'' to open it up.

Bob


Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id KAA21280
	for pups-liszt; Wed, 16 Dec 1998 10:54:57 +1100 (EST)

From msokolov at harrier.Uznet.NET  Wed Dec 16 09:54:10 1998
From: msokolov at harrier.Uznet.NET (Michael Sokolov)
Date: 15 Dec 1998   23:54:10 GMT
Subject: VAXen funzies.... (gotta start somewhere).
Message-ID: <199812152354.EAA10978@harrier.Uznet.NET>

   "User Rdkeys Robert D. Keys" <rdkeys at seedlab1.cropsci.ncsu.edu> wrote:
> There is a sliding
> door over the tape drive, and then a plastic key sticks out the front
> of the panel kind of like the keylock on a pc.
   
   The sliding window (yes, the DEC docs call it a window and not a door)
and the key are there to control access to the tape drive, to the disk
drive control buttons, to the HALT button, to the power switch, and to the
handle that opens the front door (the one you are looking for). The key has
3 positions: top. middle, and bottom. When the key is in the top position,
the window cannot be lowered at all, and the machine is secure. When the
key is in the middle position, the window can be lowered partially, and you
can access the tape drive, the disk drive control buttons, and the halt
button, but not the power switch or the front door handle. When the key is
in the bottom position, the window can be lowered completely and you can
access everything.
   
> If that key is the
> handle, then, I will open it up tomorrow when I visit surplus again
> to pick up a postscript printer, and see what is there.  If that key
> is not the handle, then it was not obvious what was on that side of
> the box that should be the ``handle'' to open it up.
   
   Turn the key to the bottom position. Lower the window all the way down.
Near the bottom of the opening you'll see the power switch and the handle
I'm talking about. This handle moves horizontally (left and right). I don't
have one of those boxes in front of me and I don't remember whether you
need to push it to the left or to the right, but I'm sure you can figure it
out experimentally.
   
   Sincerely,
   Michael Sokolov
   Cellular phone: 216-217-2579
   ARPA Internet SMTP mail: msokolov at harrier.Uznet.NET


Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id QAA22380
	for pups-liszt; Wed, 16 Dec 1998 16:26:03 +1100 (EST)

From jimc at zach1.tiac.net  Wed Dec 16 15:25:32 1998
From: jimc at zach1.tiac.net (James E. Carpenter)
Date: Wed, 16 Dec 1998 00:25:32 -0500 (EST)
Subject: Unix History Diagram
In-Reply-To: <36766225.6955995B@tholian.net> from "Joey KAHN" at Dec 15, 98 08:20:37 am
Message-ID: <199812160525.AAA19173@zach1.tiac.net>

> All I recall about pre 4.0 was that we were using SunOS 3.5 in '88. I'd
> like to think 3.2 came out in '85 or '86--but memory isn't what it used
> to be...

I just took a quick look at my SunOS 3.2 tapes. The copyright file says:

   Copyright (c) 1986 by Sun Microsystems, Inc.

Most of the files seem to be dated September 1986. Many others are dated 
July 1986. 

- Jim


-- 
James E. Carpenter                               E-Mail: jimc at zach1.tiac.net
6 Munroe Drive
Plainville, MA  02762-1108                     ICBM: 42 00' 15"N 71 20' 00"W
PGP: 7ADE9D99  Fingerprint: 8D AF 63 EC D3 51 14 3E  F1 59 8A 68 32 63 3F 8E

Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id CAA24140
	for pups-liszt; Thu, 17 Dec 1998 02:28:03 +1100 (EST)

From rdkeys at seedlab1.cropsci.ncsu.edu  Thu Dec 17 01:20:18 1998
From: rdkeys at seedlab1.cropsci.ncsu.edu (User Rdkeys Robert D. Keys)
Date: Wed, 16 Dec 1998 10:20:18 -0500 (EST)
Subject: Ancient SunOS 1.1 tapes --- how to restore?
In-Reply-To: <199812160525.AAA19173@zach1.tiac.net> from "James E. Carpenter" at "Dec 16, 98 00:25:32 am"
Message-ID: <199812161520.KAA28340@seedlab1.cropsci.ncsu.edu>

> > All I recall about pre 4.0 was that we were using SunOS 3.5 in '88. I'd
> > like to think 3.2 came out in '85 or '86--but memory isn't what it used
> > to be...
> 
> I just took a quick look at my SunOS 3.2 tapes. The copyright file says:
> 
>    Copyright (c) 1986 by Sun Microsystems, Inc.
> 
> Most of the files seem to be dated September 1986. Many others are dated 
> July 1986. 

Speaking of old SunOS tapes..... I have a friend that dug out a pair
of SunOS 1.1 tapes that he has had for years.  Alas, they are unreadable.
Is there any way to rewrite those tapes from anyones archival materials?
Sun has graciously allowed pre-sparc materials to be available on-line
in the German Sun3 archives.  All they have seems to be SunOS-4.1.1,
though.  I am wondering if there is any interest in some of the early
Sun tapes?  Are the 1.1 tapes basically a 4.2BSD port?  Are they in
QIC-11 or QIC-24 format?

Thanks

Bob Keys




Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id CAA24206
	for pups-liszt; Thu, 17 Dec 1998 02:35:36 +1100 (EST)

From eric at fudge.uchicago.edu  Thu Dec 17 01:33:06 1998
From: eric at fudge.uchicago.edu (Eric Fischer)
Date: Wed, 16 Dec 1998 09:33:06 -0600 (CST)
Subject: Unix History Diagram
In-Reply-To: <199812142344.KAA05594@henry.cs.adfa.oz.au>
References: <199812142344.KAA05594@henry.cs.adfa.oz.au>
Message-ID: <199812161533.JAA22901@fudge.uchicago.edu>

> I was thinking of trying to update my `History of UNIX' diagram at
> http://minnie.cs.adfa.oz.au/TUHS/Images/unixtimeline.gif, to bring it up
> to date and make it more accurate.

Here are a few dates I was able to find, in the format from your
web page:

	sysV
		Name: System V
		Date: 1983-01
		Reference: System V Release Description, title page

	sysVr2
		Name: System V Release 2
		Date: 1984-04
		Reference: System V manual for 3B2, title page

	sunos2
		Name: SunOS 2.0
		Date: 1985-05-15
		Reference: SunOS 2.0 manual, title page

	sunos3
		Name: SunOS 3.0
		Date: 1986-02-17
		Reference: SunOS 3.0 manual, title page

	pwb1.0
		Name: PWB/UNIX 1.0
		Date: 1977-07-1
		Reference: /usr/news/pibs in the archived PWB distribution
	#		prerelease test versions: 1977-06-6, 1977-06-13

eric

Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id FAA24733
	for pups-liszt; Thu, 17 Dec 1998 05:01:55 +1100 (EST)

From alyosha at vrytekai.Corp.Sun.COM  Thu Dec 17 03:59:44 1998
From: alyosha at vrytekai.Corp.Sun.COM (Billy Stivers)
Date: Wed, 16 Dec 1998 09:59:44 -0800 (PST)
Subject: Ancient SunOS 1.1 tapes --- how to restore?
Message-ID: <199812161759.JAA02912@vrytekai.Corp.Sun.COM>

Hey, Robert-  

do you know if anybody from Sun Legal ever officially gave the okay
for that, because, as I was telling Warren, I have most SunOSes from
the very first V7 variant that they shipped, through the present day,
and it'd be a fairly simple matter to spool all of the sun1, sun2, and sun3
ones that are readable (should be a lot, they've been stored in carefully
climate-controlled and proper containers) to disk, and set the archives up
with them.  There are some really neat innovations in older SunOS, and it'd
be neat to compare them, and try to track the tech-crossfeeding with the
4BSD trees, and early SunOSes.  There's a lot of actual hands-on mucking
around by Bill Joy in some of the earliest releases.

	--Bill
	
	
>From: "User Rdkeys Robert D. Keys" <rdkeys at seedlab1.cropsci.ncsu.edu>
>Subject: Re: Ancient SunOS 1.1 tapes --- how to restore?
>To: jimc at zach1.tiac.net (James E. Carpenter)
>Date: Wed, 16 Dec 1998 10:20:18 -0500 (EST)
>Cc: kahn at tholian.net, pups at minnie.cs.adfa.oz.au
>MIME-Version: 1.0
>Content-Transfer-Encoding: 7bit
>
>> > All I recall about pre 4.0 was that we were using SunOS 3.5 in '88. I'd
>> > like to think 3.2 came out in '85 or '86--but memory isn't what it used
>> > to be...
>> 
>> I just took a quick look at my SunOS 3.2 tapes. The copyright file says:
>> 
>>    Copyright (c) 1986 by Sun Microsystems, Inc.
>> 
>> Most of the files seem to be dated September 1986. Many others are dated 
>> July 1986. 
>
>Speaking of old SunOS tapes..... I have a friend that dug out a pair
>of SunOS 1.1 tapes that he has had for years.  Alas, they are unreadable.
>Is there any way to rewrite those tapes from anyones archival materials?
>Sun has graciously allowed pre-sparc materials to be available on-line
>in the German Sun3 archives.  All they have seems to be SunOS-4.1.1,
>though.  I am wondering if there is any interest in some of the early
>Sun tapes?  Are the 1.1 tapes basically a 4.2BSD port?  Are they in
>QIC-11 or QIC-24 format?
>
>Thanks
>
>Bob Keys
>
>
>

----------------------------------------------------------------------
A "No" uttered from deepest conviction is better and greater than a
"Yes" merely uttered to please, or what is worse, to avoid trouble.
                -- Mahatma Gandhi


Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id FAA24883
	for pups-liszt; Thu, 17 Dec 1998 05:36:19 +1100 (EST)

From rdkeys at seedlab1.cropsci.ncsu.edu  Thu Dec 17 04:29:27 1998
From: rdkeys at seedlab1.cropsci.ncsu.edu (User Rdkeys Robert D. Keys)
Date: Wed, 16 Dec 1998 13:29:27 -0500 (EST)
Subject: Ancient SunOS 1.1 tapes --- how to restore?
In-Reply-To: <199812161759.JAA02912@vrytekai.Corp.Sun.COM> from Billy Stivers at "Dec 16, 98 09:59:44 am"
Message-ID: <199812161829.NAA28899@seedlab1.cropsci.ncsu.edu>

> Hey, Robert-  
> 
> do you know if anybody from Sun Legal ever officially gave the okay
> for that, because, as I was telling Warren, I have most SunOSes from
> the very first V7 variant that they shipped, through the present day,
> and it'd be a fairly simple matter to spool all of the sun1, sun2, and sun3
> ones that are readable (should be a lot, they've been stored in carefully
> climate-controlled and proper containers) to disk, and set the archives up
> with them.  There are some really neat innovations in older SunOS, and it'd
> be neat to compare them, and try to track the tech-crossfeeding with the
> 4BSD trees, and early SunOSes.  There's a lot of actual hands-on mucking
> around by Bill Joy in some of the earliest releases.
> 
> 	--Bill
> 	
> >Speaking of old SunOS tapes..... I have a friend that dug out a pair
> >of SunOS 1.1 tapes that he has had for years.  Alas, they are unreadable.
> >Is there any way to rewrite those tapes from anyones archival materials?
> >Sun has graciously allowed pre-sparc materials to be available on-line
> >in the German Sun3 archives.  All they have seems to be SunOS-4.1.1,
> >though.  I am wondering if there is any interest in some of the early
> >Sun tapes?  Are the 1.1 tapes basically a 4.2BSD port?  Are they in
> >QIC-11 or QIC-24 format?

I think there is great potential in all of this.

AS I UNDERSTAND IT.....

Sun apparently gave the OK to a German archive site to put the the stuff
on-line.  That is, in fact, where I picked up my sun3 tapes to resurrect
my old box.  It only seems be be pre-sparc related 68000 based stuff.
The details were given on the web site, and were discussed on one
of the Sun newsfeeds.

Try the http://doener.unix-ag.uni-kl.de/  site, and it is explained
there.  The guy actually got Sun to OK it, as far as I know, but
I have no idea of the exact legalese involved, but memory tells
me it was Sun Germany that gave the go-ahead on it.

The site may have moved to http://sun3arc.krupp.net, since I was
thinking a move was in progress a couple of months back.
I think I got to it via a link from www.sunhelp.com or www.sunfreeware.com.

The idea occurred to me that IFF Sun has gone that far, we should check
into putting the older releases there, too, as they may still exist.
Also, perhaps, as they would fit under the Ancient Unix umbrella, I would
think, then PUPS/UHS should likewise take an interest in such potential.

I would be of the opinion that any of the pre-SysIII/SysV related stuff,
in addition to the purist ATT/Berkeley releases ought to be put back for
archival use, too, as it should be covered under the Ancient Unix umbrella.

If I am too far off on that, let me know.  I am but a very minor newbie
bit player in all of this.

Bob Keys


Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id FAA24923
	for pups-liszt; Thu, 17 Dec 1998 05:50:29 +1100 (EST)

From rdkeys at seedlab1.cropsci.ncsu.edu  Thu Dec 17 04:43:43 1998
From: rdkeys at seedlab1.cropsci.ncsu.edu (User Rdkeys Robert D. Keys)
Date: Wed, 16 Dec 1998 13:43:43 -0500 (EST)
Subject: Ancient SunOS Tapes for UHS archives?????
In-Reply-To: <199812161759.JAA02912@vrytekai.Corp.Sun.COM> from Billy Stivers at "Dec 16, 98 09:59:44 am"
Message-ID: <199812161843.NAA28957@seedlab1.cropsci.ncsu.edu>

> Hey, Robert-  
> 
> do you know if anybody from Sun Legal ever officially gave the okay
> for that, because, as I was telling Warren, I have most SunOSes from
> the very first V7 variant that they shipped, through the present day,
> and it'd be a fairly simple matter to spool all of the sun1, sun2, and sun3
> ones that are readable (should be a lot, they've been stored in carefully
> climate-controlled and proper containers) to disk, and set the archives up
> with them.  There are some really neat innovations in older SunOS, and it'd
> be neat to compare them, and try to track the tech-crossfeeding with the
> 4BSD trees, and early SunOSes.  There's a lot of actual hands-on mucking
> around by Bill Joy in some of the earliest releases.
> 
> 	--Bill

It would be fun to see some of Bill Joy's hacks....(:+}}.....

I went to the archive site  http://sun3arc.krupp.net
and it attributes the permission to archive materials to a
Mr. Knieriem of SUN Germany, Research and Education.

One of the UHS folks might try to contact said Mr. Knieriem
to see if adding some of our other early stuff would be feasible.
The sun3arc site only has binaries, though.

I would assume the PUPS/UHS archives might work out some kind
of binary and source arrangement, perhaps?

Someone other than the tailwagging newbie here, should persue
this and see where it goes?

Mebbie we has started somethin' 'ere, methinks....(:+}}.....

Bob Keys


Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id GAA25126
	for pups-liszt; Thu, 17 Dec 1998 06:45:26 +1100 (EST)

From erin at coffee.corliss.net  Thu Dec 17 05:47:37 1998
From: erin at coffee.corliss.net (Erin W. Corliss)
Date: Wed, 16 Dec 1998 11:47:37 -0800 (PST)
Subject: PDP-11/73
Message-ID: <Pine.LNX.3.96.981216113259.23904B-100000@coffee.corliss.net>


So get this...

I downloaded the machine emulators package and the binaries for Unix
version 7 from the PUPS ftp site, hoping that I could use it to create a
bootable disk image to put on my PDP-11/73 that would run getty on one of
the serial ports besides the console...  I compiled the emulators on a
Slackware Linux 2.0.30 machine, and they seemed to compile OK.  From the
emulator I followed the instructions for booting Unix 7.  I had the
following error every time I tried booting:

Trap stack push abort, PC: 004567 (MOV R3,(SP))

Anybody have a clue why this is happening?  




From wkt at henry.cs.adfa.oz.au  Thu Dec 17 10:34:15 1998
From: wkt at henry.cs.adfa.oz.au (Warren Toomey)
Date: Thu, 17 Dec 1998 11:34:15 +1100 (EST)
Subject: Ancient SunOS Tapes for UHS archives?????
In-Reply-To: <199812161843.NAA28957@seedlab1.cropsci.ncsu.edu> from "User Rdkeys Robert D. Keys" at "Dec 16, 98 01:43:43 pm"
Message-ID: <199812170034.LAA13086@henry.cs.adfa.oz.au>

In article by User Rdkeys Robert D. Keys:
> I went to the archive site  http://sun3arc.krupp.net
> and it attributes the permission to archive materials to a
> Mr. Knieriem of SUN Germany, Research and Education.
> 
> One of the UHS folks might try to contact said Mr. Knieriem
> to see if adding some of our other early stuff would be feasible.
> The sun3arc site only has binaries, though.
> I would assume the PUPS/UHS archives might work out some kind
> of binary and source arrangement, perhaps?

I've emailed the webmaster at the site which the above query. I've
also added a link from the TUHS page to this site, so we don't lose
the reference.

Cheers,

> Mebbie we has started somethin' 'ere, methinks....(:+}}.....
> Bob Keys

Also we also have people inside Sun too! Sounds hopeful.

Thanks all,
	Warren


From jp at spektr.ludvika.se  Mon Dec 21 07:08:00 1998
From: jp at spektr.ludvika.se (Jorgen Pehrson)
Date: Sun, 20 Dec 1998 22:08:00 +0100 (CET)
Subject: Moving a RL02..
Message-ID: <Pine.NEB.4.05.9812202150320.660-100000@spektr.ludvika.se>

Hi,
I was given a couple of QBus PDP11 on which I'm going to run 2.11BSD or
some other version of UNIX. One /73 and one /83. Both had RL02 drives, a
couple of RD53's and loads of serial boards and an extra expansion box
each. Now there's that little question of lugging them back to my
apartment. So, is there any particular precaution I should take when it
comes to the RL02's? Are they sensitive to vibrations or something? Do
they have to be in some sort of transport mode? 

Is there some information available online which explains how to operate
the RL02? Like how to open the drive, for starters... :) Or how the RL02
controller should be jumpered. (I guess that depends on what else is
present on the QBus though...)

Is there some other UNIX version that I can run on any of these machines?
I already have one PDP11/83 which happily runs 2.11BSD so it would be nice
to run older UNIX versions as well.

Thanks!

-- 
Jorgen Pehrson                  HP 9000/380 (NetBSD/hp300 1.3)
jp at spektr.ludvika.se            DECstation 5000/200 (NetBSD/pmax 1.3)
http://spektr.ludvika.se/museum PDP11/83 (2.11BSD) VAX2000 (NetBSD/vax)


Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id KAA12528
	for pups-liszt; Mon, 21 Dec 1998 10:18:04 +1100 (EST)

From jimc at zach1.tiac.net  Mon Dec 21 09:17:43 1998
From: jimc at zach1.tiac.net (James E. Carpenter)
Date: Sun, 20 Dec 1998 18:17:43 -0500 (EST)
Subject: Ancient SunOS 1.1 tapes --- how to restore?
In-Reply-To: <199812161520.KAA28340@seedlab1.cropsci.ncsu.edu> from "User Rdkeys Robert D. Keys" at Dec 16, 98 10:20:18 am
Message-ID: <199812202317.SAA19857@zach1.tiac.net>

> > I just took a quick look at my SunOS 3.2 tapes. The copyright file says:
> > 
> >    Copyright (c) 1986 by Sun Microsystems, Inc.
> > 
> > Most of the files seem to be dated September 1986. Many others are dated 
> > July 1986. 
> 
> Speaking of old SunOS tapes..... I have a friend that dug out a pair
> of SunOS 1.1 tapes that he has had for years.  Alas, they are unreadable.
> Is there any way to rewrite those tapes from anyones archival materials?
> Sun has graciously allowed pre-sparc materials to be available on-line
> in the German Sun3 archives.  All they have seems to be SunOS-4.1.1,
> though. 

I could donate SunOS 3.2, SunOS 4.0 (MC68010), and the 4.0.3 upgrade to the
archive, assuming they want Sun2 material. I also have the SunOS 4.0.3 
_upgrade_ for the 68020. All the tape files are tarred and gziped on a CDROM
I burned not too long ago.

> I am wondering if there is any interest in some of the early
> Sun tapes?  

Well I'd sure love to see SunOS 1.x running on my 2/120. :-)

> Are the 1.1 tapes basically a 4.2BSD port?  Are they in
> QIC-11 or QIC-24 format?

It would be 4-track QIC-11. SunOS 3.2 also came on four QIC-11 tapes. But
SunOS 4.x _probably_ only came on two QIC-24 tapes. (I say "probably" 
because my SunOS 4.x tapes are in 9-track QIC-11 format. I _assume_ this was 
done by somebody other than Sun so that it could be installed on a Sun2 with 
older ROMs.)

- Jim
 

-- 
James E. Carpenter                               E-Mail: jimc at zach1.tiac.net
6 Munroe Drive
Plainville, MA  02762-1108                     ICBM: 42 00' 15"N 71 20' 00"W
PGP: 7ADE9D99  Fingerprint: 8D AF 63 EC D3 51 14 3E  F1 59 8A 68 32 63 3F 8E

Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id GAA16037
	for pups-liszt; Tue, 22 Dec 1998 06:08:18 +1100 (EST)

From rickgc at calweb.com  Tue Dec 22 05:18:19 1998
From: rickgc at calweb.com (Rick Copeland)
Date: Mon, 21 Dec 1998 11:18:19 -0800
Subject: Problems booting 2.11 on a 11/84
Message-ID: <3.0.32.19981221111758.00905100@pop.calweb.com>

Dear PUPS List, 

I have connected a Fujisu M2444 9 track to an Emulex TC13 that is in my
11/84. The following is what happens when I try to boot a BSD 2.11 tape
that I made on my uVax3600/TU81+ (@6250 bpi):

	Enter device name and unit number then press the RETURN key: MS0

	Trying MS0	(tape starts rolling)

	Starting ROM boot  

	140276		(tape stops)
	@

The boot programs that are available are quite extensive on this 11/84, it
does tapes, disks, just about everything.  The M2444 is checked out by
doing the test (01 start, etc)and passes all the tests.  If I reverse the
cables on the M2444 the LED on the TC13 comes on and the M2444 will not do
anything.

Rick Copeland



From sms at moe.2bsd.com  Tue Dec 22 07:59:57 1998
From: sms at moe.2bsd.com (Steven M. Schultz)
Date: Mon, 21 Dec 1998 13:59:57 -0800 (PST)
Subject: Problems booting 2.11 on a 11/84
Message-ID: <199812212159.NAA07290@moe.2bsd.com>

Hi -

> From: Rick Copeland <rickgc at calweb.com>
> I have connected a Fujisu M2444 9 track to an Emulex TC13 that is in my
> 11/84. The following is what happens when I try to boot a BSD 2.11 tape
> that I made on my uVax3600/TU81+ (@6250 bpi):

	What CSR do you have the TC13 set for?

> 	Enter device name and unit number then press the RETURN key: MS0
> 	Trying MS0	(tape starts rolling)
> 
> 	Starting ROM boot  
> 
> 	140276		(tape stops)
> 	@

	The Boot ROM did it's job of reading in the 512 byte boot record and
	transferring control to location 0.

	The bootblock relocates itself to 48kb which is 0140000.

> cables on the M2444 the LED on the TC13 comes on and the M2444 will not do
> anything.

	I don't think the problem is cabling in this case.  

	If you have another system that you can view the sources with the
	file you really need to have in front of you at this time is
	/usr/src/sys/pdpstand/mtboot.s

	The section of code where the system is halting (with added octal 
	offsets) is:

0262		bne	ctlerr
0264		bit	$!1000,hter(csr)	/ any drive errs except HTER_FCE
0272		beq	bumpaddr		/ no, go bump address
	ctlerr:
0274		halt

	The label 'ctlerr' is shared but it indicates that a controller
	error was encountered out of the 'tmtscom' common logic (shared between
	the MT and MS drivers):

tmtscom:
	bit	$100200,(csr)		/ error or ready?
	beq	tmtscom			/ neither, keep looking
	bmi	ctlerr			/ error - go halt


	The thing to try is when the system halts looking at the registers
	(R0 thru R5) _and_ the tape controller registers (starting at 0172520).

	It's also possible to look at the command buffer being presented to
	the controller by looking at offset 0460 (0140460).  Not sure how useful
	that will be though.

	It might be possible to single step the processor starting at location
	0 as long as R0 and R1 are set up correctly (R0 has the unit number
	and R1 the control register address which is 172522 for MS and MT
	devices).

	Steven

Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id JAA16654
	for pups-liszt; Tue, 22 Dec 1998 09:18:17 +1100 (EST)

From mjenkins at carp.gbr.epa.gov  Tue Dec 22 08:17:50 1998
From: mjenkins at carp.gbr.epa.gov (Mike Jenkins)
Date: Mon, 21 Dec 1998 16:17:50 -0600 (CST)
Subject: Unix History Diagram
In-Reply-To: <199812142344.KAA05594@henry.cs.adfa.oz.au>
Message-ID: <199812212217.QAA15443@carp.gbr.epa.gov>

There is a diagram at The Internet Operating System Counter which is at
http://www.hzo.cubenet.de/ioscount/.  Take the "Unix networking" link.
It was published in iX, a German magazine.

Mike

Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id NAA17356
	for pups-liszt; Tue, 22 Dec 1998 13:44:57 +1100 (EST)

From grog at lemis.com  Tue Dec 22 12:44:15 1998
From: grog at lemis.com (Greg Lehey)
Date: Tue, 22 Dec 1998 13:14:15 +1030
Subject: Unix History Diagram
In-Reply-To: <199812212217.QAA15443@carp.gbr.epa.gov>; from Mike Jenkins on Mon, Dec 21, 1998 at 04:17:50PM -0600
References: <199812142344.KAA05594@henry.cs.adfa.oz.au> <199812212217.QAA15443@carp.gbr.epa.gov>
Message-ID: <19981222131415.A85005@freebie.lemis.com>

On Monday, 21 December 1998 at 16:17:50 -0600, Mike Jenkins wrote:
> There is a diagram at The Internet Operating System Counter which is at
> http://www.hzo.cubenet.de/ioscount/.  Take the "Unix networking" link.
> It was published in iX, a German magazine.

As I feared when I heard it came from iX, it's *very* inaccurate.
For example, it claims that 1BSD was derived from 32/V (should have
been 3BSD), derives 1BSD from 1BSD and 4.1BSD (should be 4BSD) from
the second 1BSD (should be 3BSD), derives ``BSDI'' from 4.3BSD, when
in fact BSD/OS is derived from 4.4BSD, doesn't mention System V(.1) or
System V.3, etc.  And all this is OS code, not networking code.

Greg
--
See complete headers for address, home page and phone numbers
finger grog at lemis.com for PGP public key

Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id GAA21472
	for pups-liszt; Wed, 23 Dec 1998 06:06:48 +1100 (EST)

From rickgc at calweb.com  Wed Dec 23 05:16:49 1998
From: rickgc at calweb.com (Rick Copeland)
Date: Tue, 22 Dec 1998 11:16:49 -0800
Subject: Emulex TU13 Dip Switch Layout?
Message-ID: <3.0.32.19981222111606.008f4450@pop.calweb.com>

Dear PUPS List, 

I have an Emulex TU13 tape drive interface.  Does anyone on the list have
the dip switch layout so that I can program them properly?

Thank You,

Merry Christmas,

Rick Copeland




From jp at spektr.ludvika.se  Thu Dec 24 08:11:01 1998
From: jp at spektr.ludvika.se (Jorgen Pehrson)
Date: Wed, 23 Dec 1998 23:11:01 +0100 (CET)
Subject: PDP11/83 qbus layout.
Message-ID: <Pine.NEB.4.05.9812232234500.23424-100000@spektr.ludvika.se>


(Sorry for the rather lenghty post)

Hi,
I'd just try to boot my newly aquired PDP11/83 and was planning to install
2.11BSD. But I've run into one (small?) problem. If I just try to boot
from DU0: it says: 

Trying DU0

Error 20 
Controller Error

And if I boot the install tape from the TK70 drive and run disklabel,
all accesses to the RD53 drive just times out. So I was going to remove
all unwanted QBus boards from the boxes. And that's what I was going to
ask...

Is there something special I have to think about, like there's some slots
that can't be used, some boards must be in a specific slot and so on?

This is the current layout (which is exactly as it was when it was taken
offline, or so I think)

11/83 (173QA-B3, I think this is a normal BA23 enclosure):
(As seen from the back) Also contains one TK70 drive.
    
 ____________________________________________
|Dataram 40903 revG     |        Empty slot  | (2mb ram)
---------------------------------------------
|                    M8637-EH                | (2mb ram)
---------------------------------------------
|                    M8190-AE                | (83 CPU)
---------------------------------------------
|     M7559             |         M7504      | (TK70, DEQNA)
---------------------------------------------
|     M8020             |        Empty slot  | (console?)
---------------------------------------------
|                    M7957                   | (DZV11)
---------------------------------------------
|                    m3104                   | (DHV11)
---------------------------------------------
|     M9404            |          Empty slot | (1st Qbus conn)
---------------------------------------------

Expansion box (173QA-B3)
(From the back) Also contains one RD53 and one dual floppy.

_____________________________________________
|M9405-YA               |        Empty slot  | (2nd qbus conn)
---------------------------------------------
|                     m3104                  | (DHV11)
---------------------------------------------
|     m9047             |        m9047       | (grant cont x2)
---------------------------------------------
|     m7555             |        Empty slot  | (RQDX3)
---------------------------------------------
|     m7512             |        Empty slot  | (RQDX1E)
---------------------------------------------

Plus one external disk box with two RD53 drive. (This system only uses one
drive though.)

Now, what I obviously want to keep is:
the two RAM boards, the CPU, the console board, tk70 controller, deqna,
rqdx3.

What I want to loose:
the rest of the serial boards, the rqdx1e board and the floppy drive.

What do I have to do to make this work? I would preferrably want to fit
all those boards in the main CPU enclosure box. Do I have to re-assign any
addresses (or vectors, or what the correct PDP-speak is). Are there any
slots in the enclosure that are a no-no for the dual-sized boards?

Thanks for any input!!


Jorgen Pehrson                  HP 9000/380 (NetBSD/hp300 1.3)
jp at spektr.ludvika.se            DECstation 5000/200 (NetBSD/pmax 1.3)
http://spektr.ludvika.se/museum PDP11/83 (2.11BSD) VAX2000 (NetBSD/vax)


Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id BAA28023
	for pups-liszt; Fri, 25 Dec 1998 01:16:27 +1100 (EST)

From robin at falstaf.demon.co.uk  Fri Dec 25 00:10:43 1998
From: robin at falstaf.demon.co.uk (Robin Birch)
Date: Thu, 24 Dec 1998 14:10:43 +0000
Subject: PDP11/83 qbus layout.
In-Reply-To: <Pine.NEB.4.05.9812232234500.23424-100000@spektr.ludvika.se>
Message-ID: <sB9s7CAjtkg2EwEL@falstaf.demon.co.uk>

In message <Pine.NEB.4.05.9812232234500.23424-100000 at spektr.ludvika.se>,
Jorgen Pehrson <jp at spektr.ludvika.se> writes
>
>(Sorry for the rather lenghty post)
>
Don't worry about that.
>Hi,
>I'd just try to boot my newly aquired PDP11/83 and was planning to install
>2.11BSD. But I've run into one (small?) problem. If I just try to boot
>from DU0: it says: 
>
>Trying DU0
>
>Error 20 
>Controller Error
>
>And if I boot the install tape from the TK70 drive and run disklabel,
>all accesses to the RD53 drive just times out. So I was going to remove
>all unwanted QBus boards from the boxes. And that's what I was going to
>ask...
>
A good plan
>
>Is there something special I have to think about, like there's some slots
>that can't be used, some boards must be in a specific slot and so on?
>
There are rules about where boards can go which is an off shoot of the
BG lines and so on.
>This is the current layout (which is exactly as it was when it was taken
>offline, or so I think)
>
>11/83 (173QA-B3, I think this is a normal BA23 enclosure):
>(As seen from the back) Also contains one TK70 drive.
>    
> ____________________________________________
>|Dataram 40903 revG     |        Empty slot  | (2mb ram)
>---------------------------------------------
>|                    M8637-EH                | (2mb ram)
>---------------------------------------------
>|                    M8190-AE                | (83 CPU)
>---------------------------------------------
>|     M7559             |         M7504      | (TK70, DEQNA)
>---------------------------------------------
>|     M8020             |        Empty slot  | (console?)
>---------------------------------------------
>|                    M7957                   | (DZV11)
>---------------------------------------------
>|                    m3104                   | (DHV11)
>---------------------------------------------
>|     M9404            |          Empty slot | (1st Qbus conn)
>---------------------------------------------
>
>Expansion box (173QA-B3)
>(From the back) Also contains one RD53 and one dual floppy.
>
>_____________________________________________
>|M9405-YA               |        Empty slot  | (2nd qbus conn)
>---------------------------------------------
>|                     m3104                  | (DHV11)
>---------------------------------------------
>|     m9047             |        m9047       | (grant cont x2)
>---------------------------------------------
>|     m7555             |        Empty slot  | (RQDX3)
>---------------------------------------------
>|     m7512             |        Empty slot  | (RQDX1E)
>---------------------------------------------
>
>Plus one external disk box with two RD53 drive. (This system only uses one
>drive though.)
>
>Now, what I obviously want to keep is:
>the two RAM boards, the CPU, the console board, tk70 controller, deqna,
>rqdx3.
>
What you are calling the console board probably isn't, or if it is then
you want to use the one from the CPU card rather than the M8020 (DPV11 I
think?).

>What I want to loose:
>the rest of the serial boards, the rqdx1e board and the floppy drive.
>

What I suggest is this.  Keep the CPU and the mem, the TK controller and
tape, the deqna, the RQDX3 and a serial card (You never know when a
spare serial port is going to be useful - printers, simple comms to a
PC, spare terminal etc etc etc).

A possible layout would be:

|Dataram 40903 revG     |        Empty slot  | (2mb ram)
---------------------------------------------
|                    M8637-EH                | (2mb ram)
---------------------------------------------
|                    M8190-AE                | (83 CPU)
---------------------------------------------
|     M7559             |         M7504      | (TK70, DEQNA)
---------------------------------------------
|                    M7957/M3104             | (DZV11) or (DHV11)
---------------------------------------------
|    M7555              |        Empty slot  |
----------------------------------------------
|     Empty slot        |       Empty slot   | 
---------------------------------------------
|     Empty slot        |         Empty slot | 
---------------------------------------------

>What do I have to do to make this work? I would preferrably want to fit
>all those boards in the main CPU enclosure box. Do I have to re-assign any
>addresses (or vectors, or what the correct PDP-speak is). Are there any
>slots in the enclosure that are a no-no for the dual-sized boards?
>
You would have to check with others which of the serial boards is best 
supported under 2.11BSD.  Steve Schultz is your best point of contact
for this.

Looking at you aoriginal configuration I think that the empty slot by
your M8020 is your problem (unless there is a bus grant card in there)
as there wouldn't be any BG continuity.

This should work and allow you to ditch all of the rest. (saving it for
a rainy day of course :-)).

Regards

Robin
____________________________________________________________________
Robin Birch     robin at falstaf.demon.co.uk

M1ASU/2E0ARJ    Old computers and radios always welcome


From erin at coffee.corliss.net  Sat Dec 26 13:41:55 1998
From: erin at coffee.corliss.net (Erin W. Corliss)
Date: Fri, 25 Dec 1998 19:41:55 -0800 (PST)
Subject: 2.11BSD
Message-ID: <Pine.LNX.3.96.981225193543.11045A-100000@coffee.corliss.net>


I know you've all been on the edge of your seats waiting for this, but...

I finally got my PDP-11/73 working, using a wyse terminal instead of my PC
-- for some reason neither of the serial ports were sending on the PC (but
then again, I boughtthe motherboard in an alley in korea three years
ago)...  Anyway, it boots up with RSTS/E version 9, which is OK in it's
own little way, I guess, but I'd rather be running Unix on it.  

So where can I download the binaries for 2.11BSD?

	-- Erin Corliss


Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id PAA02429
	for pups-liszt; Sat, 26 Dec 1998 15:03:53 +1100 (EST)

From SHOPPA at trailing-edge.com  Sat Dec 26 14:03:36 1998
From: SHOPPA at trailing-edge.com (Tim Shoppa)
Date: Fri, 25 Dec 1998 23:03:36 -0500
Subject: 2.11BSD
Message-ID: <981225230336.206000db@trailing-edge.com>

>I know you've all been on the edge of your seats waiting for this, but...
>
>I finally got my PDP-11/73 working, using a wyse terminal instead of my PC
>-- for some reason neither of the serial ports were sending on the PC (but
>then again, I boughtthe motherboard in an alley in korea three years
>ago)...

There are at least two different standards for the ribbon-cable-to-D-sub
adapters, and of course it's guaranteed that you'll use the wront type :-).

>  Anyway, it boots up with RSTS/E version 9, which is OK in it's
> own little way, I guess, but I'd rather be running Unix on it.  
> So where can I download the binaries for 2.11BSD?

Easiest way is for you to tell us what sort of load media you can use and
have someone write an install tape for you.  Do you have a TK50 or other tape
drive on the system?

-- 
 Tim Shoppa                        Email: shoppa at trailing-edge.com
 Trailing Edge Technology          WWW:   http://www.trailing-edge.com/
 7328 Bradley Blvd		   Voice: 301-767-5917
 Bethesda, MD, USA 20817           Fax:   301-767-5927

Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id VAA03169
	for pups-liszt; Sat, 26 Dec 1998 21:31:23 +1100 (EST)

From wkt at henry.cs.adfa.oz.au  Sat Dec 26 20:32:47 1998
From: wkt at henry.cs.adfa.oz.au (Warren Toomey)
Date: Sat, 26 Dec 1998 21:32:47 +1100 (EST)
Subject: 2.11BSD (but no src license)
In-Reply-To: <19981226180625.S12346@freebie.lemis.com> from Greg Lehey at "Dec 26, 98 06:06:25 pm"
Message-ID: <199812261032.VAA20488@henry.cs.adfa.oz.au>

In article by Greg Lehey:
> On Friday, 25 December 1998 at 23:09:48 -0800, Erin W. Corliss wrote:
> > On Sat, 26 Dec 1998, Greg Lehey wrote:
> >> Do you have an Ancient UNIX license?  I don't see you in our list.
> >> You'll need one before we can give you a copy of the software.
> >
> > Nope.  I have a licensed copy of RSTS/E I could trade, though...  8^)  No,
> > actually, I think I found another source for it, but thanks for the
> > concern.
> 
> PUPS is very glad to have been able to have created the possibility of
> legally using these old versions of UNIX.  Please don't make things
> difficult by abusing somebody's cooperation.  You can get it legally;
> see http://minnie.cs.adfa.oz.au/PUPS/getlicense.html for more details.
> 
> Greg

What Greg says is true: we can't give you access to any UNIX source
code unless you have a UNIX source license from SCO. However....
I should ask Dion at SCO if we could distribute binary-only distributions
of 2.x BSD without a license. After all, freely distributable binary-only
distributions for v5, v6, v7 and Venix (System III-ish) exist.

Just a thought, but for now you do need a source license.

Cheers,
	Warren


From msokolov at harrier.Uznet.NET  Sun Dec 27 18:38:56 1998
From: msokolov at harrier.Uznet.NET (Michael Sokolov)
Date: 27 Dec 1998   08:38:56 GMT
Subject: 4.3BSD-Quasijarus0 release
Message-ID: <199812270839.NAA09201@harrier.Uznet.NET>

Dear PUPS/TUHS members,

About three hours ago I have released 4.3BSD-Quasijarus0, the latest release of
4.3BSD-*. This release has the 4.3-Tahoe userland and a kernel that supports
all hardware supported by CSRG's Tahoe and Reno releases, including KA630 and
KA650 MicroVAXen.

You can find 4.3BSD-Quasijarus0 under Distributions/4bsd/43quasi0.vax in the
PUPS archive. It is by far the newest system in the archive, compiled only a
couple of days ago.

I haven't got around to implementing a standalone disk labeling facility yet,
so installing it on a typical MicroVAX with third-party MSCP disks is still a
little bit of a challenge. While working on building this release, I and Tim
Shoppa have come up with a usable solution to this disklabel problem. It
appears in Distributions/4bsd/tips/QTR_disklabel_note. This approach also works
with VAX builds of CSRG's Tahoe and Reno releases (QTR stands for Quasijarus,
Tahoe, and Reno).

Have fun with it!

Sincerely,
Michael Sokolov
Cellular phone: 216-217-2579
ARPA Internet SMTP mail: msokolov at harrier.Uznet.NET



From grog at lemis.com  Tue Dec 29 12:09:52 1998
From: grog at lemis.com (Greg Lehey)
Date: Tue, 29 Dec 1998 12:39:52 +1030
Subject: Converting Sixth Edition man pages
Message-ID: <19981229123952.B12346@freebie.lemis.com>

I have the Sixth Edition man pages on my machine, but I can't do much
with them, since they use obsolete macros.  Is there any way to
convert them to the Seventh Edition style?

Greg
--
See complete headers for address, home page and phone numbers
finger grog at lemis.com for PGP public key

Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id TAA12241
	for pups-liszt; Tue, 29 Dec 1998 19:12:50 +1100 (EST)

From wkt at henry.cs.adfa.oz.au  Tue Dec 29 18:14:38 1998
From: wkt at henry.cs.adfa.oz.au (Warren Toomey)
Date: Tue, 29 Dec 1998 19:14:38 +1100 (EST)
Subject: Converting Sixth Edition man pages
In-Reply-To: <19981229123952.B12346@freebie.lemis.com> from Greg Lehey at "Dec 29, 98 12:39:52 pm"
Message-ID: <199812290814.TAA22809@henry.cs.adfa.oz.au>

In article by Greg Lehey:
> I have the Sixth Edition man pages on my machine, but I can't do much
> with them, since they use obsolete macros.  Is there any way to
> convert them to the Seventh Edition style?
> 
> Greg

My off-the-cuff suggestion is to read the man(7) pages for both V6 and V7,
and write a Perl script to make the changes :-) That's probably the `best'
solution, but would take time.

Do you want to preserve the markup, or just want to view the manpages?
Just viewing them would be easier, of course!

Ciao,
	Warren


Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id TAA12285
	for pups-liszt; Tue, 29 Dec 1998 19:19:35 +1100 (EST)

From grog at lemis.com  Tue Dec 29 18:19:09 1998
From: grog at lemis.com (Greg Lehey)
Date: Tue, 29 Dec 1998 18:49:09 +1030
Subject: Converting Sixth Edition man pages
In-Reply-To: <199812290814.TAA22809@henry.cs.adfa.oz.au>; from Warren Toomey on Tue, Dec 29, 1998 at 07:14:38PM +1100
References: <19981229123952.B12346@freebie.lemis.com> <199812290814.TAA22809@henry.cs.adfa.oz.au>
Message-ID: <19981229184909.O32696@freebie.lemis.com>

On Tuesday, 29 December 1998 at 19:14:38 +1100, Warren Toomey wrote:
> In article by Greg Lehey:
>> I have the Sixth Edition man pages on my machine, but I can't do much
>> with them, since they use obsolete macros.  Is there any way to
>> convert them to the Seventh Edition style?
>
> My off-the-cuff suggestion is to read the man(7) pages for both V6 and V7,
> and write a Perl script to make the changes :-) That's probably the `best'
> solution, but would take time.

perl?  What's perl?  :-)  But yes, that was one alternative, one I
hadn't thought worth the trouble.

> Do you want to preserve the markup, or just want to view the manpages?
> Just viewing them would be easier, of course!

In fact, I'm not sure that just viewing them *would* be easier.  From
observation, the markup isn't too different from the -an macros.  A
lot of the macros seem to be the same, just in a different case.  But
there are enough differences that I wouldn't want to tackle it right
now.

Greg
--
See complete headers for address, home page and phone numbers
finger grog at lemis.com for PGP public key


From erin at coffee.corliss.net  Wed Dec 30 06:24:15 1998
From: erin at coffee.corliss.net (Erin W. Corliss)
Date: Tue, 29 Dec 1998 12:24:15 -0800 (PST)
Subject: rt11 and disk images
Message-ID: <Pine.LNX.3.96.981229120734.14487A-100000@coffee.corliss.net>


(writer bites his tongue to keep from ranting about paying $100 for an
operating system for a computer that cost $12 at a second-hand store...
8^)

So I went back to the junk store yesterday and found a TK25 tape drive,
which appears to work fine with my PDP-11/73.  It also uses the same
cartriges as my SCSI tape backup drive...  Is there a DOS, Linux, or
windows NT program that I can use to save files to tape so I can load them
on the PDP-11?  When I initialize a tape, is the format standard among
other computers, or is it specific to PDP's running RSTS?  

Is there any way to make Unix 7 use RD hard drives?

...and most importantly...

Everything for PDP's seems to be distributed on disk images for drives I
don't have.  I think I saw something somewhere about being able to mount a
.dsk file as a virtual drive under RT11...  Anyone know if this is true?


Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id IAA14527
	for pups-liszt; Wed, 30 Dec 1998 08:09:29 +1100 (EST)

From sms at moe.2bsd.com  Wed Dec 30 07:07:32 1998
From: sms at moe.2bsd.com (Steven M. Schultz)
Date: Tue, 29 Dec 1998 13:07:32 -0800 (PST)
Subject: rt11 and disk images
Message-ID: <199812292107.NAA11417@moe.2bsd.com>

Hi -

> From: "Erin W. Corliss" <erin at coffee.corliss.net>
> (writer bites his tongue to keep from ranting about paying $100 for an
> operating system for a computer that cost $12 at a second-hand store... 8^)

	If you think $100 for software is worthy of ranting I'd hate to see
	what $100k (what it used to cost for UNIX sources) worth of ranting 
	would sound like :) :) :)

> So I went back to the junk store yesterday and found a TK25 tape drive,
> which appears to work fine with my PDP-11/73.  It also uses the same
> cartriges as my SCSI tape backup drive...  Is there a DOS, Linux, or

	The TK25 (I have one also - worked the last time I checked some time
	ago) uses DC600A (the "A" is important) 60mb tapes.

	But there the similarity ends.

> windows NT program that I can use to save files to tape so I can load them
> on the PDP-11?  When I initialize a tape, is the format standard among
> other computers, or is it specific to PDP's running RSTS?  

	The TQK25 formats the tape in a 'variable' record mode format that
	is (as far as I know) peculiar to DEC (or who ever built the TK25
	for them).  This makes the TK25 look and feel like a 9-track drive
	(record boundaries are preserved) which is nice.

	Unfortunately most (all?) QIC drives in the "PC" world end up in a
	'fixed record' mode (which loses the concept of record size).   So
	while you might have a DC600A drive on a Linux system it will, odds are,
	only write in fixed record mode which the TQK25 probably won't like.
	Have to try it and see what happens.

> Is there any way to make Unix 7 use RD hard drives?

	Not easily.  MSCP devices weren't around or weren't supported at
	the time V7 came out.  You'd need a  development system running
	supported disks first (perhaps the work could be done via an
	emulator).  Then you could create "boot kits" (and adding RD/RA
	support would also entail writing bootblocks, standalone drivers,
	updating /boot, in additi0on to the mainline kernel 'ra.c' driver).

	2.11BSD supports the RD drives quite nicely - if you've an 11/73
	then perhaps using 2.11 instead of V7 might be worth considering.

> ...and most importantly...
> 
> Everything for PDP's seems to be distributed on disk images for drives I
> don't have.  I think I saw something somewhere about being able to mount a

	That's why I (even 6 years ago the older drive types were either
	too old or too bulky/powerhungry) bought an Emulex UC08 (MSCP->SCSI)
	and started using SCSI peripherals.  You should have heard the 
	ranting - but it was worth in the long haul.

	Steven Schultz
	sms at moe.2bsd.com

Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id JAA14776
	for pups-liszt; Wed, 30 Dec 1998 09:37:12 +1100 (EST)

From robin at falstaf.demon.co.uk  Wed Dec 30 08:32:24 1998
From: robin at falstaf.demon.co.uk (Robin Birch)
Date: Tue, 29 Dec 1998 22:32:24 +0000
Subject: Bob Supnik's Emulator.
Message-ID: <7OIFxAA4hVi2EwHy@falstaf.demon.co.uk>

Dear All,
I've been struggling with Bob's emulator (version 2.3d).  The main
problem appears to be around the TM device driver.  I've been creating
boot programs and data on my 11/73 under 2.11 BSD.

To do this I've been using the makesimtape program.  This hasn't worked
very well.  I've had to make individual files for each of the standalone
utilities as I havn't been able to get the emulator to find files beyond
the first one.  For instance if I make a standalone file consisting of
the bootstrap, boot, disklabel, mkfs, restor and inode then I can boot
the processor and load and run disklabel but nothing beyond this.

Using separate bootstraps, boot and <program>, I have labeled and mkfs
an RP04.  I then tried restor.  Well, I can get restor to load and run
but it doesn't want to understand the dump file written with dd that is
created as part of the generation of a distribution set on the 11/73.

I suspect that there is some form of data conversion that I have to go
through before I can read the files on the emulator.

Has anybody installed 2.11 on the emulator from scratch.  If so, can
they offer any advice.

Regards

Robin

PS, the emulator is compiled with gcc on Solaris 2.6 running on a
sparc2.  It runs the rt11 and v7 disks available with the simulator with
no worries.
____________________________________________________________________
Robin Birch     robin at falstaf.demon.co.uk

M1ASU/2E0ARJ    Old computers and radios always welcome

Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id JAA14831
	for pups-liszt; Wed, 30 Dec 1998 09:49:48 +1100 (EST)

From wkt at henry.cs.adfa.oz.au  Wed Dec 30 08:51:34 1998
From: wkt at henry.cs.adfa.oz.au (Warren Toomey)
Date: Wed, 30 Dec 1998 09:51:34 +1100 (EST)
Subject: Bob Supnik's Emulator.
In-Reply-To: <7OIFxAA4hVi2EwHy@falstaf.demon.co.uk> from Robin Birch at "Dec 29, 98 10:32:24 pm"
Message-ID: <199812292251.JAA23598@henry.cs.adfa.oz.au>

In article by Robin Birch:
> Dear All,
> I've been struggling with Bob's emulator (version 2.3d).  The main
> problem appears to be around the TM device driver.  I've been creating
> boot programs and data on my 11/73 under 2.11 BSD.
> 
> To do this I've been using the makesimtape program.  This hasn't worked
> very well.  I've had to make individual files for each of the standalone
> utilities as I havn't been able to get the emulator to find files beyond
> the first one.  For instance if I make a standalone file consisting of
> the bootstrap, boot, disklabel, mkfs, restor and inode then I can boot
> the processor and load and run disklabel but nothing beyond this.

The format of a tape image is described in simh_doc.txt in Appendix 1.3,
at roughly line 2,473 of the file. Perhaps the makesimtape program isn't
making the tape correctly. What arguments are you giving it?

On a silly note, if there is only a single thing on the tape you are trying
to restor, you could always save it without the record structure imposed
by makesimtape, attach it as RL00, and then restor it from /dev/rl00 :-)

Best of luck,
	Warren

Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id JAA14858
	for pups-liszt; Wed, 30 Dec 1998 09:51:34 +1100 (EST)

From dave at fgh.geac.com.au  Wed Dec 30 08:48:10 1998
From: dave at fgh.geac.com.au (Dave Horsfall)
Date: Wed, 30 Dec 1998 09:48:10 +1100 (EST)
Subject: Converting Sixth Edition man pages
In-Reply-To: <19981229184909.O32696@freebie.lemis.com>
Message-ID: <Pine.GSO.4.03.9812300947020.22664-100000@fgh>

On Tue, 29 Dec 1998, Greg Lehey wrote:

> In fact, I'm not sure that just viewing them *would* be easier.  From
> observation, the markup isn't too different from the -an macros.  A
> lot of the macros seem to be the same, just in a different case.  But
> there are enough differences that I wouldn't want to tackle it right
> now.

Do you have thee 6th Edition documentation to tell you what the macros
do?  I have them somewhere...

-- 
Dave Horsfall VK2KFU  dave at geac.com.au  Ph: +61 2 9978-7493 Fx: +61 2 9978-7422
Geac Computers P/L (FGH Division) 2/57 Christie St, St Leonards 2065, Australia


Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id JAA14878
	for pups-liszt; Wed, 30 Dec 1998 09:55:19 +1100 (EST)

From norman at nose.cita.utoronto.ca  Tue Dec 29 19:51:20 1998
From: norman at nose.cita.utoronto.ca (norman at nose.cita.utoronto.ca)
Date: Tue, 29 Dec 1998 04:51:20 -0500
Subject: No subject
Message-ID: <199812290952.UAA13151@csadfa.cs.adfa.oz.au>

Stuff this in the archives somewhere: V6 man macros.
I can't remember where I dug it up, unfortunately.

# To unbundle, sh this file
echo tmac.an6 1>&2
sed 's/.//' >tmac.an6 <<'//GO.SYSIN DD tmac.an6'
-'''\"	Pwb Manual Entry Macros - Version 6 (@(#)an6.src	1.6)
-'''\"	Nroff/Troff Version	@(#)1.6
-.deTH
-.tmwrong version of man entry macros - use -man
-.ab
-..
-.rnbd Bd
-.rndt Dt
-.rnit il
-.nr}I 5n
-.nr}P 0 1
-.de}C
-.ev1
-.po0
-.lt7.5i
-.tl\-\-
-.lt
-.po
-.ev
-..
-.de}E
-.wh-1p }C
-..
-.ift .em }E
-.dei0
-.in\\n(}Iu
-.dt
-..
-.delp
-.tc
-.i0
-.ta\\$2n
-.in\\$1n
-.ti-\\$2n
-..
-.des1
-.sp1v
-.ne2
-..
-.des2
-.ift .sp .5v
-.ifn .sp 1v
-..
-.des3
-.ift .sp .5v
-.ifn .sp 1v
-.ne2
-..
-.de}F
-.ev1
-'ft1
-'ps10
-'sp.5i
-.tl- % -
-'ft
-'ps
-.ev
-'bp
-..
-.deth
-.de}X
-.ev1
-.ift .}C
-'ft1
-'ps10
-'sp.5i
-.tl''THIS MANUAL ENTRY NEEDS TO BE CONVERTED - SEE mancvt(1) and man(7)''
-.tl\\$1\|(\|\\$2\|)PWB/UNIX\| \\$3\\$1\|(\|\\$2\|)
-'ps
-'ft
-'sp.5i
-.ev
-\\..
-.wh-1i }F
-.wh0 }X
-.if\\n+(}P>1 .bp1
-.ft1
-.ft1
-.ps10
-.vs12p
-.ift .po .5i
-.in\\n(}Iu
-.fi
-.dt
-.mc
-.ad
-.ifn .na
-..
-.desh
-.s1
-.ift .ft 3
-.ps8
-.ti0
-\&\\$1
-.ift .ft
-.ps
-.br
-..
-.deit
-.ul
-.ie\\nV>1 _\\$1_
-.el\&\\$1
-..
-.debd
-.ift .ft 3
-.ifn .ul
-.ie\\nV>1 _\\$1_
-.el\&\\$1
-.ift .ft 
-..
-.debn
-.ift .ft 3
-.ifn .ul
-.ie\\nV>1 _\\$1_\t\&\c
-.el\&\\$1\t\&\c
-.ift .ft 
-..
-.dedt
-.ifn .ta 8n 16n 24n 32n 40n 48n 56n 64n 72n 80n
-.ift .ta .5i 1i 1.5i 2i 2.5i 3i 3.5i 4i 4.5i 5i 5.5i 6i 6.5i
-..
-'dsv \(bv
-'ds' \(aa
-'ds> \(->
-'dsX \(mu
-'ds_ _
-'ds- \-
-'dsG \(*G
-'dsg \(ga
-'dsp \(*p
-'dsa \(aa
-'dsb \(*b
-'dsr \(rg
-'ds| \|
-'dsu \(*m
-.if\nV=1 \{\
-.po4
-.ll80
-.lt80
-.ev1
-.ll80
-.lt80
-.ev\}
-.if\nV>1 \{\
-.ll82
-.lt82
-.ev1
-.ll82
-.lt82
-.ev
-.pl84
-.rmul\}
-.hy14
-.uf2
//GO.SYSIN DD tmac.an6


Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id KAA14989
	for pups-liszt; Wed, 30 Dec 1998 10:04:45 +1100 (EST)

From sms at moe.2bsd.com  Wed Dec 30 09:03:53 1998
From: sms at moe.2bsd.com (Steven M. Schultz)
Date: Tue, 29 Dec 1998 15:03:53 -0800 (PST)
Subject: Bob Supnik's Emulator.
Message-ID: <199812292303.PAA12398@moe.2bsd.com>

Robin -

	Howdy.

> From: Robin Birch <robin at falstaf.demon.co.uk>
> I've been struggling with Bob's emulator (version 2.3d).  The main

	2.3d?  Hmmm, sounds like a little newer one than I've used in the
	past (I've updated selected modules so I'm probably running 2.3d
	but the directory is still called 2.3b ;))

> problem appears to be around the TM device driver.  I've been creating
> boot programs and data on my 11/73 under 2.11 BSD.

	I don't think that's the case - but read on and see if my new
	theory sounds plausible...

> Using separate bootstraps, boot and <program>, I have labeled and mkfs
> an RP04.  I then tried restor.  Well, I can get restor to load and run
> but it doesn't want to understand the dump file written with dd that is
> created as part of the generation of a distribution set on the 11/73.

	Umm, you can't use a 'dd'd image - you have to use 'makesimtape'
	(or a similar utility) to add the record/file/bytecount markers that
	the simulator expects to see.

> I suspect that there is some form of data conversion that I have to go
> through before I can read the files on the emulator.

	Yes, there is.  Not sure why it didn't occur to me earlier when you
	mentioned having problems.

	I assume you compiled and ran 'makesimtape' on the same system
	(Sparc) as the simulator is running.

	If so then it sounds to be like there's an endianness bug in
	makesimtape.  That wouldn't surprise me since all I have are 
	either little or pdp-11 endian systems and never tested makesimtape
	on a big endian machine.

	There are ifdefs around what I thought were the appropriate places
	for flipping bytes - what you'll need to do is get Bob's description
	of the simulated tape format (fairly simply and it's in the docs
	somewhere as I recall) and the makesimtape.c source and see where I
	"oops"d.

> Has anybody installed 2.11 on the emulator from scratch.  If so, can
> they offer any advice.
	
	Yes, I have.  But only on little endian systems.  The one time (ages
	ago) I tried the simulator on a Sparc the program dropped core because
	it wasn't bigendian capable.  That's been fixed but I've never tried
	it again.

	Steven

Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id KAA15089
	for pups-liszt; Wed, 30 Dec 1998 10:21:23 +1100 (EST)

From robin at falstaf.demon.co.uk  Wed Dec 30 09:20:18 1998
From: robin at falstaf.demon.co.uk (Robin Birch)
Date: Tue, 29 Dec 1998 23:20:18 +0000
Subject: Bob Supnik's Emulator.
In-Reply-To: <199812292303.PAA12398@moe.2bsd.com>
Message-ID: <Wta+ZIAyOWi2EwQ$@falstaf.demon.co.uk>

In message <199812292303.PAA12398 at moe.2bsd.com>, Steven M. Schultz
<sms at moe.2bsd.com> writes
>Robin -
>       I don't think that's the case - but read on and see if my new
>       theory sounds plausible...
>
I think that I've independantly come up with the same answer but by a
different logical root.
>> Using separate bootstraps, boot and <program>, I have labeled and mkfs
>> an RP04.  I then tried restor.  Well, I can get restor to load and run
>> but it doesn't want to understand the dump file written with dd that is
>> created as part of the generation of a distribution set on the 11/73.
>
>       Umm, you can't use a 'dd'd image - you have to use 'makesimtape'
>       (or a similar utility) to add the record/file/bytecount markers that
>       the simulator expects to see.
>
Now this is what I didn't realise at first.  All I thought makesimtape
was doing was packaging up the files, not writing some structure around
them.

>> I suspect that there is some form of data conversion that I have to go
>> through before I can read the files on the emulator.
>
>       Yes, there is.  Not sure why it didn't occur to me earlier when you
>       mentioned having problems.
>
>       I assume you compiled and ran 'makesimtape' on the same system
>       (Sparc) as the simulator is running.
>
This is the big one, no.  I had assumed that as the simulator was
emulating a PDP that it would accept files generated to look like boot
files etc built on a pdp so I'm running makesimtape in the standalone
direcctory of the 11/73.  Nieve maybe but at least it was logical :-).

>       If so then it sounds to be like there's an endianness bug in
>       makesimtape.  That wouldn't surprise me since all I have are 
>       either little or pdp-11 endian systems and never tested makesimtape
>       on a big endian machine.
>
What I'll do is build makesimtape on the sun and see what happens then.

>       There are ifdefs around what I thought were the appropriate places
>       for flipping bytes - what you'll need to do is get Bob's description
>       of the simulated tape format (fairly simply and it's in the docs
>       somewhere as I recall) and the makesimtape.c source and see where I
>       "oops"d.
Back in a mo.

Robin
____________________________________________________________________
Robin Birch     robin at falstaf.demon.co.uk

M1ASU/2E0ARJ    Old computers and radios always welcome

Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id KAA15164
	for pups-liszt; Wed, 30 Dec 1998 10:34:30 +1100 (EST)

From sms at moe.2bsd.com  Wed Dec 30 09:33:50 1998
From: sms at moe.2bsd.com (Steven M. Schultz)
Date: Tue, 29 Dec 1998 15:33:50 -0800 (PST)
Subject: Bob Supnik's Emulator.
Message-ID: <199812292333.PAA12655@moe.2bsd.com>

Robin -

> From robin at falstaf.demon.co.uk Tue Dec 29 15:21:08 1998
> >       Umm, you can't use a 'dd'd image - you have to use 'makesimtape'
> >       (or a similar utility) to add the record/file/bytecount markers that

> Now this is what I didn't realise at first.  All I thought makesimtape
> was doing was packaging up the files, not writing some structure around

	It's writing simulated bytecounts and simulated file and tape marks ;)

> >       I assume you compiled and ran 'makesimtape' on the same system
> >
> This is the big one, no.  I had assumed that as the simulator was

	Ah, ok - so you're running the makesimtape program on an 11.  That
	would tend to point the finger at the program not flipping the 
	'structure' bytes into correct big endian order.

> emulating a PDP that it would accept files generated to look like boot
> files etc built on a pdp so I'm running makesimtape in the standalone
> directory of the 11/73.  Nieve maybe but at least it was logical :-).

	The "data" is PDP-11 specific, but the "structure" bytes need to be
	in a canonical (big endian) form.

	I was pretty sure the endianness was ok but I guess not.  Another
	possibility is that there's an alignment disagreement.  The 11 might
	be putting something on a 2 byte bound where the Sun expects a 4 byte
	alignment.  

> >       There are ifdefs around what I thought were the appropriate places
> >       for flipping bytes - what you'll need to do is get Bob's description
> Back in a mo.

	If you find (and fix ;-)) it let me know and I'll integrate the
	changes into makesimtape.c in the 2.11 tree (and eventually in to
	the PUPS archive).

	Steve

Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id KAA15193
	for pups-liszt; Wed, 30 Dec 1998 10:42:04 +1100 (EST)

From wkt at henry.cs.adfa.oz.au  Wed Dec 30 09:43:56 1998
From: wkt at henry.cs.adfa.oz.au (Warren Toomey)
Date: Wed, 30 Dec 1998 10:43:56 +1100 (EST)
Subject: Converting Sixth Edition man pages
In-Reply-To: <19981229123952.B12346@freebie.lemis.com> from Greg Lehey at "Dec 29, 98 12:39:52 pm"
Message-ID: <199812292343.KAA23709@henry.cs.adfa.oz.au>

In article by Greg Lehey:
> I have the Sixth Edition man pages on my machine, but I can't do much
> with them, since they use obsolete macros.  Is there any way to
> convert them to the Seventh Edition style?
> 
> Greg

Here's a quick hack which is a start. It's a Perl script called fix:

#!/usr/bin/perl
while (<>) {
        s/^\.br/.BR/;
        if (/^\.bd/) {
            if (/\"/) {
                s/^\.bd/.B/; print; $_=".br\n";
            } else {
                s/^\.bd/.B/;
            }
        }
        s/^\.bl/.BL/;
        s/^\.it/.I/;
        s/^\.sh/.SH/;
        s/^\.th/.TH/;
        s/^\.s3/.PP/;
        s/\\\*/\\/g;
        print;
}

I've run the V6 section 1 manuals through it, then nroffed them using
GNU nroff under FreeBSD 2.2.x, and I get only the following error messages:

# for i in *.1
> do  perl /tmp/fix $i | nroff -man > /dev/null
> done
<standard input>:428: can't set diversion trap when no current diversion
<standard input>:95: can't set diversion trap when no current diversion
<standard input>:77: can't set diversion trap when no current diversion
<standard input>:40: can't set diversion trap when no current diversion
<standard input>:119: can't set diversion trap when no current diversion
<standard input>:132: normal or special character expected (got a node)
<standard input>:137: a tab character  is not allowed in an escape name
<standard input>:83: cannot use a space as a starting delimiter
<standard input>:127: can't set diversion trap when no current diversion
<standard input>:93: can't set diversion trap when no current diversion
<standard input>:75: can't set diversion trap when no current diversion
<standard input>:64: can't set diversion trap when no current diversion
<standard input>:36: can't set diversion trap when no current diversion
<standard input>:154: a tab character is not allowed before an argument
<standard input>:182: a tab character is not allowed before an argument
<standard input>:182: error: end of file while ignoring input lines
<standard input>:95: can't set diversion trap when no current diversion
<standard input>:95: can't set diversion trap when no current diversion

I haven't eyeballed the output from them all, but ls(1), sh(1), db(1)
and roff(1) look ok.

Send in any improvements!!

	Warren

Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id KAA15247
	for pups-liszt; Wed, 30 Dec 1998 10:59:06 +1100 (EST)

From cdl at mpl.ucsd.edu  Wed Dec 30 09:58:25 1998
From: cdl at mpl.ucsd.edu (Carl Lowenstein)
Date: Tue, 29 Dec 1998 15:58:25 -0800 (PST)
Subject: Converting Sixth Edition man pages
Message-ID: <199812292358.PAA16791@mpl.ucsd.edu>

> From owner-pups at minnie.cs.adfa.edu.au Tue Dec 29 15:07 PST 1998
> Date: Wed, 30 Dec 1998 09:48:10 +1100 (EST)
> From: Dave Horsfall <dave at fgh.geac.com.au>
> X-Sender: dave at fgh
> To: Greg Lehey <grog at lemis.com>
> cc: Unix Heritage Society <pups at minnie.cs.adfa.oz.au>
> 
> On Tue, 29 Dec 1998, Greg Lehey wrote:
> 
> > In fact, I'm not sure that just viewing them *would* be easier.  From
> > observation, the markup isn't too different from the -an macros.  A
> > lot of the macros seem to be the same, just in a different case.  But
> > there are enough differences that I wouldn't want to tackle it right
> > now.
> 
> Do you have thee 6th Edition documentation to tell you what the macros
> do?  I have them somewhere...
> 
> -- 

A quick check around some computers that I have on-line shows two sets
of v6 man macros, one for nroff and one for troff.  This is on a NeXT
running NeXTstep 3.3.  But I suspect that these same macros are
available on anything with a BSD 4.3 flavor.

/usr/lib/tmac/tmac.an6n
/usr/lib/tmac/tmac.an6t

About 200 lines total between them.

With the right macros, [ntg]roff should be able to do everything else.

    carl

        carl lowenstein         marine physical lab     u.c. san diego
                                                  clowenstein at ucsd.edu

Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id LAA15274
	for pups-liszt; Wed, 30 Dec 1998 11:06:51 +1100 (EST)

From sms at moe.2bsd.com  Wed Dec 30 10:06:30 1998
From: sms at moe.2bsd.com (Steven M. Schultz)
Date: Tue, 29 Dec 1998 16:06:30 -0800 (PST)
Subject: Tape endianness in Bob's simulator
Message-ID: <199812300006.QAA12964@moe.2bsd.com>

Hi -

	In glancing thru Bob's simulator I spotted this:


* Endian independent binary I/O package

   For consistency, all binary data read and written by the simulator
   is stored in little endian data order.  That is, in a multi-byte
   data item, the bytes are written out right to left, low order byte
   to high order byte.  On a big endian host, data is read and written
   from high byte to low byte.  Consequently, data written on a little
   endian system must be byte reversed to be usable on a big endian
   system, and vice versa.


	Perhaps this sheds some light on why a Sparc can't read a pdp-11
	generated (via 'makesimtape') tape.

	I know I've read simulated tape files on an Intel system with no
	trouble - so it would appear that the endianness was correct.

	Good Luck Robin! ;)

	Steven

Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id LAA15356
	for pups-liszt; Wed, 30 Dec 1998 11:53:44 +1100 (EST)

From grog at lemis.com  Wed Dec 30 10:51:48 1998
From: grog at lemis.com (Greg Lehey)
Date: Wed, 30 Dec 1998 11:21:48 +1030
Subject: rt11 and disk images
In-Reply-To: <199812292107.NAA11417@moe.2bsd.com>; from Steven M. Schultz on Tue, Dec 29, 1998 at 01:07:32PM -0800
References: <199812292107.NAA11417@moe.2bsd.com>
Message-ID: <19981230112148.C32696@freebie.lemis.com>

On Tuesday, 29 December 1998 at 13:07:32 -0800, Steven M. Schultz wrote:
> 	The TQK25 formats the tape in a 'variable' record mode format that
> 	is (as far as I know) peculiar to DEC (or who ever built the TK25
> 	for them).  This makes the TK25 look and feel like a 9-track drive
> 	(record boundaries are preserved) which is nice.
>
> 	Unfortunately most (all?) QIC drives in the "PC" world end up in a
> 	'fixed record' mode (which loses the concept of record size).   So
> 	while you might have a DC600A drive on a Linux system it will, odds are,
> 	only write in fixed record mode which the TQK25 probably won't like.
> 	Have to try it and see what happens.

I believe the new CAM driver for FreeBSD 3.0 can do variable block
lengths on QIC drives.

Greg
--
See complete headers for address, home page and phone numbers
finger grog at lemis.com for PGP public key

Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id XAA16818
	for pups-liszt; Wed, 30 Dec 1998 23:31:23 +1100 (EST)

From robin at falstaf.demon.co.uk  Wed Dec 30 22:28:31 1998
From: robin at falstaf.demon.co.uk (Robin Birch)
Date: Wed, 30 Dec 1998 12:28:31 +0000
Subject: Tape endianness in Bob's simulator
In-Reply-To: <199812300006.QAA12964@moe.2bsd.com>
Message-ID: <qKdBgFAvxhi2EwFc@falstaf.demon.co.uk>

In message <199812300006.QAA12964 at moe.2bsd.com>, Steven M. Schultz
<sms at moe.2bsd.com> writes
>       I know I've read simulated tape files on an Intel system with no
>       trouble - so it would appear that the endianness was correct.
>
>       Good Luck Robin! ;)
>
>       Steven
Steven,
I now have a makesimtape that creates the bootstrap files correctly.  I
have found, I think, one bug and partly rewritten another bit just to
put my mind at rest about a couple of things.  I still can't create the
root correctly though.

What I have found:

1) Your endianness is correct, it took me a couple of sample programs
and rewrites to prove it.  In doing this I have replaced trl with
another bit of code that does the same thing but is easier to play
around with to change the byte orders.

2) There are two bugs in the use of writev.  These are:

2.1) When writing the headers and data you are writing a long to the
file where iovec only supports (I think) an unsigned short.
2.2) When writing the tape marks you are writing an integer as though it
was a long.

Of the two 2.2 is the most significant (I think).

After correcting both of these.  By changing zero from an int to a long
and by replacing the writevs with writes for the headers, data and
trailers I have a version of makesimtape that creates a bootstrap file
that works.

I can load and run all of the bootstrap programs as though I was looking
at a real pdp which I couldn't before. This makes me think that I have
probably got makesimtape about right.

Now for the bad bit.  I have created a root.dump then run it through
makesimtape with the command file:

/usr/root.dump 2
* 1

and it won't load from restor.  I get a succession of "missing address
(header) block" errors but I successfully detect the end of the tape and
restor stops running, as it is supposed to do.

So, am I doing something wrong in creating the root file? or is there
something still wrong with makesimtape?.  This is probably a red herring
but the distribution tapes are written with a blocksize of 20 for all of
the data after the bootstraps whilst makesimtape only writes multiples
of 512.

Advice please

Robin
____________________________________________________________________
Robin Birch     robin at falstaf.demon.co.uk

M1ASU/2E0ARJ    Old computers and radios always welcome

Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id CAA17289
	for pups-liszt; Thu, 31 Dec 1998 02:53:20 +1100 (EST)

From sms at moe.2bsd.com  Thu Dec 31 01:52:58 1998
From: sms at moe.2bsd.com (Steven M. Schultz)
Date: Wed, 30 Dec 1998 07:52:58 -0800 (PST)
Subject: Tape endianness in Bob's simulator
Message-ID: <199812301552.HAA10714@moe.2bsd.com>

Robin -

> From robin at falstaf.demon.co.uk Wed Dec 30 04:31:15 1998
> What I have found:
> 
> 1) Your endianness is correct, it took me a couple of sample programs

	Whew - that's a relief.

> 2) There are two bugs in the use of writev.  These are:
> 
> 2.1) When writing the headers and data you are writing a long to the
> file where iovec only supports (I think) an unsigned short.

	iovec can write as much as it wants to.  To write a 'long' one
	simply stuffs the _address_ of the long variable into iov_base
	and "sizeof long" into iov_len.  I'm not sure what you mean by
	iovec only supporting a short.

> 2.2) When writing the tape marks you are writing an integer as though it
> was a long.

	It isn't?  Oops.

	On some systms (those where "sizeof long == sizeof int") 'zero' 
	would be a long.

	Sigh - I've been contaminated by machines where that assumption is
	true.

> Now for the bad bit.  I have created a root.dump then run it through
> makesimtape with the command file:
> 
> /usr/root.dump 2
> * 1
> 
> and it won't load from restor.  I get a succession of "missing address
> (header) block" errors but I successfully detect the end of the tape and
> restor stops running, as it is supposed to do.

> So, am I doing something wrong in creating the root file? or is there

	Uh, yes ;)

	'dump' tapes *must* consist of 10kb records.  'restore' is expecting
	10kb (or 20 sector) records and complaining about the shortness of
	what it is reading.

> something still wrong with makesimtape?.  This is probably a red herring
> but the distribution tapes are written with a blocksize of 20 for all of
> the data after the bootstraps whilst makesimtape only writes multiples
> of 512.

	Correct.  The bootblock+boot needs to be 512 byte records so the
	boot rom can deal with it.  The standalone programs are 1kb records
	(because that's the filesystem block size and to make the 'seeking'
	in the pseudo-stdio routines possible/simple).

	All the _data_ files are 10kb records because that's what 'tar' and
	'dump' use.

	Steven

Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id DAA17381
	for pups-liszt; Thu, 31 Dec 1998 03:15:43 +1100 (EST)

From belfry at nsw.bigpond.net.au  Thu Dec 31 02:13:57 1998
From: belfry at nsw.bigpond.net.au (Michael Kraus)
Date: Thu, 31 Dec 1998 03:13:57 +1100
Subject: PDP Free to good home...
Message-ID: <368A5145.BE11CED3@nsw.bigpond.net.au>

G'day all...

I've got a DEC Pro/350 machine (including Pro OS and manuals, etc), as
well as a serial printer for it.

I've been planning on putting UNIX on it, and tracking down a network
card for it.  However, I don't really have enough time or space to do
such.

It is a PDP (unsure if it is a PDP-11 or not... I did find out, but that
was a while ago). I'm pretty sure that you will be able to get it to run
UNIX (v6, I think).

Rather then let it sit useless in my hall, I thought one of you guys (or
girls, as the case may be) may appreciate it more than what I currently
am.

The only cost involved would be the cost of getting yourself here,
picking it up and taking it back home.  FYI, I live in Paddington (NSW).

Email me if you are interested.

Michael.

P.s. It is in my posssesion as my father is a doctor and it was in use
for many years in his practice.  (Its only recently that they upgraded
as it suited the purpose so well!)


From norman at nose.cita.utoronto.ca  Thu Dec 31 01:29:56 1998
From: norman at nose.cita.utoronto.ca (norman at nose.cita.utoronto.ca)
Date: Wed, 30 Dec 1998 10:29:56 -0500
Subject: No subject
Message-ID: <199812301530.CAA18891@csadfa.cs.adfa.oz.au>

//GO.SYSIN DD ... is more a clue about what system I packed up
the file on than where I originally found it.  It's all rob's fault.



From mxs46 at k2.scl.cwru.edu  Tue Dec  1 11:02:02 1998
From: mxs46 at k2.scl.cwru.edu (Michael Sokolov)
Date: Mon, 30 Nov 1998 20:02:02 -0500
Subject: System Industries MSCP disk controller problem
Message-ID: <199812010102.UAA21295@skybridge.scl.cwru.edu>

   Dear Ladies and Gentlemen,
   
   I wonder, is anyone here familiar with System Industries (SI) Q-bus MSCP
controllers for ESDI disks? The VAX I'm working has one. It's quad-height
board with connectors for 4 ESDI drives. I couldn't find a model number or
anything like that, but there is a sticker on one of the chips that says
"SYS IND" on it (that's how I deduced that it's SI). The problem I'm having
is that I have no idea how to configure it. It has two DIP switch packs,
one with 4 switches and one with 10. Originally it was configured to be the
secondary disk MSCP controller at 160334. I want it to be the primary one
at 172150. I tried every reasonable switch combination I could think of,
but no luck.
   
   What's even worse is that I can't leave it as secondary either. For some
reason its configuration makes the CPU (KA650) unhappy. When I pull it out,
the CPU passes all power-up tests beautifully. When I put it in, I still
get to the ">>>" prompt eventually, but first I get a load of error
messages from the self-tests. Then when I try to boot from DUB0, it tells
me "DEVASSIGN", suggesting that it doesn't recognize the second disk MSCP
controller at all. All docs I have suggest that 160334 is the correct
address for secondary disk MSCP. It's in the floating address range,
though, so I suspected that it's the side effect of adding or removing
other cards. I tried making the configuration as close to the original as I
could. No luck still. The only card I had to pull out is the secondary
TMSCP (Emulex QT13 9-track tape controller), because it appears totally
toast (the CPU refuses to power up with that infamous 9 when this card is
present). But then secondary TMSCP should be AFTER secondary disk MSCP in
the floating address space, right? I tried some more investigation and by
pure accident I discovered that the SI controller also responds somehow to
160400. What the hell is that address for? Could this be what makes the CPU
unhappy?
   
   Does anyone have any clues? Is anyone here familiar with SI MSCP disk
controllers? TIA for any help.
   
   Sincerely,
   Michael Sokolov
   Cellular phone: 216-217-2579
   ARPA Internet SMTP mail: mxs46 at k2.scl.cwru.edu

Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id OAA12137
	for pups-liszt; Tue, 1 Dec 1998 14:27:04 +1100 (EST)

From SHOPPA at trailing-edge.com  Tue Dec  1 13:24:21 1998
From: SHOPPA at trailing-edge.com (Tim Shoppa)
Date: Mon, 30 Nov 1998 22:24:21 -0500
Subject: System Industries MSCP disk controller problem
Message-ID: <981130222421.2de00129@trailing-edge.com>

>   I wonder, is anyone here familiar with System Industries (SI) Q-bus MSCP
>controllers for ESDI disks? The VAX I'm working has one. It's quad-height
>board with connectors for 4 ESDI drives. I couldn't find a model number or
>anything like that, but there is a sticker on one of the chips that says
>"SYS IND" on it (that's how I deduced that it's SI). The problem I'm having
>is that I have no idea how to configure it. It has two DIP switch packs,
>one with 4 switches and one with 10. Originally it was configured to be the
>secondary disk MSCP controller at 160334. I want it to be the primary one
>at 172150. I tried every reasonable switch combination I could think of,
>but no luck.

This sounds a lot like the Webster WQESD, which was repackaged
and sold by many different folks (Sigma, DSD, Qualogy, American
Digital, etc.)

If it is a repackaged WQESD, SW9 on the 10-switch pack was originally
on, with SW10 and SW5-8 off, to put the CSR at 160334.  
To set it to be 172150, you put SW10 on, and SW5-9 off.

Then again, it might not be a repackaged WQESD, but instead a Dilog
or Emulex.

Is there a 10-pin header on the card edge?  Can you describe the positions
and types of "big chips" on the board?
   
>pure accident I discovered that the SI controller also responds somehow to
>160400. What the hell is that address for? Could this be what makes the CPU
>unhappy?

It might be because you've enabled the on-board PDP-11 bootstrap,
a very big no-no when used in a Microax system.  (This
bootstrap effectively tries to jam code by DMA into main memory,
and can wreak all sorts of havoc on a Microvax.)  Some
other switches also set the interrupt priority, and this being
off can also confuse some tests and OS's.

As to your power-on self-test woes, you're going to have to tell
us what's in the system and what slot it lives in, as well as what
sort of backplane it's all in.

Incidentally, I happen to use a Webster WQESD in my 4.3BSD-Reno
machine, and am very happy with it there.

-- 
 Tim Shoppa                        Email: shoppa at trailing-edge.com
 Trailing Edge Technology          WWW:   http://www.trailing-edge.com/
 7328 Bradley Blvd		   Voice: 301-767-5917
 Bethesda, MD, USA 20817           Fax:   301-767-5927


From wkt at henry.cs.adfa.oz.au  Thu Dec  3 09:18:43 1998
From: wkt at henry.cs.adfa.oz.au (Warren Toomey)
Date: Thu, 3 Dec 1998 10:18:43 +1100 (EST)
Subject: New Apout PDP-11 simulator
Message-ID: <199812022318.KAA27852@henry.cs.adfa.oz.au>

All,
	I've just spent the week tidying up my Apout program. This runs
PDP-11 user-mode programs (specifically 7th Edition binaries), and
translates V7 syscalls to native syscalls.

I've tidied the program up and optimised it a bit too. Over the summer
break (it's summer down here) I want to add floating-point and start
work on emulating 2.11BSD user-mode binaries.

The program runs on FreeBSD 2.2.x and 3.0 systems: porting to other 32-bit
little-endian Unix systems should be relatively easy. Porting to big-endian
systems might be harder :-) I'll have a look at that too.

Anyway, an alpha of the new 2.2 version is at:
	ftp://minnie.cs.adfa.edu.au/pub/PDP-11/Sims/Apout

Cheers,
	Warren

Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id PAA24007
	for pups-liszt; Thu, 3 Dec 1998 15:51:17 +1100 (EST)

From msokolov at harrier.Uznet.NET  Thu Dec  3 14:48:30 1998
From: msokolov at harrier.Uznet.NET (Michael Sokolov)
Date: 3 Dec 1998   04:48:30 GMT
Subject: System Industries MSCP disk controller problem
Message-ID: <199812030448.JAA06898@harrier.Uznet.NET>

   Tim Shoppa <SHOPPA at trailing-edge.com> wrote:
> This sounds a lot like the Webster WQESD, which was repackaged
> and sold by many different folks (Sigma, DSD, Qualogy, American
> Digital, etc.)
   
   Quite possible, since this funny Xerox system has a lot of Sigma
components. The outer box in which the BA23 is mounted is made by Sigma,
the funny way the ESDI drives are mechanically mounted is clearly a Sigma
invention, the card connecting the BA23 backplane to the expansion
backplane in the outer Sigma box is made by Sigma, and so is another
totally unmarked card of unknown purpose (its presence or absence appears
to have absolutely no effect on anything). The system is not 100% Sigma,
though. There also another 2-drive ESDI controller (that's the one that was
at 172150 from the beginning) and a 9-track tape controller, both made by
Emulex (QD21 and QT13, respectively) and both appear toast (I want to get
rid of both).
   
> If it is a repackaged WQESD, SW9 on the 10-switch pack was originally
> on, with SW10 and SW5-8 off, to put the CSR at 160334.
> To set it to be 172150, you put SW10 on, and SW5-9 off.
   
   Before I got your E-mail, SW5 and SW8 were ON and the rest were OFF
(don't remember if it was the original position). I also tried SW10 ON and
the rest OFF. In both cases the effect is exactly the same. At power-up the
CPU screams, but then gives the ">>>" prompt. Trying to read different
locations with the E/P/W command (the Q-bus I/O page is mapped at
0x20000000 in the VAX address space), I see that the card responds somehow
to 160334 and to 160400, but not to 172150. (I know that it's this card and
not something else, since when I pull it out the CPU is happy and no one
responds to these addresses.)
   
> Then again, it might not be a repackaged WQESD, but instead a Dilog
> or Emulex.
   
   I'm 99% sure that it's neither Dilog nor Emulex. I have seen quite a few
Dilog and Emulex cards, and I think I should be able to detect them easily.
   
> Is there a 10-pin header on the card edge?  Can you describe the
> positions and types of "big chips" on the board?
   
   This is a quad-height board. All components are thru-hole and all chips
are in DIP packages. There are no 4-sided chips or surface-mounted
components. Hold it with the component side up, the fingers to the right
and the handles to the left. On the left (handle) side there is a row of
shrouded header connectors. From top to bottom, they are: 10-pin (connected
to something, but purpose unknown), 34-pin (ESDI control and status), 20-
pin (drive 0 data), 20-pin (drive 1 data), 20-pin (drive 2 data). Directly
behind the bottom 20-pin header there is another 20-pin header for drive 3
data. The biggest chip is a 48-pin DIP labeled DP8466AN (National
Semiconductor as far as I can tell), and it's right behind the drive 3 data
connector. There are two AM2901CPCs behind the 34-pin connector. There is
one 28-pin EPROM right about in the center, shifted downward a little. The
ROM size is obscured by the sticker saying "ESDI V2.41 9901-8918 REV.A".
There is a stack of narrow 24-pin DIP chips going from the top of the board
to right above the EPROM. All have stickers, suggesting that they are
programmable. The stickers have different 6-character codes on them, all
starting with "1583". Directly to the right from the last one there is one
more such chip labeled "SYS IND 1583W3".
   
   Actually, I was wrong about there being 2 switch packs. There are 3 of
them, one of 10 and two of 4. The 10-switch one is right above the chip
labeled "SYS IND 1583W3". In the top right corner (right next to row A
fingers) there is a 4-switch pack. All switches are ON. Directly behind it
there is a 16-pin DIP chip labeled "1583I1" (the only chip with a sticker
not mentioned before). At the top of the board directly to the left from
the 10-chip stack there is a 10 MHz oscillator, the only clock on the
board. Directly to the left from it there is the last 4-switch pack. All
switches are ON. Finally, there are 3 LEDs between the top handle and the
10-pin header. The top one is red and the other two are green.
   
> Some
> other switches also set the interrupt priority, and this being
> off can also confuse some tests and OS's.
   
   What's the correct priority for disk MSCP? Should it be different
between primary and secondary?
   
> As to your power-on self-test woes, you're going to have to tell
> us what's in the system and what slot it lives in, as well as what
> sort of backplane it's all in.
   
   The outer box is Sigma. It provides funny mounting for 4 ESDI drives, an
expansion Q-bus backplane, and a big bay for a BA23. The BA23 contains the
CPU, the memory, and all peripherals except the controller in question.
First comes the KA650 CPU. Then two MS650 memory modules. Then DELQA,
DZQ11, TQK50, and the Sigma Q-bus extender card. The latter takes the Q-bus
into the expansion backplane, where the controller in question is the only
device. It's in the expansion backplane instead of the BA23 because that's
where the actual drives are. I have tried pulling the Sigma Q-bus extender
card out and putting the ESDI controller right in the BA23 backplane, but
this didn't change anything, so there is nothing wrong with the Q-bus
expansion.
   
   You know what, I just looked a little closer and noticed that in this
configuration (both 4-switch packs all ON, SW1-9 on the 10-switch pack OFF,
and SW10 ON) the controller responds not only to 160334 and 160400, but to
just about any address in the Q-bus I/O page (except 172150)! No wonder the
CPU screams about it! What the hell is going on? How can it possibly do
this? Is someone trying to port Plug-n-Pray to Q-bus? Is it something like
KFQSA with a separate address for each drive and everything soft-
configured?
   
   Sincerely,
   Michael Sokolov
   Cellular phone: 216-217-2579
   ARPA Internet SMTP mail: msokolov at harrier.Uznet.NET


Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id BAA25817
	for pups-liszt; Fri, 4 Dec 1998 01:27:17 +1100 (EST)

From SHOPPA at trailing-edge.com  Fri Dec  4 00:25:04 1998
From: SHOPPA at trailing-edge.com (Tim Shoppa)
Date: Thu, 3 Dec 1998 9:25:04 -0500
Subject: System Industries MSCP disk controller problem
Message-ID: <981203092504.2de002c1@trailing-edge.com>

>> This sounds a lot like the Webster WQESD, which was repackaged
>> and sold by many different folks (Sigma, DSD, Qualogy, American
>> Digital, etc.)
>   Quite possible, since this funny Xerox system has a lot of Sigma
>components.

I regularly work with "PDP-11 systems" now that don't have a single
DEC component in them.  CPU by Mentec ( http://www.mentec.com/ ), 
disk controller by Andromeda ( http://www.andromedasystems.com/ ),
async and parallel I/O by the Logical Company ( http://www.logical-co.com ),
etc.  What else are commercial developers left to do now that
DEC (after over a decade of trying to) has finally abandoned their
PDP-11 product line?  At least the other companies named are still
doing active support and (at least in Mentec's case) development!

> The outer box in which the BA23 is mounted is made by Sigma,
>...
>though. There also another 2-drive ESDI controller (that's the one that was
>at 172150 from the beginning) and a 9-track tape controller, both made by
>Emulex (QD21 and QT13, respectively) and both appear toast (I want to get
>rid of both).

You might be a bit hasty in casting these off, as you aren't having
the best of luck with the rest of the peripherals, either!
   
>> If it is a repackaged WQESD, SW9 on the 10-switch pack was originally
>> on, with SW10 and SW5-8 off, to put the CSR at 160334.
>> To set it to be 172150, you put SW10 on, and SW5-9 off.
>   Before I got your E-mail, SW5 and SW8 were ON and the rest were OFF
>(don't remember if it was the original position). I also tried SW10 ON and
>the rest OFF. In both cases the effect is exactly the same. At power-up the
>CPU screams, but then gives the ">>>" prompt. Trying to read different
>locations with the E/P/W command (the Q-bus I/O page is mapped at
>0x20000000 in the VAX address space), I see that the card responds somehow
>to 160334 and to 160400, but not to 172150. (I know that it's this card and
>not something else, since when I pull it out the CPU is happy and no one
>responds to these addresses.)
>> Is there a 10-pin header on the card edge?  Can you describe the
>> positions and types of "big chips" on the board?
>   This is a quad-height board. All components are thru-hole and all chips
>are in DIP packages. There are no 4-sided chips or surface-mounted
>components. Hold it with the component side up, the fingers to the right
>and the handles to the left. On the left (handle) side there is a row of
>shrouded header connectors. From top to bottom, they are: 10-pin (connected
>to something, but purpose unknown), 34-pin (ESDI control and status), 20-
>pin (drive 0 data), 20-pin (drive 1 data), 20-pin (drive 2 data). Directly
>behind the bottom 20-pin header there is another 20-pin header for drive 3
>data. The biggest chip is a 48-pin DIP labeled DP8466AN (National
>Semiconductor as far as I can tell), and it's right behind the drive 3 data
>connector. There are two AM2901CPCs behind the 34-pin connector. There is
>one 28-pin EPROM right about in the center, shifted downward a little. The
>ROM size is obscured by the sticker saying "ESDI V2.41 9901-8918 REV.A".

That clinches it - it's a Webster WQESD, running Wombat V2.41.

9901-8918 is evidently the SI part number for the complete system.
It's a bit confusing to go from the SI part number because they all
begin with "9900" or "9901"!
   
>   What's the correct priority for disk MSCP? Should it be different
>between primary and secondary?

A summary of the WQESD switch settings, and the various ways in which
you can invoke Wombat, lives at:

 ftp://sunsite.unc.edu/pub/academic/computer-science/history/pdp-11/hardware

as the file "WQESD.txt".
   
>> As to your power-on self-test woes, you're going to have to tell
>> us what's in the system and what slot it lives in, as well as what
>> sort of backplane it's all in.
   
>   The outer box is Sigma. It provides funny mounting for 4 ESDI drives, an
>expansion Q-bus backplane, and a big bay for a BA23. The BA23 contains the
>CPU, the memory, and all peripherals except the controller in question.
>First comes the KA650 CPU. Then two MS650 memory modules. Then DELQA,
>DZQ11, TQK50, and the Sigma Q-bus extender card. The latter takes the Q-bus
>into the expansion backplane, where the controller in question is the only
>device. It's in the expansion backplane instead of the BA23 because that's
>where the actual drives are. I have tried pulling the Sigma Q-bus extender
>card out and putting the ESDI controller right in the BA23 backplane, but
>this didn't change anything, so there is nothing wrong with the Q-bus
>expansion.

I'm willing to bet that you have severe Q-bus continuity problems,
especially now that you've told us that you have an expansion Q-bus
cabinet and that you've been randomly moving Q-bus cards around.
You have to tell us exactly which slot each card is in, and preferably
the original configuration as well (the Sigma backplanes have different
wirings than the common DEC ones.)

Is the "BA23" indeed a real DEC BA23, and not the Sigma "clone"?
The sigma 5.25" 9-slot backplanes have very different backplane
wirings (and, indeed, putting a DEC dual-wide Microvax CPU into
it will very likely cause damage.)

As a start, work just with the BA23.  Put the CPU in slot 1, with
the two memory boards in slots 2 and 3.  Put the WQESD in slot 4.
Have nothing else plugged in at all - especially not the boards
that jumper the two backplanes together.

Set the DIPswitches on the WQESD as follows:
10-switch pack: Switches 1-2 off, 3 on, 4-9 off, 10 on.
4-switch pack near the edge connector: 1-3 on, 4 off.
4-switch pack near the handles: 1-4 on.

Then try to start up wombat with the following sequence of console commands:

Microvax II:
Halt the processor
U
I
D/P/W 20001F40  20
D/L 20088008 80000002
D/W 20001468 AC
S 400

If this doesn't start Wombat, tell us *exactly* what the error message
produced is.

--    
 Tim Shoppa                        Email: shoppa at trailing-edge.com
 Trailing Edge Technology          WWW:   http://www.trailing-edge.com/
 7328 Bradley Blvd		   Voice: 301-767-5917
 Bethesda, MD, USA 20817           Fax:   301-767-5927


From msokolov at harrier.Uznet.NET  Fri Dec  4 06:08:37 1998
From: msokolov at harrier.Uznet.NET (Michael Sokolov)
Date: 3 Dec 1998   20:08:37 GMT
Subject: System Industries MSCP disk controller problem
Message-ID: <199812032008.BAA08080@harrier.Uznet.NET>

   Dear Tim,
   
   I have just tried configuring the board as you have suggested and it
works! Thanks! You have saved the Project!
   
   When I tried starting WOMBAT, it also worked. However, there are tons of
configuration parameters you can set there. All 4 disks connected to this
controller are already configured and formatted, so for now I'd just leave
it alone and install Ultrix on these disks as they are. For the future,
however, I would really appreciate being able to configure all that stuff.
Do you have a full manual for this controller? Would you mind sending me a
xerox copy?
   
> What else are commercial developers left to do now that
> DEC (after over a decade of trying to) has finally abandoned their
> PDP-11 product line?
   
   What about VAXen? Can you still call 1-800-DIGITAL with a _BIG_ credit
card in hand and order a VAX?
   
> You might be a bit hasty in casting these off, as you aren't having
> the best of luck with the rest of the peripherals, either!
   
   Well, now that the WQESD works and while I'm waiting for the TQK50 (one
very friendly PUPS member is providing me with a working one), I can turn
my attention to these two. Let's start with the 2-drive ESDI one. The
Emulex logo and copyright appear in a lot of places, so there is no problem
with identification. The board is labeled "ASSY QD2110402 REV G", and just
like every other Emulex board I have ever seen, it has a 40-pin chip with
an Emulex SUB-ASSY sticker. In this case it's "QD2110202-00G". Do you know
anything about this board? It has two switch packs, one of 4 and one of 8.
What are the switch settings?
   
   Now let's turn to the 9-track tape controller. Again there is no problem
with identification (straight Emulex). The board is labeled "ASSY
QT1310401-00 REV E" and the 40-pin chip is labeled "QT1310201-02 REV K".
Again it has one 4-switch pack and one 8-switch pack. There is something
seriously wrong with this board, since when it's present in the backplane
the CPU refuses to power up. It stalls at that infamous 9 very early in the
power-up sequence, before any console tests or displays, suggesting that
something is HORRIBLY wrong with Q-bus (maybe a short or something?).
   
   And while we are at it, I have a question about 9-track tape transports
and controllers in general. I often hear about something called Pertec.
What is it? Is it some kind of standard interface that nearly all tape
transports use? It is what this QT13 controller is for? (It has 2 50-lead
connectors.) I remember at CWRU there was a very neat-looking tape
transport called Cipher. It looked EXACTLY like DEC TS05, suggesting that
it's what the TS05 really is. That one also had a two-50-lead-cables
interface as far as I could tell (it was disconnected). It also appeared to
be dual-ported. Does this mean that DEC also used this Pertec interface?
Then why are there different DEC controllers for different DEC 9-track tape
transports (TSV05 for TS05, KLESI for TU81+, etc.)? If they were all Pertec
one controller would fit all, wouldn't it? Or is that some DEC 9-track tape
hardware uses Pertec and other DEC hardware doesn't?
   
   Moving on to the next and last unidentified flying board. This one is a
total mystery. The board is labeled "SIGMA INFORMATION SYSTEMS, INC." and
"ASSY NO 400135 REV A". There are NO microprocessors, ROMs, or any other
LSI chips on the board, only SSI/MSI chips, resistors, and capacitors. It's
a dual-height board. It has 3 8-switch packs. There is one 40-lead shrouded
header connector on the board, and a straight 40-lead ribbon cable connects
it to a bulkhead which has a female 37-lead D-sub connector on the outside.
Any ideas on what in the world is this?
   
> I'm willing to bet that you have severe Q-bus continuity problems,
> especially now that you've told us that you have an expansion Q-bus
> cabinet and that you've been randomly moving Q-bus cards around.
   
   I am perfectly aware of the fact that Q-bus requires grant continuity
and, no, I was NOT moving cards around "randomly". I have them in the order
DEC recommends in all of its manuals. There is no problem with the
expansion backplane either, the WQESD is quite happy sitting there right
now.
   
> Is the "BA23" indeed a real DEC BA23, and not the Sigma "clone"?
   
   A real DEC one, of course. While I have never been a DEC engineer or
anything like that, I have certainly seen and used enough BA23s to tell one
from a third-party box.
   
   The expansion backplane is Sigma, though.
   
> The sigma 5.25" 9-slot backplanes have very different backplane
> wirings (and, indeed, putting a DEC dual-wide Microvax CPU into
> it will very likely cause damage.)
   
   Yes, I know. The yellow sticker on the expansion backplane says:
"CAUTION! Do not install MicroVAX or KDJ11-B series CPUs into this
backplane."
   
   Sincerely,
   Michael Sokolov
   Cellular phone: 216-217-2579
   ARPA Internet SMTP mail: msokolov at harrier.Uznet.NET


Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id IAA27264
	for pups-liszt; Fri, 4 Dec 1998 08:36:51 +1100 (EST)

From djenner at halcyon.com  Fri Dec  4 07:35:51 1998
From: djenner at halcyon.com (David C. Jenner)
Date: Thu, 03 Dec 1998 13:35:51 -0800
Subject: System Industries MSCP disk controller problem
References: <199812032008.BAA08080@harrier.Uznet.NET>
Message-ID: <36670437.966A4527@halcyon.com>

> > The sigma 5.25" 9-slot backplanes have very different backplane
> > wirings (and, indeed, putting a DEC dual-wide Microvax CPU into
> > it will very likely cause damage.)
> 
>    Yes, I know. The yellow sticker on the expansion backplane says:
> "CAUTION! Do not install MicroVAX or KDJ11-B series CPUs into this
> backplane."

I have a box with one of these.  I noticed the bussing appeared to
be non-standard, but exactly what is the problem here?

I also have a couple of Netcom HV1148 backplanes that
appear to be non-standard.  Any experience with these?

What can you do with these backplane?  What sort of Q-Bus system
can you use them in?

Thanks,
Dave

Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id MAA28393
	for pups-liszt; Fri, 4 Dec 1998 12:45:17 +1100 (EST)

From msokolov at harrier.Uznet.NET  Fri Dec  4 11:44:38 1998
From: msokolov at harrier.Uznet.NET (Michael Sokolov)
Date: 4 Dec 1998   01:44:38 GMT
Subject: Emulex QT13 and related questions
Message-ID: <199812040144.GAA08380@harrier.Uznet.NET>

   Dear Tim and other Q-bus gurus,
   
   Emanuel Stiebler has pointed me to a message posted to vmsnet.pdp11 by
Tim a while ago, and there I have found the info on Emulex QT13. Thanks!
   
   Since none of my two non-working TQK50s is currently installed, I have
tried configuring the QT13 as the primary TMSCP controller and plugging it
in. Guess what, this time it powered up without that ugly 9! Nice! I
probably won't do much with it, though, since although I do have a 9-track
tape transport here in my apartment, I want to leave it alone for now. It's
enormous, by far the biggest piece of equipment here, and I don't feel like
playing with it now. Some time later maybe.
   
   This exercise does raise a few questions, though. Suppose some time
later I decided to use this beast. Suppose I wanted to make this QT13 a
secondary TMSCP controller. This and other very similar exercises require
knowing the rules for floating CSR and vector assignments. What can I find
the complete rules for this? My ancient UNIBUS DZ11 manual only lists the
earliest floating devices, no MSCP or DHUs or anything like that. I once
had some MicroVAX manual that included a table for "common configurations",
but I don't have it any more, plus I'm really looking for the complete
rules and not just "common configurations". Any ideas? Of course if I had a
KA655 or a KA660 I would just type "CONFIGURE" at the ">>>" prompt, but I
only have a plain 650 which doesn't have this luxury.
   
   Also looking at the configuration of this QT13 board, I noticed that it
was originally configured for trailing edge strobe. Tim's notes indicate
that this is for Kennedy 9300 only and that the rest should use leading
edge strobe. The tape transport I have here is labeled as CDC KEYSTONE. Is
this another name for Kennedy 9300 or a different beast? Does anyone know
anything about this transport?
   
   Sincerely,
   Michael Sokolov
   Cellular phone: 216-217-2579
   ARPA Internet SMTP mail: msokolov at harrier.Uznet.NET


Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id NAA28457
	for pups-liszt; Fri, 4 Dec 1998 13:14:10 +1100 (EST)

From msokolov at harrier.Uznet.NET  Fri Dec  4 12:13:33 1998
From: msokolov at harrier.Uznet.NET (Michael Sokolov)
Date: 4 Dec 1998   02:13:33 GMT
Subject: System Industries MSCP disk controller problem
Message-ID: <199812040213.HAA08416@harrier.Uznet.NET>

   David C. Jenner <djenner at halcyon.com> wrote:
> I have a box with one of these.  I noticed the bussing appeared to
> be non-standard, but exactly what is the problem here?
   
   I don't think it's non-standard. It's probably just a different
standard. Strictly speaking, there is no such thing as a Q-bus backplane.
There are Q/Q, Q/CD, and other types of Q-bus'ish backplanes. Generally,
you call something a "Q-bus backplane" if it has Q-bus in rows A and B.
Rows C and D may be used for lots of different things. In theory you can
have these rows used for something REALLY weird. Allison J. Parent tells me
that once upon a time you could get a special version of BA11 where rows C
and D were customer-wired, i.e., you could have absolutely anything you
want in there.
   
   In practice, however, there are only two types of row C&D wiring. On
some backplanes you have Q-bus in both A&B and C&D, with the grant
continuity going in a serpentine. Some BA11 versions are like this. Such
backplanes are called Q/Q. On other backplanes Q-bus goes straight down the
A&B rows without ever touching rows C and D. In these backplanes rows C&D
are connected in a daisy chain, i.e., the fingers on the solder side of the
board in slot 1 connect to the fingers on the component side of the board
in slot 2, the fingers on the solder side of the board in slot 2 connect to
the fingers on the component side of the board in slot 3, and so on. This
way immediately adjacent boards can use rows C&D as a totally private
interconnect that has zero effect on or relationship with anything else in
the system, just like an over-the-top cable. The best example of this is
RLV11, although the most common example is MicroVAX II and III memory. Such
backplanes are usually called Q/CD, and the examples are some versions of
BA11 and all BA2xx and BA4xx backplanes.
   
   Finally, there are mixed backplanes that have several Q/CD slots
followed by many Q/Q slots. These are specifically designed for MicroVAXen
and other CPUs using rows C&D as a private memory interconnect. These
backplanes are BA23 (3 Q/CD slots and 5 Q/Q slots) and BA123 (4 Q/CD slots
and 8 Q/Q slots).
   
   Getting back to the Sigma backplanes, the inability to put a MicroVAX
CPU in there suggests that they are Q/Q.
   
   Sincerely,
   Michael Sokolov
   Cellular phone: 216-217-2579
   ARPA Internet SMTP mail: msokolov at harrier.Uznet.NET


Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id QAA29379
	for pups-liszt; Fri, 4 Dec 1998 16:19:44 +1100 (EST)

From wkt at henry.cs.adfa.oz.au  Fri Dec  4 15:21:40 1998
From: wkt at henry.cs.adfa.oz.au (Warren Toomey)
Date: Fri, 4 Dec 1998 16:21:40 +1100 (EST)
Subject: New Apout PDP-11 simulator
In-Reply-To: <19981204154443.E38307@freebie.lemis.com> from Greg Lehey at "Dec 4, 98 03:44:43 pm"
Message-ID: <199812040521.QAA03261@henry.cs.adfa.oz.au>

[greg] Looks good.  When are you going to add support for 2.11BSD? :-)

[warren] I've just started. Emulating all 150+ syscalls is going to take a
   while. I'll try to modify the V7 syscall support for 2.11BSD; that should
   get  most simple programs working. After that, one syscall at a time....
 
[greg] Hmm.  I suppose the networking will cause you the most headaches
       (maybe...  maybe, of course, you can pass them through to FreeBSD
       almost unchanged).  Most of the things I use the PDP 11 for are
       networking (letting people dial in, etc), but I'll certainly try
       things out as soon as you think it would be worthwhile.

I'm thinking sometime early next year for an initial release with
just the `V7' syscalls in the 2.11BSD emulation. As you said, many of
the syscalls will be a pass-thru, with just args and return values to
be mapped.

I'll let the list know as I go...

	Warren

Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id VAA00320
	for pups-liszt; Fri, 4 Dec 1998 21:32:38 +1100 (EST)

From msokolov at harrier.Uznet.NET  Fri Dec  4 20:31:01 1998
From: msokolov at harrier.Uznet.NET (Michael Sokolov)
Date: 4 Dec 1998   10:31:01 GMT
Subject: Some nice progress with hardware and Ultrix in the PUPS archive
Message-ID: <199812041031.PAA09422@harrier.Uznet.NET>

   Dear Ladies and Gentlemen,
   
   Emanuel Stiebler has graciously provided me with a reference to a freely
downloadable copy of the Emulex QD21 manual. Using that manual, I have got
mine configured correctly and ran firmware diagnostics on it. It looks like
the Emulex card is OK, but for some reason it isn't seeing the drive
attached to it. Probably a defective drive reporting not ready or maybe
just a connection problem (the drive is mounted in some very weird way so
that I can't even check the connection, let alone see the jumpers or
anything). Oh well, I'll figure it out later. Right now i have the WQESD
controller configured as the primary one, and it has 4 working 320 MB disks
attached to it, so it should be enough for me to build and release 4.3BSD-
Quasijarus1.
   
   But there is something even more interesting. I got the TK50 to work!
Yay! It turned out that one of the TQK50 boards was working after all, it
was simply being screwed up by the rest of the system standing on its ears.
   
   After I got the VAX to boot from some VMSish tape I have (it boots, asks
for date and time, prints something about some "standalone backup" and
gives me a "$" prompt, but I'm absolutely NULL in VMS, so this doesn't do
me much good), I realized that I couldn't boot from my Ultrix tapes because
there is something wrong with the way I wrote them. I wrote them on a TZ30
(half-height native-SCSI TK50 clone) connected to a 386 with an Adaptec
1520A running FreeBSD booted from a floppy (the 386's big ESDI hard disk is
filled with DOS stuff only). In fact, when I tried reading that tape back
on this very same FreeBSD thing it didn't read! Something is clearly wrong.
   
   As I was thinking about how else can I get correctly written Ultrix
tapes, the following idea sneaked into my mind. The PUPS archive already
contains PDP-11 Ultrix. How about VAX Ultrix? With Warren's permission, I
would be more than happy to upload my VAX Ultrix tape images (I have them
sitting as files on my DOS disk). Once that is done, would someone
volunteer to download them, write them to two TK50 cartridges, and send
them to me? TIA for any help.
   
   Sincerely,
   Michael Sokolov
   Cellular phone: 216-217-2579
   ARPA Internet SMTP mail: msokolov at harrier.Uznet.NET



From wkt at henry.cs.adfa.oz.au  Sat Dec  5 17:27:36 1998
From: wkt at henry.cs.adfa.oz.au (Warren Toomey)
Date: Sat, 5 Dec 1998 18:27:36 +1100 (EST)
Subject: Some nice progress with hardware and Ultrix in the PUPS archive
In-Reply-To: <199812041031.PAA09422@harrier.Uznet.NET> from Michael Sokolov at "Dec 4, 98 10:31:01 am"
Message-ID: <199812050727.SAA04411@henry.cs.adfa.oz.au>

In article by Michael Sokolov:
>    As I was thinking about how else can I get correctly written Ultrix
> tapes, the following idea sneaked into my mind. The PUPS archive already
> contains PDP-11 Ultrix. How about VAX Ultrix? With Warren's permission, I
> would be more than happy to upload my VAX Ultrix tape images (I have them
> sitting as files on my DOS disk). Once that is done, would someone
> volunteer to download them, write them to two TK50 cartridges, and send
> them to me? TIA for any help.

We have to be careful with 3rd party UNIXes. We would have to get approval
from DEC (or whoever they are) to allow us to add their product into the
archive. I did this with V7M and the later Ultrix-11s before DEC got bought
out.

	Warren

Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id BAA04900
	for pups-liszt; Sun, 6 Dec 1998 01:36:15 +1100 (EST)

From SHOPPA at trailing-edge.com  Sun Dec  6 00:33:16 1998
From: SHOPPA at trailing-edge.com (Tim Shoppa)
Date: Sat, 5 Dec 1998 9:33:16 -0500
Subject: System Industries MSCP disk controller problem
Message-ID: <981205093316.2de002c3@trailing-edge.com>

>   I have just tried configuring the board as you have suggested and it
>works! Thanks! You have saved the Project!

"It has to be simple or I can't do it :-)".  In this case (like just
about all), it's a matter of getting rid of unknowns.
   
>   When I tried starting WOMBAT, it also worked. However, there are tons of
>configuration parameters you can set there.

Oh yeah - the Webster controllers are wonderfully configurable.  It's
incredibly useful, as one physical disk can be partitioned up many ways
into "virtual" MSCP units - especially useful for OS's which don't deal
well with large units (or when it's desirable to have many different 
versions of many different OS's on the same disk.)

>Do you have a full manual for this controller? Would you mind sending me a
>xerox copy?

Sure, for the cost of copying and postage.  Or I'd trade you for some
surplus of yours.
   
>   What about VAXen? Can you still call 1-800-DIGITAL with a _BIG_ credit
>card in hand and order a VAX?

Yep - high end 3100 and 4000 units are still available.

(It looks like someone has already pointed you towards the Emulex QD21
and QT13 docs available around the net.)   
   
>   And while we are at it, I have a question about 9-track tape transports
>and controllers in general. I often hear about something called Pertec.
>What is it? Is it some kind of standard interface that nearly all tape
>transports use?

Nearly all non-SCSI, non-proprietary interface tape drives will have
either (or both) Pertec formatted and Pertec unformatted interfaces.

Pertec unformatted drives have three cables; one carries read data, 
another carries write data, and the third carries control signals.  It's
a rather low-level interface - the controller tells the drive to go
forward, then reads or writes data, with the controller responsible
for all the timing.  The controller gets to do the nitty-gritty work
of repositioning and spacing forward and backward over tape marks.

Pertec formatted drives have two 50-pin cables.  It's a higher-level
interface, where the "formatter" does a lot of the nitty-gritty work, and
the controller in the backplane just has to spew out data bytes (or
take them in).

Many times you'll see a Pertec unformatted drive with a formatter bolted
onto it with two 50-pin cables coming out.  (In most cases, a formatter
could control multiple physical drives.)  Other times you'll find
"embedded formatter" drives, where there is no 3-cable unformatted
interface lurking inside.

> It is what this QT13 controller is for? (It has 2 50-lead
>connectors.)

Yep, Pertec formatted.  The QT13 is nice because it'll emulate
either MU: or MS:-type devices.

> I remember at CWRU there was a very neat-looking tape
>transport called Cipher. It looked EXACTLY like DEC TS05, suggesting that
>it's what the TS05 really is.

Yep, a TS05 is a rebadged Cipher F880 (with some slightly-different 
firmware).

> That one also had a two-50-lead-cables
>interface as far as I could tell (it was disconnected). It also appeared to
>be dual-ported.

It probably had 4 50-pin edge connectors, so that multiple drives could
be chained on the same Pertec-formatted-bus.  (There are terminators at
each end of the bus, much like SCSI.)  There's provisions for at least
4 formatters per bus, with each formatter potentially running multiple
drives.

> Does this mean that DEC also used this Pertec interface?

Yep.  Actually, the DEC TS05/TSV05/TU80 controllers are rebadged Dilog boards
(again, with slightly different firmware - for instance a DEC TU80 controller
will only work with TU80 drives or their CDC equivalent, the Keystone.)

>Then why are there different DEC controllers for different DEC 9-track tape
>transports (TSV05 for TS05, KLESI for TU81+, etc.)? If they were all Pertec
>one controller would fit all, wouldn't it? Or is that some DEC 9-track tape
>hardware uses Pertec and other DEC hardware doesn't?

At the guts of most DEC tape drives, you will often find either a Pertec
formatted or unformatted interface.  TU80's and TS(V)05's are simple
Pertec formatted interfaces.  Other times they convert to some other
interface (Massbus, LESI, etc.) before the cables come out to the "real
world".
   
>   Moving on to the next and last unidentified flying board. This one is a
>total mystery. The board is labeled "SIGMA INFORMATION SYSTEMS, INC." and
>"ASSY NO 400135 REV A". There are NO microprocessors, ROMs, or any other
>LSI chips on the board, only SSI/MSI chips, resistors, and capacitors. It's
>a dual-height board. It has 3 8-switch packs. There is one 40-lead shrouded
>header connector on the board, and a straight 40-lead ribbon cable connects
>it to a bulkhead which has a female 37-lead D-sub connector on the outside.
>Any ideas on what in the world is this?

Any chance it's a simple parallel I/O?

Could also be the bus interface for a Sigma and/or DSD MFM drive controller
(if so, it probably emulates RL02's).  The assembly number sounds vaguely
DSD-like.

-- 
 Tim Shoppa                        Email: shoppa at trailing-edge.com
 Trailing Edge Technology          WWW:   http://www.trailing-edge.com/
 7328 Bradley Blvd		   Voice: 301-767-5917
 Bethesda, MD, USA 20817           Fax:   301-767-5927

Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id BAA04942
	for pups-liszt; Sun, 6 Dec 1998 01:44:43 +1100 (EST)

From SHOPPA at trailing-edge.com  Sun Dec  6 00:42:42 1998
From: SHOPPA at trailing-edge.com (Tim Shoppa)
Date: Sat, 5 Dec 1998 9:42:42 -0500
Subject: Some nice progress with hardware and Ultrix in the PUPS archive
Message-ID: <981205094242.2de002c3@trailing-edge.com>

>   As I was thinking about how else can I get correctly written Ultrix
>tapes, the following idea sneaked into my mind. The PUPS archive already
>contains PDP-11 Ultrix. How about VAX Ultrix?

As Warren pointed out, there might be a problem with putting such
tapes on the PUPS archive.  I'd be glad to run off TK50's from images
for you, though I think your earlier idea, about installing from
the miniroot image that's commonly put on 4.2- and 4.3BSD derived
distributions, is a *far* better idea as it avoids using a TK50
tape drive at all.

It's not that tape copies are bad ideas - it's just that TK50's
are so slow.  If you were coming from 9-track or DLT or something
fast, that wouldn't be so bad.

If you can get just about any OS running on your
Q-bus machine, under any CPU - i.e. NetBSD, RT-11, 2.11BSD, RSX,
whatever you might have - then you can just write the miniroot
straight to a "scratch" disk.  You can also write the root
dump and tar savesets straight to another scratch disk, in "raw"
format, if you desire.

-- 
 Tim Shoppa                        Email: shoppa at trailing-edge.com
 Trailing Edge Technology          WWW:   http://www.trailing-edge.com/
 7328 Bradley Blvd                 Voice: 301-767-5917
 Bethesda, MD, USA 20817           Fax:   301-767-5927


From msokolov at harrier.Uznet.NET  Tue Dec  8 02:37:52 1998
From: msokolov at harrier.Uznet.NET (Michael Sokolov)
Date: 7 Dec 1998   16:37:52 GMT
Subject: Some nice progress with hardware and Ultrix in the PUPS archive
Message-ID: <199812071638.VAA15617@harrier.Uznet.NET>

   Dear Tim,
   
   You write:
> I'd be glad to run off TK50's from images
> for you, though I think your earlier idea, about installing from
> the miniroot image that's commonly put on 4.2- and 4.3BSD derived
> distributions, is a *far* better idea as it avoids using a TK50
> tape drive at all.
   
   I will need to boot from a tape at some point in any case. I have to
boot from SOMETHING. Since none of the disks in this machine is bootable, I
have to boot either from a tape or over the network. Since the only two
computers in my apartment are the VAX in question and my DOS machine,
netbooting is not an option. Well, I could attach another disk to the PC,
download FreeBSD, and install it, but this is _WAY_ too much pain. Also
there is no guarantee of success with this approach, since there are all
kinds of traps waiting to catch me. The spare disk I'm talking about may
turn out to be toast, FreeBSD may not like something about this PC, the
DELQA in the VAX may turn out broken, etc., etc., etc. OTOH, the labor
investment in just trying it out is enormous (this PC has a VERY special
configuration, and adding another disk may turn out to be a royal pita,
plus downloading FreeBSD or some other PeeCee UNIX clone over my 14400 BPS
modem is going to be a nightmare). On the other hand, I know that the TK50
boot path is working, since I have been able to boot from some VMSish tape
(see my previous messages), thus all I need is a good Ultrix tape.
   
   Another friendly PUPS member has promised to send me copies of his
Ultrix tapes, so hopefully I'll get something going.
   
> It's not that tape copies are bad ideas - it's just that TK50's
> are so slow.  If you were coming from 9-track or DLT or something
> fast, that wouldn't be so bad.
   
   Are 9-track tapes faster than TK50s? In addition to the TK50 I also have
the CDC Keystone and the QT13 which seems to work after all, but I
_STRONGLY_ doubt that it's going to be any easier. This big beast is very
dirty, it has been exposed to a little rain, and it has been dropped on
concrete pavement a couple times, so before I even try plugging it in, I
would have to perform a very careful cleaning and inspection procedure, and
I currently don't have anywhere near the resources and knowledge needed for
that operation.
   
> If you can get just about any OS running on your
> Q-bus machine, under any CPU - i.e. NetBSD, RT-11, 2.11BSD, RSX,
> whatever you might have - then you can just write the miniroot
> straight to a "scratch" disk.
   
   Again, regardless of what approach I take, I'll need to boot from some
device first. See above.
   
   Sincerely,
   Michael Sokolov
   Cellular phone: 216-217-2579
   ARPA Internet SMTP mail: msokolov at harrier.Uznet.NET


Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id DAA13664
	for pups-liszt; Tue, 8 Dec 1998 03:51:29 +1100 (EST)

From msokolov at harrier.Uznet.NET  Tue Dec  8 02:49:46 1998
From: msokolov at harrier.Uznet.NET (Michael Sokolov)
Date: 7 Dec 1998   16:49:46 GMT
Subject: 9-track tape interfaces
Message-ID: <199812071650.VAA15637@harrier.Uznet.NET>

   Dear Tim,
   
   Your explanation of 9-track tape interfaces is extremely helpful!
Thanks! This area has always been a huge gap in my hardware knowledge.
   
   What I still don't understand is how do all these interfaces handle the
issue of recording density (800 BPI vs. 1600 BPI vs. 6250 BPI). You are
saying that the Pertec unformatted interface is very low-level. Do you mean
that it gives the controller the raw stream from the heads without trying
to separate data and clock bits? It is my understanding (please correct me
if I'm wrong) that the difference between 1600 and 6250 BPI is the data
encoding (PE vs. GCR) and that the actual magnetic density (flux
transitions per inch) is the same. If so, does this mean that a Pertec
unformatted transport can be made 1600 or 6250 BPI at the formatter's
discretion without the transport knowing or caring about the density? I
mean, is it like the ST-506/412 MFM vs. ST-506/412 RLL thing?
   
   And how does the Pertec formatted interface address this issue? In this
case the controller has to tell the transport what density it wants with
the transport being able to accept or deny the request depending on its
capabilities, right?
   
   You write:
> Yep, Pertec formatted.  The QT13 is nice because it'll emulate
> either MU: or MS:-type devices.
   
   This brings me to the following question. Assuming that the Pertec
formatted interface does carry explicit density control information, which
software interface would be a better choice in terms of density control,
TS-11 or TMSCP? It is my understanding that the original UNIBUS TS-11 is a
formatter for Pertec unformatted transports that supports 1600 BPI only,
right? If so, the TS-11 interface doesn't give the OS any control over the
density, does it? If so, what density does the QT13 choose in this mode?
And what about TMSCP? How much control does it give to the OS in terms of
density selection?
   
> Yep, a TS05 is a rebadged Cipher F880 (with some slightly-different
> firmware).
   
   And where does it stand density-wise? According to DEC, TS05 is a 1600
BPI only transport, and as far as I can remember, the Cipher at CWRU had
"1600 BPI" printed on the back somewhere. However, it had a switch on the
front panel labeled "HI DEN" or something like that. What the hell is this?
According to DEC docs, on TS05 this switch is labeled "ENTER" and the docs
call it "reserved".
   
> It probably had 4 50-pin edge connectors [...]
   
   Yes.
   
> [...] so that multiple drives could
> be chained on the same Pertec-formatted-bus.  (There are terminators at
> each end of the bus, much like SCSI.)  There's provisions for at least
> 4 formatters per bus, with each formatter potentially running multiple
> drives.
   
   Huh! I have never thought about it this way.
   
> (again, with slightly different firmware - for instance a DEC TU80
> controller
> will only work with TU80 drives or their CDC equivalent, the Keystone.)
   
   CDC Keystone is exactly what I have here. The interface coming out of
the (incredibly huge) cabinet is Pertec formatted. Does it have a Pertec
unformatted interface lurking inside or not? Which densities does it
support?
   
> TU80's and TS(V)05's are simple
> Pertec formatted interfaces.  Other times they convert to some other
> interface (Massbus, LESI, etc.) before the cables come out to the "real
> world".
   
   Hmm, the only DEC tape transport with LESI I know of is TU81+. Are there
any others? And what about that plus? Has there ever been a TU81 without
the plus? My manuals are at my main VAX farm from which I'm currently away,
but I remember the picture of the TU81+ in there looked similar to the
Keystone I have here. Since you say above that TU80 is Keystone in
disguise, does it mean that TU80, TU81, and TU81+ are all the same beast
with different interface converters tacked on?
   
   And what is LESI anyway? I have heard somewhere that the KLESI
controller can drive more than just a TU81+, so is LESI actually more than
just a tape interface?
   
   Oh, what about that leading edge strobe vs. trailing edge strobe? Your
vmsnet.pdp11 posting with the QT13 switch settings says that Kennedy 9300
uses trailing edge strobe while all others use leading edge strobe. Mine,
however, is set for trailing edge strobe, and it was connected to the
Keystone. Does this mean that the Keystone and Kennedy 9300 are the same
beast, or is it simply that the 9300 is not the only transport using
trailing edge strobe?
   
   Sincerely,
   Michael Sokolov
   Cellular phone: 216-217-2579
   ARPA Internet SMTP mail: msokolov at harrier.Uznet.NET


Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id DAA13678
	for pups-liszt; Tue, 8 Dec 1998 03:51:55 +1100 (EST)

From msokolov at harrier.Uznet.NET  Tue Dec  8 02:51:09 1998
From: msokolov at harrier.Uznet.NET (Michael Sokolov)
Date: 7 Dec 1998   16:51:09 GMT
Subject: Sigma unidentified flying board
Message-ID: <199812071651.VAA15642@harrier.Uznet.NET>

   Dear Tim,
   
   You write:
> Any chance it's a simple parallel I/O?
>
> Could also be the bus interface for a Sigma and/or DSD MFM drive
> controller (if so, it probably emulates RL02's).  The assembly number
> sounds vaguely DSD-like.
   
   From looking at the board I see that the BDMGI and BDMGO fingers are
simply shorted and not connected to any circuitry. This means that the
board is non-DMA, right? If so, it can't emulate RL-11 or any other DEC
disk controller because they are all DMA, right? The BIAKI and BIAKO
fingers ARE connected to some circuitry, though, so at least this board
interrupts, right?
   
   And what's DSD? What MFM controller are you referring to? The "SIGMA
INFORMATION SYSTEMS, INC." label and the assembly number are etched, not
silk-screened, stamped, or stickered, so it suggests that Sigma is the
original designer.
   
   Sincerely,
   Michael Sokolov
   Cellular phone: 216-217-2579
   ARPA Internet SMTP mail: msokolov at harrier.Uznet.NET


Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id FAA14057
	for pups-liszt; Tue, 8 Dec 1998 05:32:10 +1100 (EST)

From rickgc at calweb.com  Tue Dec  8 04:41:59 1998
From: rickgc at calweb.com (Rick Copeland)
Date: Mon, 07 Dec 1998 10:41:59 -0800
Subject: Rugged 1182
Message-ID: <3.0.32.19981207104119.00926100@pop.calweb.com>

Dear PUPS list,

I recently picked up a rack mounted computer that is called a "Rugged
11/82".  One individual I know has suggested that it is a pdp 11/82 is a
ruggedized box.  Has anyone on this list seen one of these.  Is there any
software in the PUPS archive that might run on one of these?

Sincerely,

Rick Copeland

Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id FAA14248
	for pups-liszt; Tue, 8 Dec 1998 05:53:26 +1100 (EST)

From SHOPPA at trailing-edge.com  Tue Dec  8 04:53:01 1998
From: SHOPPA at trailing-edge.com (Tim Shoppa)
Date: Mon, 7 Dec 1998 13:53:01 -0500
Subject: Rugged 1182
Message-ID: <981207135301.2f0000e2@trailing-edge.com>

>I recently picked up a rack mounted computer that is called a "Rugged
>11/82".  One individual I know has suggested that it is a pdp 11/82 is a
>ruggedized box.  Has anyone on this list seen one of these.

I have seen ruggedized 11/83's, as well as "Industrial 11/83"'s, but
it's not clear yet exactly what you have.  The obvious solution
is to look inside and see what Q-bus and/or Unibus boards are present.

>  Is there any
>software in the PUPS archive that might run on one of these?

Some ruggedized PDP-11 systems didn't have a real Q-bus or Unibus backplane
at all, making it very difficult (if not impossible) to use them
with a standard disk controller.  That's why it's vital that you figure
out what exactly is in your machine.

Assuming that the guts are indeed a Q-bus or Unibus KDJ-based CPU,
you'll be able to run 2.11BSD once you get a compatible disk, load,
and console system up and going on it.

-- 
 Tim Shoppa                        Email: shoppa at trailing-edge.com
 Trailing Edge Technology          WWW:   http://www.trailing-edge.com/
 7328 Bradley Blvd		   Voice: 301-767-5917
 Bethesda, MD, USA 20817           Fax:   301-767-5927

Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id GAA14657
	for pups-liszt; Tue, 8 Dec 1998 06:42:52 +1100 (EST)

From SHOPPA at trailing-edge.com  Tue Dec  8 05:42:28 1998
From: SHOPPA at trailing-edge.com (Tim Shoppa)
Date: Mon, 7 Dec 1998 14:42:28 -0500
Subject: 9-track tape interfaces
Message-ID: <981207144228.2f0000e2@trailing-edge.com>

>   Are 9-track tapes faster than TK50s? 

In every reasonable case that I know of, yes.

>In addition to the TK50 I also have
>the CDC Keystone and the QT13 which seems to work after all, but I
>_STRONGLY_ doubt that it's going to be any easier. This big beast is very
>dirty, it has been exposed to a little rain, and it has been dropped on
>concrete pavement a couple times, so before I even try plugging it in, I
>would have to perform a very careful cleaning and inspection procedure, and
>I currently don't have anywhere near the resources and knowledge needed for
>that operation.

You're lucky - there's an incredible scarcity of moving parts on
a TU80/CDC Keystone: two reel motors and a blower are all you've
got.  There's also two metallic "hub" sensors used to sense tape
motion/tension.  Clean these and the heads, load a scratch tape with
write ring, power it up, close the door, make sure the logic is on,
and hit "TEST" followed by "EXECUTE".  It'll go into a self-test mode,
including some maximum-Maytag gymnastics, which will run for 15
minutes or so on a 2400-foot tape.
   
[Unknown Sigma board]
>   From looking at the board I see that the BDMGI and BDMGO fingers are
>simply shorted and not connected to any circuitry. This means that the
>board is non-DMA, right? If so, it can't emulate RL-11 or any other DEC
>disk controller because they are all DMA, right? The BIAKI and BIAKO
>fingers ARE connected to some circuitry, though, so at least this board
>interrupts, right?

Hmm - you said it has a 40-pin connector.  Given that it doesn't
do DMA, I'm guessing that it's either a DLV11-type clone (a single
serial line) or a parallel interface (either a DRV11-C type or a
line-printer driver, possibly either Data Products or Centronics
interface.)
   
>   And what's DSD?

Data Systems Design - they made some disk controller subsystems.

> The "SIGMA
>INFORMATION SYSTEMS, INC." label and the assembly number are etched, not
>silk-screened, stamped, or stickered, so it suggests that Sigma is the
>original designer.

Any obvious buffers (or banks of buffers) near the external connector?  What
are the date codes on the chips?
   
>   What I still don't understand is how do all these interfaces handle the
>issue of recording density (800 BPI vs. 1600 BPI vs. 6250 BPI). You are
>saying that the Pertec unformatted interface is very low-level. Do you mean
>that it gives the controller the raw stream from the heads without trying
>to separate data and clock bits?

At least at 800 and 1600 BPI, the Pertec Unformatted interface does
do the data recovery.  There's a line from the formatter that puts
the drive into either PE (1600 BPI) or NRZI (800 BPI) mode, and some
optional lines that set the thresholds of the analog comparators used
for data recovery.

I'm not too sure about Pertec Unformatted drives at 6250 BPI.

> It is my understanding (please correct me
>if I'm wrong) that the difference between 1600 and 6250 BPI is the data
>encoding (PE vs. GCR) and that the actual magnetic density (flux
>transitions per inch) is the same.

6250 BPI is definitely higher flux density on the tape (in addition to
the different encoding.)

>   And how does the Pertec formatted interface address this issue? In this
>case the controller has to tell the transport what density it wants with
>the transport being able to accept or deny the request depending on its
>capabilities, right?

There are a couple "spare" lines on the Pertec formatted interface
so that the host can tell the formatter such "optional" information.
The interpretation of these spare lines was never perfectly standardized:
sometimes they're used to select 800 vs 1600 or 1600 vs 6250 BPI
operation, other times they're used to put the drive into streaming
vs non-streaming mode, other times it's used to change the speed on
a streaming drive.  The IDEN line was the most commonly used line
on the Pertec formatted interface to choose these options, but some
CDC drives implemented a scheme where density/speed negotiation were
done in a much more complex way.
   
>   This brings me to the following question. Assuming that the Pertec
>formatted interface does carry explicit density control information, which
>software interface would be a better choice in terms of density control,
>TS-11 or TMSCP?

It depends on what your OS's driver is capable of.  In most cases
TMSCP gives you more control.

> It is my understanding that the original UNIBUS TS-11 is a
>formatter for Pertec unformatted transports that supports 1600 BPI only,
>right?

Right.

> If so, the TS-11 interface doesn't give the OS any control over the
>density, does it?

The "official DEC" TS-11 interface didn't.  The DEC TSV05 interface
(which was upward-compatible with the TS11's)
gave the software control over the "high speed" vs "low speed" bit.
And as I pointed out, some drives could be set to interpret this
bit as a density select.  I don't think the ability to set/clear
this bit ever made it into 2.11BSD (looking at the ts driver
code there I don't see it, at least) and I have no idea if it ever
made it to the 4.xBSD's.

> If so, what density does the QT13 choose in this mode?

The QT13 will support either IDEN-style density select or CDC-style
density select, and I believe in MS: mode this choice is made through
the TSV05 speed-select bit.

>And what about TMSCP? How much control does it give to the OS in terms of
>density selection?

TMSCP is much more flexible, and supports at least two different schemes
for selecting and reporting density.  Here's what I've figured out about
possible reported-back density values in the TMSCP packets (as
excerpted from my DUSTAT.MAC):

DENTBL: TBLENT  1       ,<NRZI 800 BPI>
        TBLENT  2       ,<PE 1600 BPI>
        TBLENT  4       ,<GCR 6250 BPI>
        TBLENT  10      ,<Cartridge (TK50)>
        TBLENT  401     ,<NRZI 800 BPI>
        TBLENT  402     ,<PE 1600 BPI>
        TBLENT  404     ,<GCR 6250 BPI>
        TBLENT  420     ,<TU82 special high density>;according to RSTS/E
        TBLENT  1001    ,<Cartridge (TK50)>
        TBLENT  1002    ,<Cartridge (TK70)>
        ;       20xx entries are supposed to be RV80, whatever that is,
        ;            according to RSTS/E sources.

I'm pretty sure that 2.11BSD properly handles TU81 density select
in its TMSCP driver.  (Steve, can you confirm this?  I know you've
made some effort to get write caching to work with TU81's over the
years!)

In any event, remote density selection/reporting is largely a
frill, as any drive/controller combination that I ever used let you
explicitly select it with a physical button or a switch and displayed
the current selection in some useful way on the drive.
   
>> Yep, a TS05 is a rebadged Cipher F880 (with some slightly-different
>> firmware).
>   And where does it stand density-wise? According to DEC, TS05 is a 1600
>BPI only transport, and as far as I can remember, the Cipher at CWRU had
>"1600 BPI" printed on the back somewhere. However, it had a switch on the
>front panel labeled "HI DEN" or something like that. What the hell is this?

Some Cipher's (I think F890's) supported a special 3200 BPI mode.  It
was never in real wide use, but it was supported on some other
manufacturer's drives (some Kennedy 96xx's, for example.)

I know that some F880's had a button that said "HI DEN" but was for
all normal purposes non-functional (I think it did become useful
for selecting diagnostics.)

>   CDC Keystone is exactly what I have here. The interface coming out of
>the (incredibly huge) cabinet is Pertec formatted. Does it have a Pertec
>unformatted interface lurking inside or not? Which densities does it
>support?

1600 BPI only, it's an "embedded-formatter" drive, so there is no
internal Pertec unformatted interface.
   
>   Hmm, the only DEC tape transport with LESI I know of is TU81+. Are there
>any others?

Yep, the RC25 also used the LESI bus.  (LESI="Low End Storage Interconnect".)

> And what about that plus? Has there ever been a TU81 without
>the plus?

Hmm - the non-plus may have been the version without write-caching.
Not real sure.

>Keystone I have here. Since you say above that TU80 is Keystone in
>disguise, does it mean that TU80, TU81, and TU81+ are all the same beast
>with different interface converters tacked on?

They all look similar, and have similar mechanics, but the 81's electronics
can do 6250 BPI, something an 80's can't.
   
>   And what is LESI anyway? I have heard somewhere that the KLESI
>controller can drive more than just a TU81+, so is LESI actually more than
>just a tape interface?

It was CDC's attempt at a SCSI-like universal interface.
   
>   Oh, what about that leading edge strobe vs. trailing edge strobe? Your
>vmsnet.pdp11 posting with the QT13 switch settings says that Kennedy 9300
>uses trailing edge strobe while all others use leading edge strobe. Mine,
>however, is set for trailing edge strobe, and it was connected to the
>Keystone. Does this mean that the Keystone and Kennedy 9300 are the same
>beast, or is it simply that the 9300 is not the only transport using
>trailing edge strobe?

Hmm - some combinations of drives may not be sensitive to this.  (It's
also possibly a misprint in my QT13 manual, as I remember having to
futz with this switch's setting in some cases to get everything to work.)

No, the Keystone and the Kennedy 9300 are not the same beast.  The
Keystone is a cute little streaming tape drive, while the 9300 is
a humongous vacuum-column 125IPS machine.  (I'm sure someone will
now chime in about the days when Univac UniServo drives ruled the
earth...)

-- 
 Tim Shoppa                        Email: shoppa at trailing-edge.com
 Trailing Edge Technology          WWW:   http://www.trailing-edge.com/
 7328 Bradley Blvd		   Voice: 301-767-5917
 Bethesda, MD, USA 20817           Fax:   301-767-5927


From djenner at halcyon.com  Tue Dec  8 06:12:20 1998
From: djenner at halcyon.com (David C. Jenner)
Date: Mon, 07 Dec 1998 12:12:20 -0800
Subject: 9-track tape interfaces
References: <981207144228.2f0000e2@trailing-edge.com>
Message-ID: <366C36A4.7921683A@halcyon.com>

Tim Shoppa wrote:
> 
> A lot, so I snipped it out!
>

As long as this thread is red hot, how about these questions:

I have an M4 Data 9914 tape drive with Pertec and SCSI interfaces.
It will do 800, 1600, 6250.  I want to set up and run 2.11BSD on a
Q-Bus system.

1) I'd rather not spend a lot to get a SCSI interface.  I now have
   Emulex TC02 and Dilog DQ130 Q-Bus controllers.  Is there
   any way these controllers are going to enable 6250 BPI?

2) Is there another Q-Bus, Pertec controller that will do 6250?

3) If I had a Q-Bus SCSI controller, would it enable 6250?

4) (Already asked in thread) Supposing I get the hardware to work
   at 6250, will 2.11BSD handle it?

Thanks,
Dave

Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id HAA15025
	for pups-liszt; Tue, 8 Dec 1998 07:27:55 +1100 (EST)

From SHOPPA at trailing-edge.com  Tue Dec  8 06:27:09 1998
From: SHOPPA at trailing-edge.com (Tim Shoppa)
Date: Mon, 7 Dec 1998 15:27:09 -0500
Subject: 9-track tape interfaces
Message-ID: <981207152709.2f0000e2@trailing-edge.com>

>1) I'd rather not spend a lot to get a SCSI interface.  I now have
>   Emulex TC02 and Dilog DQ130 Q-Bus controllers.  Is there
>   any way these controllers are going to enable 6250 BPI?

Sure - I use them at 6250 BPI all the time.  The controller
doesn't have to know what density the data is at - the formatter
takes care of that.  If you absoultely insist on the computer
being able to switch the drive between 1600 and 6250 BPI modes,
you won't be able to achieve this with a TC02 or DQ130 under 2.11BSD,
but this is purely a frill as you can always select the mode from
the drive's front panel.

One thing you do have to worry about is data rate.  Pertec
formatted interfaces on "fast" buffered modern drives may want to suck
or spew data at rates that are often too fast for a lowly TC02 or
DQ130's capability to push data over the Q-bus.  Most modern Pertec-
formatted drives will let you throttle the rate to something reasonable.
And some more modern Q-bus controllers - like the Dilog DQ152 - have
internal buffers for handling such cases without having to throttle
the drive itself.

>4) (Already asked in thread) Supposing I get the hardware to work
>   at 6250, will 2.11BSD handle it?

Absolutely.  I use a Fuji 2444 and a Storagetek 2925 with a TC02
and 2.11BSD all the time in 6250 BPI mode.  I had to throttle the
data rates on both, but that's not such a big deal.

On the other hand, my Storagetek 2920, which is pretty much a 2925
without the cache option, doesn't let me throttle the data rate
at 6250 mode because there is no effective buffer.  These don't
work with my TC02 on a Q-bus machine, but they do work with a TC13
on a Unibus 11/44 or with a DQ152 on a Q-bus -11.

Also keep in mind that some third-party controllers don't interact
well with the fast polling that the most recent Q-bus CPU's can
do.  For example, my TC02 won't work at all with
a loaned Mentec M100 (roughly comparable with a 11/93) that I have.  
I've never had this problem with 11/83's and slower CPU's.

-- 
 Tim Shoppa                        Email: shoppa at trailing-edge.com
 Trailing Edge Technology          WWW:   http://www.trailing-edge.com/
 7328 Bradley Blvd		   Voice: 301-767-5917
 Bethesda, MD, USA 20817           Fax:   301-767-5927

Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id JAA15470
	for pups-liszt; Tue, 8 Dec 1998 09:40:18 +1100 (EST)

From sms at moe.2bsd.com  Tue Dec  8 08:33:57 1998
From: sms at moe.2bsd.com (Steven M. Schultz)
Date: Mon, 7 Dec 1998 14:33:57 -0800 (PST)
Subject: 9-track tape interfaces
Message-ID: <199812072233.OAA07800@moe.2bsd.com>

Tim -

	Howdy.

> I'm pretty sure that 2.11BSD properly handles TU81 density select
> in its TMSCP driver.  (Steve, can you confirm this?  I know you've
> made some effort to get write caching to work with TU81's over the years!)

	Indeed it does.  However TMSCP only defines 800,1600 and 6250 so
	on the quad density drive I have the 3200 setting must be selected
	manually on the front panel of the tape drive.

	Also the 'enable cache' works fine and makes a dramatic difference
	on a TU81+ attached to an 11/44.  The 'cache enabled' setting is
	sticky across open/close cycles so that you set it once manually
	when the first reel is loaded.  This was done to avoid having to
	modify dump/restore/tar/etc

> In any event, remote density selection/reporting is largely a
> frill, as any drive/controller combination that I ever used let you
> explicitly select it with a physical button or a switch and displayed
> the current selection in some useful way on the drive.

	Quite so.  Eons ago the one Cipher drive supported 800/1600 operation
	but the controller (TM11 clone) did not - you just made sure to
	select the density on the front panel when loading the tape

	Steve

Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id OAA16643
	for pups-liszt; Tue, 8 Dec 1998 14:49:04 +1100 (EST)

From peterc at softway.com.au  Tue Dec  8 13:48:27 1998
From: peterc at softway.com.au (Peter Chubb)
Date: Tue, 8 Dec 1998 14:48:27 +1100 (ADST)
Subject: John Lions
Message-ID: <13932.41355.645423.303757@swarm.sw.oz.au>


     Associate Professor John Lions, who  was instrumental in UNIX's
     acceptance in Australia, and in its popularity (through his two
     books) world wide, died last Saturday morning, after long
     illness.

Peter C



Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id OAA16671
	for pups-liszt; Tue, 8 Dec 1998 14:52:06 +1100 (EST)

From wkt at henry.cs.adfa.oz.au  Tue Dec  8 13:54:59 1998
From: wkt at henry.cs.adfa.oz.au (Warren Toomey)
Date: Tue, 8 Dec 1998 14:54:59 +1100 (EST)
Subject: John Lions
In-Reply-To: <13932.41355.645423.303757@swarm.sw.oz.au> from Peter Chubb at "Dec 8, 98 02:48:27 pm"
Message-ID: <199812080354.OAA09118@henry.cs.adfa.oz.au>

In article by Peter Chubb:
>      Associate Professor John Lions, who  was instrumental in UNIX's
>      acceptance in Australia, and in its popularity (through his two
>      books) world wide, died last Saturday morning, after long
>      illness.

Gee, that's very bad news.

Thanks for the email, Peter.

	Warren

Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id SAA17323
	for pups-liszt; Tue, 8 Dec 1998 18:20:42 +1100 (EST)

From msokolov at harrier.Uznet.NET  Tue Dec  8 17:19:34 1998
From: msokolov at harrier.Uznet.NET (Michael Sokolov)
Date: 8 Dec 1998   07:19:34 GMT
Subject: 9-track tape interfaces
Message-ID: <199812080719.MAA16509@harrier.Uznet.NET>

   Dear Tim,
   
   You write:
> Hmm - you said it has a 40-pin connector.
   
   Yes. A straight flat ribbon cable connects it to the bulkhead, which has
a female 37-lead D-sub connector on the outside.
   
> Any obvious buffers (or banks of buffers) near the external connector?
   
   I have just spent a couple of hours tracing the etches on this board,
and here is what I have found out. One side of the 40-pin connector is all
ground (well, that's pretty obvious). On other side we have the following.
4 pins are permanently connected to pull-up resistors, and one pin is
permanently connected to a pull-down resistor. The other 15 pins are
connected through jumpers so that the user can connect or disconnect them
on an individual basis. Some of these go to different outputs of a 74S241
(dual 4-bit 3-state buffer), some go to a 7437 (unfamiliar with this IC),
and some go to a missing IC.
   
   Both halves of the 74S241 are permanently enabled. All 8 outputs of this
half are connected to different pins on the connector. 7 of them are
connected in the obvious way, but one is also connected to a pull-up
resistor (purpose non-understood, since the 3-state buffer is always
enabled). The jumpers for all 8 are ON. Then there are 3 pins that go to
the 7437. Although 3 pins of the connector are used for this, 4 pins of the
7437 are used. Two of the connector pins go through simple jumpers, and
both are OFF. The third pin is connected to two different 7437 pins through
different jumpers. One of them is ON and the other is OFF. Finally, there
are 4 pins that connect to a missing IC. The jumpers for all 4 are OFF.
   
   Now, does this tell you anything? :-)
   
> What are the date codes on the chips?
   
   The most recent dates are mid-1988.
   
> [Explanation of the mess with host-side density control]
   
   OK, from now on I'll only use the front panel switch for density
selection. :-)
   
> other times they're used to put the drive into streaming
> vs non-streaming mode, other times it's used to change the speed on
> a streaming drive.
   
   Hmm, this is another big gap in my knowledge. What does streaming vs.
non-streaming mean?
   
> The QT13 will support either IDEN-style density select or CDC-style
> density select [...]
   
   How does it determine which one to use? Is there a switch on the board?
   
> Yep, the RC25 also used the LESI bus.  (LESI="Low End Storage
> Interconnect".)
   
   Hmm, so then KLESI can do disk MSCP as well as TMSCP, right? Can it do
both simultaneously or only one at a time?
   
> They all look similar, and have similar mechanics, but the 81's
> electronics can do 6250 BPI, something an 80's can't.
   
   But they are all different CDC Keystones, right? This means that my
Keystone may or may not support 6250 BPI, right? How can I tell?
   
> No, the Keystone and the Kennedy 9300 are not the same beast.  The
> Keystone is a cute little streaming tape drive, while the 9300 is
> a humongous [...]
   
   "Cute little"?!?! I mean, I'm still amazed how I was able to get it
inside my apartment without knocking a couple walls down first! It's
certainly huge compared to the REALLY cute little Cipher we had at CWRU. (I
really miss that Cipher, BTW. Not only is it much smaller, according to
what I have been able to glean from the docs, it's much easier to load
tapes into than the Keystone. But then of course if this Keystone does 6250
BPI I will be much more than happy with it.)
   
   But hey, if the Keystone is a cute little baby, poor CSRG fellows! I
think Kennedy 9300 was their primary machine, and I can just imagine what
it is like if the Keystone is "cute little". Does the 9300 do 6250 BPI?
   
> [...] vacuum-column 125IPS machine.
   
   Yet another gap in my knowledge. I remember seeing the term "vacuum
columns" in the BSD documentation and having no idea what are they. Could
you enlighten me?
   
> (I'm sure someone will
> now chime in about the days when Univac UniServo drives ruled the
> earth...)
   
   Just out of curiosity, what are they?
   
   Sincerely,
   Michael Sokolov
   Cellular phone: 216-217-2579
   ARPA Internet SMTP mail: msokolov at harrier.Uznet.NET


Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id TAA17591
	for pups-liszt; Tue, 8 Dec 1998 19:52:37 +1100 (EST)

From dave at fgh.geac.com.au  Tue Dec  8 18:49:40 1998
From: dave at fgh.geac.com.au (Dave Horsfall)
Date: Tue, 8 Dec 1998 19:49:40 +1100 (EST)
Subject: 9-track tape interfaces
In-Reply-To: <199812080719.MAA16509@harrier.Uznet.NET>
Message-ID: <Pine.GSO.4.03.9812081928170.14240-100000@fgh>

On 8 Dec 1998, Michael Sokolov wrote:

> on an individual basis. Some of these go to different outputs of a 74S241
> (dual 4-bit 3-state buffer), some go to a 7437 (unfamiliar with this IC),

>From my TTL Data Book: Quadruple 2-input positive-NAND buffer (Y=AB bar).
Outputs are 3, 6, 8, 11.  Corresponding inputs are 1/2, 4/5, 9/10, 12/13.
Vcc is 14, GND is 7.

>    Hmm, this is another big gap in my knowledge. What does streaming vs.
> non-streaming mean?

Streaming means that data can be supplied to the tape (or read from) fast
enough to keep it moving, as opposed stop/start (or more likely, stop
backspace start).  Requires double-buffering somewhere.

>    Yet another gap in my knowledge. I remember seeing the term "vacuum
> columns" in the BSD documentation and having no idea what are they. Could
> you enlighten me?

ROTFL :-)  Look at an old Sci-Fi movie some time, in particular the
obligatory IBM tape drives spinning back and forth.  The vacuum columns
were buffers; columns into which bits of the tape were sucked so as to
keep the tape moving past the heads at constant velocity (not sure how
good the clock recovery was in those days) whilst the reels did their
thing.  The column has various pairs of pressure sensors, between which
the tape was kept for that particular mode; if it crept past one hole,
it upset the pressure differential, and the pumps came into play...

Remember, folks; this real-time stuff was *before* micro-chips!  I still
remember looking at the old Cipher (I have the magic codes somewhere, that
allowed it to load with the door open etc) aghast that it had no vacuum
columns, but swing-arms instead...

> > (I'm sure someone will
> > now chime in about the days when Univac UniServo drives ruled the
> > earth...)
>    
>    Just out of curiosity, what are they?

Big BIG tape drives - real Sci-Fi material :-)

-- 
Dave Horsfall VK2KFU  dave at geac.com.au  Ph: +61 2 9978-7493 Fx: +61 2 9978-7422
Geac Computers P/L (FGH Division) 2/57 Christie St, St Leonards 2065, Australia


Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id UAA17635
	for pups-liszt; Tue, 8 Dec 1998 20:06:48 +1100 (EST)

From grog at lemis.com  Tue Dec  8 19:06:34 1998
From: grog at lemis.com (Greg Lehey)
Date: Tue, 8 Dec 1998 19:36:34 +1030
Subject: 9-track tape interfaces
In-Reply-To: <Pine.GSO.4.03.9812081928170.14240-100000@fgh>; from Dave Horsfall on Tue, Dec 08, 1998 at 07:49:40PM +1100
References: <199812080719.MAA16509@harrier.Uznet.NET> <Pine.GSO.4.03.9812081928170.14240-100000@fgh>
Message-ID: <19981208193634.A29025@freebie.lemis.com>

On Tuesday,  8 December 1998 at 19:49:40 +1100, Dave Horsfall wrote:
> On 8 Dec 1998, Michael Sokolov wrote:
>>> (I'm sure someone will now chime in about the days when Univac
>>> UniServo drives ruled the earth...)
>>
>>    Just out of curiosity, what are they?
>
> Big BIG tape drives - real Sci-Fi material :-)

UniServo was UNIVAC's name for all its tape drives, at least as long
as I was involved with them.  They were all vacuum column jobs, but
some were definitely ``cheap'' ones, such as the UniServo 6 and 12,
which were intended for smaller machines.  IIRC the latest ``big''
ones were the UniServo 16 and 20, at least when I was still involved
with UNIVAC.

Greg
--
See complete headers for address, home page and phone numbers
finger grog at lemis.com for PGP public key

Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id BAA18425
	for pups-liszt; Wed, 9 Dec 1998 01:02:41 +1100 (EST)

From dave at fgh.geac.com.au  Tue Dec  8 23:59:53 1998
From: dave at fgh.geac.com.au (Dave Horsfall)
Date: Wed, 9 Dec 1998 00:59:53 +1100 (EST)
Subject: John Lions
In-Reply-To: <Pine.GSO.4.03.9812081523440.10402-100000@fgh>
Message-ID: <Pine.GSO.4.03.9812090031300.14240-100000@fgh>

On Tue, 8 Dec 1998, Dave Horsfall wrote:

> Thanks for letting us know.  Damn...

Sic transit gloria mundi.

Damn.

John, why did you have to die?  You taught me everything that I knew.

Shit.

-- 
Dave Horsfall VK2KFU  dave at geac.com.au  Ph: +61 2 9978-7493 Fx: +61 2 9978-7422
Geac Computers P/L (FGH Division) 2/57 Christie St, St Leonards 2065, Australia


Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id BAA18465
	for pups-liszt; Wed, 9 Dec 1998 01:13:54 +1100 (EST)

From msokolov at harrier.Uznet.NET  Wed Dec  9 00:13:08 1998
From: msokolov at harrier.Uznet.NET (Michael Sokolov)
Date: 8 Dec 1998   14:13:08 GMT
Subject: 9-track tape interfaces
Message-ID: <199812081413.TAA16834@harrier.Uznet.NET>

   Dave Horsfall <dave at fgh.geac.com.au> wrote:
> From my TTL Data Book: Quadruple 2-input positive-NAND buffer (Y=AB bar).
> Outputs are 3, 6, 8, 11.  Corresponding inputs are 1/2, 4/5, 9/10, 12/13.
> Vcc is 14, GND is 7.
   
   Looks trivial, except that the author of the digital design textbook I'm
using has chosen to omit it. :-) Anyway, I have looked at the board again,
and all pins that go to the connector are outputs. This means that at least
in this form, with the U10 chip omitted, there are NO inputs on that
connector, only outputs.
   
   That missing chip could very well have to do with inputs, though. Hmm,
there are 4 lines going to that missing chip, and that sounds like the
number of input lines in some flavor of Centronics. On the output side, 8
pins go to the 74S241 and 3 pins go to the 7437, again suggesting 8-bit
output and some control signals.
   
   All this sounds very much like Centronics or some similar interface.
Figuring out what the host interface is and what do those myriads of
switches and jumpers mean would be harder, though.
   
   Sincerely,
   Michael Sokolov
   Cellular phone: 216-217-2579
   ARPA Internet SMTP mail: msokolov at harrier.Uznet.NET



From dave at fgh.geac.com.au  Thu Dec 10 20:35:19 1998
From: dave at fgh.geac.com.au (Dave Horsfall)
Date: Thu, 10 Dec 1998 21:35:19 +1100 (EST)
Subject: John Lions
Message-ID: <Pine.GSO.4.03.9812102037020.7904-100000@fgh>

It's possible that my incoherent outburst may have offended a few people,
in which case I apologise.  In my defence, I would like to say that Dr.
John Lions was my lecturer at Uni of NSW, and I still remember him saying
that he and Ken Robinson (anyone know how he's doing?) saw this article in
CACM, and were going to write off for it.  Thus from little acorns do
mighty oak trees grow, or however the aphorism goes...

Requiescat In Pace.

PS: In the "2nd Book," look under the "Acknowledgements" section; I helped
him with the NROFF layout (I printed chapters on an LA36 Duckwriter (as we
called them!) to see how they were formatted).

-- 
Dave Horsfall VK2KFU  dave at geac.com.au  Ph: +61 2 9978-7493 Fx: +61 2 9978-7422
Geac Computers P/L (FGH Division) 2/57 Christie St, St Leonards 2065, Australia



From eric at fudge.uchicago.edu  Tue Dec 15 08:17:04 1998
From: eric at fudge.uchicago.edu (Eric Fischer)
Date: Mon, 14 Dec 1998 16:17:04 -0600 (CST)
Subject: nondisclosure clause in SCO license
Message-ID: <199812142217.QAA03614@fudge.uchicago.edu>

Does anyone know how serious SCO is about enforcing the nondisclosure
clause from the Ancient Unix license?  I'm referring to this one:

   8.4 (a) LICENSEE agrees that it shall hold all parts of the
   SOURCE CODE PRODUCTS subject to this Agreement in confidence for
   SCO.  LICENSEE further agrees that should it make such disclosure
   of any or all of such SOURCE CODE PRODUCTS (including methods or
   concepts utilized therein) to anyone to whom such disclosure is
   necessary to the use for which rights are granted hereunder,
   LICENSEE shall appropriately notify each such person to whom any
   such disclosure is made that such disclosure is made in
   confidence and shall be kept in confidence and have each such
   person sign a confidentiality agreement containing restrictions
   on disclosure substantially similar to those set forth herein.

So if I mention to someone that (for instance) the Sixth Edition
version of ed didn't have the "j" command but it was in PWB and the
Seventh Edition, and I know this from reading the source code, are the
SCO police going to come after me?

eric

Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id JAA15475
	for pups-liszt; Tue, 15 Dec 1998 09:23:08 +1100 (EST)

From wkt at henry.cs.adfa.oz.au  Tue Dec 15 08:23:22 1998
From: wkt at henry.cs.adfa.oz.au (Warren Toomey)
Date: Tue, 15 Dec 1998 09:23:22 +1100 (EST)
Subject: nondisclosure clause in SCO license
In-Reply-To: <199812142217.QAA03614@fudge.uchicago.edu> from Eric Fischer at "Dec 14, 98 04:17:04 pm"
Message-ID: <199812142223.JAA04880@henry.cs.adfa.oz.au>

In article by Eric Fischer:
> Does anyone know how serious SCO is about enforcing the nondisclosure
> clause from the Ancient Unix license?  I'm referring to this one:
> 
>    8.4 (a) LICENSEE agrees that it shall hold all parts of the
>    SOURCE CODE PRODUCTS subject to this Agreement in confidence for
>    SCO.  LICENSEE further agrees that should it make such disclosure
>    of any or all of such SOURCE CODE PRODUCTS (including methods or
>    concepts utilized therein) to anyone to whom such disclosure is
>    necessary to the use for which rights are granted hereunder,
>    LICENSEE shall appropriately notify each such person to whom any
>    such disclosure is made that such disclosure is made in
>    confidence and shall be kept in confidence and have each such
>    person sign a confidentiality agreement containing restrictions
>    on disclosure substantially similar to those set forth herein.
> 
> So if I mention to someone that (for instance) the Sixth Edition
> version of ed didn't have the "j" command but it was in PWB and the
> Seventh Edition, and I know this from reading the source code, are the
> SCO police going to come after me?
> 
> eric

I hope not Eric. I'll ask SCO for their impressions, and will pass them
back on to the mailing list.

	Warren

Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id JAA15495
	for pups-liszt; Tue, 15 Dec 1998 09:28:32 +1100 (EST)

From erin at coffee.corliss.net  Tue Dec 15 08:31:14 1998
From: erin at coffee.corliss.net (Erin W. Corliss)
Date: Mon, 14 Dec 1998 14:31:14 -0800 (PST)
Subject: PDP-11/73 problems
Message-ID: <Pine.LNX.3.96.981214140751.32409C-100000@coffee.corliss.net>


I recently bought a PDP-11/73.  It has one RD-52A MFM hard drive that
boots up to RSTS, eight serial ports (besides the console), and what looks
like a SCSI connector on the back (labeled TK25, so I assume this is the
tape drive connector).

I have connected it to my PC and I am able to either boot it up from the
hard drive or start up into the ROM monitor.  Unfortunately, at this point
I can't continue because the PDP won't receive anything through the
console serial port.

Does anybody know if there are any quirks about the serial port on this
machine that would cause this (if, for instance, the PDP-11 required some
sort of handshaking that my PC doesn't do).  Also, there is a block of dip
switches on the CPU card that appear to affect booting and serial port
stuff.  Does anyone know where there is a list of what these switches
control?  Furthermore....  Between the cryptically labeled switch that
chooses monitor or boot mode and the knob that changes the baud rate is a
knob with three settings labeled with an arrow, a talking head, and an
uppercase T with an arrow orbiting it.  What does this knob do?  

Finally, assuming that the UART on the CPU board is fried and the entire
CPU board needs to be replaced before it will work again, what are the
chances I could get someone who has the Unix source code to compile me a
kernel that uses one of the other serial ports as the console?

Thanks in advance for all of the help that I know you people will send me.
8^)

	-- Erin Corliss


Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id JAA15515
	for pups-liszt; Tue, 15 Dec 1998 09:30:03 +1100 (EST)

From wkt at henry.cs.adfa.oz.au  Tue Dec 15 08:30:20 1998
From: wkt at henry.cs.adfa.oz.au (Warren Toomey)
Date: Tue, 15 Dec 1998 09:30:20 +1100 (EST)
Subject: PDP-11/73 problems
In-Reply-To: <Pine.LNX.3.96.981214140751.32409C-100000@coffee.corliss.net> from "Erin W. Corliss" at "Dec 14, 98 02:31:14 pm"
Message-ID: <199812142230.JAA04928@henry.cs.adfa.oz.au>

In article by Erin W. Corliss:
> Finally, assuming that the UART on the CPU board is fried and the entire
> CPU board needs to be replaced before it will work again, what are the
> chances I could get someone who has the Unix source code to compile me a
> kernel that uses one of the other serial ports as the console?
> 	-- Erin Corliss

What version of UNIX are you running on it?

	Warren

Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id KAA15610
	for pups-liszt; Tue, 15 Dec 1998 10:00:16 +1100 (EST)

From SHOPPA at trailing-edge.com  Tue Dec 15 08:59:53 1998
From: SHOPPA at trailing-edge.com (Tim Shoppa)
Date: Mon, 14 Dec 1998 17:59:53 -0500
Subject: PDP-11/73 problems
Message-ID: <981214175953.2f000656@trailing-edge.com>

>I have connected it to my PC and I am able to either boot it up from the
>hard drive or start up into the ROM monitor.  Unfortunately, at this point
>I can't continue because the PDP won't receive anything through the
>console serial port.

Am I correct in assuming that up until RSTS/E is started, the console
serial port seems to work fine?   i.e. you can talk to ODT?

>Does anybody know if there are any quirks about the serial port on this
>machine that would cause this (if, for instance, the PDP-11 required some
>sort of handshaking that my PC doesn't do).

RSTS/E might be picky about parity bits in some cases.  (Heaven knows
that it's incredibly picky about some other things!)

On the other hand, your PC might not be seeing the RTS/CTS (I forget
which one it'll actually be looking for) and this is the reason your
keystrokes never go out.  Or it might not be seeing DSR and refusing
to send keystrokes because of this.  Have you configured your comm 
software for XON/XOFF and *not* hardware flow control?

>  Also, there is a block of dip
>switches on the CPU card that appear to affect booting and serial port
>stuff.  Does anyone know where there is a list of what these switches
>control?

>From a list that John Wilson supplied to me once:

        dip switch near handle

        1       on      disables console terminal (factory use only)
        2-4     off off off     boot auto according to the dialog mode settings
                off off on      boot dev. # 1 in dialog mode settings.
                off on  off     "    "      2 "
                off on  on      "    "      3 "
                on  off off     "    "      4 "
                on  off on      "    "      5 "
                on  on  off     "    "      6 "
                on  on  on      if sw. 1 off, power up into ODT
                                if sw. 1 on , run self-test disg. in a cont loop
        5       off     enters dialog mode on power up
        6-8     on  on  on      38400 baud rate console.
                on  on  off     19200
                on  off on      9600
                on  off off     4800
                off on  on      2400
                off on  off     1200
                off off on      600
                off off off     300

        All of these s/b turned OFF if you have the console patch panel rotary
        switch connected to the cpu.

        rotary switch positions definitions.
        switch pos.s    v               v
        baud rate       auto boot       dialog mode
        38400           0               8
        19200           1               9
        9600            2               10
        4800            3               11
        2400            4               12
        1200            5               13
        600             6               14
        300             7               15

>  Furthermore....  Between the cryptically labeled switch that
>chooses monitor or boot mode and the knob that changes the baud rate is a
>knob with three settings labeled with an arrow, a talking head, and an
>uppercase T with an arrow orbiting it.  What does this knob do?  

It selects power-on mode.  I think arrow means to boot straight from the
default device, talking head means to go to interactive console dialog,
and the T with the circle around it means infinite test loop.

>Finally, assuming that the UART on the CPU board is fried and the entire
>CPU board needs to be replaced before it will work again, what are the
>chances I could get someone who has the Unix source code to compile me a
>kernel that uses one of the other serial ports as the console?

I'm sure it can be done, but I don't know of any that are easily persuaded
to do this!  It'd be far easier to disable your CPU board's console
port and drop in a separate DLV11-type interface.

-- 
 Tim Shoppa                        Email: shoppa at trailing-edge.com
 Trailing Edge Technology          WWW:   http://www.trailing-edge.com/
 7328 Bradley Blvd		   Voice: 301-767-5917
 Bethesda, MD, USA 20817           Fax:   301-767-5927

Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id KAA15820
	for pups-liszt; Tue, 15 Dec 1998 10:44:03 +1100 (EST)

From wkt at henry.cs.adfa.oz.au  Tue Dec 15 09:44:25 1998
From: wkt at henry.cs.adfa.oz.au (Warren Toomey)
Date: Tue, 15 Dec 1998 10:44:25 +1100 (EST)
Subject: Unix History Diagram
Message-ID: <199812142344.KAA05594@henry.cs.adfa.oz.au>

All,

I was thinking of trying to update my `History of UNIX' diagram at
http://minnie.cs.adfa.oz.au/TUHS/Images/unixtimeline.gif, to bring it up
to date and make it more accurate. The current status of my update is at:
	
	http://minnie.cs.adfa.edu.au/Unix_History/

I'm missing details on many of the commercial versions of UNIX:

	+ SunOS/Solaris
	+ SysVR4.x
	+ Ultrix
	+ Xenix
	+ Unixware :-)
	+ BSDI stuff
	+ lots more

If anybody can supply release dates and relationships for systems that I
don't have yet, could you email them to me with a reference where possible.

This is going to be a back-burner project, I'll do a bit here and there, but
hopefully by sometime next year we'll have a large wall-sized family tree
for UNIX.

Cheers,
	Warren

Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id OAA16605
	for pups-liszt; Tue, 15 Dec 1998 14:23:51 +1100 (EST)

From msokolov at harrier.Uznet.NET  Tue Dec 15 13:23:10 1998
From: msokolov at harrier.Uznet.NET (Michael Sokolov)
Date: 15 Dec 1998   03:23:10 GMT
Subject: Unix History Diagram
Message-ID: <199812150323.IAA09225@harrier.Uznet.NET>

   Warren Toomey <wkt at henry.cs.adfa.oz.au> wrote:
> The current status of my update is at:
>
> http://minnie.cs.adfa.edu.au/Unix_History/
   
   I have looked at it. Note that the data files are not hyperlinked. I
don't think this is intentional, is it?
   
   Being the TUHS 4BSD Coordinator :-), I feel obligated to do some work on
the 4bsd data file. Quoting:
   
> 3bsd
>         Name: 3BSD
>         Date: 1980-03
>         Reference: last-mod timestamps in Distributions/ucb/3bsd.tar
>         Successor to 32V
>         Code taken from 2bsd
> #                       virtual memory, page replacement,
> #                       demand paging
>
> 4bsd
>         Name: 4BSD
>         Date: 1980-10
>         Reference: Quarter Century of UNIX by Peter Salus, pg 164
>         Successor to 3bsd
   
   Are you sure that virtual memory appears first in 3BSD? I have always
thought that it's a 4BSD milestone. Page replacement and demand paging
probably go with it.
   
> 4.2bsd
>         Name: 4.2BSD
>         Date: 1983-09
>         Reference: Quarter Century of UNIX by Peter Salus, pg 164
>         Successor to 4.1cbsd
   
   I would add the following comment:
   
> #                       Landmark filesystem change.
> #                       VAX hardware support extended to 11/730.
> #                       Now runs on 11/780, 11/750, 11/730.
   
   Further:
> 4.3bsd
>         Name: 4.3BSD
>         Date: 1986-06
>         Reference: Quarter Century of UNIX by Peter Salus, pg 165
>         Successor to 4.2bsd
   
   I would add:
   
>         Code taken from DEC Ultrix with DEC's blessing
> #                       DNS added to the standard libc
> #                               (no MX records in Sendmail, though).
> #                       Added DEC's VAX 8600 and TMSCP support code
> #                               with DEC's blessing.
> #                       Added kernel-only support for MicroVAX II
> #                               (KA630). Without DEC's help!
> #                               It's unusable, though.
   
   Sorry, I don't know the Ultrix version (don't even know if it's a
release and not some DEC internal code), but it's obviously among the very
first.
   
   Further:
> 4.3tahoe
>         Name: 4.3BSD Tahoe
>         Date: 1988-06
>         Reference: Quarter Century of UNIX by Peter Salus, pg 165
>         Successor to 4.3bsd
   
   I would add:
   
>         Code taken from CCI's 4.2BSD-based vendor release
> #                       tahoe architecture support added.
> #                       VAX hardware support enhancements:
> #                           MicroVAX II (KA630) support made actually
> #                               usable and extended to support QVSS and
> #                               QDSS graphics.
> #                           VAX 8200 support added by Chris Torek.
> #                           New drivers for disk MSCP (U/Q and BI).
> #                       No distribution tapes for VAX ever shipped,
> #                               though.
> #                       MX record support in Sendmail!
   
   Further:
> 4.3reno
>         Name: 4.3BSD Reno
>         Date: 1990-06
>         Reference: Quarter Century of UNIX by Peter Salus, pg 165
>         Successor to 4.3tahoe
   
   I would add:
   
>         Influenced by Sun and DEC vendor systems (NFS and /var)
> #                       experimental hp300 architecture support added.
> #                       MicroVAX support extended to KA650 (MicroVAX III)
> #                               everywhere except the tmscp bootblock.
   
   Back to Warren:
> I'm missing details on many of the commercial versions of UNIX:
>
> + SunOS/Solaris
> [...]
> + Ultrix
   
   I know that SunOS and Ultrix played key roles in the history of BSD
(huge bidirectional exchange of code and ideas between CSRG, Sun, and DEC),
but I don't know anything about versions and such.
   
> + BSDI stuff
   
   Just like 386BSD, FreeBSD, and NetBSD, it's based on Net/2, 4.4BSD-Lite,
and 4.4BSD-Lite2. That's all I know.
   
   Sincerely,
   Michael Sokolov
   Cellular phone: 216-217-2579
   ARPA Internet SMTP mail: msokolov at harrier.Uznet.NET


Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id RAA17068
	for pups-liszt; Tue, 15 Dec 1998 17:11:10 +1100 (EST)

From mckusick at mckusick.com  Tue Dec 15 15:10:48 1998
From: mckusick at mckusick.com (Kirk McKusick)
Date: Mon, 14 Dec 1998 21:10:48 -0800
Subject: Unix History Diagram 
In-Reply-To: Your message of "15 Dec 1998 03:23:10 GMT."
             <199812150323.IAA09225@harrier.Uznet.NET> 
Message-ID: <199812150510.VAA06982@flamingo.McKusick.COM>

	From: Michael Sokolov <msokolov at harrier.Uznet.NET>
	Date: 15 Dec 1998   03:23:10 GMT
	To: pups at minnie.cs.adfa.edu.au
	Subject: Re: Unix History Diagram
	Sender: owner-pups at minnie.cs.adfa.edu.au

	...

	   Are you sure that virtual memory appears first in 3BSD? I have always
	thought that it's a 4BSD milestone. Page replacement and demand paging
	probably go with it.

The first virtual memory release was 3BSD. It's performance was
significantly improved in 4BSD.

	Kirk

Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id SAA17294
	for pups-liszt; Tue, 15 Dec 1998 18:36:33 +1100 (EST)

From grog at lemis.com  Tue Dec 15 17:36:15 1998
From: grog at lemis.com (Greg Lehey)
Date: Tue, 15 Dec 1998 18:06:15 +1030
Subject: Unix History Diagram
In-Reply-To: <199812142344.KAA05594@henry.cs.adfa.oz.au>; from Warren Toomey on Tue, Dec 15, 1998 at 10:44:25AM +1100
References: <199812142344.KAA05594@henry.cs.adfa.oz.au>
Message-ID: <19981215180615.H15815@freebie.lemis.com>

On Tuesday, 15 December 1998 at 10:44:25 +1100, Warren Toomey wrote:
> All,
>
> I was thinking of trying to update my `History of UNIX' diagram at
> http://minnie.cs.adfa.oz.au/TUHS/Images/unixtimeline.gif, to bring it up
> to date and make it more accurate. The current status of my update is at:
>
> 	http://minnie.cs.adfa.edu.au/Unix_History/
>
> I'm missing details on many of the commercial versions of UNIX:
>
>> SunOS/Solaris
>> SysVR4.x
>> Ultrix
>> Xenix
>> Unixware :-)
>> BSDI stuff
>> lots more
>
> If anybody can supply release dates and relationships for systems that I
> don't have yet, could you email them to me with a reference where possible.

OK, I've dragged out some old tapes which may be of some interest:

Tandem NonStop UX for Tandem LXN (68020), effectively System V.2, 10
April 1987.

Tandem NonStop-UX B00 for Tandem LXN (68020), effectively System
V.3.0, dated 22 August 1989.

Tandem NonStop-UX B10 for Tandem LXN (68020), effectively System
V.3.1, dated 20 September 1989.

Consensys UNIX System V.4.2.1.0, in PaCkAgE DaTaStReAm mode (yup,
that's what it says).  I'm not sure how reliable this is, but the
first package has the PSTAMP destiny921114141358, which presumably can
be interpreted as a date; certainly it's plausible.

BSD BSD/386, version 0.3.2.  The tar archive has the date Feb 28 09:18
1992 on the first few files; presumably this is US MST.

Univel Unixware 1.0, also this funny PaCkAgE DaTaStReAm.  This one has
a PSTAMP=SVR4.2 11/02/92.  I'd assume that they really meant 2
November 1992.

I've got a number of old CDs which I haven't looked at yet.  I'd guess
that I have most FreeBSD releases, and we can find the rest.

Greg
--
See complete headers for address, home page and phone numbers
finger grog at lemis.com for PGP public key

Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id AAA18317
	for pups-liszt; Wed, 16 Dec 1998 00:22:36 +1100 (EST)

From kahn at tholian.net  Tue Dec 15 23:20:37 1998
From: kahn at tholian.net (Joey KAHN)
Date: Tue, 15 Dec 1998 08:20:37 -0500
Subject: Unix History Diagram
References: <199812142344.KAA05594@henry.cs.adfa.oz.au> <19981215180615.H15815@freebie.lemis.com>
Message-ID: <36766225.6955995B@tholian.net>


Found this on a sun web page:




SunOS       Solaris     FCS     Comments                       
OpenWindows
----------- -------     ------- ---------------------------    
-----------
3.2
3.3
3.4
3.5
4.0
4.0.2                   Sept 89 (386i Roadrunner)
4.0.3                   May  89 (Sun2, Sun3/3x, Sun4)
4.0.3c                  June 89 (SPARC Sun4c only)
4.0.3 PSR_A             July 89 (SPARC 470/490 only)
4.1                     Mar  90 (3/3x/4/4c except 470/490)
4.1 PSR_A               May  90 (SPARC only for 390/490) 
4.1.1       1.0         Nov  90 (All Sun3/4's)                 
OW2.0/3.0
4.1.1B                  Feb  91 (SPARC only)                   
OW2.0/3.0
4.1.1.1                 July 91 (CTE patches for Sun3/3x)
4.1.1_U1                Nov  91 (Last Sun3/3x release)
4.1.2       1.0.1       Dec  91 (SPARC + Sun4m/600MP Ross)     
OW2.0/3.0
4.1.3       1.1A        Aug  92 (All SPARC+MP,Viking S10)       OW3.0
4.1.3c      1.1C        Nov  93 (LX and Classic only)           OW3.0
4.1.3_U1    1.1.1       Dec  93 (SPARC,LX,Classic/no-sun4d)     OW3.0
4.1.3_U1b   1.1.1B      Feb  94 (SPARC3.5/S10,4mm & all 1.1s)   OW3.0
4.1.4       1.1.2       Sep  94 (SPARC4m [Colorado CPUs]+new
WS)                

5.0         2.0         July 92 (Desktop Sun4c only)            OW3.0
5.1         2.1         Dec  92 (All SPARC/no-1000/2000)        OW3.1
5.2         2.2         May  93 (All SPARC + 1000/2000)         OW3.2
5.3         2.3         Nov  93 (All SPARC + SS10SX)            OW3.3
5.3         2.3 5/94    Mar  94 (SS5-audio & Voyager)           OW3.3
5.3         2.3 8/94    Sep  94 (All SPARC+SSA+S24 fb)
5.4         2.4         Dec  94 (All SPARC + Intel)             OW3.4 
5.4         2.4 3/95    Mar  95 (All SPARC+SSA)                 OW3.4
5.5         2.5         Nov  95 (All SPARC+Fusion-[NO SUN4/SUN4E]+SSA)
OW3.5



All I recall about pre 4.0 was that we were using SunOS 3.5 in '88. I'd
like to think 3.2 came out in '85 or '86--but memory isn't what it used
to be...

More research: first patch in Sun patch library:

	Patch-ID# 100001-01
	Keywords:       cc stack overflow local variable
	Synopsis: C compiler: stack overflow: too many local variables
	Date: 20-Apr-88

	SunOS release:
        	3.4, 3.5


Sun's bug database still contains bug reports going back to 3.2 (heck,
even 2.2 and 1.0) but none of them have dates ;(((

Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id CAA18903
	for pups-liszt; Wed, 16 Dec 1998 02:10:43 +1100 (EST)

From rdkeys at seedlab1.cropsci.ncsu.edu  Wed Dec 16 01:04:11 1998
From: rdkeys at seedlab1.cropsci.ncsu.edu (User Rdkeys Robert D. Keys)
Date: Tue, 15 Dec 1998 10:04:11 -0500 (EST)
Subject: Unix History Diagram
In-Reply-To: <199812142344.KAA05594@henry.cs.adfa.oz.au> from Warren Toomey at "Dec 15, 98 10:44:25 am"
Message-ID: <199812151504.KAA26443@seedlab1.cropsci.ncsu.edu>

> All,
> 
> I was thinking of trying to update my `History of UNIX' diagram at
> http://minnie.cs.adfa.oz.au/TUHS/Images/unixtimeline.gif, to bring it up
> to date and make it more accurate. The current status of my update is at:
> 	
> 	http://minnie.cs.adfa.edu.au/Unix_History/
> 
> I'm missing details on many of the commercial versions of UNIX:
> 
> 	+ SunOS/Solaris
> 	+ SysVR4.x
> 	+ Ultrix
> 	+ Xenix
> 	+ Unixware :-)
> 	+ BSDI stuff
> 	+ lots more

A couple of lesser known BSDish oddities from Big Blue....

Add IBM's AOS.  That was a straight 4.3BSD port dating from 1987 or 1988.
This was the only official port for the RT-PC hardware.

Add IBM's unofficial ``Reno'' port.  That was a somewhere between 4.3/4.4
port dating from 1991 or 1992.   It was apparently done by IBM or IBM
contractors.  It looks very straight 4.4, in appearance.

Add IBM's unoffical ``4.4Lite'' port.  That was a somewhere between 4.4
and the real Lite dating from 1994 or 1995.  It was apparently done by
IBM or IBM contractors, with source trees from two development streams
combined together to resolve developmental divergences.

They all were used on the RT-PC hardware (ROMP Risc processor).

The 4.3 is very nice.  Code size about 75 megs binary.  It runs fine
on a small machine with 8 megs ram and 115 megs HD, or the biggest
RT class machine.  The C compilers are slightly broken, but usually
can be worked around (good old pcc seems the best).

The Reno is fair to good, but missing things like working tape I/O.
You can tar or dump, but no other tape functions work correctly.
Code size about 150 megs binary.  It needs 16M ram and 300mb HD.
I dunno exactly how ``Reno'' it really is.

The 4.4Lite is fair to good, but still missing working tape I/O.
Code size about 300 megs binary.  It needs 16M ram and 300mb HD.
Bloat seems to have set in on this one, since the whole system is
well over 1 gig in size.  It barely will run on two 300mb HD.
The login says it is 4.4Lite and not straight 4.4.  There is no
indication of how pure ``Lite'' it really is.

I dunno anything about how these originated developmentally, but
the AOS seems to be vanilla 4.3BSD and all else may have developed
from that, possibly after the RT line became back-burner stuff.
I would be very interested in any history from anyone on the list
that was around IBM at the time on these.

.......

Add Xenix for the Radio Shack 16B machines on 8 inch floppers.
That seems to date from around 1982 or 1983, although I have
misplaced my disks on that one, and don't have the machine anymore.
I was thinking someone on the list had one of those beasts running?

That is all I can think of offhand to add.....

Bob Keys

p.s.  Anyone got a spare V7ish Xenix they would part with for x86
      hardware?  I would like to try a native suite rather than
      an emulator, if possible.  There were one or two such ports
      I am thinking like Xenix, Microport, or PC-IX maybe?  I just
      missed one a few days ago at out state surplus house, when I
      picked it up, looked at it, set it down, and then someone
      else grabbed it... oh, well....(:+{{.....


Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id FAA19970
	for pups-liszt; Wed, 16 Dec 1998 05:43:04 +1100 (EST)

From rdkeys at seedlab1.cropsci.ncsu.edu  Wed Dec 16 04:36:37 1998
From: rdkeys at seedlab1.cropsci.ncsu.edu (User Rdkeys Robert D. Keys)
Date: Tue, 15 Dec 1998 13:36:37 -0500 (EST)
Subject: Unix History Diagram --- AOS quirks
In-Reply-To: <19981215122947.B11834@rek.tjls.com> from Thor Lancelot Simon at "Dec 15, 98 12:29:47 pm"
Message-ID: <199812151836.NAA26799@seedlab1.cropsci.ncsu.edu>

> > A couple of lesser known BSDish oddities from Big Blue....
> > 
> > Add IBM's AOS.  That was a straight 4.3BSD port dating from 1987 or 1988.
> > This was the only official port for the RT-PC hardware.
> 
> I have a paper about this port which claims that it's in fact tahoe or so,
> and has an independent implementation of mmap().  I'll try to dig it up --
> 
> I think it was in one of the old Waite Group books.

Please do!  I would like to see that.  I did see at one time Tahoe
mentioned, but I did not understand how the IBM ports were related
through that.  There are so few folks around that know anything about
these IBM critters, even on the old RT newsfeed.  Most of the stuff
has become dumpster fodder, sadly, although I had the good fortune
this past week to resurrect two RT's from the dumpster, and get one
up by combining sufficient parts to get it to boot.

What specifically would one look for to exactly differentiate
a vanilla 4.3, from a Tahoe, from a Reno, from a 4.4, from a 4.4Lite,
on non-standard hardware?  The books get somewhat obscure on this
unless running VAXen or HP300's or such.  The RT is a little bit
non-standard.  I was thinking it was a 68000ish machine in IBM's
wrappers, but others have said it was distinctly different from a
68000 based line.  Also, I can't find anyone that was in on the
AOS project enough to know from whence it was originally derived.
The dating seems to be 1987 or 1988.  Was Tahoe around then?
Salus suggests straight 4.3 was June of 1986, and Tahoe was June
of 1988 (Salus, p. 165).  Anyone around CSRG then that remembers
when IBM got what code?  Salus does not mention any IBM AOS stuff,
only the mainframe stuff.  AOS seems to be mostly a sleeper, almost
forgotten in time.

.....

> > Add IBM's unoffical ``4.4Lite'' port.  That was a somewhere between 4.4
> > and the real Lite dating from 1994 or 1995.  It was apparently done by
> > IBM or IBM contractors, with source trees from two development streams
> > combined together to resolve developmental divergences.
> 
> Someone here had a tape of this, yes?

There is a Finnish repository that has some of it relating to the 4.3
port, and one or two other RTish archives.  Try something like jumo.luti.fi,
or jumi.luto.fi, or something like that, but I don't have the url exactly,
and can't find the stick'em note where I ran across it.

Yes, there was an IBM'er that said he had some original tapes.  I was
hoping he would check with someone at IBM to see what the status was.
There was a group at Carnegie-Mellon that had some machines with AOS,
but I don't have any pointers to anyone up there, for sure.  I would
hope the old RT boxes and AOS would fall under the Antique Unix umbrella,
and thus, be amenable to the PUPS archives scope of things.  But, I
am only a newbie voice in the crowd.....

>From what I have found out, there were two install tapes and two boot
floppies.

The main boot floppy is the sautils disk (stand alone utilities).
That then loads a miniroot floppy that does the scripted install.
The scripts don't work unless you have the original tapes, and
the orignal hardware configuration which was a pair of 70mb esdi
drives.  The installation needs to be done manually, instead, if
the hardware differs from that.  It should be a straight 4.3 style
restore process.  I guess they expected only to have dual 70mb
esdi drives in the old RT tower machines, as AOS platforms.

The first tape is the combined root and user dumps to hd0a and hd0g.
The second tape is the source tree dump to hd1g.

> The AOS releases I saw all came with source.  I wish IBM would donate the
> bits they wrote -- much information on ROMP processor bugs, etc. simply
> doesn't exist anywhere else.

That is how I understand it.  There were some manuals for it, but
noone seems to know anything about those anymore, and what info I
have is more sketchy than for sure.  There was also some other machine
called an ``Academic Machine'' that was a siamesed ROMP processor
on a Model 60 PS/2 MCA bus machine.  I have not exactly understood
how that thing actually worked, and noone on the net seems to have
one, although there are two ROMP boards that are reputed to still
exist that plug into the MCA Model 60 PS/2 box.  Apparently the
Model 60 was the terminal/disk IO system and the ROMP board ran
the BSD.

> Patches to fix this circulated widely -- I recall one _very_ late night
> in Bill Cattey's office at Athena waiting for someone in Stockholm to
> send us a patch so we could make some tapes I needed the next morning.

The thing will tar/dump to the tape, but won't retension or erase
correctly.  If you know what that patch was, I would be interested
in it, for sure.  I assume it has to do with something like twiddling
the right hardware ports with the right bit patterns, maybe, to run
the retension and erase functions on the hardware.  I am curious,
though, and wonder if something like the 4.3 mt, which does work,
would work correctly in the Lite suite.  I was of the impression
that there was some binary compatibility between 4.3 and 4.4/4.4-Lite,
but I am not sure.

.....

> > The 4.4Lite is fair to good, but still missing working tape I/O.
> > Code size about 300 megs binary.  It needs 16M ram and 300mb HD.
> > Bloat seems to have set in on this one, since the whole system is
> > well over 1 gig in size.  It barely will run on two 300mb HD.
> > The login says it is 4.4Lite and not straight 4.4.  There is no
> > indication of how pure ``Lite'' it really is.
> 
> Wow, I wonder if it really is "Lite".  Again... I wish IBM would free
> the relevant bits, we've wanted for a long time to make NetBSD run on
> these beasts.  One major obstacle is that nobody at IBM seems to even
> know where the "official" sources are, or who would have authority to
> turn them over.

I have no idea how pure or impure the code is.  I came along so late
in the song and dance act that I don't know enough of the internals
to compare, yet.  So much to learn.....  Years ago I bounced this
off our IBM rep, but went to AIX on the PS/2, instead of the RT BSD.
I did not know very much then, nor now....(:+{{.....

> > I dunno anything about how these originated developmentally, but
> > the AOS seems to be vanilla 4.3BSD and all else may have developed
> > from that, possibly after the RT line became back-burner stuff.
> > I would be very interested in any history from anyone on the list
> > that was around IBM at the time on these.
> 
> Me too.

Who all on the list were IBM'ers in that era that might still remember
enough of this to fill us in?  The history is half the fun, and sure
makes the perspective on the rest more interesting and well rounded.

Anyone on the list actually playing around and running an RT?
I am beginning to feel very lowendian that I am not on a PDP11, VAX,
HP300 or such.....{:+{{...   but, a VAXStation 3500 just appeared
in surplus.... maybe the bidding force will be with me.

Bob Keys


Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id GAA20122
	for pups-liszt; Wed, 16 Dec 1998 06:15:11 +1100 (EST)

From msokolov at harrier.Uznet.NET  Wed Dec 16 05:14:23 1998
From: msokolov at harrier.Uznet.NET (Michael Sokolov)
Date: 15 Dec 1998   19:14:23 GMT
Subject: A program to read tapes in a snap
Message-ID: <199812151914.AAA10682@harrier.Uznet.NET>

Dear PUPS/TUHS members,

While exchanging tapes and tape images with a number of people on this list, I
have mentioned the existence of this program to a number of people, but so far
I haven't given it to anyone. Now I'm posting it to the list for everyone's
benefit. This program can read a tape on a UNIX box without the user having to
know anything about its format. This program automatically determines how many
files are on the tape, what is the record size for each, and whether there are
any oddities such as partial records. It saves each tape file into a separate
disk file and produces a log of everything found on the tape.

It's a simple C program and should compile and run on virtually any UNIX or
UNIX-like system. The original version was written by one guy I met on another
list once and then it was significantly enhanced by me. I include it below as
a uuencoded gzipped tarball.

Sincerely,
Michael Sokolov
Cellular phone: 216-217-2579
ARPA Internet SMTP mail: msokolov at harrier.Uznet.NET

Enclosure: uuencoded cptape.tar.gz:

begin 644 cptape.tar.gz
M'XL("`ZQ=C8``V-P=&%P92YT87(`[5AM4QLW$.:K]2L$-(,-QOC`.!D[ID,(
MM&D)S$#2-YKIB#N=?<-9<N_D&)KPW[N[.OGN'%+:SD`^Y'8FPTE:[<NS;W)>
MBRL91K%<>D#RVNUNI\.7./?:W1W\RSN[M+;D=9YRWNWN[.[NM+>];6)K[R[Q
M]D,:Y6B:&I%POC2^3CO=?^![.PS.'\.>1Z95M at H1>)UE`0]UPOV)$1/)5AD[
M??'#H#86D6II=GYVD'W[C!T<'>]_=SZH;9XR9ME[M6_JP-Y at -=_G]I-O:B>+
M?6DW*_H,G1WNOWQ]^+`Z[JE_K[-=J/^=I\C6WNU6]?\89`N4)U($*1><%I'B
M6DF>CK1I\DDL_$@-N13^R!Y3HXB4T<"?RHE(A)$\B-(K1B="!3S6PR%>,B/D
MA*8R%B;2BHM+/36 at S-=)P-/H+YFV7`,A13+]-WKLB1)C&?`U_&XIM=;DLY%,
M)%.*1RDI-C.]&43#R,#M/Z=2F4C$7$W'ES+A.B06$@1V$3OJK(/O@?2CL8 at 9
M)H9!+V:1&?&VUVCQ-R.9VEL`5B*Y#[@9L"*R(OQIDH`>,!)<-#JY:?$C:*AF
M%*4,.%.MR$I%<*-DP96<D>8F03[3TSC@"O&*XYM,/'#-!5*#CDR3^0$'8."+
M\$ZF*FNU/$ST&(U))$![,I=D#R&DJ.!2T at V1@K at XUK.T-X_"9DSF6!>?IQ/`
M0L1[C!&X^8;#&(/@P$R$=04`?!_YH,SR$EQ-+EO#5I-MP=F62L:FC6""D%D4
MQ[F?=P667*:L6(P60]?+E^:VK]FH"1Y'J4$+`88\K5)[2E;GR<B<IM;7,Z_L
M1']8'??T_]W=;KO0_]O(MMWUJO[_&+2USOBZ:P^;W->3FV*90.%,U972,^4*
M)99J:$9P:8NQU4CY\33`OF""2+=&>X6MT%<F+F_))%$+7.E-ND65#KML-8#B
MA39X\N+M48V>!J at CI#7?@U7Y7J3]3(-4010R!L."#Z71$\/KC3Z3UT8FT!A'
M$.!UV!3)<+Z)K+`5J:")?\&R?JX?U)V_^NW0FM#=>=:I;:WS?1_]IZFF^1C&
M6;W3:/*QN+9X7<;:O[)MI`8$H&(W.3\X?T7GJ6M</^W_ at LW3Z_[8RABWR'`6
M:`2_COT[!*- at A"(N#7+*;O;9T:OC0[Z>'?79!X860@*;R(<XI=%001,D?R^G
M82B3B\R3=WWBG+/$&MRP`57:GI$:D*HG,)\&O+UP`X\@H'#BY?Q&HU&X(IVP
M!"[LQ!?/[M1(\]%'C`!L/$:(ZOW^W)2-C0;_P&K$?'EC9(J#$GAKE#G6K-K\
M`-;X9PZ9];GIP@<94(/DJ>?\SWF;Y*/J"8C427UE_OQ907X\2:290H9X?5I!
MY'%^8\R$XG0)0U:[Y3*&MT!9P6!0T(!'#M&&W8(3,LF/=2KK"%\#3FJX7;0)
M'DF3J0U'CQ,O&4<\\CHR=8^6M_!ODD`@POK*&W!C+)(K&+0P%*%L:2JN/FEO
M3W]7*TT7/[J7?6]LN$4><U)Q:_^@?[G98%!ZAQJ$SQJ7P580DD&4P0%`$D:I
MAB=#((QP[08>:`CHI^E"N,Z2R!BI,`D<J,MWH.IP.'>/MMS_9G'&]_B3N(1(
M,\,5:!Y'\@<US8O0\H29EFR[R5>._KN6.U2EF=R\@$`T=464O!`]S!H(%KV9
M2C?:W6YW;KGE&O!-[_X$0TF?3;!"?G at VS+94LWRIY34-.X6:_323%HIQ>5#H
M!R4CLU#^+!(%D>PY8%<!TW)F8U'B)@E%N,LH.U/S*"S@[A*J$.;:IS'^'W;<
MK_HVR^=B8YLG1I;SL(U?ME'D[:TDR+E0NK=<B$3#EL==@2?AI>+U^K90\S;G
M2IG:]2V>A?:$935]<OKF['#_X/O#E[AKW:)YAB_+.HQ<'WZB),/W=I#ANL_L
M1%[';3?$\-`OS!(WY.@'QH"?O#T^MJ>E$5 at ZL?=H&-QU,9^C',LBWP1GPWAH
M8T";LQ&*KM=]V+//B8(?D!!Q;Z710)`/3X\(WA1^3<#OD[I/*U]`TUN+UWH6
MO;(C[AEB at PT!NH)O>':(:6QZ[NZW[JXUC1IUD3^+AK46HY^Y\/%C]J9!X]!D
M:+$>V>2R&MYIP`L^3%,QQ-JW#[\+^-F7V?F.0((DQKR at 7K#=Z"_J*_B4#6P7
MCA![1?$<=,U6W"A>SBNM/(:+`C-G\SY4<G<AOAB2"^OTNWZ!(R"LP90B?Y.?
M_G'V\O3D^%?HEIE7-*6S&]0NT9]YN8`$>O'9_Q9QI9-CXY6QR<KH,T^Y/I3'
BEW[O5U1111555%%%%5544445551115\?_0UI&$I7`"@``)6Q
`
end


Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id GAA20201
	for pups-liszt; Wed, 16 Dec 1998 06:34:19 +1100 (EST)

From pat at transarc.com  Wed Dec 16 05:34:00 1998
From: pat at transarc.com (Pat Barron)
Date: Tue, 15 Dec 1998 14:34:00 -0500 (EST)
Subject: Unix History Diagram --- AOS quirks
In-Reply-To: <199812151836.NAA26799@seedlab1.cropsci.ncsu.edu>
Message-ID: <Pine.GSO.3.96.981215141724.4474C-100000@smithfield.transarc.com>

On Tue, 15 Dec 1998, User Rdkeys Robert D. Keys wrote:
> [...] The RT is a little bit
> non-standard.  I was thinking it was a 68000ish machine in IBM's
> wrappers, but others have said it was distinctly different from a
> 68000 based line.

No, the ROMP (the RT's CPU) is a RISC CPU.  I have a processor reference
for the C-ROMP (the CMOS version that was on the 6152 Academic
Workstation), but I only have hardcopy.

> Yes, there was an IBM'er that said he had some original tapes.  I was
> hoping he would check with someone at IBM to see what the status was.

That would probably be me.  I'm still looking - I have a call in right now
to someone who might be able to help.

> There was a group at Carnegie-Mellon that had some machines with AOS,
> but I don't have any pointers to anyone up there, for sure.

Best bet would probably be someone at the ITC or the CS department, or the
Andrew Consortium.  Don't really know many of those folks anymore, though,
and not sure if anyone from the right time period is still around.

> [...]  There was also some other machine
> called an ``Academic Machine'' that was a siamesed ROMP processor
> on a Model 60 PS/2 MCA bus machine.  I have not exactly understood
> how that thing actually worked, and noone on the net seems to have
> one, although there are two ROMP boards that are reputed to still
> exist that plug into the MCA Model 60 PS/2 box.  Apparently the
> Model 60 was the terminal/disk IO system and the ROMP board ran
> the BSD.

I have one in my living room....  Yes, your description is pretty much
correct.  The C-ROMP co-processor plugs into the Model 60 (though I don't 
know why it couldn't be used with another type of Microchannel PS/2). The
co-processor card has the C-ROMP CPU, support hardware, and memory.  To
IPL the thing, you run a DOS program on the PS/2 that loads the boot
program into the C-ROMP memory, and twiddles some bits that start the
processor.  The C-ROMP board pretty much takes over the machine, and uses
the PS/2 itself as an I/O processor.

--Pat.





From msokolov at harrier.Uznet.NET  Wed Dec 16 06:04:56 1998
From: msokolov at harrier.Uznet.NET (Michael Sokolov)
Date: 15 Dec 1998   20:04:56 GMT
Subject: Unix History Diagram --- AOS quirks
Message-ID: <199812152005.BAA10743@harrier.Uznet.NET>

   "User Rdkeys Robert D. Keys" <rdkeys at seedlab1.cropsci.ncsu.edu> wrote:
> What specifically would one look for to exactly differentiate
> a vanilla 4.3, from a Tahoe, from a Reno, from a 4.4, from a 4.4Lite,
> on non-standard hardware?
   
   Telling between pre-Reno and post-Reno is trivial. If you see
directories like /usr/ucb, /usr/doc, /usr/man, binaries in /etc and in
/usr/lib, and so on, it's pre-Reno. If you see all docs, manpages, etc.
moved into /usr/share, /usr/ucb gone, no binaries in /etc or in /usr/lib,
strange critters appearing like /sbin, /usr/sbin, /usr/libexec, and
/usr/libdata, it's post-Reno.
   
   Distinguishing between plain-4.3-based and Tahoe-based non-UCB systems
can be tough, and, frankly, pointless. Aside from hardware issues, the
noticeable differences between 4.3 and 4.3-Tahoe are the location of
source-form manpages (/usr/man/man[1-8] on 4.3, /usr/src/man/man[1-8] on
Tahoe), MX record support in Sendmail (present in Tahoe but not in 4.3),
and the Olson timezone implementation, i.e., that big pile of zoneinfo
files (again present in Tahoe but not in 4.3).
   
   The reason exercises like this are pointless is because when some brave
vendor takes BSD sources and tries to make a vendor release from them, they
usually have their own mind about what the system should look like,
different from CSRG's. Vendors often take different pieces from different
systems on a subjective basis. A vendor release can have the feature set of
one system and the look and feel of another. For example, Ultrix V4.0 has
the classical pre-Reno look and feel, but yet is POSIXized to about the
same extent as Reno. Thus the blurb above about telling between pre-Reno
and post-Reno systems refers to the look and feel of a system, not to its
feature set. The plain 4.3 vs. Tahoe distinction doesn't really hold in
vendor systems either. Ultrix V4.0 has MX record support in Sendmail, but
its man mechanism is plain 4.3 vintage. Don't remember if there were
zoneinfo files there or not.
   
   /var also has an interesting story. In the BSD line it appears in Reno,
but it originates in SunOS and Ultrix, systems with pre-Reno look and feel
on which a number of directories were moved from /usr to the newly-created
/var. Thus on 4.3 or 4.3-Tahoe you have /usr/spool/mail, on SunOS and
Ultrix you have /var/spool/mail, and on Reno and later you have /var/mail.
   
   Oh, I forgot to mention that the filesystem format changed slightly and
disk label support was added between 4.3 and 4.3-Tahoe. Again this is
certainly meaningless for vendor systems because they always tweak the
filesystem format themselves and have their own disk label implementations
that are not compatible with the one in Tahoe and later BSD releases.
   
> The dating seems to be 1987 or 1988.  Was Tahoe around then?
   
   The Tahoe tape shipped in the summer of 1988, but of course the work at
CSRG was going all the time.
   
> Salus suggests straight 4.3 was June of 1986, and Tahoe was June
> of 1988 (Salus, p. 165).
   
   Correct.
   
> but, a VAXStation 3500 just appeared
> in surplus.... maybe the bidding force will be with me.
   
   Good luck. 4.3BSD-Quasijarus1 will run like a charm on it. If the force
is really with you, you may even be able to run it with the graphical
console, but if not, it's trivial to pull the QDSS boards out and run the
machine as a standard VAX.
   
   Sincerely,
   Michael Sokolov
   Cellular phone: 216-217-2579
   ARPA Internet SMTP mail: msokolov at harrier.Uznet.NET


Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id HAA20397
	for pups-liszt; Wed, 16 Dec 1998 07:11:43 +1100 (EST)

From rdkeys at seedlab1.cropsci.ncsu.edu  Wed Dec 16 06:05:16 1998
From: rdkeys at seedlab1.cropsci.ncsu.edu (User Rdkeys Robert D. Keys)
Date: Tue, 15 Dec 1998 15:05:16 -0500 (EST)
Subject: Unix History Diagram --- AOS quirks
In-Reply-To: <Pine.GSO.3.96.981215141724.4474C-100000@smithfield.transarc.com> from Pat Barron at "Dec 15, 98 02:34:00 pm"
Message-ID: <199812152005.PAA27002@seedlab1.cropsci.ncsu.edu>

> On Tue, 15 Dec 1998, User Rdkeys Robert D. Keys wrote:
> No, the ROMP (the RT's CPU) is a RISC CPU.

OK.

> > Yes, there was an IBM'er that said he had some original tapes.  I was
> > hoping he would check with someone at IBM to see what the status was.
> 
> That would probably be me.  I'm still looking - I have a call in right now
> to someone who might be able to help.

Oh, now that might be interesting.  Maybe the old AOS BSD will roll again!

> > There was a group at Carnegie-Mellon that had some machines with AOS,
> > but I don't have any pointers to anyone up there, for sure.
> 
> Best bet would probably be someone at the ITC or the CS department, or the
> Andrew Consortium.  Don't really know many of those folks anymore, though,
> and not sure if anyone from the right time period is still around.

All I could find was one more recent fellow that had a ROMP board and
a set of BSD tapes for it, but he had not apparently gotten it running.
Also, most of the original folks seemed to be gone.  Most everyone
I have run into has wanted to run AIX on the RT hardware instead of BSD.
I am beginning to feel like the odd man out if I shun AIX on the RT.

> I have one in my living room....

Gee, that make 3 extant boards and 1 real live machine!  Neato!
Have you had yours up with a BSD?  Anyone for a BSD rolling party?
Sounds like a little interest, maybe?

I wish Blue would donate that to the PUPS archives, yup, yup, yup.
That would be a nice gesture, and ought to be worth some PR brownies
for them.  Technically, would that not fall under the Ancient Unix,
umbrella, anyway?  That would be a legalese mumbo jumbo to sort out,
though, and not my forte.

Bob


Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id IAA20667
	for pups-liszt; Wed, 16 Dec 1998 08:17:30 +1100 (EST)

From rdkeys at seedlab1.cropsci.ncsu.edu  Wed Dec 16 07:10:49 1998
From: rdkeys at seedlab1.cropsci.ncsu.edu (User Rdkeys Robert D. Keys)
Date: Tue, 15 Dec 1998 16:10:49 -0500 (EST)
Subject: Unix History Diagram --- AOS quirks
In-Reply-To: <199812152005.BAA10743@harrier.Uznet.NET> from Michael Sokolov at "Dec 15, 98 08:04:56 pm"
Message-ID: <199812152110.QAA27141@seedlab1.cropsci.ncsu.edu>

>    "User Rdkeys Robert D. Keys" <rdkeys at seedlab1.cropsci.ncsu.edu> wrote:
> > What specifically would one look for to exactly differentiate
> > a vanilla 4.3, from a Tahoe, from a Reno, from a 4.4, from a 4.4Lite,
> > on non-standard hardware?
>    
>    Telling between pre-Reno and post-Reno is trivial.

.....  Lotsa neat info for us lesser newbie types.

My main reason for asking was to try to place the AOS historically.
It is definitely pre-Reno, and the manpages are in user/man/manX
as to source pages.  I was thinking it had timezones, though.
The compiler was still pcc, and a custom Hi-Tech C thing called hc.

>    The reason exercises like this are pointless is because when some brave
> vendor takes BSD sources and tries to make a vendor release from them, they
> usually have their own mind about what the system should look like,
> different from CSRG's.

Granted, but the AOS system felt very unmodified, subjectively.  So,
I was not thinking it was almost Reno, or somewhere close to that.
Knowing anything of the detailed structure helps me to place it
developmentally.

>    Oh, I forgot to mention that the filesystem format changed slightly and
> disk label support was added between 4.3 and 4.3-Tahoe. Again this is
> certainly meaningless for vendor systems because they always tweak the
> filesystem format themselves and have their own disk label implementations
> that are not compatible with the one in Tahoe and later BSD releases.

OK, the AOS seemed to have a disklabel, but of a different format from
later releases.  fsck has a field day if an update to one of the later
after-AOS builds is installed.

What would one use to differentiate the Lite from earlier systems?
The last build was in the 4xx range, and dated 1996, IFF I am remembering
right.  It is running gcc at the 2.5.8 level.  Are there key file system
dates or revision levels that would help to indicate how late it is?

......

> > but, a VAXStation 3500 just appeared
> > in surplus.... maybe the bidding force will be with me.
>    
>    Good luck. 4.3BSD-Quasijarus1 will run like a charm on it. If the force
> is really with you, you may even be able to run it with the graphical
> console, but if not, it's trivial to pull the QDSS boards out and run the
> machine as a standard VAX.

It is so ugly, noone in their normal PCish minds locally should bid on
it.  So, maybe I will have a chance at it in a reasonable sort of way.
The machine is just the main tower box, and nothing else.  It does have
a TK70 tape, but I was unable to open it up on the pallet and see what
was inside.  There were no other bits and pieces with it.  I was thinking
I could run it with a VT100ish terminal of some sort, as a bare-bones
system in the basement.  How would the front/back cover open up, so
I could do a quick spot check and see what actually was inside?
If it has been gutted, I would probably pass, but if it was mostly
there, it might be worth looking at.

>    Sincerely,
>    Michael Sokolov

Thanks!

Bob Keys


Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id JAA20871
	for pups-liszt; Wed, 16 Dec 1998 09:16:32 +1100 (EST)

From wkt at henry.cs.adfa.oz.au  Wed Dec 16 08:17:01 1998
From: wkt at henry.cs.adfa.oz.au (Warren Toomey)
Date: Wed, 16 Dec 1998 09:17:01 +1100 (EST)
Subject: Unix History Diagram
Message-ID: <199812152217.JAA06715@henry.cs.adfa.oz.au>

All,
	Goodness, that was a lot of email :-) I spent the night playing with
the Graphviz tools, and my first drawing of the UNIX family tree is now on
the web page I mentioned yesterday

	http://minnie.cs.adfa.edu.au/Unix_History/

I've fixed the broken HTML so that Lynx will read the pages. I haven't
had a chance to convert all the version/date information that was sent in,
and I probably won't get to it before January.

Mind you, if people convert it into the file format I'm using, and mail it
to me, then it will be included immediately :-)

Anyway, thanks for all the feedback, and I'll get to it eventually.

Cheers,
	Warren


Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id JAA20983
	for pups-liszt; Wed, 16 Dec 1998 09:32:08 +1100 (EST)

From msokolov at harrier.Uznet.NET  Wed Dec 16 08:31:08 1998
From: msokolov at harrier.Uznet.NET (Michael Sokolov)
Date: 15 Dec 1998   22:31:08 GMT
Subject: Unix History Diagram --- AOS quirks
Message-ID: <199812152231.DAA10882@harrier.Uznet.NET>

   "User Rdkeys Robert D. Keys" <rdkeys at seedlab1.cropsci.ncsu.edu> wrote:
> [...] the manpages are in user/man/manX
> as to source pages.
   
   This is definitely plain 4.3 vintage, not Tahoe vintage. This does not
necessarily mean that other parts of the system are straight 4.3, though,
they could easily be Tahoe vintage. What version of Sendmail does it ship
with?
   
> I was thinking it had timezones, though.
   
   Well, every UNIX system has some kind of timezone system, the question
is what kind. On plain 4.3 it just remembers "OK, I'm 8 hours behind
Greenwich" or so. On Tahoe it has a pile of zoneinfo files trying to
describe the timezone and daylight saving time rules for every city in the
world. I think these files are in /etc/zoneinfo, or maybe
/usr/lib/zoneinfo, something like that.
   
> Granted, but the AOS system felt very unmodified, subjectively.  So,
> I was not thinking it was almost Reno, or somewhere close to that.
   
   Well, that's good.
   
> Knowing anything of the detailed structure helps me to place it
> developmentally.
   
   Then why don't you take its source and the sources for 4.3, 4.3-Tahoe,
or whatever you suspect it is, and see for yourself? In my directory on
minnie (Distributions/4bsd) you can find the full sources for 4.3 (both
plain and Rev 2), but unfortunately not for Tahoe (Rick Copeland hasn't
been able to read that part of the Tahoe tape due to media defects).
However, the CSRG Archives CD-ROMs have the full sources for everything,
including Tahoe.
   
> OK, the AOS seemed to have a disklabel, but of a different format from
> later releases.
   
   Is the command actually called disklabel, or is it called something like
format or chpt? (This is how it's called under SunOS and Ultrix,
respectively, and they are indeed incompatible.)
   
> What would one use to differentiate the Lite from earlier systems?
   
   If you are trying to tell between 4.4BSD and 4.4BSD-Lite, don't bother.
If you system boots, it can't be Lite. "Lite" means that there are no
binaries, only sources, and the sources won't build because about one half
of them is deleted. Now, it's true that there had been some changes to the
source tree between the 4.4BSD and 4.4BSD-Lite releases. If you want to see
if these changes have been incorporated into your vendor release, check the
Sendmail version number. For 4.4BSD it's 8.1. For 4.4BSD-Lite it's
8.6.something aka 8.7 Beta Rev something.
   
> It is running gcc at the 2.5.8 level.
   
   Since I generally don't do gcc, I don't know anything about its version
numbers. However, just because it's gcc the system has to belong to Class
3. This is my own classification. Class 1 is True UNIX(R). Everything I
develop under Quasijarus Project will also belong to Class 1. It includes
everything from the original PDP-11 UNIX to 4.3BSD-Tahoe. Class 2 is
4.3BSD-Reno. In some respects it's still True UNIX (the compiler is pcc and
the kernel is 90% pure), but in other respects it's fallen (the directory
hierarchy is turned upside down and the evil spirit of POSIX starts to
creep in). Class 3 is Net/2, 4.4BSD-*, and Free/Net/OpenBSD. These are 100%
fallen (the evil spirit POSIX runs the sinful world, VAX support in the
kernel permanently broken, the compiler is gcc).
   
> The machine is just the main tower box, and nothing else.  It does have
> a TK70 tape [...]
   
   What else do you need? The disks are internal, and you do have a tape
drive. In fact, not just "a" tape drive, but a TK70, one of the best.
Unfortunately it can't write TK50 tapes, but it can read them, and its
native format is 3 times denser than the TK50 one and much faster too.
   
> I was thinking
> I could run it with a VT100ish terminal of some sort [...]
   
   Sure! You say it's badged as a VAXstation, so you'll probably need to
pull two or three boards out to make it use the serial console.
   
> [...] as a bare-bones system [...]
   
   What do you mean "bare-bones"? It's a VAX! What can be more powerful? It
has a KA650 CPU, which is not bad at all (2.8 VUPs), and you can upgrade it
to a KA655 (3.8 VUPs) or KA660 (5 VUPs) with a single board swap (the
memory is the same for all). KA650/655 is already supported by 4.3BSD-Reno
and Ultrix, and will be supported by 4.3BSD-Quasijarus1 as soon as I
release it. KA660 is not supported yet, but it will only take a dozen lines
or so to add this support.
   
> How would the front/back cover open up, so
> I could do a quick spot check and see what actually was inside?
   
   There is nothing interesting in the back. The front door opens
trivially, just push the handle and swing the door open. You'll a 12-slot
backplane with a cover over each slot. The covers are supposed to have
labels on them. Reading them from right to left, you should see the CPU
(KA650-BA), memory (some variant of MS650), Ethernet (DELQA-SA), a disk
controller (probably KDA50 or KFQSA), and the TK70 controller (TQK70). If
all these pieces are there, you are all set! Of course if there is more
stuff there you are even more lucky.
   
   Sincerely,
   Michael Sokolov
   Cellular phone: 216-217-2579
   ARPA Internet SMTP mail: msokolov at harrier.Uznet.NET


Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id KAA21142
	for pups-liszt; Wed, 16 Dec 1998 10:12:56 +1100 (EST)

From rdkeys at seedlab1.cropsci.ncsu.edu  Wed Dec 16 09:06:19 1998
From: rdkeys at seedlab1.cropsci.ncsu.edu (User Rdkeys Robert D. Keys)
Date: Tue, 15 Dec 1998 18:06:19 -0500 (EST)
Subject: VAXen funzies.... (gotta start somewhere).
In-Reply-To: <199812152231.DAA10882@harrier.Uznet.NET> from Michael Sokolov at "Dec 15, 98 10:31:08 pm"
Message-ID: <199812152306.SAA27350@seedlab1.cropsci.ncsu.edu>

> > How would the front/back cover open up, so
> > I could do a quick spot check and see what actually was inside?
>    
>    There is nothing interesting in the back. The front door opens
> trivially, just push the handle and swing the door open. You'll a 12-slot
> backplane with a cover over each slot. The covers are supposed to have
> labels on them. Reading them from right to left, you should see the CPU
> (KA650-BA), memory (some variant of MS650), Ethernet (DELQA-SA), a disk
> controller (probably KDA50 or KFQSA), and the TK70 controller (TQK70). If
> all these pieces are there, you are all set! Of course if there is more
> stuff there you are even more lucky.

This one does not have a handle that I can find.  There is a sliding
door over the tape drive, and then a plastic key sticks out the front
of the panel kind of like the keylock on a pc.  If that key is the
handle, then, I will open it up tomorrow when I visit surplus again
to pick up a postscript printer, and see what is there.  If that key
is not the handle, then it was not obvious what was on that side of
the box that should be the ``handle'' to open it up.

Bob


Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id KAA21280
	for pups-liszt; Wed, 16 Dec 1998 10:54:57 +1100 (EST)

From msokolov at harrier.Uznet.NET  Wed Dec 16 09:54:10 1998
From: msokolov at harrier.Uznet.NET (Michael Sokolov)
Date: 15 Dec 1998   23:54:10 GMT
Subject: VAXen funzies.... (gotta start somewhere).
Message-ID: <199812152354.EAA10978@harrier.Uznet.NET>

   "User Rdkeys Robert D. Keys" <rdkeys at seedlab1.cropsci.ncsu.edu> wrote:
> There is a sliding
> door over the tape drive, and then a plastic key sticks out the front
> of the panel kind of like the keylock on a pc.
   
   The sliding window (yes, the DEC docs call it a window and not a door)
and the key are there to control access to the tape drive, to the disk
drive control buttons, to the HALT button, to the power switch, and to the
handle that opens the front door (the one you are looking for). The key has
3 positions: top. middle, and bottom. When the key is in the top position,
the window cannot be lowered at all, and the machine is secure. When the
key is in the middle position, the window can be lowered partially, and you
can access the tape drive, the disk drive control buttons, and the halt
button, but not the power switch or the front door handle. When the key is
in the bottom position, the window can be lowered completely and you can
access everything.
   
> If that key is the
> handle, then, I will open it up tomorrow when I visit surplus again
> to pick up a postscript printer, and see what is there.  If that key
> is not the handle, then it was not obvious what was on that side of
> the box that should be the ``handle'' to open it up.
   
   Turn the key to the bottom position. Lower the window all the way down.
Near the bottom of the opening you'll see the power switch and the handle
I'm talking about. This handle moves horizontally (left and right). I don't
have one of those boxes in front of me and I don't remember whether you
need to push it to the left or to the right, but I'm sure you can figure it
out experimentally.
   
   Sincerely,
   Michael Sokolov
   Cellular phone: 216-217-2579
   ARPA Internet SMTP mail: msokolov at harrier.Uznet.NET


Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id QAA22380
	for pups-liszt; Wed, 16 Dec 1998 16:26:03 +1100 (EST)

From jimc at zach1.tiac.net  Wed Dec 16 15:25:32 1998
From: jimc at zach1.tiac.net (James E. Carpenter)
Date: Wed, 16 Dec 1998 00:25:32 -0500 (EST)
Subject: Unix History Diagram
In-Reply-To: <36766225.6955995B@tholian.net> from "Joey KAHN" at Dec 15, 98 08:20:37 am
Message-ID: <199812160525.AAA19173@zach1.tiac.net>

> All I recall about pre 4.0 was that we were using SunOS 3.5 in '88. I'd
> like to think 3.2 came out in '85 or '86--but memory isn't what it used
> to be...

I just took a quick look at my SunOS 3.2 tapes. The copyright file says:

   Copyright (c) 1986 by Sun Microsystems, Inc.

Most of the files seem to be dated September 1986. Many others are dated 
July 1986. 

- Jim


-- 
James E. Carpenter                               E-Mail: jimc at zach1.tiac.net
6 Munroe Drive
Plainville, MA  02762-1108                     ICBM: 42 00' 15"N 71 20' 00"W
PGP: 7ADE9D99  Fingerprint: 8D AF 63 EC D3 51 14 3E  F1 59 8A 68 32 63 3F 8E

Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id CAA24140
	for pups-liszt; Thu, 17 Dec 1998 02:28:03 +1100 (EST)

From rdkeys at seedlab1.cropsci.ncsu.edu  Thu Dec 17 01:20:18 1998
From: rdkeys at seedlab1.cropsci.ncsu.edu (User Rdkeys Robert D. Keys)
Date: Wed, 16 Dec 1998 10:20:18 -0500 (EST)
Subject: Ancient SunOS 1.1 tapes --- how to restore?
In-Reply-To: <199812160525.AAA19173@zach1.tiac.net> from "James E. Carpenter" at "Dec 16, 98 00:25:32 am"
Message-ID: <199812161520.KAA28340@seedlab1.cropsci.ncsu.edu>

> > All I recall about pre 4.0 was that we were using SunOS 3.5 in '88. I'd
> > like to think 3.2 came out in '85 or '86--but memory isn't what it used
> > to be...
> 
> I just took a quick look at my SunOS 3.2 tapes. The copyright file says:
> 
>    Copyright (c) 1986 by Sun Microsystems, Inc.
> 
> Most of the files seem to be dated September 1986. Many others are dated 
> July 1986. 

Speaking of old SunOS tapes..... I have a friend that dug out a pair
of SunOS 1.1 tapes that he has had for years.  Alas, they are unreadable.
Is there any way to rewrite those tapes from anyones archival materials?
Sun has graciously allowed pre-sparc materials to be available on-line
in the German Sun3 archives.  All they have seems to be SunOS-4.1.1,
though.  I am wondering if there is any interest in some of the early
Sun tapes?  Are the 1.1 tapes basically a 4.2BSD port?  Are they in
QIC-11 or QIC-24 format?

Thanks

Bob Keys




Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id CAA24206
	for pups-liszt; Thu, 17 Dec 1998 02:35:36 +1100 (EST)

From eric at fudge.uchicago.edu  Thu Dec 17 01:33:06 1998
From: eric at fudge.uchicago.edu (Eric Fischer)
Date: Wed, 16 Dec 1998 09:33:06 -0600 (CST)
Subject: Unix History Diagram
In-Reply-To: <199812142344.KAA05594@henry.cs.adfa.oz.au>
References: <199812142344.KAA05594@henry.cs.adfa.oz.au>
Message-ID: <199812161533.JAA22901@fudge.uchicago.edu>

> I was thinking of trying to update my `History of UNIX' diagram at
> http://minnie.cs.adfa.oz.au/TUHS/Images/unixtimeline.gif, to bring it up
> to date and make it more accurate.

Here are a few dates I was able to find, in the format from your
web page:

	sysV
		Name: System V
		Date: 1983-01
		Reference: System V Release Description, title page

	sysVr2
		Name: System V Release 2
		Date: 1984-04
		Reference: System V manual for 3B2, title page

	sunos2
		Name: SunOS 2.0
		Date: 1985-05-15
		Reference: SunOS 2.0 manual, title page

	sunos3
		Name: SunOS 3.0
		Date: 1986-02-17
		Reference: SunOS 3.0 manual, title page

	pwb1.0
		Name: PWB/UNIX 1.0
		Date: 1977-07-1
		Reference: /usr/news/pibs in the archived PWB distribution
	#		prerelease test versions: 1977-06-6, 1977-06-13

eric

Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id FAA24733
	for pups-liszt; Thu, 17 Dec 1998 05:01:55 +1100 (EST)

From alyosha at vrytekai.Corp.Sun.COM  Thu Dec 17 03:59:44 1998
From: alyosha at vrytekai.Corp.Sun.COM (Billy Stivers)
Date: Wed, 16 Dec 1998 09:59:44 -0800 (PST)
Subject: Ancient SunOS 1.1 tapes --- how to restore?
Message-ID: <199812161759.JAA02912@vrytekai.Corp.Sun.COM>

Hey, Robert-  

do you know if anybody from Sun Legal ever officially gave the okay
for that, because, as I was telling Warren, I have most SunOSes from
the very first V7 variant that they shipped, through the present day,
and it'd be a fairly simple matter to spool all of the sun1, sun2, and sun3
ones that are readable (should be a lot, they've been stored in carefully
climate-controlled and proper containers) to disk, and set the archives up
with them.  There are some really neat innovations in older SunOS, and it'd
be neat to compare them, and try to track the tech-crossfeeding with the
4BSD trees, and early SunOSes.  There's a lot of actual hands-on mucking
around by Bill Joy in some of the earliest releases.

	--Bill
	
	
>From: "User Rdkeys Robert D. Keys" <rdkeys at seedlab1.cropsci.ncsu.edu>
>Subject: Re: Ancient SunOS 1.1 tapes --- how to restore?
>To: jimc at zach1.tiac.net (James E. Carpenter)
>Date: Wed, 16 Dec 1998 10:20:18 -0500 (EST)
>Cc: kahn at tholian.net, pups at minnie.cs.adfa.oz.au
>MIME-Version: 1.0
>Content-Transfer-Encoding: 7bit
>
>> > All I recall about pre 4.0 was that we were using SunOS 3.5 in '88. I'd
>> > like to think 3.2 came out in '85 or '86--but memory isn't what it used
>> > to be...
>> 
>> I just took a quick look at my SunOS 3.2 tapes. The copyright file says:
>> 
>>    Copyright (c) 1986 by Sun Microsystems, Inc.
>> 
>> Most of the files seem to be dated September 1986. Many others are dated 
>> July 1986. 
>
>Speaking of old SunOS tapes..... I have a friend that dug out a pair
>of SunOS 1.1 tapes that he has had for years.  Alas, they are unreadable.
>Is there any way to rewrite those tapes from anyones archival materials?
>Sun has graciously allowed pre-sparc materials to be available on-line
>in the German Sun3 archives.  All they have seems to be SunOS-4.1.1,
>though.  I am wondering if there is any interest in some of the early
>Sun tapes?  Are the 1.1 tapes basically a 4.2BSD port?  Are they in
>QIC-11 or QIC-24 format?
>
>Thanks
>
>Bob Keys
>
>
>

----------------------------------------------------------------------
A "No" uttered from deepest conviction is better and greater than a
"Yes" merely uttered to please, or what is worse, to avoid trouble.
                -- Mahatma Gandhi


Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id FAA24883
	for pups-liszt; Thu, 17 Dec 1998 05:36:19 +1100 (EST)

From rdkeys at seedlab1.cropsci.ncsu.edu  Thu Dec 17 04:29:27 1998
From: rdkeys at seedlab1.cropsci.ncsu.edu (User Rdkeys Robert D. Keys)
Date: Wed, 16 Dec 1998 13:29:27 -0500 (EST)
Subject: Ancient SunOS 1.1 tapes --- how to restore?
In-Reply-To: <199812161759.JAA02912@vrytekai.Corp.Sun.COM> from Billy Stivers at "Dec 16, 98 09:59:44 am"
Message-ID: <199812161829.NAA28899@seedlab1.cropsci.ncsu.edu>

> Hey, Robert-  
> 
> do you know if anybody from Sun Legal ever officially gave the okay
> for that, because, as I was telling Warren, I have most SunOSes from
> the very first V7 variant that they shipped, through the present day,
> and it'd be a fairly simple matter to spool all of the sun1, sun2, and sun3
> ones that are readable (should be a lot, they've been stored in carefully
> climate-controlled and proper containers) to disk, and set the archives up
> with them.  There are some really neat innovations in older SunOS, and it'd
> be neat to compare them, and try to track the tech-crossfeeding with the
> 4BSD trees, and early SunOSes.  There's a lot of actual hands-on mucking
> around by Bill Joy in some of the earliest releases.
> 
> 	--Bill
> 	
> >Speaking of old SunOS tapes..... I have a friend that dug out a pair
> >of SunOS 1.1 tapes that he has had for years.  Alas, they are unreadable.
> >Is there any way to rewrite those tapes from anyones archival materials?
> >Sun has graciously allowed pre-sparc materials to be available on-line
> >in the German Sun3 archives.  All they have seems to be SunOS-4.1.1,
> >though.  I am wondering if there is any interest in some of the early
> >Sun tapes?  Are the 1.1 tapes basically a 4.2BSD port?  Are they in
> >QIC-11 or QIC-24 format?

I think there is great potential in all of this.

AS I UNDERSTAND IT.....

Sun apparently gave the OK to a German archive site to put the the stuff
on-line.  That is, in fact, where I picked up my sun3 tapes to resurrect
my old box.  It only seems be be pre-sparc related 68000 based stuff.
The details were given on the web site, and were discussed on one
of the Sun newsfeeds.

Try the http://doener.unix-ag.uni-kl.de/  site, and it is explained
there.  The guy actually got Sun to OK it, as far as I know, but
I have no idea of the exact legalese involved, but memory tells
me it was Sun Germany that gave the go-ahead on it.

The site may have moved to http://sun3arc.krupp.net, since I was
thinking a move was in progress a couple of months back.
I think I got to it via a link from www.sunhelp.com or www.sunfreeware.com.

The idea occurred to me that IFF Sun has gone that far, we should check
into putting the older releases there, too, as they may still exist.
Also, perhaps, as they would fit under the Ancient Unix umbrella, I would
think, then PUPS/UHS should likewise take an interest in such potential.

I would be of the opinion that any of the pre-SysIII/SysV related stuff,
in addition to the purist ATT/Berkeley releases ought to be put back for
archival use, too, as it should be covered under the Ancient Unix umbrella.

If I am too far off on that, let me know.  I am but a very minor newbie
bit player in all of this.

Bob Keys


Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id FAA24923
	for pups-liszt; Thu, 17 Dec 1998 05:50:29 +1100 (EST)

From rdkeys at seedlab1.cropsci.ncsu.edu  Thu Dec 17 04:43:43 1998
From: rdkeys at seedlab1.cropsci.ncsu.edu (User Rdkeys Robert D. Keys)
Date: Wed, 16 Dec 1998 13:43:43 -0500 (EST)
Subject: Ancient SunOS Tapes for UHS archives?????
In-Reply-To: <199812161759.JAA02912@vrytekai.Corp.Sun.COM> from Billy Stivers at "Dec 16, 98 09:59:44 am"
Message-ID: <199812161843.NAA28957@seedlab1.cropsci.ncsu.edu>

> Hey, Robert-  
> 
> do you know if anybody from Sun Legal ever officially gave the okay
> for that, because, as I was telling Warren, I have most SunOSes from
> the very first V7 variant that they shipped, through the present day,
> and it'd be a fairly simple matter to spool all of the sun1, sun2, and sun3
> ones that are readable (should be a lot, they've been stored in carefully
> climate-controlled and proper containers) to disk, and set the archives up
> with them.  There are some really neat innovations in older SunOS, and it'd
> be neat to compare them, and try to track the tech-crossfeeding with the
> 4BSD trees, and early SunOSes.  There's a lot of actual hands-on mucking
> around by Bill Joy in some of the earliest releases.
> 
> 	--Bill

It would be fun to see some of Bill Joy's hacks....(:+}}.....

I went to the archive site  http://sun3arc.krupp.net
and it attributes the permission to archive materials to a
Mr. Knieriem of SUN Germany, Research and Education.

One of the UHS folks might try to contact said Mr. Knieriem
to see if adding some of our other early stuff would be feasible.
The sun3arc site only has binaries, though.

I would assume the PUPS/UHS archives might work out some kind
of binary and source arrangement, perhaps?

Someone other than the tailwagging newbie here, should persue
this and see where it goes?

Mebbie we has started somethin' 'ere, methinks....(:+}}.....

Bob Keys


Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id GAA25126
	for pups-liszt; Thu, 17 Dec 1998 06:45:26 +1100 (EST)

From erin at coffee.corliss.net  Thu Dec 17 05:47:37 1998
From: erin at coffee.corliss.net (Erin W. Corliss)
Date: Wed, 16 Dec 1998 11:47:37 -0800 (PST)
Subject: PDP-11/73
Message-ID: <Pine.LNX.3.96.981216113259.23904B-100000@coffee.corliss.net>


So get this...

I downloaded the machine emulators package and the binaries for Unix
version 7 from the PUPS ftp site, hoping that I could use it to create a
bootable disk image to put on my PDP-11/73 that would run getty on one of
the serial ports besides the console...  I compiled the emulators on a
Slackware Linux 2.0.30 machine, and they seemed to compile OK.  From the
emulator I followed the instructions for booting Unix 7.  I had the
following error every time I tried booting:

Trap stack push abort, PC: 004567 (MOV R3,(SP))

Anybody have a clue why this is happening?  




From wkt at henry.cs.adfa.oz.au  Thu Dec 17 10:34:15 1998
From: wkt at henry.cs.adfa.oz.au (Warren Toomey)
Date: Thu, 17 Dec 1998 11:34:15 +1100 (EST)
Subject: Ancient SunOS Tapes for UHS archives?????
In-Reply-To: <199812161843.NAA28957@seedlab1.cropsci.ncsu.edu> from "User Rdkeys Robert D. Keys" at "Dec 16, 98 01:43:43 pm"
Message-ID: <199812170034.LAA13086@henry.cs.adfa.oz.au>

In article by User Rdkeys Robert D. Keys:
> I went to the archive site  http://sun3arc.krupp.net
> and it attributes the permission to archive materials to a
> Mr. Knieriem of SUN Germany, Research and Education.
> 
> One of the UHS folks might try to contact said Mr. Knieriem
> to see if adding some of our other early stuff would be feasible.
> The sun3arc site only has binaries, though.
> I would assume the PUPS/UHS archives might work out some kind
> of binary and source arrangement, perhaps?

I've emailed the webmaster at the site which the above query. I've
also added a link from the TUHS page to this site, so we don't lose
the reference.

Cheers,

> Mebbie we has started somethin' 'ere, methinks....(:+}}.....
> Bob Keys

Also we also have people inside Sun too! Sounds hopeful.

Thanks all,
	Warren


From jp at spektr.ludvika.se  Mon Dec 21 07:08:00 1998
From: jp at spektr.ludvika.se (Jorgen Pehrson)
Date: Sun, 20 Dec 1998 22:08:00 +0100 (CET)
Subject: Moving a RL02..
Message-ID: <Pine.NEB.4.05.9812202150320.660-100000@spektr.ludvika.se>

Hi,
I was given a couple of QBus PDP11 on which I'm going to run 2.11BSD or
some other version of UNIX. One /73 and one /83. Both had RL02 drives, a
couple of RD53's and loads of serial boards and an extra expansion box
each. Now there's that little question of lugging them back to my
apartment. So, is there any particular precaution I should take when it
comes to the RL02's? Are they sensitive to vibrations or something? Do
they have to be in some sort of transport mode? 

Is there some information available online which explains how to operate
the RL02? Like how to open the drive, for starters... :) Or how the RL02
controller should be jumpered. (I guess that depends on what else is
present on the QBus though...)

Is there some other UNIX version that I can run on any of these machines?
I already have one PDP11/83 which happily runs 2.11BSD so it would be nice
to run older UNIX versions as well.

Thanks!

-- 
Jorgen Pehrson                  HP 9000/380 (NetBSD/hp300 1.3)
jp at spektr.ludvika.se            DECstation 5000/200 (NetBSD/pmax 1.3)
http://spektr.ludvika.se/museum PDP11/83 (2.11BSD) VAX2000 (NetBSD/vax)


Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id KAA12528
	for pups-liszt; Mon, 21 Dec 1998 10:18:04 +1100 (EST)

From jimc at zach1.tiac.net  Mon Dec 21 09:17:43 1998
From: jimc at zach1.tiac.net (James E. Carpenter)
Date: Sun, 20 Dec 1998 18:17:43 -0500 (EST)
Subject: Ancient SunOS 1.1 tapes --- how to restore?
In-Reply-To: <199812161520.KAA28340@seedlab1.cropsci.ncsu.edu> from "User Rdkeys Robert D. Keys" at Dec 16, 98 10:20:18 am
Message-ID: <199812202317.SAA19857@zach1.tiac.net>

> > I just took a quick look at my SunOS 3.2 tapes. The copyright file says:
> > 
> >    Copyright (c) 1986 by Sun Microsystems, Inc.
> > 
> > Most of the files seem to be dated September 1986. Many others are dated 
> > July 1986. 
> 
> Speaking of old SunOS tapes..... I have a friend that dug out a pair
> of SunOS 1.1 tapes that he has had for years.  Alas, they are unreadable.
> Is there any way to rewrite those tapes from anyones archival materials?
> Sun has graciously allowed pre-sparc materials to be available on-line
> in the German Sun3 archives.  All they have seems to be SunOS-4.1.1,
> though. 

I could donate SunOS 3.2, SunOS 4.0 (MC68010), and the 4.0.3 upgrade to the
archive, assuming they want Sun2 material. I also have the SunOS 4.0.3 
_upgrade_ for the 68020. All the tape files are tarred and gziped on a CDROM
I burned not too long ago.

> I am wondering if there is any interest in some of the early
> Sun tapes?  

Well I'd sure love to see SunOS 1.x running on my 2/120. :-)

> Are the 1.1 tapes basically a 4.2BSD port?  Are they in
> QIC-11 or QIC-24 format?

It would be 4-track QIC-11. SunOS 3.2 also came on four QIC-11 tapes. But
SunOS 4.x _probably_ only came on two QIC-24 tapes. (I say "probably" 
because my SunOS 4.x tapes are in 9-track QIC-11 format. I _assume_ this was 
done by somebody other than Sun so that it could be installed on a Sun2 with 
older ROMs.)

- Jim
 

-- 
James E. Carpenter                               E-Mail: jimc at zach1.tiac.net
6 Munroe Drive
Plainville, MA  02762-1108                     ICBM: 42 00' 15"N 71 20' 00"W
PGP: 7ADE9D99  Fingerprint: 8D AF 63 EC D3 51 14 3E  F1 59 8A 68 32 63 3F 8E

Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id GAA16037
	for pups-liszt; Tue, 22 Dec 1998 06:08:18 +1100 (EST)

From rickgc at calweb.com  Tue Dec 22 05:18:19 1998
From: rickgc at calweb.com (Rick Copeland)
Date: Mon, 21 Dec 1998 11:18:19 -0800
Subject: Problems booting 2.11 on a 11/84
Message-ID: <3.0.32.19981221111758.00905100@pop.calweb.com>

Dear PUPS List, 

I have connected a Fujisu M2444 9 track to an Emulex TC13 that is in my
11/84. The following is what happens when I try to boot a BSD 2.11 tape
that I made on my uVax3600/TU81+ (@6250 bpi):

	Enter device name and unit number then press the RETURN key: MS0

	Trying MS0	(tape starts rolling)

	Starting ROM boot  

	140276		(tape stops)
	@

The boot programs that are available are quite extensive on this 11/84, it
does tapes, disks, just about everything.  The M2444 is checked out by
doing the test (01 start, etc)and passes all the tests.  If I reverse the
cables on the M2444 the LED on the TC13 comes on and the M2444 will not do
anything.

Rick Copeland



From sms at moe.2bsd.com  Tue Dec 22 07:59:57 1998
From: sms at moe.2bsd.com (Steven M. Schultz)
Date: Mon, 21 Dec 1998 13:59:57 -0800 (PST)
Subject: Problems booting 2.11 on a 11/84
Message-ID: <199812212159.NAA07290@moe.2bsd.com>

Hi -

> From: Rick Copeland <rickgc at calweb.com>
> I have connected a Fujisu M2444 9 track to an Emulex TC13 that is in my
> 11/84. The following is what happens when I try to boot a BSD 2.11 tape
> that I made on my uVax3600/TU81+ (@6250 bpi):

	What CSR do you have the TC13 set for?

> 	Enter device name and unit number then press the RETURN key: MS0
> 	Trying MS0	(tape starts rolling)
> 
> 	Starting ROM boot  
> 
> 	140276		(tape stops)
> 	@

	The Boot ROM did it's job of reading in the 512 byte boot record and
	transferring control to location 0.

	The bootblock relocates itself to 48kb which is 0140000.

> cables on the M2444 the LED on the TC13 comes on and the M2444 will not do
> anything.

	I don't think the problem is cabling in this case.  

	If you have another system that you can view the sources with the
	file you really need to have in front of you at this time is
	/usr/src/sys/pdpstand/mtboot.s

	The section of code where the system is halting (with added octal 
	offsets) is:

0262		bne	ctlerr
0264		bit	$!1000,hter(csr)	/ any drive errs except HTER_FCE
0272		beq	bumpaddr		/ no, go bump address
	ctlerr:
0274		halt

	The label 'ctlerr' is shared but it indicates that a controller
	error was encountered out of the 'tmtscom' common logic (shared between
	the MT and MS drivers):

tmtscom:
	bit	$100200,(csr)		/ error or ready?
	beq	tmtscom			/ neither, keep looking
	bmi	ctlerr			/ error - go halt


	The thing to try is when the system halts looking at the registers
	(R0 thru R5) _and_ the tape controller registers (starting at 0172520).

	It's also possible to look at the command buffer being presented to
	the controller by looking at offset 0460 (0140460).  Not sure how useful
	that will be though.

	It might be possible to single step the processor starting at location
	0 as long as R0 and R1 are set up correctly (R0 has the unit number
	and R1 the control register address which is 172522 for MS and MT
	devices).

	Steven

Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id JAA16654
	for pups-liszt; Tue, 22 Dec 1998 09:18:17 +1100 (EST)

From mjenkins at carp.gbr.epa.gov  Tue Dec 22 08:17:50 1998
From: mjenkins at carp.gbr.epa.gov (Mike Jenkins)
Date: Mon, 21 Dec 1998 16:17:50 -0600 (CST)
Subject: Unix History Diagram
In-Reply-To: <199812142344.KAA05594@henry.cs.adfa.oz.au>
Message-ID: <199812212217.QAA15443@carp.gbr.epa.gov>

There is a diagram at The Internet Operating System Counter which is at
http://www.hzo.cubenet.de/ioscount/.  Take the "Unix networking" link.
It was published in iX, a German magazine.

Mike

Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id NAA17356
	for pups-liszt; Tue, 22 Dec 1998 13:44:57 +1100 (EST)

From grog at lemis.com  Tue Dec 22 12:44:15 1998
From: grog at lemis.com (Greg Lehey)
Date: Tue, 22 Dec 1998 13:14:15 +1030
Subject: Unix History Diagram
In-Reply-To: <199812212217.QAA15443@carp.gbr.epa.gov>; from Mike Jenkins on Mon, Dec 21, 1998 at 04:17:50PM -0600
References: <199812142344.KAA05594@henry.cs.adfa.oz.au> <199812212217.QAA15443@carp.gbr.epa.gov>
Message-ID: <19981222131415.A85005@freebie.lemis.com>

On Monday, 21 December 1998 at 16:17:50 -0600, Mike Jenkins wrote:
> There is a diagram at The Internet Operating System Counter which is at
> http://www.hzo.cubenet.de/ioscount/.  Take the "Unix networking" link.
> It was published in iX, a German magazine.

As I feared when I heard it came from iX, it's *very* inaccurate.
For example, it claims that 1BSD was derived from 32/V (should have
been 3BSD), derives 1BSD from 1BSD and 4.1BSD (should be 4BSD) from
the second 1BSD (should be 3BSD), derives ``BSDI'' from 4.3BSD, when
in fact BSD/OS is derived from 4.4BSD, doesn't mention System V(.1) or
System V.3, etc.  And all this is OS code, not networking code.

Greg
--
See complete headers for address, home page and phone numbers
finger grog at lemis.com for PGP public key

Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id GAA21472
	for pups-liszt; Wed, 23 Dec 1998 06:06:48 +1100 (EST)

From rickgc at calweb.com  Wed Dec 23 05:16:49 1998
From: rickgc at calweb.com (Rick Copeland)
Date: Tue, 22 Dec 1998 11:16:49 -0800
Subject: Emulex TU13 Dip Switch Layout?
Message-ID: <3.0.32.19981222111606.008f4450@pop.calweb.com>

Dear PUPS List, 

I have an Emulex TU13 tape drive interface.  Does anyone on the list have
the dip switch layout so that I can program them properly?

Thank You,

Merry Christmas,

Rick Copeland




From jp at spektr.ludvika.se  Thu Dec 24 08:11:01 1998
From: jp at spektr.ludvika.se (Jorgen Pehrson)
Date: Wed, 23 Dec 1998 23:11:01 +0100 (CET)
Subject: PDP11/83 qbus layout.
Message-ID: <Pine.NEB.4.05.9812232234500.23424-100000@spektr.ludvika.se>


(Sorry for the rather lenghty post)

Hi,
I'd just try to boot my newly aquired PDP11/83 and was planning to install
2.11BSD. But I've run into one (small?) problem. If I just try to boot
from DU0: it says: 

Trying DU0

Error 20 
Controller Error

And if I boot the install tape from the TK70 drive and run disklabel,
all accesses to the RD53 drive just times out. So I was going to remove
all unwanted QBus boards from the boxes. And that's what I was going to
ask...

Is there something special I have to think about, like there's some slots
that can't be used, some boards must be in a specific slot and so on?

This is the current layout (which is exactly as it was when it was taken
offline, or so I think)

11/83 (173QA-B3, I think this is a normal BA23 enclosure):
(As seen from the back) Also contains one TK70 drive.
    
 ____________________________________________
|Dataram 40903 revG     |        Empty slot  | (2mb ram)
---------------------------------------------
|                    M8637-EH                | (2mb ram)
---------------------------------------------
|                    M8190-AE                | (83 CPU)
---------------------------------------------
|     M7559             |         M7504      | (TK70, DEQNA)
---------------------------------------------
|     M8020             |        Empty slot  | (console?)
---------------------------------------------
|                    M7957                   | (DZV11)
---------------------------------------------
|                    m3104                   | (DHV11)
---------------------------------------------
|     M9404            |          Empty slot | (1st Qbus conn)
---------------------------------------------

Expansion box (173QA-B3)
(From the back) Also contains one RD53 and one dual floppy.

_____________________________________________
|M9405-YA               |        Empty slot  | (2nd qbus conn)
---------------------------------------------
|                     m3104                  | (DHV11)
---------------------------------------------
|     m9047             |        m9047       | (grant cont x2)
---------------------------------------------
|     m7555             |        Empty slot  | (RQDX3)
---------------------------------------------
|     m7512             |        Empty slot  | (RQDX1E)
---------------------------------------------

Plus one external disk box with two RD53 drive. (This system only uses one
drive though.)

Now, what I obviously want to keep is:
the two RAM boards, the CPU, the console board, tk70 controller, deqna,
rqdx3.

What I want to loose:
the rest of the serial boards, the rqdx1e board and the floppy drive.

What do I have to do to make this work? I would preferrably want to fit
all those boards in the main CPU enclosure box. Do I have to re-assign any
addresses (or vectors, or what the correct PDP-speak is). Are there any
slots in the enclosure that are a no-no for the dual-sized boards?

Thanks for any input!!


Jorgen Pehrson                  HP 9000/380 (NetBSD/hp300 1.3)
jp at spektr.ludvika.se            DECstation 5000/200 (NetBSD/pmax 1.3)
http://spektr.ludvika.se/museum PDP11/83 (2.11BSD) VAX2000 (NetBSD/vax)


Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id BAA28023
	for pups-liszt; Fri, 25 Dec 1998 01:16:27 +1100 (EST)

From robin at falstaf.demon.co.uk  Fri Dec 25 00:10:43 1998
From: robin at falstaf.demon.co.uk (Robin Birch)
Date: Thu, 24 Dec 1998 14:10:43 +0000
Subject: PDP11/83 qbus layout.
In-Reply-To: <Pine.NEB.4.05.9812232234500.23424-100000@spektr.ludvika.se>
Message-ID: <sB9s7CAjtkg2EwEL@falstaf.demon.co.uk>

In message <Pine.NEB.4.05.9812232234500.23424-100000 at spektr.ludvika.se>,
Jorgen Pehrson <jp at spektr.ludvika.se> writes
>
>(Sorry for the rather lenghty post)
>
Don't worry about that.
>Hi,
>I'd just try to boot my newly aquired PDP11/83 and was planning to install
>2.11BSD. But I've run into one (small?) problem. If I just try to boot
>from DU0: it says: 
>
>Trying DU0
>
>Error 20 
>Controller Error
>
>And if I boot the install tape from the TK70 drive and run disklabel,
>all accesses to the RD53 drive just times out. So I was going to remove
>all unwanted QBus boards from the boxes. And that's what I was going to
>ask...
>
A good plan
>
>Is there something special I have to think about, like there's some slots
>that can't be used, some boards must be in a specific slot and so on?
>
There are rules about where boards can go which is an off shoot of the
BG lines and so on.
>This is the current layout (which is exactly as it was when it was taken
>offline, or so I think)
>
>11/83 (173QA-B3, I think this is a normal BA23 enclosure):
>(As seen from the back) Also contains one TK70 drive.
>    
> ____________________________________________
>|Dataram 40903 revG     |        Empty slot  | (2mb ram)
>---------------------------------------------
>|                    M8637-EH                | (2mb ram)
>---------------------------------------------
>|                    M8190-AE                | (83 CPU)
>---------------------------------------------
>|     M7559             |         M7504      | (TK70, DEQNA)
>---------------------------------------------
>|     M8020             |        Empty slot  | (console?)
>---------------------------------------------
>|                    M7957                   | (DZV11)
>---------------------------------------------
>|                    m3104                   | (DHV11)
>---------------------------------------------
>|     M9404            |          Empty slot | (1st Qbus conn)
>---------------------------------------------
>
>Expansion box (173QA-B3)
>(From the back) Also contains one RD53 and one dual floppy.
>
>_____________________________________________
>|M9405-YA               |        Empty slot  | (2nd qbus conn)
>---------------------------------------------
>|                     m3104                  | (DHV11)
>---------------------------------------------
>|     m9047             |        m9047       | (grant cont x2)
>---------------------------------------------
>|     m7555             |        Empty slot  | (RQDX3)
>---------------------------------------------
>|     m7512             |        Empty slot  | (RQDX1E)
>---------------------------------------------
>
>Plus one external disk box with two RD53 drive. (This system only uses one
>drive though.)
>
>Now, what I obviously want to keep is:
>the two RAM boards, the CPU, the console board, tk70 controller, deqna,
>rqdx3.
>
What you are calling the console board probably isn't, or if it is then
you want to use the one from the CPU card rather than the M8020 (DPV11 I
think?).

>What I want to loose:
>the rest of the serial boards, the rqdx1e board and the floppy drive.
>

What I suggest is this.  Keep the CPU and the mem, the TK controller and
tape, the deqna, the RQDX3 and a serial card (You never know when a
spare serial port is going to be useful - printers, simple comms to a
PC, spare terminal etc etc etc).

A possible layout would be:

|Dataram 40903 revG     |        Empty slot  | (2mb ram)
---------------------------------------------
|                    M8637-EH                | (2mb ram)
---------------------------------------------
|                    M8190-AE                | (83 CPU)
---------------------------------------------
|     M7559             |         M7504      | (TK70, DEQNA)
---------------------------------------------
|                    M7957/M3104             | (DZV11) or (DHV11)
---------------------------------------------
|    M7555              |        Empty slot  |
----------------------------------------------
|     Empty slot        |       Empty slot   | 
---------------------------------------------
|     Empty slot        |         Empty slot | 
---------------------------------------------

>What do I have to do to make this work? I would preferrably want to fit
>all those boards in the main CPU enclosure box. Do I have to re-assign any
>addresses (or vectors, or what the correct PDP-speak is). Are there any
>slots in the enclosure that are a no-no for the dual-sized boards?
>
You would have to check with others which of the serial boards is best 
supported under 2.11BSD.  Steve Schultz is your best point of contact
for this.

Looking at you aoriginal configuration I think that the empty slot by
your M8020 is your problem (unless there is a bus grant card in there)
as there wouldn't be any BG continuity.

This should work and allow you to ditch all of the rest. (saving it for
a rainy day of course :-)).

Regards

Robin
____________________________________________________________________
Robin Birch     robin at falstaf.demon.co.uk

M1ASU/2E0ARJ    Old computers and radios always welcome


From erin at coffee.corliss.net  Sat Dec 26 13:41:55 1998
From: erin at coffee.corliss.net (Erin W. Corliss)
Date: Fri, 25 Dec 1998 19:41:55 -0800 (PST)
Subject: 2.11BSD
Message-ID: <Pine.LNX.3.96.981225193543.11045A-100000@coffee.corliss.net>


I know you've all been on the edge of your seats waiting for this, but...

I finally got my PDP-11/73 working, using a wyse terminal instead of my PC
-- for some reason neither of the serial ports were sending on the PC (but
then again, I boughtthe motherboard in an alley in korea three years
ago)...  Anyway, it boots up with RSTS/E version 9, which is OK in it's
own little way, I guess, but I'd rather be running Unix on it.  

So where can I download the binaries for 2.11BSD?

	-- Erin Corliss


Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id PAA02429
	for pups-liszt; Sat, 26 Dec 1998 15:03:53 +1100 (EST)

From SHOPPA at trailing-edge.com  Sat Dec 26 14:03:36 1998
From: SHOPPA at trailing-edge.com (Tim Shoppa)
Date: Fri, 25 Dec 1998 23:03:36 -0500
Subject: 2.11BSD
Message-ID: <981225230336.206000db@trailing-edge.com>

>I know you've all been on the edge of your seats waiting for this, but...
>
>I finally got my PDP-11/73 working, using a wyse terminal instead of my PC
>-- for some reason neither of the serial ports were sending on the PC (but
>then again, I boughtthe motherboard in an alley in korea three years
>ago)...

There are at least two different standards for the ribbon-cable-to-D-sub
adapters, and of course it's guaranteed that you'll use the wront type :-).

>  Anyway, it boots up with RSTS/E version 9, which is OK in it's
> own little way, I guess, but I'd rather be running Unix on it.  
> So where can I download the binaries for 2.11BSD?

Easiest way is for you to tell us what sort of load media you can use and
have someone write an install tape for you.  Do you have a TK50 or other tape
drive on the system?

-- 
 Tim Shoppa                        Email: shoppa at trailing-edge.com
 Trailing Edge Technology          WWW:   http://www.trailing-edge.com/
 7328 Bradley Blvd		   Voice: 301-767-5917
 Bethesda, MD, USA 20817           Fax:   301-767-5927

Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id VAA03169
	for pups-liszt; Sat, 26 Dec 1998 21:31:23 +1100 (EST)

From wkt at henry.cs.adfa.oz.au  Sat Dec 26 20:32:47 1998
From: wkt at henry.cs.adfa.oz.au (Warren Toomey)
Date: Sat, 26 Dec 1998 21:32:47 +1100 (EST)
Subject: 2.11BSD (but no src license)
In-Reply-To: <19981226180625.S12346@freebie.lemis.com> from Greg Lehey at "Dec 26, 98 06:06:25 pm"
Message-ID: <199812261032.VAA20488@henry.cs.adfa.oz.au>

In article by Greg Lehey:
> On Friday, 25 December 1998 at 23:09:48 -0800, Erin W. Corliss wrote:
> > On Sat, 26 Dec 1998, Greg Lehey wrote:
> >> Do you have an Ancient UNIX license?  I don't see you in our list.
> >> You'll need one before we can give you a copy of the software.
> >
> > Nope.  I have a licensed copy of RSTS/E I could trade, though...  8^)  No,
> > actually, I think I found another source for it, but thanks for the
> > concern.
> 
> PUPS is very glad to have been able to have created the possibility of
> legally using these old versions of UNIX.  Please don't make things
> difficult by abusing somebody's cooperation.  You can get it legally;
> see http://minnie.cs.adfa.oz.au/PUPS/getlicense.html for more details.
> 
> Greg

What Greg says is true: we can't give you access to any UNIX source
code unless you have a UNIX source license from SCO. However....
I should ask Dion at SCO if we could distribute binary-only distributions
of 2.x BSD without a license. After all, freely distributable binary-only
distributions for v5, v6, v7 and Venix (System III-ish) exist.

Just a thought, but for now you do need a source license.

Cheers,
	Warren


From msokolov at harrier.Uznet.NET  Sun Dec 27 18:38:56 1998
From: msokolov at harrier.Uznet.NET (Michael Sokolov)
Date: 27 Dec 1998   08:38:56 GMT
Subject: 4.3BSD-Quasijarus0 release
Message-ID: <199812270839.NAA09201@harrier.Uznet.NET>

Dear PUPS/TUHS members,

About three hours ago I have released 4.3BSD-Quasijarus0, the latest release of
4.3BSD-*. This release has the 4.3-Tahoe userland and a kernel that supports
all hardware supported by CSRG's Tahoe and Reno releases, including KA630 and
KA650 MicroVAXen.

You can find 4.3BSD-Quasijarus0 under Distributions/4bsd/43quasi0.vax in the
PUPS archive. It is by far the newest system in the archive, compiled only a
couple of days ago.

I haven't got around to implementing a standalone disk labeling facility yet,
so installing it on a typical MicroVAX with third-party MSCP disks is still a
little bit of a challenge. While working on building this release, I and Tim
Shoppa have come up with a usable solution to this disklabel problem. It
appears in Distributions/4bsd/tips/QTR_disklabel_note. This approach also works
with VAX builds of CSRG's Tahoe and Reno releases (QTR stands for Quasijarus,
Tahoe, and Reno).

Have fun with it!

Sincerely,
Michael Sokolov
Cellular phone: 216-217-2579
ARPA Internet SMTP mail: msokolov at harrier.Uznet.NET



From grog at lemis.com  Tue Dec 29 12:09:52 1998
From: grog at lemis.com (Greg Lehey)
Date: Tue, 29 Dec 1998 12:39:52 +1030
Subject: Converting Sixth Edition man pages
Message-ID: <19981229123952.B12346@freebie.lemis.com>

I have the Sixth Edition man pages on my machine, but I can't do much
with them, since they use obsolete macros.  Is there any way to
convert them to the Seventh Edition style?

Greg
--
See complete headers for address, home page and phone numbers
finger grog at lemis.com for PGP public key

Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id TAA12241
	for pups-liszt; Tue, 29 Dec 1998 19:12:50 +1100 (EST)

From wkt at henry.cs.adfa.oz.au  Tue Dec 29 18:14:38 1998
From: wkt at henry.cs.adfa.oz.au (Warren Toomey)
Date: Tue, 29 Dec 1998 19:14:38 +1100 (EST)
Subject: Converting Sixth Edition man pages
In-Reply-To: <19981229123952.B12346@freebie.lemis.com> from Greg Lehey at "Dec 29, 98 12:39:52 pm"
Message-ID: <199812290814.TAA22809@henry.cs.adfa.oz.au>

In article by Greg Lehey:
> I have the Sixth Edition man pages on my machine, but I can't do much
> with them, since they use obsolete macros.  Is there any way to
> convert them to the Seventh Edition style?
> 
> Greg

My off-the-cuff suggestion is to read the man(7) pages for both V6 and V7,
and write a Perl script to make the changes :-) That's probably the `best'
solution, but would take time.

Do you want to preserve the markup, or just want to view the manpages?
Just viewing them would be easier, of course!

Ciao,
	Warren


Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id TAA12285
	for pups-liszt; Tue, 29 Dec 1998 19:19:35 +1100 (EST)

From grog at lemis.com  Tue Dec 29 18:19:09 1998
From: grog at lemis.com (Greg Lehey)
Date: Tue, 29 Dec 1998 18:49:09 +1030
Subject: Converting Sixth Edition man pages
In-Reply-To: <199812290814.TAA22809@henry.cs.adfa.oz.au>; from Warren Toomey on Tue, Dec 29, 1998 at 07:14:38PM +1100
References: <19981229123952.B12346@freebie.lemis.com> <199812290814.TAA22809@henry.cs.adfa.oz.au>
Message-ID: <19981229184909.O32696@freebie.lemis.com>

On Tuesday, 29 December 1998 at 19:14:38 +1100, Warren Toomey wrote:
> In article by Greg Lehey:
>> I have the Sixth Edition man pages on my machine, but I can't do much
>> with them, since they use obsolete macros.  Is there any way to
>> convert them to the Seventh Edition style?
>
> My off-the-cuff suggestion is to read the man(7) pages for both V6 and V7,
> and write a Perl script to make the changes :-) That's probably the `best'
> solution, but would take time.

perl?  What's perl?  :-)  But yes, that was one alternative, one I
hadn't thought worth the trouble.

> Do you want to preserve the markup, or just want to view the manpages?
> Just viewing them would be easier, of course!

In fact, I'm not sure that just viewing them *would* be easier.  From
observation, the markup isn't too different from the -an macros.  A
lot of the macros seem to be the same, just in a different case.  But
there are enough differences that I wouldn't want to tackle it right
now.

Greg
--
See complete headers for address, home page and phone numbers
finger grog at lemis.com for PGP public key


From erin at coffee.corliss.net  Wed Dec 30 06:24:15 1998
From: erin at coffee.corliss.net (Erin W. Corliss)
Date: Tue, 29 Dec 1998 12:24:15 -0800 (PST)
Subject: rt11 and disk images
Message-ID: <Pine.LNX.3.96.981229120734.14487A-100000@coffee.corliss.net>


(writer bites his tongue to keep from ranting about paying $100 for an
operating system for a computer that cost $12 at a second-hand store...
8^)

So I went back to the junk store yesterday and found a TK25 tape drive,
which appears to work fine with my PDP-11/73.  It also uses the same
cartriges as my SCSI tape backup drive...  Is there a DOS, Linux, or
windows NT program that I can use to save files to tape so I can load them
on the PDP-11?  When I initialize a tape, is the format standard among
other computers, or is it specific to PDP's running RSTS?  

Is there any way to make Unix 7 use RD hard drives?

...and most importantly...

Everything for PDP's seems to be distributed on disk images for drives I
don't have.  I think I saw something somewhere about being able to mount a
.dsk file as a virtual drive under RT11...  Anyone know if this is true?


Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id IAA14527
	for pups-liszt; Wed, 30 Dec 1998 08:09:29 +1100 (EST)

From sms at moe.2bsd.com  Wed Dec 30 07:07:32 1998
From: sms at moe.2bsd.com (Steven M. Schultz)
Date: Tue, 29 Dec 1998 13:07:32 -0800 (PST)
Subject: rt11 and disk images
Message-ID: <199812292107.NAA11417@moe.2bsd.com>

Hi -

> From: "Erin W. Corliss" <erin at coffee.corliss.net>
> (writer bites his tongue to keep from ranting about paying $100 for an
> operating system for a computer that cost $12 at a second-hand store... 8^)

	If you think $100 for software is worthy of ranting I'd hate to see
	what $100k (what it used to cost for UNIX sources) worth of ranting 
	would sound like :) :) :)

> So I went back to the junk store yesterday and found a TK25 tape drive,
> which appears to work fine with my PDP-11/73.  It also uses the same
> cartriges as my SCSI tape backup drive...  Is there a DOS, Linux, or

	The TK25 (I have one also - worked the last time I checked some time
	ago) uses DC600A (the "A" is important) 60mb tapes.

	But there the similarity ends.

> windows NT program that I can use to save files to tape so I can load them
> on the PDP-11?  When I initialize a tape, is the format standard among
> other computers, or is it specific to PDP's running RSTS?  

	The TQK25 formats the tape in a 'variable' record mode format that
	is (as far as I know) peculiar to DEC (or who ever built the TK25
	for them).  This makes the TK25 look and feel like a 9-track drive
	(record boundaries are preserved) which is nice.

	Unfortunately most (all?) QIC drives in the "PC" world end up in a
	'fixed record' mode (which loses the concept of record size).   So
	while you might have a DC600A drive on a Linux system it will, odds are,
	only write in fixed record mode which the TQK25 probably won't like.
	Have to try it and see what happens.

> Is there any way to make Unix 7 use RD hard drives?

	Not easily.  MSCP devices weren't around or weren't supported at
	the time V7 came out.  You'd need a  development system running
	supported disks first (perhaps the work could be done via an
	emulator).  Then you could create "boot kits" (and adding RD/RA
	support would also entail writing bootblocks, standalone drivers,
	updating /boot, in additi0on to the mainline kernel 'ra.c' driver).

	2.11BSD supports the RD drives quite nicely - if you've an 11/73
	then perhaps using 2.11 instead of V7 might be worth considering.

> ...and most importantly...
> 
> Everything for PDP's seems to be distributed on disk images for drives I
> don't have.  I think I saw something somewhere about being able to mount a

	That's why I (even 6 years ago the older drive types were either
	too old or too bulky/powerhungry) bought an Emulex UC08 (MSCP->SCSI)
	and started using SCSI peripherals.  You should have heard the 
	ranting - but it was worth in the long haul.

	Steven Schultz
	sms at moe.2bsd.com

Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id JAA14776
	for pups-liszt; Wed, 30 Dec 1998 09:37:12 +1100 (EST)

From robin at falstaf.demon.co.uk  Wed Dec 30 08:32:24 1998
From: robin at falstaf.demon.co.uk (Robin Birch)
Date: Tue, 29 Dec 1998 22:32:24 +0000
Subject: Bob Supnik's Emulator.
Message-ID: <7OIFxAA4hVi2EwHy@falstaf.demon.co.uk>

Dear All,
I've been struggling with Bob's emulator (version 2.3d).  The main
problem appears to be around the TM device driver.  I've been creating
boot programs and data on my 11/73 under 2.11 BSD.

To do this I've been using the makesimtape program.  This hasn't worked
very well.  I've had to make individual files for each of the standalone
utilities as I havn't been able to get the emulator to find files beyond
the first one.  For instance if I make a standalone file consisting of
the bootstrap, boot, disklabel, mkfs, restor and inode then I can boot
the processor and load and run disklabel but nothing beyond this.

Using separate bootstraps, boot and <program>, I have labeled and mkfs
an RP04.  I then tried restor.  Well, I can get restor to load and run
but it doesn't want to understand the dump file written with dd that is
created as part of the generation of a distribution set on the 11/73.

I suspect that there is some form of data conversion that I have to go
through before I can read the files on the emulator.

Has anybody installed 2.11 on the emulator from scratch.  If so, can
they offer any advice.

Regards

Robin

PS, the emulator is compiled with gcc on Solaris 2.6 running on a
sparc2.  It runs the rt11 and v7 disks available with the simulator with
no worries.
____________________________________________________________________
Robin Birch     robin at falstaf.demon.co.uk

M1ASU/2E0ARJ    Old computers and radios always welcome

Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id JAA14831
	for pups-liszt; Wed, 30 Dec 1998 09:49:48 +1100 (EST)

From wkt at henry.cs.adfa.oz.au  Wed Dec 30 08:51:34 1998
From: wkt at henry.cs.adfa.oz.au (Warren Toomey)
Date: Wed, 30 Dec 1998 09:51:34 +1100 (EST)
Subject: Bob Supnik's Emulator.
In-Reply-To: <7OIFxAA4hVi2EwHy@falstaf.demon.co.uk> from Robin Birch at "Dec 29, 98 10:32:24 pm"
Message-ID: <199812292251.JAA23598@henry.cs.adfa.oz.au>

In article by Robin Birch:
> Dear All,
> I've been struggling with Bob's emulator (version 2.3d).  The main
> problem appears to be around the TM device driver.  I've been creating
> boot programs and data on my 11/73 under 2.11 BSD.
> 
> To do this I've been using the makesimtape program.  This hasn't worked
> very well.  I've had to make individual files for each of the standalone
> utilities as I havn't been able to get the emulator to find files beyond
> the first one.  For instance if I make a standalone file consisting of
> the bootstrap, boot, disklabel, mkfs, restor and inode then I can boot
> the processor and load and run disklabel but nothing beyond this.

The format of a tape image is described in simh_doc.txt in Appendix 1.3,
at roughly line 2,473 of the file. Perhaps the makesimtape program isn't
making the tape correctly. What arguments are you giving it?

On a silly note, if there is only a single thing on the tape you are trying
to restor, you could always save it without the record structure imposed
by makesimtape, attach it as RL00, and then restor it from /dev/rl00 :-)

Best of luck,
	Warren

Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id JAA14858
	for pups-liszt; Wed, 30 Dec 1998 09:51:34 +1100 (EST)

From dave at fgh.geac.com.au  Wed Dec 30 08:48:10 1998
From: dave at fgh.geac.com.au (Dave Horsfall)
Date: Wed, 30 Dec 1998 09:48:10 +1100 (EST)
Subject: Converting Sixth Edition man pages
In-Reply-To: <19981229184909.O32696@freebie.lemis.com>
Message-ID: <Pine.GSO.4.03.9812300947020.22664-100000@fgh>

On Tue, 29 Dec 1998, Greg Lehey wrote:

> In fact, I'm not sure that just viewing them *would* be easier.  From
> observation, the markup isn't too different from the -an macros.  A
> lot of the macros seem to be the same, just in a different case.  But
> there are enough differences that I wouldn't want to tackle it right
> now.

Do you have thee 6th Edition documentation to tell you what the macros
do?  I have them somewhere...

-- 
Dave Horsfall VK2KFU  dave at geac.com.au  Ph: +61 2 9978-7493 Fx: +61 2 9978-7422
Geac Computers P/L (FGH Division) 2/57 Christie St, St Leonards 2065, Australia


Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id JAA14878
	for pups-liszt; Wed, 30 Dec 1998 09:55:19 +1100 (EST)

From norman at nose.cita.utoronto.ca  Tue Dec 29 19:51:20 1998
From: norman at nose.cita.utoronto.ca (norman at nose.cita.utoronto.ca)
Date: Tue, 29 Dec 1998 04:51:20 -0500
Subject: No subject
Message-ID: <199812290952.UAA13151@csadfa.cs.adfa.oz.au>

Stuff this in the archives somewhere: V6 man macros.
I can't remember where I dug it up, unfortunately.

# To unbundle, sh this file
echo tmac.an6 1>&2
sed 's/.//' >tmac.an6 <<'//GO.SYSIN DD tmac.an6'
-'''\"	Pwb Manual Entry Macros - Version 6 (@(#)an6.src	1.6)
-'''\"	Nroff/Troff Version	@(#)1.6
-.deTH
-.tmwrong version of man entry macros - use -man
-.ab
-..
-.rnbd Bd
-.rndt Dt
-.rnit il
-.nr}I 5n
-.nr}P 0 1
-.de}C
-.ev1
-.po0
-.lt7.5i
-.tl\-\-
-.lt
-.po
-.ev
-..
-.de}E
-.wh-1p }C
-..
-.ift .em }E
-.dei0
-.in\\n(}Iu
-.dt
-..
-.delp
-.tc
-.i0
-.ta\\$2n
-.in\\$1n
-.ti-\\$2n
-..
-.des1
-.sp1v
-.ne2
-..
-.des2
-.ift .sp .5v
-.ifn .sp 1v
-..
-.des3
-.ift .sp .5v
-.ifn .sp 1v
-.ne2
-..
-.de}F
-.ev1
-'ft1
-'ps10
-'sp.5i
-.tl- % -
-'ft
-'ps
-.ev
-'bp
-..
-.deth
-.de}X
-.ev1
-.ift .}C
-'ft1
-'ps10
-'sp.5i
-.tl''THIS MANUAL ENTRY NEEDS TO BE CONVERTED - SEE mancvt(1) and man(7)''
-.tl\\$1\|(\|\\$2\|)PWB/UNIX\| \\$3\\$1\|(\|\\$2\|)
-'ps
-'ft
-'sp.5i
-.ev
-\\..
-.wh-1i }F
-.wh0 }X
-.if\\n+(}P>1 .bp1
-.ft1
-.ft1
-.ps10
-.vs12p
-.ift .po .5i
-.in\\n(}Iu
-.fi
-.dt
-.mc
-.ad
-.ifn .na
-..
-.desh
-.s1
-.ift .ft 3
-.ps8
-.ti0
-\&\\$1
-.ift .ft
-.ps
-.br
-..
-.deit
-.ul
-.ie\\nV>1 _\\$1_
-.el\&\\$1
-..
-.debd
-.ift .ft 3
-.ifn .ul
-.ie\\nV>1 _\\$1_
-.el\&\\$1
-.ift .ft 
-..
-.debn
-.ift .ft 3
-.ifn .ul
-.ie\\nV>1 _\\$1_\t\&\c
-.el\&\\$1\t\&\c
-.ift .ft 
-..
-.dedt
-.ifn .ta 8n 16n 24n 32n 40n 48n 56n 64n 72n 80n
-.ift .ta .5i 1i 1.5i 2i 2.5i 3i 3.5i 4i 4.5i 5i 5.5i 6i 6.5i
-..
-'dsv \(bv
-'ds' \(aa
-'ds> \(->
-'dsX \(mu
-'ds_ _
-'ds- \-
-'dsG \(*G
-'dsg \(ga
-'dsp \(*p
-'dsa \(aa
-'dsb \(*b
-'dsr \(rg
-'ds| \|
-'dsu \(*m
-.if\nV=1 \{\
-.po4
-.ll80
-.lt80
-.ev1
-.ll80
-.lt80
-.ev\}
-.if\nV>1 \{\
-.ll82
-.lt82
-.ev1
-.ll82
-.lt82
-.ev
-.pl84
-.rmul\}
-.hy14
-.uf2
//GO.SYSIN DD tmac.an6


Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id KAA14989
	for pups-liszt; Wed, 30 Dec 1998 10:04:45 +1100 (EST)

From sms at moe.2bsd.com  Wed Dec 30 09:03:53 1998
From: sms at moe.2bsd.com (Steven M. Schultz)
Date: Tue, 29 Dec 1998 15:03:53 -0800 (PST)
Subject: Bob Supnik's Emulator.
Message-ID: <199812292303.PAA12398@moe.2bsd.com>

Robin -

	Howdy.

> From: Robin Birch <robin at falstaf.demon.co.uk>
> I've been struggling with Bob's emulator (version 2.3d).  The main

	2.3d?  Hmmm, sounds like a little newer one than I've used in the
	past (I've updated selected modules so I'm probably running 2.3d
	but the directory is still called 2.3b ;))

> problem appears to be around the TM device driver.  I've been creating
> boot programs and data on my 11/73 under 2.11 BSD.

	I don't think that's the case - but read on and see if my new
	theory sounds plausible...

> Using separate bootstraps, boot and <program>, I have labeled and mkfs
> an RP04.  I then tried restor.  Well, I can get restor to load and run
> but it doesn't want to understand the dump file written with dd that is
> created as part of the generation of a distribution set on the 11/73.

	Umm, you can't use a 'dd'd image - you have to use 'makesimtape'
	(or a similar utility) to add the record/file/bytecount markers that
	the simulator expects to see.

> I suspect that there is some form of data conversion that I have to go
> through before I can read the files on the emulator.

	Yes, there is.  Not sure why it didn't occur to me earlier when you
	mentioned having problems.

	I assume you compiled and ran 'makesimtape' on the same system
	(Sparc) as the simulator is running.

	If so then it sounds to be like there's an endianness bug in
	makesimtape.  That wouldn't surprise me since all I have are 
	either little or pdp-11 endian systems and never tested makesimtape
	on a big endian machine.

	There are ifdefs around what I thought were the appropriate places
	for flipping bytes - what you'll need to do is get Bob's description
	of the simulated tape format (fairly simply and it's in the docs
	somewhere as I recall) and the makesimtape.c source and see where I
	"oops"d.

> Has anybody installed 2.11 on the emulator from scratch.  If so, can
> they offer any advice.
	
	Yes, I have.  But only on little endian systems.  The one time (ages
	ago) I tried the simulator on a Sparc the program dropped core because
	it wasn't bigendian capable.  That's been fixed but I've never tried
	it again.

	Steven

Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id KAA15089
	for pups-liszt; Wed, 30 Dec 1998 10:21:23 +1100 (EST)

From robin at falstaf.demon.co.uk  Wed Dec 30 09:20:18 1998
From: robin at falstaf.demon.co.uk (Robin Birch)
Date: Tue, 29 Dec 1998 23:20:18 +0000
Subject: Bob Supnik's Emulator.
In-Reply-To: <199812292303.PAA12398@moe.2bsd.com>
Message-ID: <Wta+ZIAyOWi2EwQ$@falstaf.demon.co.uk>

In message <199812292303.PAA12398 at moe.2bsd.com>, Steven M. Schultz
<sms at moe.2bsd.com> writes
>Robin -
>       I don't think that's the case - but read on and see if my new
>       theory sounds plausible...
>
I think that I've independantly come up with the same answer but by a
different logical root.
>> Using separate bootstraps, boot and <program>, I have labeled and mkfs
>> an RP04.  I then tried restor.  Well, I can get restor to load and run
>> but it doesn't want to understand the dump file written with dd that is
>> created as part of the generation of a distribution set on the 11/73.
>
>       Umm, you can't use a 'dd'd image - you have to use 'makesimtape'
>       (or a similar utility) to add the record/file/bytecount markers that
>       the simulator expects to see.
>
Now this is what I didn't realise at first.  All I thought makesimtape
was doing was packaging up the files, not writing some structure around
them.

>> I suspect that there is some form of data conversion that I have to go
>> through before I can read the files on the emulator.
>
>       Yes, there is.  Not sure why it didn't occur to me earlier when you
>       mentioned having problems.
>
>       I assume you compiled and ran 'makesimtape' on the same system
>       (Sparc) as the simulator is running.
>
This is the big one, no.  I had assumed that as the simulator was
emulating a PDP that it would accept files generated to look like boot
files etc built on a pdp so I'm running makesimtape in the standalone
direcctory of the 11/73.  Nieve maybe but at least it was logical :-).

>       If so then it sounds to be like there's an endianness bug in
>       makesimtape.  That wouldn't surprise me since all I have are 
>       either little or pdp-11 endian systems and never tested makesimtape
>       on a big endian machine.
>
What I'll do is build makesimtape on the sun and see what happens then.

>       There are ifdefs around what I thought were the appropriate places
>       for flipping bytes - what you'll need to do is get Bob's description
>       of the simulated tape format (fairly simply and it's in the docs
>       somewhere as I recall) and the makesimtape.c source and see where I
>       "oops"d.
Back in a mo.

Robin
____________________________________________________________________
Robin Birch     robin at falstaf.demon.co.uk

M1ASU/2E0ARJ    Old computers and radios always welcome

Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id KAA15164
	for pups-liszt; Wed, 30 Dec 1998 10:34:30 +1100 (EST)

From sms at moe.2bsd.com  Wed Dec 30 09:33:50 1998
From: sms at moe.2bsd.com (Steven M. Schultz)
Date: Tue, 29 Dec 1998 15:33:50 -0800 (PST)
Subject: Bob Supnik's Emulator.
Message-ID: <199812292333.PAA12655@moe.2bsd.com>

Robin -

> From robin at falstaf.demon.co.uk Tue Dec 29 15:21:08 1998
> >       Umm, you can't use a 'dd'd image - you have to use 'makesimtape'
> >       (or a similar utility) to add the record/file/bytecount markers that

> Now this is what I didn't realise at first.  All I thought makesimtape
> was doing was packaging up the files, not writing some structure around

	It's writing simulated bytecounts and simulated file and tape marks ;)

> >       I assume you compiled and ran 'makesimtape' on the same system
> >
> This is the big one, no.  I had assumed that as the simulator was

	Ah, ok - so you're running the makesimtape program on an 11.  That
	would tend to point the finger at the program not flipping the 
	'structure' bytes into correct big endian order.

> emulating a PDP that it would accept files generated to look like boot
> files etc built on a pdp so I'm running makesimtape in the standalone
> directory of the 11/73.  Nieve maybe but at least it was logical :-).

	The "data" is PDP-11 specific, but the "structure" bytes need to be
	in a canonical (big endian) form.

	I was pretty sure the endianness was ok but I guess not.  Another
	possibility is that there's an alignment disagreement.  The 11 might
	be putting something on a 2 byte bound where the Sun expects a 4 byte
	alignment.  

> >       There are ifdefs around what I thought were the appropriate places
> >       for flipping bytes - what you'll need to do is get Bob's description
> Back in a mo.

	If you find (and fix ;-)) it let me know and I'll integrate the
	changes into makesimtape.c in the 2.11 tree (and eventually in to
	the PUPS archive).

	Steve

Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id KAA15193
	for pups-liszt; Wed, 30 Dec 1998 10:42:04 +1100 (EST)

From wkt at henry.cs.adfa.oz.au  Wed Dec 30 09:43:56 1998
From: wkt at henry.cs.adfa.oz.au (Warren Toomey)
Date: Wed, 30 Dec 1998 10:43:56 +1100 (EST)
Subject: Converting Sixth Edition man pages
In-Reply-To: <19981229123952.B12346@freebie.lemis.com> from Greg Lehey at "Dec 29, 98 12:39:52 pm"
Message-ID: <199812292343.KAA23709@henry.cs.adfa.oz.au>

In article by Greg Lehey:
> I have the Sixth Edition man pages on my machine, but I can't do much
> with them, since they use obsolete macros.  Is there any way to
> convert them to the Seventh Edition style?
> 
> Greg

Here's a quick hack which is a start. It's a Perl script called fix:

#!/usr/bin/perl
while (<>) {
        s/^\.br/.BR/;
        if (/^\.bd/) {
            if (/\"/) {
                s/^\.bd/.B/; print; $_=".br\n";
            } else {
                s/^\.bd/.B/;
            }
        }
        s/^\.bl/.BL/;
        s/^\.it/.I/;
        s/^\.sh/.SH/;
        s/^\.th/.TH/;
        s/^\.s3/.PP/;
        s/\\\*/\\/g;
        print;
}

I've run the V6 section 1 manuals through it, then nroffed them using
GNU nroff under FreeBSD 2.2.x, and I get only the following error messages:

# for i in *.1
> do  perl /tmp/fix $i | nroff -man > /dev/null
> done
<standard input>:428: can't set diversion trap when no current diversion
<standard input>:95: can't set diversion trap when no current diversion
<standard input>:77: can't set diversion trap when no current diversion
<standard input>:40: can't set diversion trap when no current diversion
<standard input>:119: can't set diversion trap when no current diversion
<standard input>:132: normal or special character expected (got a node)
<standard input>:137: a tab character  is not allowed in an escape name
<standard input>:83: cannot use a space as a starting delimiter
<standard input>:127: can't set diversion trap when no current diversion
<standard input>:93: can't set diversion trap when no current diversion
<standard input>:75: can't set diversion trap when no current diversion
<standard input>:64: can't set diversion trap when no current diversion
<standard input>:36: can't set diversion trap when no current diversion
<standard input>:154: a tab character is not allowed before an argument
<standard input>:182: a tab character is not allowed before an argument
<standard input>:182: error: end of file while ignoring input lines
<standard input>:95: can't set diversion trap when no current diversion
<standard input>:95: can't set diversion trap when no current diversion

I haven't eyeballed the output from them all, but ls(1), sh(1), db(1)
and roff(1) look ok.

Send in any improvements!!

	Warren

Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id KAA15247
	for pups-liszt; Wed, 30 Dec 1998 10:59:06 +1100 (EST)

From cdl at mpl.ucsd.edu  Wed Dec 30 09:58:25 1998
From: cdl at mpl.ucsd.edu (Carl Lowenstein)
Date: Tue, 29 Dec 1998 15:58:25 -0800 (PST)
Subject: Converting Sixth Edition man pages
Message-ID: <199812292358.PAA16791@mpl.ucsd.edu>

> From owner-pups at minnie.cs.adfa.edu.au Tue Dec 29 15:07 PST 1998
> Date: Wed, 30 Dec 1998 09:48:10 +1100 (EST)
> From: Dave Horsfall <dave at fgh.geac.com.au>
> X-Sender: dave at fgh
> To: Greg Lehey <grog at lemis.com>
> cc: Unix Heritage Society <pups at minnie.cs.adfa.oz.au>
> 
> On Tue, 29 Dec 1998, Greg Lehey wrote:
> 
> > In fact, I'm not sure that just viewing them *would* be easier.  From
> > observation, the markup isn't too different from the -an macros.  A
> > lot of the macros seem to be the same, just in a different case.  But
> > there are enough differences that I wouldn't want to tackle it right
> > now.
> 
> Do you have thee 6th Edition documentation to tell you what the macros
> do?  I have them somewhere...
> 
> -- 

A quick check around some computers that I have on-line shows two sets
of v6 man macros, one for nroff and one for troff.  This is on a NeXT
running NeXTstep 3.3.  But I suspect that these same macros are
available on anything with a BSD 4.3 flavor.

/usr/lib/tmac/tmac.an6n
/usr/lib/tmac/tmac.an6t

About 200 lines total between them.

With the right macros, [ntg]roff should be able to do everything else.

    carl

        carl lowenstein         marine physical lab     u.c. san diego
                                                  clowenstein at ucsd.edu

Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id LAA15274
	for pups-liszt; Wed, 30 Dec 1998 11:06:51 +1100 (EST)

From sms at moe.2bsd.com  Wed Dec 30 10:06:30 1998
From: sms at moe.2bsd.com (Steven M. Schultz)
Date: Tue, 29 Dec 1998 16:06:30 -0800 (PST)
Subject: Tape endianness in Bob's simulator
Message-ID: <199812300006.QAA12964@moe.2bsd.com>

Hi -

	In glancing thru Bob's simulator I spotted this:


* Endian independent binary I/O package

   For consistency, all binary data read and written by the simulator
   is stored in little endian data order.  That is, in a multi-byte
   data item, the bytes are written out right to left, low order byte
   to high order byte.  On a big endian host, data is read and written
   from high byte to low byte.  Consequently, data written on a little
   endian system must be byte reversed to be usable on a big endian
   system, and vice versa.


	Perhaps this sheds some light on why a Sparc can't read a pdp-11
	generated (via 'makesimtape') tape.

	I know I've read simulated tape files on an Intel system with no
	trouble - so it would appear that the endianness was correct.

	Good Luck Robin! ;)

	Steven

Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id LAA15356
	for pups-liszt; Wed, 30 Dec 1998 11:53:44 +1100 (EST)

From grog at lemis.com  Wed Dec 30 10:51:48 1998
From: grog at lemis.com (Greg Lehey)
Date: Wed, 30 Dec 1998 11:21:48 +1030
Subject: rt11 and disk images
In-Reply-To: <199812292107.NAA11417@moe.2bsd.com>; from Steven M. Schultz on Tue, Dec 29, 1998 at 01:07:32PM -0800
References: <199812292107.NAA11417@moe.2bsd.com>
Message-ID: <19981230112148.C32696@freebie.lemis.com>

On Tuesday, 29 December 1998 at 13:07:32 -0800, Steven M. Schultz wrote:
> 	The TQK25 formats the tape in a 'variable' record mode format that
> 	is (as far as I know) peculiar to DEC (or who ever built the TK25
> 	for them).  This makes the TK25 look and feel like a 9-track drive
> 	(record boundaries are preserved) which is nice.
>
> 	Unfortunately most (all?) QIC drives in the "PC" world end up in a
> 	'fixed record' mode (which loses the concept of record size).   So
> 	while you might have a DC600A drive on a Linux system it will, odds are,
> 	only write in fixed record mode which the TQK25 probably won't like.
> 	Have to try it and see what happens.

I believe the new CAM driver for FreeBSD 3.0 can do variable block
lengths on QIC drives.

Greg
--
See complete headers for address, home page and phone numbers
finger grog at lemis.com for PGP public key

Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id XAA16818
	for pups-liszt; Wed, 30 Dec 1998 23:31:23 +1100 (EST)

From robin at falstaf.demon.co.uk  Wed Dec 30 22:28:31 1998
From: robin at falstaf.demon.co.uk (Robin Birch)
Date: Wed, 30 Dec 1998 12:28:31 +0000
Subject: Tape endianness in Bob's simulator
In-Reply-To: <199812300006.QAA12964@moe.2bsd.com>
Message-ID: <qKdBgFAvxhi2EwFc@falstaf.demon.co.uk>

In message <199812300006.QAA12964 at moe.2bsd.com>, Steven M. Schultz
<sms at moe.2bsd.com> writes
>       I know I've read simulated tape files on an Intel system with no
>       trouble - so it would appear that the endianness was correct.
>
>       Good Luck Robin! ;)
>
>       Steven
Steven,
I now have a makesimtape that creates the bootstrap files correctly.  I
have found, I think, one bug and partly rewritten another bit just to
put my mind at rest about a couple of things.  I still can't create the
root correctly though.

What I have found:

1) Your endianness is correct, it took me a couple of sample programs
and rewrites to prove it.  In doing this I have replaced trl with
another bit of code that does the same thing but is easier to play
around with to change the byte orders.

2) There are two bugs in the use of writev.  These are:

2.1) When writing the headers and data you are writing a long to the
file where iovec only supports (I think) an unsigned short.
2.2) When writing the tape marks you are writing an integer as though it
was a long.

Of the two 2.2 is the most significant (I think).

After correcting both of these.  By changing zero from an int to a long
and by replacing the writevs with writes for the headers, data and
trailers I have a version of makesimtape that creates a bootstrap file
that works.

I can load and run all of the bootstrap programs as though I was looking
at a real pdp which I couldn't before. This makes me think that I have
probably got makesimtape about right.

Now for the bad bit.  I have created a root.dump then run it through
makesimtape with the command file:

/usr/root.dump 2
* 1

and it won't load from restor.  I get a succession of "missing address
(header) block" errors but I successfully detect the end of the tape and
restor stops running, as it is supposed to do.

So, am I doing something wrong in creating the root file? or is there
something still wrong with makesimtape?.  This is probably a red herring
but the distribution tapes are written with a blocksize of 20 for all of
the data after the bootstraps whilst makesimtape only writes multiples
of 512.

Advice please

Robin
____________________________________________________________________
Robin Birch     robin at falstaf.demon.co.uk

M1ASU/2E0ARJ    Old computers and radios always welcome

Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id CAA17289
	for pups-liszt; Thu, 31 Dec 1998 02:53:20 +1100 (EST)

From sms at moe.2bsd.com  Thu Dec 31 01:52:58 1998
From: sms at moe.2bsd.com (Steven M. Schultz)
Date: Wed, 30 Dec 1998 07:52:58 -0800 (PST)
Subject: Tape endianness in Bob's simulator
Message-ID: <199812301552.HAA10714@moe.2bsd.com>

Robin -

> From robin at falstaf.demon.co.uk Wed Dec 30 04:31:15 1998
> What I have found:
> 
> 1) Your endianness is correct, it took me a couple of sample programs

	Whew - that's a relief.

> 2) There are two bugs in the use of writev.  These are:
> 
> 2.1) When writing the headers and data you are writing a long to the
> file where iovec only supports (I think) an unsigned short.

	iovec can write as much as it wants to.  To write a 'long' one
	simply stuffs the _address_ of the long variable into iov_base
	and "sizeof long" into iov_len.  I'm not sure what you mean by
	iovec only supporting a short.

> 2.2) When writing the tape marks you are writing an integer as though it
> was a long.

	It isn't?  Oops.

	On some systms (those where "sizeof long == sizeof int") 'zero' 
	would be a long.

	Sigh - I've been contaminated by machines where that assumption is
	true.

> Now for the bad bit.  I have created a root.dump then run it through
> makesimtape with the command file:
> 
> /usr/root.dump 2
> * 1
> 
> and it won't load from restor.  I get a succession of "missing address
> (header) block" errors but I successfully detect the end of the tape and
> restor stops running, as it is supposed to do.

> So, am I doing something wrong in creating the root file? or is there

	Uh, yes ;)

	'dump' tapes *must* consist of 10kb records.  'restore' is expecting
	10kb (or 20 sector) records and complaining about the shortness of
	what it is reading.

> something still wrong with makesimtape?.  This is probably a red herring
> but the distribution tapes are written with a blocksize of 20 for all of
> the data after the bootstraps whilst makesimtape only writes multiples
> of 512.

	Correct.  The bootblock+boot needs to be 512 byte records so the
	boot rom can deal with it.  The standalone programs are 1kb records
	(because that's the filesystem block size and to make the 'seeking'
	in the pseudo-stdio routines possible/simple).

	All the _data_ files are 10kb records because that's what 'tar' and
	'dump' use.

	Steven

Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id DAA17381
	for pups-liszt; Thu, 31 Dec 1998 03:15:43 +1100 (EST)

From belfry at nsw.bigpond.net.au  Thu Dec 31 02:13:57 1998
From: belfry at nsw.bigpond.net.au (Michael Kraus)
Date: Thu, 31 Dec 1998 03:13:57 +1100
Subject: PDP Free to good home...
Message-ID: <368A5145.BE11CED3@nsw.bigpond.net.au>

G'day all...

I've got a DEC Pro/350 machine (including Pro OS and manuals, etc), as
well as a serial printer for it.

I've been planning on putting UNIX on it, and tracking down a network
card for it.  However, I don't really have enough time or space to do
such.

It is a PDP (unsure if it is a PDP-11 or not... I did find out, but that
was a while ago). I'm pretty sure that you will be able to get it to run
UNIX (v6, I think).

Rather then let it sit useless in my hall, I thought one of you guys (or
girls, as the case may be) may appreciate it more than what I currently
am.

The only cost involved would be the cost of getting yourself here,
picking it up and taking it back home.  FYI, I live in Paddington (NSW).

Email me if you are interested.

Michael.

P.s. It is in my posssesion as my father is a doctor and it was in use
for many years in his practice.  (Its only recently that they upgraded
as it suited the purpose so well!)


From norman at nose.cita.utoronto.ca  Thu Dec 31 01:29:56 1998
From: norman at nose.cita.utoronto.ca (norman at nose.cita.utoronto.ca)
Date: Wed, 30 Dec 1998 10:29:56 -0500
Subject: No subject
Message-ID: <199812301530.CAA18891@csadfa.cs.adfa.oz.au>

//GO.SYSIN DD ... is more a clue about what system I packed up
the file on than where I originally found it.  It's all rob's fault.



