I've assembled some notes from old manuals and other sources
on the formats used for on-disk file systems through the
Seventh Edition:
http://www.cita.utoronto.ca/~norman/old-unix/old-fs.html
Additional notes, comments on style, and whatnot are welcome.
(It may be sensible to send anything in the last two categories
directly to me, rather than to the whole list.)
Markus Weber <jmbw(a)nather.com> wrote:
> Stand/copy from tms(0,1) to ra(0,1) fails with a 'disk unlabeled' diagnostic
> on a cold disk image.
It should print the unlabeled diagnostic, but then proceed rather than fail. I
just double-checked the standalone driver source, and it does provide a default
label for RA82, as long as the MSCP controller actually returns RA82 as the MSCP
disk ID. Does it give you an error message about disk type (some hex humber)
not supported? If so, SIMH's MSCP emulation must be lacking in quality.
> If only ra0 is
> configured for simh, it takes the kernel a long time to decide that ra1,
> ra2, and ra3 are offline. Having said that, I do not know how long this
> takes on actual hardware.
On real HW it takes no noticeable time.
> the kernel (and
> not simh) subsequently segfaults (trap type 8, code = c0000200, pc =
> 8003fe16).
Well, obviously this doesn't happen on real HW, since on real HW it works (I'm
typing this message on a MicroVAX 3+ running 4.3BSD-Quasijarus).
But I will grant the possibility that the kernel is not w/o fault either in that
perhaps it's going south (dereferencing a garbage pointer and crashing) when the
MSCP controller (in this case SIMH's poor emulation) is doing something it
doesn't expect. If this is so, it should be fixed, since even w/o emulators
(which I refuse to support on principle) real HW can be broken and return
garbage on reg reads, and the kernel must handle it gracefully. I'll look into
it.
MS
From my experience, you need to have a recent release of SIMH in order to
run 4.3BSD. A few months ago, I managed to build "working" Quasijarus and
Reno disk images (Quasijarus appears to work fine for me, but Reno is as
buggy as I remember it being on real hardware). I had to use Ultrix and
Netbsd to do the bootstrap/install; I could not get the tape boot to work
at all.
Here's my SIMH ini file for Quasijarus:
---------------------------------------------------------------------------------------------------------------
set cpu 32m
set cpu conhalt
set tto 7b
set tti 7b
at rom ka655.bin
at nvr nvr.bin
set rq0 ra82
at rq0 bsd43q_ra0.dsk
set rq1 ra82
at rq1 /dev/null
set rq2 ra82
at rq2 /dev/null
set rq3 ra82
at rq3 /dev/null
set tq0 locked
at tq0 BSD43Q_TAPE.tap
set dz 7b
at -m dz0 4501
at xq eth0
set lpt dis
set ts dis
set rl dis
boot cpu
--------------------------------------------------------------------------------------------------------------
Here's an example boot log for Quasijarus under SIMH:
>>>boot dua0
(BOOT/R5:0 DUA0
2..
-DUA0
1..0..
loading boot
Boot
: /vmunix
327204+103384+130352 start 0x23a8
4.3 BSD Quasijarus UNIX #0: Sat Oct 2 22:15:38 CDT 1999
msokolov@luthien:/usr/src/sys/GENERIC
real mem = 33521664
SYSPTSIZE limits number of buffers to 80
avail mem = 31697920
using 80 buffers containing 655360 bytes of memory
MicroVAX 3000, ucode rev 6
tmscp0 at uba0 csr 174500 vec 774, ipl 15
tms0 at tmscp0 slave 0
tms1 at tmscp0 slave 1
uda0 at uba0 csr 172150 vec 770, ipl 15
uda0: version 3 model 3
uda0: DMA burst size set to 4
ra0 at uda0 slave 0: RA82, size = 1216665 sectors
ra1 at uda0 slave 1: no disk label: ra82, size = 1216665 sectors
ra2 at uda0 slave 2: no disk label: ra82, size = 1216665 sectors
ra3 at uda0 slave 3: no disk label: ra82, size = 1216665 sectors
dz0 at uba0 csr 160100 vec 300, ipl 15
dz1 at uba0 csr 160110 vec 310, ipl 15
dz2 at uba0 csr 160120 vec 320, ipl 15
dz3 at uba0 csr 160130 vec 330, ipl 15
qe0 at uba0 csr 174440 vec 764, ipl 15
qe0: delqa, hardware address 08:00:2b:aa:bb:cc
Changing root device to ra0a
WARNING: clock gained 91 days -- CHECK AND RESET THE DATE!
Automatic reboot in progress...
Mon Sep 29 08:38:03 CDT 2003
/dev/ra0a: 669 files, 5242 used, 25429 free (37 frags, 3174 blocks, 0.1%
fragmentation)
/dev/rra0g: 12267 files, 71408 used, 376714 free (1634 frags, 46885 blocks,
0.4% fragmentation)
Mon Sep 29 08:43:51 CDT 2003
checking quotas: done.
starting system logger
preserving editor files
clearing /tmp
standard daemons: update cron accounting.
starting network daemons: routed named inetd printer.
Sep 29 08:44:28 simh named[66]: /etc/named.boot: No such file or directory
starting local daemons: sendmail.
Mon Sep 29 08:44:52 CDT 2003
4.3 BSD UNIX (simh.localdomain) (console)
login:
-----------------------------------------------------------------------------------------------------------
Cheers,
----
Joseph Young
jy99(a)swbell.net
Markus Weber <jmbw(a)nather.com> wrote:
> Clearly, stand boots. I'm hopeful that 4.3-Quasijarus0a will indeed run on
> simh.
Just be warned that I have heard from others that the kernel won't boot on SIMH
due to sucky emulation.
> For some follow-up questions... Standalone format supports hp and up disks,
> but simh only emulates RL and RQ controllers - which means that the Ultrix
> utilities to label a cold disk must be ported or recreated to the simh host
> platform. Of course, it may well be that applying a hex editor to the disk
> image will suffice.
Arghh, why don't people just f-ing get it! Standalone format is what is known
as low-level format in the PeeCee world (magnetic level stuff, certainly not
needed on an emulator), and it has absolutely nothing to do with disk labeling.
4.3BSD-Quasijarus0[a] does not have standalone disklabel, but RA82 is known to
the compiled-in tables and thus will work unlabeled. Also Ultrix' disk labels
are not useful for 4.3BSD-Tahoe/Quasijarus, since the labels are stored in a
different place in a different format. (Berkeley and DEC developed pack labels
independently. BSD stores them in the boot block, Ultrix stores them in the
root fs superblock, which has the disadvantage of requiring you to create some
dummy root fs before you can write a label, even if you want a root fs of
different size.)
> Am I correct that Quasijarus supports RA82 disks (using the ra type) and the
> TK50 tape (as a tms)?
Yes.
MS
Greetings all, and forgive me if this was answered prevously, but i
didnt see it when i grepped the archive..
Are there any *nix versions in the archive that will run on a MicroPDP11
model 630QZ-AX? Currently it is running RSX-11 /w what looks like a
seagate MFM/RLL type HDD. It has only dual floppy for removeable. But
i might be able to get my hands on a TK50/70 and qbus adapter for it.
Thanks.
-Matt
--
# Matthew E. Hoskins #############################################
# Information Systems Analyst /| / / / ~~/~~ #
# University Information Systems / | / / / / #
# New Jersey Institute of Technology / | / / / / / #
# University Heights, Newark, NJ 07102 / |/ /___/ / / #
# Ph: 973-596-5202 # Beep: pagematt(a)cobol.njit.edu #
# Rm: 5400 GITC Building # Email: matt(a)njit.edu #
###################################################################
"Any technology sufficiently advanced is indistinguishable
from a perl script"
"Anyone who considers arithmetical methods of producing
random digits is, of course, in a state of sin
-- John von Neumann"
Warren Toomey <wkt(a)tuhs.org> wrote:
> The 4.3BSD-Quasijarus dists were compressed with a compression format
> that's not compatible with either gzip nor old compress(1). Michael
> Sokolov should be able to send in some notes on the tools required.
Yes, for political reasons I needed to make the 4.3BSD-Quasijarus compressor a
version of compress, not gzip (can't have any GNU), but I wanted to have the
higher compression ratio of deflation, so I created a new version of compress
that supports deflation in addition to the original LZW algorith. You can find
the new compress in components/compress.tar either on my FTP site or in Warren's
archive in the 4BSD area.
> > Is there a set of 4.3BSD-Tahoe Vax distribution files that's complete?
>
> Not that I know of.
"4.3BSD-Tahoe Vax distribution" is an oxymoron. Berkeley released the Tahoe
tape with Tahoe binaries, no VAX binaries. I was the one who compiled the Tahoe
source for the VAX, and the result was 4.3BSD-Quasijarus0.
OTOH, you may be referring to the fact that the Tahoe distribution in the
archive is broken. Yes, it is. Unfortunately there was an unrecoverable tape
read error.
> > Finally, do you know of any 4.3BSD version that will install and run on
> > simh? Quasijarus and Tahoe of the Unix Archive are broken for me and Reno
> > doesn't boot stand. Admittedly, I haven't tried the vanilla version yet.
>
> Not that I know of. I'll cc this to the TUHS list and see if any other
> people know the answer.
This has come up time and again. SIMH's emulation of VAX is too poor. VAX is
not an easy architecture to emulate.
MS
On Wed, Sep 24, 2003 at 11:12:54AM -0500, Markus Weber wrote:
> Can you decompress the files in either of the two 4.3BSD-Quasijarus dists
> (in /4BSD/Distributions)? If so, how? The oldest versions that I have date
> back to a CD somebody cut me in mid-2000, and I can't decompress these files
> no matter what.
The 4.3BSD-Quasijarus dists were compressed with a compression format
that's not compatible with either gzip nor old compress(1). Michael
Sokolov should be able to send in some notes on the tools required.
> Is there a set of 4.3BSD-Tahoe Vax distribution files that's complete?
Not that I know of.
> Finally, do you know of any 4.3BSD version that will install and run on
> simh? Quasijarus and Tahoe of the Unix Archive are broken for me and Reno
> doesn't boot stand. Admittedly, I haven't tried the vanilla version yet.
Not that I know of. I'll cc this to the TUHS list and see if any other
people know the answer.
> If I manage to get a version of 4.3 working on simh, I'll offer a turnkey
> system for download on my site.
Yes, I'd appreciate that :-)
Thanks,
Warren
Hi all,
It's probably bad form to release a new version of a program
24 hours after the last version, but version 1.2 of my C comparison
tool is now available at http://minnie.tuhs.org/Programs/Ctcompare.
The speed has been vastly improved by using the Rabin-Karp string
comparison algorithm, and thanks go to Roger Willcocks who pointed
me at the algorithm. There are no other bug fixes, and I shouldn't
bring out a new version for quite a while now.
So if you have access to any restricted C source trees, maybe you can
send me the ctf file of the tree so I can do some comparisons!
Cheers,
Warren
On Thu, Sep 18, 2003 at 01:41:10PM +0300, Aharon Robbins wrote:
> > If anybody has Unix kernel trees which they cannot divulge due to licensing
> > restrictions, I'd appreciate you creating tokenised files of the kernel
> > source and e-mailing them to me.
>
> Hmmm. Just between us chickens, given tokenized versions of an entire tree,
> how hard would it be to recreate a functional kernel?
Pretty damn hard. All identifiers, (variable names) are reduced to
a single token. Actually, that's not true. The meaning of the names
is removed an replaced with numeric identifiers that are unique to
each file. Here's a tokenised portion of 32V (bio.c):
56: struct id10 *
57: id13 ( id14 , id15 )
58: id16 id14 ;
59: id17 id15 ;
60: {
61: register struct id10 * id18 ;
62:
63: id18 = id19 ( id14 , id15 ) ;
64: if ( id18 ->id20 & id21 ) {
65: #ifdef id1
66: id9 . id5 ++ ;
67: #endif
68: return( id18 ) ;
69: }
70: id18 ->id20 |= id22 ;
71: id18 ->id23 = id24 ;
72: ( * id25 [ id26 ( id14 ) ] . id27 ) ( id18 ) ;
73: #ifdef id1
74: id9 . id3 ++ ;
75: #endif
76: id28 ( id18 ) ;
77: return( id18 ) ;
78: }
Now go and check the actual source and work out which function it is!
[ see http://minnie.tuhs.org/UnixTree/32VKern/usr/src/sys/sys/bio.c.html ]
Warren