I just found a project that has ported Unix V7 to a modern system, and
a search of my TUHS archives finds no previous mention of it:
V7/x86 - x86 port of UNIX V7
http://www.nordier.com/v7x86/index.html
V7/x86 on VirtualBox
http://www.nordier.com/articles/v7x86_vbox.html
The jwhois command identifies the host site as (possibly) located in
Durban, South Africa.
-------------------------------------------------------------------------------
- Nelson H. F. Beebe Tel: +1 801 581 5254 -
- University of Utah FAX: +1 801 581 4148 -
- Department of Mathematics, 110 LCB Internet e-mail: beebe(a)math.utah.edu -
- 155 S 1400 E RM 233 beebe(a)acm.org beebe(a)computer.org -
- Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------
Can’t help about that DEC-ism.
Do have these 2.
News from Xerox Corporation:
FOR IMMEDIATE RELEASE
XEROX ANNOUNCES HYPER-ETHERNET
SAN FRANCISCO, CA. Jan 7. 2010 - Xerox today announced Hyper-Ethernet their fourth
generation local area network. In addition to its ability to transmit text data and images, Hyper-
Ethernet enables the transmission of people. ”People transmission over Hyper-Ethernet" according
to Michael Liddle, V.P. of Office Systems. "will greatly reduce elevator congestion and eliminate the
need for video conferencing.“ Order taking for Hyper-Ethemet will begin next month. Installation
will start in Los Angeles in the Third Quarter.
In a related announcement. Wang Labs. headquartered in Hoboken. New Jersey, announced Super-
Hyper Wangnet their twelfth generation local area network. According to Freddie Wang, President
of Wang Labs. "Super-Hyper-Wangnet will not only transmit people over the Wangband, but will
also transmit furniture and buildings over the interconnect and utility bands. These additional
capabilities of Super-Hyper Wangnet are vital to the emerging office of the future." Order taking
for Super-Hyper-Wangnet will begin next month. Installation has already occurred worldwide.
IBM Corporation. who has been rumored to be about to announce a local area network since 1980,
was not available for comment.
xxx
Followed by
Digital Responds to Hyper-Ethernet
TEWKSBURY. MA. April 1. 2010 -- Digital Equipment announced today it's new DECnet Phase
XVIII Architecture. In response to recent Xerox and Wang improvements to Ethernet that provide
people and facility transportation across inter-node links DEC‘s latest DECnet provides these
capabilities as well as providing for the creation of virtual facilities and even countries. These
capabilities are provided by breakthroughs in communications technology that actually uses the
Ether as a communications media. Through the use of a new dedicated NANO-PDP-11/E99
gateway processor system, ETHERGATE, DECnet users can access anywhere in the Ethereal Plane.
This development obsoletes teleconferencing, since meeting groups can create their own common
conference rooms and cafeterias, thus resolving space, travel and dining problems. There may be a
few bugs left, as some of the dissenting DECnet Review Group members have not been seen since
the last meeting held in such a virtual conference facility.
This breakthrough was brought about by a team effort of the Distributed Systems‘ Software and
Hardware engineering teams in a effort to improve on their Tewksbury, Massachusetts facility. In a
compromise decision, Distributed Systems will maintain an ETHERGATE in TWOOO, but it will
connect directly to their new home somewhere in the Shire of their newly defined Middle Earth
reality. Despite some difficulties, the scenery, windows tax breaks, pool and racquetball courts
made the relocation go quite smoothly. Engineering Network topology will not change, as all
forwarding will be done by the TWOOO Ethereal Plane Router residing in the crater at the former
building site.
Utility packages such as Ethereal Person Transfer (EPT) and Ethereal Facility Transfer (EFT)
provide appropriate capabilities for casual users. Sophiscated users can create (SCREATE), access
(SOPEN), and delete (SNUKE) ethereal entities transparently from high level languages using the
Ethereal Management System (EMS) package and the Ethereal Access Protocol (EAP). An
ETHERTRIEVE utility for easy interactive use will be available shortly.
DECnet Phase XVIII follows on the success of the Phase XVI ability to access everyone‘s Digital
Professional wrist watch computer system. This lead to the current Phase XVII architecture, which
has routing capabilities that allow direct communications with the entire Earth population's Atari
home video games.
Distributed Systems architects are hard at work on the next phase of DECnet that will include
multi-plane existence network management (using the NIECE protocol) and galaxy level routing
using 64K bit addresses.
Digital will continue to support it's Gateway products into the Prime Material Plane. These
products include an IBM ANA (Acronym-based Network Architecture) Gateway, the TOLKIEN
product that allows control of all ring based networks, and our Mega-broad-jump-band hardware
which leaps past Wang's products in the hype weary business marketplace.
From our Engineering Net. (You can tell that they're really working on on it. Racquetball courts
indeed!)
David
> On Nov 17, 2016, at 6:00 PM, tuhs-request(a)minnie.tuhs.org wrote:
>
> Send TUHS mailing list submissions to
> tuhs(a)minnie.tuhs.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://minnie.tuhs.org/cgi-bin/mailman/listinfo/tuhs
> or, via email, send a message with subject or body 'help' to
> tuhs-request(a)minnie.tuhs.org
>
> You can reach the person managing the list at
> tuhs-owner(a)minnie.tuhs.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of TUHS digest..."
>
>
> Today's Topics:
>
> 1. OT: USENET article involving DEC machines and atomic tests
> (Dave Horsfall)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 18 Nov 2016 11:54:40 +1100 (EST)
> From: Dave Horsfall <dave(a)horsfall.org>
> To: The Eunuchs Hysterical Society <tuhs(a)tuhs.org>
> Subject: [TUHS] OT: USENET article involving DEC machines and atomic
> tests
> Message-ID: <alpine.BSF.2.11.1611181148020.19595(a)aneurin.horsfall.org>
> Content-Type: TEXT/PLAIN; charset=US-ASCII
>
> Hoping someone can help me here, as I've grepped the 'net to no avail.
>
> Back when USENET was supreme and dinosaurs strode the earth, there was a
> hilarious article involving a DEC box (long forgotten it) that was used to
> instrument underground atomic tests. In one scene, the box was atop a
> truck which was right over the hole; they both went skywards, but the data
> was recovered by taking out the core memory boards and plugging them into
> another box.
>
> Does anyone remember it? It does sound rather suss...
>
> --
> Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> TUHS mailing list
> TUHS(a)minnie.tuhs.org
> http://minnie.tuhs.org/cgi-bin/mailman/listinfo/tuhs
>
> ------------------------------
>
> End of TUHS Digest, Vol 12, Issue 5
> ***********************************
Hoping someone can help me here, as I've grepped the 'net to no avail.
Back when USENET was supreme and dinosaurs strode the earth, there was a
hilarious article involving a DEC box (long forgotten it) that was used to
instrument underground atomic tests. In one scene, the box was atop a
truck which was right over the hole; they both went skywards, but the data
was recovered by taking out the core memory boards and plugging them into
another box.
Does anyone remember it? It does sound rather suss...
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."
> From: Don North
> Track 0 is not used by standard DEC software
I wonder why DEC did't use track 0. The thing is small enough (256KB in the
original single-density) that even 1% is a good chunk to throw away. Does
anyone know? (I had a look online, but couldn't turn anything up.)
If I had to _guess_, one possibility would be that track 0 is the innermost
track, where the media is moving the slowest, and as a result it's more
error-prone. Another is that IBM used track 0 for something special, and DEC
tried to conform with that. But those are pure guesses, I would love to know
for sure.
Noel
> From: Don North <north(a)alum.mit.edu>
> .. the hardware bootstrap reads track 1 sectors 1, 3, 5, 7
Ah, thanks for that. Starting to look at the code, I had missed the
interleave.
So does DEC do anything with track 0, or is it always just empty?
Noel
So, I'm winding up to boot Unix V6 from an RX02 floppy. So I need two things:
- Details of how DEC ROM bootstraps boot from RX02's. I vaguely recall seeing
documentation of this somewhere (e.g. which sectors it loads, etc), but now I
can't find it. Don North has dumps of the RX02 ROM's, but I'm too lazy to read
through the code and figure out how they work. Is there some documentation
which covers it? I did a quick Google search, but if there is anything out
there, my Google-fu was inadequate.
- Did anyone ever do an RX02 driver for the V6 disk bootstrap? (Well, I guess
a V7 driver would work, too.) Note: what I need is _not_ either i) the Unix OS
driver for the RX02 (I found one of those already), or ii) a driver for the v7
standalone second-stage bootstrap (which would probably be in C). The thing
I'm looking for would be called rx.s, or something like that. Yes, I could
write it, but again, I'm lazy! :-)
Noel
> From: Jacob Goense <dugo(a)xs4all.nl>
> There is the issue with the non-existing man command.
My page on "Bringing up V6 Unix on the Ersatz-11 PDP-11 Emulator" has a
section on man:
http://mercury.lcs.mit.edu/~jnc/tech/V6Unix.html#man
It's pretty straight-forward.
Noel
So, in a fit of brain-fade, I originally sent this to the Classic Computers
list, when it was probably really more appropriate for this one. (Apologies to
those who are subscribed to both, and are thus seeing this again.)
So, I'm trying to do what VTServer was invented for - load Unix into an actual
PDP-11, over its serial line, when one doesn't have machine-readable Unix on
any mass storage for the machine.
However, all the initial code that VTServer loads ('mkfs', etc) is V7-specific
(V6 has a slightly different file system format) - and I want to install V6.
Has anyone ever tweaked the programs which VTServer loads to do V6-format
filesystems? I did a quick Google, but didn't see anything.
Another option is to do something more V6-like, and copy a small bootable V6
file-system image over the serial line; that may be an easier way to go.
No biggie if not, it won't be much work to adapt things, but I figured I'd try
to avoid re-inventing the wheel...
Note that the installation procedures for V6 and V7 are wholly different,
something which confused a number of people on CCTalk.
The 'Setting up Unix' documents are more checklists, they don't go into a lot
of detail as to what is actually happening, so I have prepared two pages on the
Computer History wiki:
http://gunkies.org/wiki/Installing_UNIX_Sixth_Editionhttp://gunkies.org/wiki/Installing_UNIX_Seventh_Edition
which go into more detail on what is actually happening.
Noel
> I'll start with getting VTServer to run under V6 (my only Unix, don't
> have anything later :-)
So, I just got VTServer runnin under V6: it successfully loaded a memory
diagnostic from the 'server', into the 'client', using 'vtboot' on the
latter. (Both running on emulated machines, for the moment - I thought I'd
take all the hardware-related variables out of the equation, until I have the
software all running OK.)
It didn't require as much work on VTServer as I thought it might: I had to
convert the C to the V6 dialect (no '+=', etc), and some other small things
(e.g. convert the TTY setup code), but in general, it was pretty smooth and
painless.
Note that it won't run under vanilla V6, which does not provide 8-bit input
and output on serial lines. I had previously added 'LITIN' and 'LITOUT' modes
(8-bit input and output) to my V6; since the mode word in stty/gtty was
already full, I had to extend the device interface to support them. I didn't
add ioctl() or anything later, I did an upward-compatible extension to
stty/gtty. (I'm a real NIH guy. :-)
My only real problem in getting VTServer running was with LITIN; I did it
some while back, but had never actually tested it (I was only using LITOUT,
for my custom program to talk to PDP-11 consoles, which also did downloads,
so needed 8-bit output). So when I went to use it, it didn't work, and it was
a real stumper! But I did eventually figure out what the problem was (after
writing a custom program to reach into the kernel and dump the entire state
of a serial line), and get it working.
(I had taken the shortcut of not fully understanding how the kernel serial
line code worked, just tried to install point fixes. This turned out not to
work, because of a side-effect elsewhere in the code. Moral of the story: you
can't change the operation of a piece of software without complete
understanding of how it works...)
Is there any interest in all this? If so, I can put together a web page with
the V6-verion VTServer source, along with the modified V6 serial line stuff
(including a short description of the extended stty/gtty interface), etc.
> so if you turn up whatever you used to boot V6, it would probably still
> be useful.
So I guess my next step, if I don't hear shortly from someone who has
previously used VTServer to install V6, is to start on actually getting
a V6 file system created.
I'm still vacillating over whether it would be better to go V6-style (and
just transfer a complete, small existing V6 filesystem), or V7-style (and
get stand-alone 'mkfs', etc running with V6-format file systems). Anyone
have an opinion?
Noel
> From: Clem Cole
> I miss my AAA
Well, I'm not sure I actually _miss_ mine (my old eyes prefer black on white),
but I definitely have fond memories of it. It was such a huge thing when I
finally managed to snag one to replace my (IIRC) VT52.
You could actually have three useful windows in Emacs!! And the detached
keyboard was definitely more ergonomic.
Noel
