There was a well known ftp site in the early 1990s called
simtel20.army.mil. It was mostly known as a repository for ms-dos
utilities, but it also had a collection of source code to various
user-contributed unix utilities. I just uploaded those to the Internet
Archive: https://archive.org/details/oak-unix-c--full-mirror-1999.12.14
So in working on an unrelated 6502 project, I got to wondering about UNIX on it and other 8-bits. Did some Googling, and while I was able to turn up some attempts at UNIX-likes on 6502 as well as Z80, the only one I found that might have some Bell connection is "uNIX" as documented here: https://bitsavers.org/pdf/uNIX/uNIX_Jan82.pdf
A forum post I read suggested those involved were some former Bell folks from NJ. In any case, this begs the question for me: Were there ever any serious attempts at an 8-bit UNIX in the labs or Bell System at large? Certainly it would've provided quite the challenge without much return compared with 16 and 32-bit efforts, but does anyone know if, say, an LSX/Mini-UNIX-ish attempt was ever made at the 6502, Z80, or other 8-bits? Thanks all!
- Matt G.
Hi,
I am trying to use the 'dump' program but it references rmt1.
My system only has rmt0. I have been unable to find how to
create this device. I have looked over the reference material
but it only references rmt0.
Is there any way to redirect a dump to use rmt0?
Any help is appreciated.
# ls -l
total 4
drwxr-xr-x 2 root 336 Mar 1 16:56 .
drwxr-xr-x 8 root 288 Feb 21 17:18 ..
crw--w--w- 1 root 0, 0 Mar 2 07:47 console
crw-r--r-- 1 bin 8, 1 Jan 10 1979 kmem
-rw-rw-r-- 1 bin 775 Jan 10 1979 makefile
crw-r--r-- 1 bin 8, 0 Jan 10 1979 mem
*brw-rw-rw- 1 root 3, 0 Mar 1 20:42 mt0*
crw-rw-rw- 1 root 12,128 Dec 31 1969 nrmt0
crw-rw-rw- 1 bin 8, 2 Dec 31 1969 null
*crw-rw-rw- 1 root 12, 0 Feb 23 15:55 rmt0*
brw-r--r-- 1 root 6, 0 Mar 2 07:47 rp0
brw-r--r-- 1 root 6, 15 Dec 31 1969 rp3
crw-r--r-- 1 root 14, 0 Dec 31 1969 rrp0
crw-r--r-- 1 root 14, 15 Dec 31 1969 rrp3
brw-r--r-- 1 root 6, 1 Dec 31 1969 swap
crw-rw-rw- 1 bin 17, 0 Mar 1 19:39 tty
crw--w--w- 1 root 3, 0 Mar 1 19:41 tty00
crw--w--w- 1 root 3, 1 Feb 23 16:47 tty01
crw--w--w- 1 root 3, 2 Feb 21 16:56 tty02
crw--w--w- 1 root 3, 3 Feb 21 16:56 tty03
Not only that but when attempting to use dump it creates
a file and consumes all the space on rp0
In dev it creates:
-rw-rw-r-- 1 root 174080 Mar 2 09:20 rmt1
Sample run:
# dump
date = Thu Mar 2 09:20:16 2023
dump date = the epoch
dumping /dev/rrp3 to */dev/rmt1*
I
II
estimated 24870 tape blocks on 0 tape(s)
III
IV
*no space on dev 6/0*
no space on dev 6/0
no space on dev 6/0
no space on dev 6/0
Thanks,
Ken
--
WWL 📚
> This one, perhaps:
> https://patents.google.com/patent/US3964059A/en
Yes, that's the Typo patent. Notice that it features "method and
apparatus". The bizarre idea of doing it in hardware was a figment of
the patent department's imagination. This was a dance to circumvent
the belief at the time that software could not be patented. Software
was smuggled in by stating that it was one way to realize the
apparatus in the patent disclosure.
The now obsolete belief was fallout from Gottsschalk v Benson, in
which the Supreme Court invalidated another Bell Labs patent, on a
trick to save a few cycles in converting integers between BCD and
binary. The grounds for rejection were roughly that software was math
(a "mental step") and therefore not patentable.
The Benson decision, written by William O. Douglas, makes ludicrous
reading: it argues, though the patent does not claim, that a patent on
this narrow method could be enforced against any program that converts
BCD to binary. Apparently Douglas thought that all black-box programs
for a given purpose were the same, although the patent office did not
so conflate different mechanical or electrical apparatuses that have a
common purpose.
Doug
> I am having a problem clearing a dup inode.
V6 had almost no tools for automagically fixing file system corruption.
To do it, you need to i) understand how the FS works (see:
https://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/man/man5/fs.5
but it's pretty simple); ii) understand what the few tools (dcheck; icheck;
clri) do; iii) dive in.
I recall I used to use 'adb' a lot, to manually patch things when there was a
problem, so you'll want to study up on the 'db' syntax (no 'adb' in vanilla
V6, but for this, they are basically equivalent):
https://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/man/man1/db.1
You'll have to use the non-raw version of the device (the raw version can only
read/write complete blocks), and then judiciously use 'sync' to flush the
updated blocks out to the 'physical' disk. (There are some corner cases where
data is stored elsewhere, such as when one is patching the inode of an open
file, but I'm going to ignore them.)
> # icheck -s /dev/rp0
'icheck -s' only rebuilds the free list; it doesn't help with any other error
(e.g. a block being assigned to two different files).
> 4244 dup; inode=323
Which is probably what is happening here. 'icheck':
https://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/man/man8/icheck.8
is not telling you what _else_ is using that block, because it has already
forgotten that by the time it discovers this second claimant (it only keeps a
bit array of 'used' blocks).
> # icheck -b 323 /dev/rp0
Err, you wanted to say 'icheck -b 4244' to find out who else was using block
4244.
I'm not sure if 'fsck' would fix these; I have a V6 one, if anyone wants it.
The 'easy' way to fix this is i) copy the second file to somewhere else, ii)
delete the original, iii) re-build the free list (because the duplicate block
will now be in both the first file, and the free list), iv) examine both files,
and see which one has the smashed contents.
I'll turn this into a 'Fixing damaged V5/V6 file systems' article on the
CHWiki.
Noel
I think discussion of early Linux is in scope for this list, after all that is 30 years ago. Warren, if that is a mis-assumption please slap my wrist.
Following on from the recent discussion of early workstations and windowing systems, I’m wondering about early windowing on Linux. I only discovered Linux in the later nineties (Red Hat 4.x I think), and by that time Linux already seemed to have settled on Xfree86. At that time svgalib was still around but already abandoned.
By 1993 even student class PC hardware already outperformed the workstations of the early/mid eighties, memory was much more abundant and pixels were no longer bits but bytes (making drawing easier). Also, early Linux was (I think) more local machine oriented, not LAN oriented. Maybe a different system than X would have made sense.
In short, I could imagine a frame buffer device and a compositor for top-level windows (a trail that had been pioneered by Oriel half a decade before), a declarative widget set inspired by the contemporary early browsers and the earlier NeWS, etc. Yet nothing like that happened as far as I know. I vaguely recall an OS from the late 90’s that mixed Linux with a partly in-kernel GUI called “Berlin” or something like that, but I cannot find any trace of that today, so maybe I misremember.
So here are a few things that I am interested in and folks on this list might remember:
- were there any window systems popular on early Linux other than X?
- was there any discussion of alternatives to X?
- was there any discussion of what kernel support for graphics was appropriate?
> From: KenUnix
> things are missing:
> Undefined:
> _setexit
> _reset
> _seek
> _alloc
> _end
> Yes, I am trying to compile it on Unix v7.
Well, there's your answer. They are all in the V6 library. Here's
the source for setexit/reset:
https://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/source/s5/reset.s
You do realize that if you got it compiled under V7 and ran it, it would
trash the disk, right? (The V6 and V7 filesystems are different; very
similar, but block nubers are 16 bits on V6, ans 32 bits on V7.)
> Is there a makefile?
No. No 'make' in V6. Which is why you find those 'run' shell files:
https://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/source/s4/run
everywhere.
> From: John Cowan
> It was an update/rewrite of the MIT version.
Which one? There were two: "MIT's AI Lab", by CSTACY, Alan Wecsler, and me;
which Rob Austein re-wrote into "Alice's PDP-10". I thought the original was
centered around ITS, but my memory was poor (hey, it has been ~40 years :-),
it seems to sort of be about LISP Machines. Rob's version was about TWENEX
(yech). The original was written in 926, MOON's office; I can't believe he
put up with me hanging out there!
>> Although I like the old story about the person at their oral exam and
>> the Coke bottle in the window.
> Details?
So they're giving someone an oral exam. They can't make up their minds, or
something, and they ask the person to step out for a second. When the person
comes back in, they point to a Coke bottle sitting on a window-sill in the
sunlight, and ask them to examine it. The person notices that it's warm on
one side - the side facing the window. 'Why that side?', they ask. So the
person goes into a long explanation about how the curved glass must have
focused the light, yadda-yadda. WRONG! They turned it around while the
person was out of the room. I think that the person fails their oral. I
have no idea if it's a true story.
Steve Ward told another oral story which I'm pretty sure _is_ true, though.
They ask the candidate to design a state machine (or digital logic, I forget
which) which can tell if a number is divisible by three (I think I have the
details correct, but I'm not absolutely certain). So they describe one - and
then point out that you can feed the number in from either end (most or least
significant end first) - and proves that it will work either way! The
committee was blown away.
Noel
> I'm not sure if 'fsck' would fix these
Turns out it was called 'fcheck' when we had it.
> I have a V6 one
I'd already put it on my Web site, here:
http://ana-3.lcs.mit.edu/~jnc/tech/unix/s1/fcheck.c
if anyone wants it.
> From: "Ron Natalie"
> You had adb?
Yeah, MIT had a lot of stuff that 'fell off the back of a truck' (including
things like the circuit design tools, etc). Well, having an undergrad who was
in the famous Boy Scout troop at Bell helped... :-)
> From: KenUnix <ken.unix.guy(a)gmail.com>
> What I finally did was restore the ".disk" files from a previous backup
You may sit with Arlo Guthrie on the 'Windows user' bench. :-)
> From: "Theodore Ts'o"
> some have argued that if someone doesn't do backups of their research
> data, maybe they don't *deserve* to get their Ph.D. :-)
'Think of it as evolution in action.'
Although I like the old story about the person at their oral exam and
the Coke bottle in the window.
Noel
