I'm sorry if this has been done before, but I could find no indication
this was the case in the unix archive itself or in any of the months I
checked in the mailing list.
I have figured out what the first 50176 bytes of s1-bits are.
It is an "INIT Tape" as described in Dennis_v1 Boot Procedures(VII) and
Dennis_v3 bproc.8. It is apparently contemporary with s2 [all of the
files on it /etc/getty /bin/ls and so on match up exactly with their
counterparts on s2], and this would seem to make s2 the "/bin-/etc-/lib
tape" described in bproc.8.
Also - is there any other known copy of the "bos" bootloader? I'm
partway through hand-disassembling the one on the tape.
Anyone know how to get SIMH to send ^J for return?
Anyway - with the KE-11A enabled you need to use "d system sr" to set
the switch register [which must be set to 1 to cold boot, 73700 to come
up in single user mode, and any random value other than the special ones
0 57500 10 20 40 1 2 to come up normally]
The RF disk is not even large enough to contain the whole s2 tape, and
while even v1 supported mountable filesystems, there is no mkfs or mount
on the tapes.
I was looking at several NetBSD manual pages and saw that some HISTORY
sections had wrong .Bx or BSD reference like:
HISTORY
The xstr command appeared in 3.0BSD.
I looked at a few and saw this was in 4.4BSD manual pages. By the way,
when were these history sections added? (They aren't in 4.2BSD manual
pages. I should look at 4.3 before asking ...)
I didn't see any that refered to original Berkeley UNIX Software Tape
nor 2BSD.
But from looking at the 1BSD and 2BSD, I see:
apropos was in 2bsd
colcrt was in 1bsd but not in 2bsd
even though 2BSD iul, soelim, and ssp manuals referenced it
(why missing from 2BSD?)
colrm was in 1bsd but not in 2bsd
csh was in 2bsd (even 1bsd referenced the upcoming "csh")
ctags was in 2bsd, but as a shell script using ed
expand was in 1bsd and 2bsd
finger was in 2bsd
fmt was in 2bsd
from was in 2bsd
head was in 1bsd and 2bsd
lock was in 2bsd
last was in 1bsd and 2bsd
mkstr was in 1bsd and 2bsd
msgs was in 2bsd
printenv was in 2bsd
soelim was in first BSD and 2BSD
tset was in 1bsd and 2bsd
w was in 2bsd as finger -sf
whatis was in 2bsd
whereis was in 2bsd
xstr was in 2bsd
lastlog file format was in 1bsd and 2bsd (?? maybe different format??)
Any comments on the above?
Or is this simply because "2BSD" is not a operating system release per
se, so "3.0BSD" is correct?
But this makes me wonder if my 2BSD versions are newer than first
2BSD, so really 3BSD is correct for some of this.
I was going to ask a NetBSD list about this to fix these histories, but
decided to consult TUHS instead. Okay to change history to fix history?
:)
I don't know if this is interesting to anyone, but I thought I'd share that
386BSD will install on Bochs (although slowly, and it's prone to crashing),
however once the first patchkit is installed, it'll then run on Qemu!
(0.11.0, it seems the new bios layout of 0.12 is incompatible)
If anyone is interested, here is a link to a hard disk image that I've
prepared for Qemu:
http://vpsland.superglobalmegacorp.com/install/386BSD/bsd386.qcow2.gz
I run it like this:
qemu.exe -L pc-bios -hda bsd386.qcow2 -M isapc -net nic -net user -no-reboot
-m 256
And I can run lynx/irc as a test of the TCP/IP.
At any rate, I figure this kind of brings 386BSD back out of it's grave.
Is anything likely to happen to the status of various historical
Unices? Is Novell likely to keep the Ancient Unix license intact or
are they likely to lock things back up? Is there any chance that
SysIII and early SysV might finally get opened up? Does anybody have
any ideas here?
Mike
_______________________________________________
TUHS mailing list
TUHS(a)minnie.tuhs.org
https://minnie.tuhs.org/mailman/listinfo/tuhs
Hi, doesn't anybody know if there is a disk size limit on Unix 6? I wrote a
C program to create a file and it won't go above around 1.5Mb. It doesn't
crash or report any errors but the file size never exceeds around that size.
Maybe it's a disk size limitation?
Also, is it possible to add other devices? like using an ISO file perhaps.
Regards,
Andrew.
On Thu, Apr 8, 2010 at 7:40 PM, John  Holden <johnh(a)psych.usyd.edu.au> wrote:
>
>> Well I found the ar specification (in ar.5 not ar.1).
>>
>> Â Â Â Â Â Â Â struct ar_hdr {
>>            char    ar_name[14];
>>            long    ar_date;
>>            char    ar_uid;
>>            char    ar_gid;
>>            int    ar_mode;
>>            long    ar_size;
>> Â Â Â Â Â Â Â };
>
> Endian should not be a problem on a Intel/AMD processor. More likely your C
> compiler is padding out the array for alignment. Try a '-fpack-struct' or
> more safely, read the elements individually rather than a structure.
>
In the PDP-11 long is 32 bits, int 16 bits. Â And the PDP-11 is
determinedly little-endian if you stick to integers.
They got floating-point software right in 1971, but somebody screwed
up the word order when building FP hardware, which led to the
middle-endian mess.
  carl
--
  carl lowenstein     marine physical lab   u.c. san diego
                        clowenstein(a)ucsd.edu
> Well I found the ar specification (in ar.5 not ar.1).
>
> struct ar_hdr {
> char ar_name[14];
> long ar_date;
> char ar_uid;
> char ar_gid;
> int ar_mode;
> long ar_size;
> };
Endian should not be a problem on a Intel/AMD processor. More likely your C
compiler is padding out the array for alignment. Try a '-fpack-struct' or
more safely, read the elements individually rather than a structure.
PS
To check, see what 'sizeof (struct ar_hdr_)' returns.
John
Bob Eager:
The 'ar' format of that vintage is trivial, and documentation easily
found. I wrote programs to read it back in 1976!
======
That's nothing. Either Ken or Dennis wrote such a program
years before that!
Warren even has a binary somewhere to prove it!
Seriously, it's a binary format, so I don't know that
it would be easy to process in awk. (At least not in
awk-classic; stuff that works only in ghootandwaveawk
is not all that interesting to me.) But the format is
simple, and any language new or old that can handle
binary data without tears should do.
If I didn't have an overfull plate already (and a
visit to the Auto-Electrocution Consultant tomorrow,
and one to the Canal Rooting Clinic Monday--proving
that one should follow Father's advice and Stay Away
>From The Canal, Neddie) it would be interesting to
collect the different specifications for ar headers
over the years, and write a small suite of programs
to read them. Perhaps in Python, just to be difficult.
(Why isn't there a language called Goon, Warren?)
Norman Wilson
Toronto ON
(owwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww)
On Thu, 8 Apr 2010, Michael Davidson wrote:
> Your modern compiler is almost certainly inserting two bytes of padding
> after ar_name[]
> so that the int32_t ar_date is aligned on a 4 byte boundary - that shifts
> everything else
> down by 2 bytes and means that ar_size lines up with the last 2 bytes of the
> size in
> the header which, as luck would have it, is the low order 16 bits of the
> size as it would
> have been stored in a 32 bit long.
>
> Something like this should work on a modern little endian processor"
>
> struct {
>     char  ar_name[14];
> Â Â Â Â int16_t ar_date_16_31;
> Â Â Â Â Â Â Â int16_t ar_date_00_15;
>     char   ar_uid;
>     char  ar_gid;
>     uint16_t    ar_mode;
>     uint16_t    ar_size_16_31;
>        uint16_t       ar_size_00_15;
> } ar_buf;
Thank you! That works for me! I can now get correct sizes, names, and
data. I will clean up my little ar extractor over the next few days and
share it.
