3 Oct
2014
3 Oct
'14
2:45 a.m.
I just received a new TUHS subscription request along with
an interesting query. Can anybody help Michael with his problem?
Cheers, Warren
----- Forwarded message from "Engel, Michael" -----
Dear Warren,
Could you please subscribe me to the TUHS mailing list?
I haven't worked with old Unix systems for quite some time, but I was appointed as a
Senior Lecturer at Leeds Beckett University (UK) two months ago and - to my big
surprise - I found an old Unix machine collecting dust in a corner..
The machine is a Codata 300, a Multibus-based system using a licensed clone of the
original Sun 100U CPU board and a number of additional Multibus controllers. The
machine seems to be complete, including two 8" SMD disks and a Cipher 9-track
tape drive, we also seem to have a set of replacement boards and the CPU board
manual (including schematics and code snippets explaining how to access the onboard
devices - some Codata documentation can also be found on bitkeeper).
We haven't tried to power up the machine yet (and, built around 1983, it certainly
needs
a close examination of the power supply and capacitors). From information on the net,
this machine runs a Unisoft port of 7th Edition Unix - similar to the Sun 1 machines and
probably a Whitesmiths C compiler (there's a Whitesmiths license badge attached to
the
case). Definitely a very interesting and probably quite rare machine and we would like
to revive it (and, if things go well, create a FPGA reimplementation of the system in
the context of a student design project).
Now, I would love to know more details about the implementation of 7th Edition Unix on
the 68000 and the use of the custom MMU built out of fast SRAM and TTL logic.
I do not think that source code to any of the various 68k 7th Edition ports produced by
Unisoft is available somewhere - do you know of a possible source?
Alternatively, do you think it would be worthwhile asking Unisoft for the source code or
do you know if anyone has tried this already? According to the Unisoft history web page
(http://www.unisoft.com/history.html), they still seem to know that they were porting Unix
30 years ago...
The only remotely related source code I could find in my archives is the A/UX 0.7 source
(SVR2, if I'm not mistaken), which probably already required a 68020 with 68851 MMU.
Best regards,
Michael Engel
----- End forwarded message -----
3 Oct
3 Oct
4:02 a.m.
I recently sent the following message to port-m68k(a)netbsd.org that relates to that period
in time:
Begin forwarded message:
From: Erik Fair <fair(a)netbsd.org>
Subject: DUAL Systems documentation
Date: February 22, 2014 at 02:12:17 PST
To: port-m68k(a)netbsd.org
For those of you of a historical or digital archeological bent: while googling for
something else, I came across this URL:
http://www.hartetechnologies.com/manuals/DUAL/
which contains PDFs of a few manuals & a price list from DUAL Systems of Berkeley,
CA. DUAL produced the very first mc68000-based UNIX system (V7 UNIX on the S-100
(IEEE-696) bus), starting in November of 1981. I worked there as a UNIX systems programmer
(kernel hacker) as my first job out of U.C. Berkeley from March 1983 to May 1985.
Of particular interest to this group: the CPU/MMU board manual. Please note: the mc68000
could not demand-page (i.e. no virtual memory) because the CPU did not save enough state
from a memory access fault to restart the faulted instruction, so UNIX was a swapping OS
(whole process in RAM, whole process out to swap area on disk if not enough RAM is
available for whatever else needed to run).
Motorola corrected the fault state save in the mc68010, which provided the ability to
make a proper VM system ... except for the mc68451 MMU (yes, a discrete MMU chip, in a
package every bit as big as the CPU) which had only 32 descriptor registers (translation
table entries). Motorola's theory was that if you wanted more (as one might for a
lots of smaller-sized pages), add more MMU chips to your CPU board. Unfortunately, that
doesn't fly on a board size as small as allowed by the S-100 standard. They were
working on a proper paged MMU (PMMU) chip to go along with the mc68020 (the first fully
32-bit (address & data) 68k family CPU), but it was very, very late (DUAL was moving
onto VMEbus from S-100 for the mc68020).
An aside, before Motorola shipped the mc68010, I saw another solution to the
faulted-instruction state save problem from MassComp: their CPU board had two mc68k CPUs
on it, one running a cycle behind the other, so a page fault would stop them both, the
missing page could be paged in (I think they designed their own MMU; long since
forgotten), and then execution resumed on the second, following CPU which hadn't
taken the memory-access fault. Throw hardware at the problem ...
faulting my way down memory lane,
Erik <fair(a)netbsd.org>
formerly {ihnp4,ucbvax,hplabs,decwrl,cbosgd,sun,nsc,apple,pyramid}!dual!fair
UniSoft Systems was started by Jeff Schriebman at the behest of Dual to port V7 UNIX to
Dual’s system; they were just a few blocks away from Dual in west Berkeley, on 6th Street,
if memory serves.
CoData was one of Dual’s competitors - I usually saw their gear at vendor shows (e.g. when
/usr/group held its vendor show co-located with USENIX conferences). One of the problems
at the time that bedeviled UniSoft was that every 68k-based Unix box had its own unique
MMU because Motorola’s offerings in that space (as noted above) were … lacking. So UniSoft
had to redo the kernel MMU code for every strange and wonderful MMU that each hardware
vendor came up with. Pixel, Plexus, Fortune, Codata, Apple (yes, UniSoft did a port of
Unix to the Lisa and the awful 5MB “profile” drive on a parallel port (!!)), ...
I have at least two old Dual boxes in my garage that I keep for sentimental reasons, but I
have no idea what’s on those disks, or if they’ll even spin up after so long. They’re
ST-506/419 interface 5.25 inch “winchester” drives; a forerunner of a sort of the IBM PC’s
IDE. I wrote the drivers for the Morrow Designs (“ThinkerToys”) S-100 controller as my
first project for Dual in March/April 1983.
Previously, Dual was using 8-inch Memorex hard drives controlled by a CompuPro (nee
“Godbout Electronics”) controller whose interface standard I don’t recall. I’ll have to
see if they can be fired up again, and see what’s on the hard drives. Dual was very
particular about using big, heavy linear power supplies in its systems as a matter of
reliability, over the (to their mind) squirrelly switching power supplies that many of our
competitors were using.
The other way to go to get Unix going on that old Codata box would be a port of
NetBSD/m68k - it supports a wide array of mc68k systems:
http://www.netbsd.org/ports/#ports-by-cpu
The trick would be writing the MMU code, and a booter that would work with whatever
firmware Codata used back in the day. I had to work on Dual’s boot firmware from time to
time, and I recall it being fairly simple (“find /unix and see if it’s a.out, load, and
jump”), and usually the trick is to make a secondary booter that the system firmware will
load (in whatever executable format the firmware will recognize) to then parse a modern
ELF kernel from FFSv2.
NetBSD continues to support a whole lot of pretty old hardware - we believe in
portability.
Erik <fair(a)netbsd.org>
3486
days inactive
3486
days old
1 comments
2 participants
participants (2)
-
Erik Fair -
Warren Toomey