3 Jul
2015
3 Jul
'15
7:54 p.m.
In the late 80?s, I bought from a surplus/junk shop a (by then somewhat obsolete) Unix
computer, branded UniSys, I think. It had 10 serial ports; one was the primary console,
one was intended for a printer, and the other 8 were regular user TTYs. The processor was
a 68000 (not 010, 020, or anything else), I don?t remember how much memory, and it had an
integral full-height hard drive as well (60 mB, maybe?).
When I say Unix, I mean real System-7 Unix ? not Linux or any other *nix. I thought it
was really a pretty neat system ? 8 (or 9) users and a printer, just perfect for a small
office ? or my apartment at the time, which had a terminal or two in every room. I
learned how to program in Unix on that machine, since it matched exactly the System 7
manuals I had. Sadly, time moved on, I got married, and got rid of a bunch of ?useless
junk?, like that computer.
Recently, I?ve been reminiscing and poking around some on the Web to try to find
information about it, but it seems to have vanished completely with nary a ripple. Has
anyone else stumbled across this unit, or at least have any knowledge of it? It was a
black case, about the size of a standard IBM-PC, with ten serial ports on the back and not
much else. I?d sure be interested to know where I might locate data about that unit, or
(gasp!) possibly even an existing one...
~~
Mark Moulding
3 Jul
3 Jul
7:59 p.m.
On 2015-07-04 01:54, mark at markesystems.com wrote:
In the late 80?s, I bought from a surplus/junk shop a
(by then somewhat obsolete) Unix computer, branded UniSys, I think. It had 10 serial
ports; one was the primary console, one was intended for a printer, and the other 8 were
regular user TTYs. The processor was a 68000 (not 010, 020, or anything else), I don?t
remember how much memory, and it had an integral full-height hard drive as well (60 mB,
maybe?).
When I say Unix, I mean real System-7 Unix ? not Linux or any other *nix. I thought it
was really a pretty neat system ? 8 (or 9) users and a printer, just perfect for a small
office ? or my apartment at the time, which had a terminal or two in every room. I
learned how to program in Unix on that machine, since it matched exactly the System 7
manuals I had. Sadly, time moved on, I got married, and got rid of a bunch of ?useless
junk?, like that computer.
Recently, I?ve been reminiscing and poking around some on the Web to try to find
information about it, but it seems to have vanished completely with nary a ripple. Has
anyone else stumbled across this unit, or at least have any knowledge of it? It was a
black case, about the size of a standard IBM-PC, with ten serial ports on the back and not
much else. I?d sure be interested to know where I might locate data about that unit, or
(gasp!) possibly even an existing one...
I find it hard to believe it was a plain 68K in there. That CPU have
some serious issues that makes it close to impossible to implement
virtual memory or proper usermode protection.
(Yes, it can be done, but the amount of hardware required means most did
not. I think SUN did it with their own MMU, and an extra CPU in there.
Trying to remember who else - I seem to remember one other company who
actually used a plain 68K, and it was not Unisys.)
Essentially, the 68010 is pretty much the minimum of processor needed to
make a sane system to run Unix on.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
8:01 p.m.
Wasn't it Apollo, that used a pair of 68000s in their very early systems?
Best,
Sean
On Fri, Jul 3, 2015 at 7:59 PM, Johnny Billquist <bqt at update.uu.se> wrote:
On 2015-07-04 01:54, mark at markesystems.com wrote:
In the late 80?s, I bought from a surplus/junk
shop a (by then somewhat
obsolete) Unix computer, branded UniSys, I think. It had 10 serial ports;
one was the primary console, one was intended for a printer, and the other
8 were regular user TTYs. The processor was a 68000 (not 010, 020, or
anything else), I don?t remember how much memory, and it had an integral
full-height hard drive as well (60 mB, maybe?).
When I say Unix, I mean real System-7 Unix ? not Linux or any other
*nix. I thought it was really a pretty neat system ? 8 (or 9) users and a
printer, just perfect for a small office ? or my apartment at the time,
which had a terminal or two in every room. I learned how to program in
Unix on that machine, since it matched exactly the System 7 manuals I had.
Sadly, time moved on, I got married, and got rid of a bunch of ?useless
junk?, like that computer.
Recently, I?ve been reminiscing and poking around some on the Web to try
to find information about it, but it seems to have vanished completely with
nary a ripple. Has anyone else stumbled across this unit, or at least have
any knowledge of it? It was a black case, about the size of a standard
IBM-PC, with ten serial ports on the back and not much else. I?d sure be
interested to know where I might locate data about that unit, or (gasp!)
possibly even an existing one...
I find it hard to believe it was a plain 68K in there. That CPU have some
serious issues that makes it close to impossible to implement virtual
memory or proper usermode protection.
(Yes, it can be done, but the amount of hardware required means most did
not. I think SUN did it with their own MMU, and an extra CPU in there.
Trying to remember who else - I seem to remember one other company who
actually used a plain 68K, and it was not Unisys.)
Essentially, the 68010 is pretty much the minimum of processor needed to
make a sane system to run Unix on.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
8:09 p.m.
On Jul 3, 2015 4:59 PM, "Johnny Billquist" <bqt at update.uu.se> wrote:
Apollo is the classic example of using plain 68K (two).
I find it hard to believe it was a plain 68K in there. That CPU have some
serious
issues that makes it close to impossible to implement virtual
memory or proper usermode protection.
(Yes, it can be done, but the amount of hardware
required means most did
not. I think SUN did it with their own MMU, and an extra CPU
in there.
Trying to remember who else - I seem to remember one other company who
actually used a plain 68K, and it was not Unisys.)
8:16 p.m.
On 2015-07-04 02:09, Glen Slick wrote:
On Jul 3, 2015 4:59 PM, "Johnny Billquist"
<bqt at update.uu.se> wrote:
Apollo is the classic example of using plain 68K (two).
Thanks. Yes, Apollo was the name I was searching for.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
I find it hard to believe it was a plain 68K in there. That CPU have some
serious
issues that makes it close to impossible to implement virtual
memory or proper usermode protection.
(Yes, it can be done, but the amount of hardware
required means most did
not. I think SUN did it with their own MMU, and an extra
CPU in there.
Trying to remember who else - I seem to remember one other company who
actually used a plain 68K, and it was not Unisys.)
10:11 p.m.
New subject: Paired 68000 systems - was Re: out-of-mainstream minis
On 2015-07-03 8:09 PM, Glen Slick wrote:
On Jul 3, 2015 4:59 PM, "Johnny Billquist"
<bqt at update.uu.se> wrote:
Apollo is the classic example of using plain 68K (two).
I always associate it with Tandem:
http://www.hpl.hp.com/techreports/tandem/TR-86.2.pdf
--Toby
I find it hard to believe it was a plain 68K in there. That CPU have some
serious
issues that makes it close to impossible to implement virtual
memory or proper usermode protection.
(Yes, it can be done, but the amount of hardware
required means most did
not. I think SUN did it with their own MMU, and an extra
CPU in there.
Trying to remember who else - I seem to remember one other company who
actually used a plain 68K, and it was not Unisys.)
11:13 p.m.
New subject: Paired 68000 systems - was Re: out-of-mainstream minis
On 07/03/2015 09:11 PM, Toby Thain wrote:
On 2015-07-03 8:09 PM, Glen Slick wrote:
Not sure what you are referring to, here. Tandem did not
use 68K processors as the main CPU
in any of their machines. (There could, possibly, have been
68Ks in some of the peripherals.)
They had their own 16-bit mini architecture, loosely based
on HP's stack oriented minis.
Jon
Apollo is the classic example of using plain 68K (two).
I always associate it with Tandem:
http://www.hpl.hp.com/techreports/tandem/TR-86.2.pdf
4 Jul
4 Jul
12:45 a.m.
New subject: Paired 68000 systems - was Re: out-of-mainstream minis
On 07/03/2015 08:13 PM, Jon Elson wrote:
With regard to the 68000 not being restartable after a trap for some
instructions such as MOVEM, didn't the Lisa guidelines avoid the problem
by avoiding the problem instructions?
I'm trying hard to remember--it's been a long time.
--Chuck
11:09 a.m.
New subject: Paired 68000 systems for fault tolerance - was Re: out-of-mainstream minis
On 2015-07-03 11:13 PM, Jon Elson wrote:
On 07/03/2015 09:11 PM, Toby Thain wrote:
Yes, you are right. The report gives some examples of dual 68000's in
Tandem's peripheral subsystems.
I likely was thinking of Stratus, because I remember reading this before:
http://pages.cs.wisc.edu/~david/papers/ibmsj1987_stratus.pdf
Also Sequioa, who also used two 68000's operating in lockstep, described
in P.A. Bernstein's paper that is comprehensively paywalled :(
--Toby
On 2015-07-03 8:09 PM, Glen Slick wrote:
Not sure what you are referring to, here. Tandem did not use 68K
processors as the main CPU
in any of their machines. (There could, possibly, have been 68Ks in
some of the peripherals.)
Apollo is the classic example of using plain 68K (two).
I always associate it with Tandem:
http://www.hpl.hp.com/techreports/tandem/TR-86.2.pdf
They had their own 16-bit mini architecture, loosely
based on HP's stack
oriented minis.
Jon
11:54 a.m.
New subject: Paired 68000 systems for fault tolerance - was Re: out-of-mainstream minis
On Sat, Jul 04, 2015 at 11:09:20AM -0400, Toby Thain wrote:
Yes, you are right. The report gives some examples of
dual 68000's in
Tandem's peripheral subsystems.
Later systems had dual 68302s in the Service Processors.
I know -- I maintained that code for a while :-)
mcl
noon
New subject: Paired 68000 systems for fault tolerance - was Re: out-of-mainstream minis
On 2015-07-04 17:09, Toby Thain wrote:
On 2015-07-03 11:13 PM, Jon Elson wrote:
Yup.
On 07/03/2015 09:11 PM, Toby Thain wrote:
Yes, you are right. The report gives some examples of dual 68000's in
Tandem's peripheral subsystems. On 2015-07-03 8:09 PM, Glen Slick wrote:
Not sure what you are referring to, here. Tandem did not use 68K
processors as the main CPU
in any of their machines. (There could, possibly, have been 68Ks in
some of the peripherals.)
Apollo is the classic example of using plain 68K (two).
I always associate it with Tandem:
http://www.hpl.hp.com/techreports/tandem/TR-86.2.pdf
I likely was thinking of Stratus, because I remember
reading this before:
http://pages.cs.wisc.edu/~david/papers/ibmsj1987_stratus.pdf
Unfortunately, that paper can slightly confuse you. They talk about
68000-family, and if you read on, you'll find that the "current" models
use the 68020...
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
12:29 p.m.
New subject: Paired 68000 systems for fault tolerance - was Re: out-of-mainstream minis
On 2015-07-04 12:00 PM, Johnny Billquist wrote:
On 2015-07-04 17:09, Toby Thain wrote:
...
Well, this being cctalk, it's just as interesting to discuss
"non-current" models?
I likely was thinking of Stratus, because I
remember reading this before:
http://pages.cs.wisc.edu/~david/papers/ibmsj1987_stratus.pdf
Unfortunately, that paper can slightly confuse you. They talk about
68000-family, and if you read on, you'll find that the "current" models
use the 68020... Also Sequioa, who also used two 68000's operating
in lockstep,
described in P.A. Bernstein's paper
Just after I hit send, I remembered something a friend told me about a
Sequioa installed in Moscow's first (?) credit card processing facility:
"it was constantly malfunctioning, but it was fault tolerant"
--Toby
Johnny
7:39 a.m.
New subject: Paired 68000 systems - was Re: out-of-mainstream minis
On 2015-07-04 04:11, Toby Thain wrote:
On 2015-07-03 8:09 PM, Glen Slick wrote:
Tandem have definitely done lots of funky stuff. The dual 68K designs
mentioned in that paper, though, is for lock stepped 68K in peripherial
controllers, to detect hardware errors. Thus, they are not running
something close to a "normal" operating system. In that environment
there are no problems with the 68K at all. The dual processor design in
Tandem is purely for the fault tolerance parts.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On Jul 3, 2015 4:59 PM, "Johnny
Billquist" <bqt at update.uu.se> wrote:
Apollo is the classic example of using plain 68K (two).
I always associate it with Tandem:
http://www.hpl.hp.com/techreports/tandem/TR-86.2.pdf
I find it hard to believe it was a plain 68K in there. That CPU have
some
serious issues that makes it close to impossible to implement virtual
memory or proper usermode protection.
(Yes, it can be done, but the amount of hardware
required means most did
not. I think SUN did it with their own MMU, and an extra
CPU in there.
Trying to remember who else - I seem to remember one other company who
actually used a plain 68K, and it was not Unisys.)
11:08 a.m.
On 07/03/2015 06:59 PM, Johnny Billquist wrote:
I find it hard to believe it was a plain 68K in there.
That CPU have some
serious issues that makes it close to impossible to implement virtual
memory or proper usermode protection.
(Yes, it can be done, but the amount of hardware required means most did
not. I think SUN did it with their own MMU, and an extra CPU in there.
Trying to remember who else - I seem to remember one other company who
actually used a plain 68K, and it was not Unisys.)
Essentially, the 68010 is pretty much the minimum of processor needed to
make a sane system to run Unix on.
I've got a few Torch boards which use a plain ol' m68k (either 8 or 10MHz
depending on the variant) and they were capable of running Uniplus+.
There's very little other logic on the boards, although they do have a
local Z80 (they were designed to run Torch's CP/M variant too), so I
suppose it's possible that could be employed somehow to provide the
necessary support for the m68k.
Jules
12:07 p.m.
On 2015-07-04 17:08, Jules Richardson wrote:
On 07/03/2015 06:59 PM, Johnny Billquist wrote:
How hard can it be to understand/believe that the 68000 cannot be used
without some serious hardware hacking? Not something most companies did.
The problems revolve around the fact that instructions cannot be
properly restarted on the 68000. Not enough context is saved. This in
turn means you cannot do demand paging, as that will cause a memory
exception trap, from which you cannot recover.
(The tricks done by those who did fix this consists of having a second
processor which gets interrupted when you get a page fault, and the
second processor do all the work related to the page fault, while the
primary processor just stalls until the memory is available, at which
point it can continue. There is no limits to how long the CPU can wait
for memory to return data on a read.)
Also, there is no MMU from Motorola for the 68000, so you would have to
design your own.
In addition, there is also a potential privilege escalation problem with
the 68K if I remember right. You always have full access to the whole
processor status word in that CPU. I can't remember what the scope of
that issue is. It might only be information leak, or it might be that
you can elevate yourself as well.
These problems were all addresses in the 68010.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
I find it hard to believe it was a plain 68K in
there. That CPU have some
serious issues that makes it close to impossible to implement virtual
memory or proper usermode protection.
(Yes, it can be done, but the amount of hardware required means most did
not. I think SUN did it with their own MMU, and an extra CPU in there.
Trying to remember who else - I seem to remember one other company who
actually used a plain 68K, and it was not Unisys.)
Essentially, the 68010 is pretty much the minimum of processor needed to
make a sane system to run Unix on.
I've got a few Torch boards which use a plain ol' m68k (either 8 or
10MHz depending on the variant) and they were capable of running Uniplus+.
There's very little other logic on the boards, although they do have a
local Z80 (they were designed to run Torch's CP/M variant too), so I
suppose it's possible that could be employed somehow to provide the
necessary support for the m68k.
7:20 p.m.
On 2015-07-04 18:14, tony duell wrote:
Sigh. I should learn to check things better. I thought it only was
usable with the 68010, but apparently you could also use it with the
68000. My fault.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
Also, there is no MMU from Motorola for the
68000, so you would have to
design your own.
What about the 68451? 
5 Jul
5 Jul
1:34 a.m.
Also, there is no MMU from Motorola for the 68000, so
you would have to
design your own.
What about the 68451? 
4 Jul
4 Jul
12:33 p.m.
The problems revolve around the fact that instructions
cannot be
properly restarted on the 68000. Not enough context is saved.
[...]
(The tricks done by those who did fix this consists of having a
second processor which gets interrupted when you get a page fault,
and the second processor do all the work related to the page fault,
while the primary processor just stalls until the memory is
available, at which point it can continue. There is no limits to how
long the CPU can wait for memory to return data on a read.)
I recall hearing of a company that build a machine with two 68000s, one
running one instruction behind the other. When the leading processor
got a page fault, hardware interrupted the lagging processor (which had
not yet encountered the faulting instruction) and there's a dance where
the two processors switch roles, allowing useful page faults.
Perhaps such a thing existed. Perhaps my informant was misled - it
sounds like a plausible corruption of what you describe. Perhaps my
own memory has bitrotted. But it sounds to me as though it certainly
_could_ work.
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML mouse at rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
12:42 p.m.
On Sat, Jul 04, 2015 at 12:33:05PM -0400, Mouse wrote:
Both Apollo and SUN did this. The clocks were two phase so one ran
behind the other. It was a hack.
--
- db at FreeBSD.org db at db.net http://www.db.net/~db
The problems
revolve around the fact that instructions cannot be
properly restarted on the 68000. Not enough context is saved.
[...]
(The tricks done by those who did fix this consists of having a
second processor which gets interrupted when you get a page fault,
and the second processor do all the work related to the page fault,
while the primary processor just stalls until the memory is
available, at which point it can continue. There is no limits to how
long the CPU can wait for memory to return data on a read.)
I recall hearing of a company that build a machine with two 68000s, one
running one instruction behind the other. When the leading processor
got a page fault, hardware interrupted the lagging processor (which had
not yet encountered the faulting instruction) and there's a dance where
the two processors switch roles, allowing useful page faults.
Perhaps such a thing existed. Perhaps my informant was misled - it
sounds like a plausible corruption of what you describe. Perhaps my
own memory has bitrotted. But it sounds to me as though it certainly
_could_ work.
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML mouse at rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
1:06 p.m.
On 07/04/2015 09:42 AM, Diane Bruce wrote:
Both Apollo and SUN did this. The clocks were two
phase so one ran
behind the other. It was a hack.
I don't remember when I first saw the 68000 in detail--perhaps it was at
a WESCON in the late 70s. My 68K manual is from that show and I took
some time to actually sit down and read the first couple of chapters at
the show. The mention of a supervisor mode and faulting on undefined
addresses (bus faults, actually) got me very excited and immediately
sent visions of virtual memory spinning.
I went back to the guy at the Motorola sales booth and asked him about
the prospect. He sighed and rolled his eyes a bit and said that I must
have been the hundredth person to ask about the subject that day. He
did his best to gently break it to me that not all instructions could be
restarted from a bus fault--the CPU simply didn't save enough
information to make that possible.
The following year, there were a number of Unix boxes being shown that
used the 68K, advertising that they were real competition for
traditional minis. Against my better judgment, it was decided that the
the system to supplement our VAX 11/750 setup would be a Plexus box.
That was a mistake, as I predicted. The box became the butt of jokes
about its lack of performance.
--Chuck
2:16 p.m.
On Sat, Jul 04, 2015 at 10:06:16AM -0700, Chuck Guzis wrote:
On 07/04/2015 09:42 AM, Diane Bruce wrote:
Sure, and the information they did push on the stack when they finally
added instruction continuation was pretty hefty. 68010 had that with
limited addressing (Which the MAC (ab)used).
Both Apollo and SUN did this. The clocks were two
phase so one ran
behind the other. It was a hack.
I don't remember when I first saw the 68000 in detail--perhaps it was at
a WESCON in the late 70s. My 68K manual is from that show and I took
some time to actually sit down and read the first couple of chapters at
the show. The mention of a supervisor mode and faulting on undefined
addresses (bus faults, actually) got me very excited and immediately
sent visions of virtual memory spinning.
I went back to the guy at the Motorola sales booth and asked him about
the prospect. He sighed and rolled his eyes a bit and said that I must
have been the hundredth person to ask about the subject that day. He
did his best to gently break it to me that not all instructions could be
restarted from a bus fault--the CPU simply didn't save enough
information to make that possible.
--Chuck
Diane
--
- db at FreeBSD.org db at db.net http://www.db.net/~db
4:04 p.m.
On 07/04/2015 11:16 AM, Diane Bruce wrote:
Sure, and the information they did push on the stack when they finally
added instruction continuation was pretty hefty. 68010 had that with
limited addressing (Which the MAC (ab)used).
I recall that I'd suggested to the guy at WESCON that a programmable
trap for user-mode instructions would be most valuable. The
instructions that raised Cain with virtual memory implementations could
be implemented with other, simpler, instructions--if only they could be
trapped before issue--and emulated by a bit of supervisor code.
He admitted that it was a good idea, but that the 68010 design was
already being tested, so it was unlikely to see my idea done.
Of course, today, with very few people programming in much at a lower
level than "C", the obvious solution would be never to generate the
problem instructions.
--Chuck
1:45 p.m.
On Sat, Jul 4, 2015 at 6:42 PM, Diane Bruce <db at db.net> wrote:
On Sat, Jul 04, 2015 at 12:33:05PM -0400, Mouse
wrote:
Both Apollo and SUN did this. The clocks were two phase so one ran
behind the other. It was a hack.
Sun did not do this. The Sun-1 CPU was indeed a 68000 to which was
coupled a custom MMU in discreet logic. It didn't handle demand
paging. Sun soon switched to the 68010.
-Jon
The
problems revolve around the fact that instructions cannot be
properly restarted on the 68000. Not enough context is saved.
[...]
(The tricks done by those who did fix this consists of having a
second processor which gets interrupted when you get a page fault,
and the second processor do all the work related to the page fault,
while the primary processor just stalls until the memory is
available, at which point it can continue. There is no limits to how
long the CPU can wait for memory to return data on a read.)
I recall hearing of a company that build a machine with two 68000s, one
running one instruction behind the other. When the leading processor
got a page fault, hardware interrupted the lagging processor (which had
not yet encountered the faulting instruction) and there's a dance where
the two processors switch roles, allowing useful page faults.
Perhaps such a thing existed. Perhaps my informant was misled - it
sounds like a plausible corruption of what you describe. Perhaps my
own memory has bitrotted. But it sounds to me as though it certainly
_could_ work.
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML mouse at rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
12:43 p.m.
I've heard of that design too. It was back in the late 70'r or early 80's.
A quick search leads to Apollo, but I seem to recall others trying the
same. Onyx and Dual systems come to mind.
https://en.wikipedia.org/wiki/Apollo_Computer
On Sat, Jul 4, 2015 at 12:33 PM, Mouse <mouse at rodents-montreal.org> wrote:
The problems
revolve around the fact that instructions cannot be
properly restarted on the 68000. Not enough context is saved.
[...]
(The tricks done by those who did fix this consists of having a
second processor which gets interrupted when you get a page fault,
and the second processor do all the work related to the page fault,
while the primary processor just stalls until the memory is
available, at which point it can continue. There is no limits to how
long the CPU can wait for memory to return data on a read.)
I recall hearing of a company that build a machine with two 68000s, one
running one instruction behind the other. When the leading processor
got a page fault, hardware interrupted the lagging processor (which had
not yet encountered the faulting instruction) and there's a dance where
the two processors switch roles, allowing useful page faults.
Perhaps such a thing existed. Perhaps my informant was misled - it
sounds like a plausible corruption of what you describe. Perhaps my
own memory has bitrotted. But it sounds to me as though it certainly
_could_ work.
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML mouse at rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
3:43 p.m.
Mouse wrote:
I recall hearing of a company that build a machine
with two 68000s,
one
running one instruction behind the other. When the
leading processor
got a
page fault, hardware interrupted the lagging processor
(which had not
yet
encountered the faulting instruction) and there's
a dance where the
two
processors switch roles, allowing useful page faults.
I think Wicat Systems did this in their System 100 (early Unix
workstation) machines.
I very clearly remember that Tektronix got one of these systems for
evaluation back in the day when I worked there.
I went to a presentation when the machine was brought in by the local
distributor, and the presentation mentioned that there were two Motorola
68000 microprocessors in it "to make it more powerful" or some such
marketing BS.
When the Microprocessor Development Group got its hands on the machine,
immediately it was opened up, and on the CPU board were indeed two
Motorola 68000 chips sitting side-by-side. Some reverse-engineering was
done, and it was determined that these two CPUs worked together in some
way to provide way to provide demand paging.
We got lots of early Unix workstations for evaluation back in those
days. I remember the Wicat quite vividly, and I'm pretty sure this
was the machine, but it's possible it was some other Unix workstation
machine.
-Rick
7:26 p.m.
On 2015-07-04 18:33, Mouse wrote:
I've heard that one too, but I have never found any reliable information
about such a system, so I suspect it might just be a corruption of the
design with a second CPU taking handling page faults and stalling the
primary processor.
The problem with having a second CPU shadowing the first one are plenty.
First of all, not all instructions are the same number of cycles, making
it really hard to actually stay one instruction behind. Second, since
many operations depends on content in memory, this would require the
second CPU to see the same memory content as the first CPU, which means
any changes done by the first CPU in the last instruction must not be
allowed to be visible to the second CPU. Third, any modifications of
memory by the second CPU must actually not happen, or else you might
modify memory in ways not intended. However, as soon as you hit an error
in the primary CPU, from which it cannot recover, the secondary CPU
suddenly must be allowed to actually change state and modify memory, and
any relationship to the primary CPU cease. I honestly cannot see how you
would actually implement this.
Having the primary CPU just stall, and have the second CPU normally just
be idle until a page fault happens on the other hand is something I can
see how it could be done.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
The problems
revolve around the fact that instructions cannot be
properly restarted on the 68000. Not enough context is saved.
[...]
(The tricks done by those who did fix this consists of having a
second processor which gets interrupted when you get a page fault,
and the second processor do all the work related to the page fault,
while the primary processor just stalls until the memory is
available, at which point it can continue. There is no limits to how
long the CPU can wait for memory to return data on a read.)
I recall hearing of a company that build a machine with two 68000s, one
running one instruction behind the other. When the leading processor
got a page fault, hardware interrupted the lagging processor (which had
not yet encountered the faulting instruction) and there's a dance where
the two processors switch roles, allowing useful page faults.
Perhaps such a thing existed. Perhaps my informant was misled - it
sounds like a plausible corruption of what you describe. Perhaps my
own memory has bitrotted. But it sounds to me as though it certainly
_could_ work. 
2:58 p.m.
The problems revolve around the fact that instructions
cannot be
properly restarted on the 68000. Not enough context is saved. This in
turn means you cannot do demand paging, a that will cause a memory
exception trap, from which you cannot recover.
True, but IIRC the OP was talking about a system that ran 7th Edition
UNIX, and 7th Edition didn't do demand paging. As long as you treat
it more like a big PDP-11 rather than a small VAX, you can write a
perfectly usable OS for a straight 68000.
Remember that it's only a problem on bus error and address error
interrupts. External interrupts, like a clock interrupt used for time
sharing, don't get handled until after the current instruction is
complete. Therefore, there's no need for instruction restarting.
It was the extension of the exception stack frame in the 68010
for the group 0 exceptions that made it practical to support demand
loading for the full instruction set. The stack frames for group 1
and 2 exceptions didn't change substantially.
Also, there is no MMU from Motorola for the 68000, so
you would
have to design your own.
There was the 68451, but you rarely saw those in the wild. Not
having ever had to make the design decision of whether to use
one, I can't really say whether the lack of design-in was primarily
a function of cost or of speed.
As far as designing your own goes, that's quite easy to do as long
as you're not trying to do a large number of small pages with the
capacity to recover from a page fault. Simple relocation and
protection with a modest number of pages can be done with just
a handful of latches and multiplexers. I recently did a small MMU
for a 6809 that mapped 128K of physical memory into the lower
48K of the address space in the form of mapping 8-16K pages
into 3-16K page frames. It just took 9 otherwise unused pins on
a parallel port and a pair of 74153s. Things don't start getting
particularly complicated until you start talking about putting page
tables in main memory and requiring a TLB.
In addition, there is also a potential privilege
escalation problem with
the 68K if I remember right. You always have full access to the
whole processor status word in that CPU. I can't remember what
the scope of that issue is. It might only be information leak, or it
might be that you can elevate yourself as well.
It's only a leak. The move to sr and other sr modifying instructions
were privileged on all members of the family. However, the move
from sr was not privileged in the 68000, but was on the
68010. Plus
what got leaked didn't amount to much. The system byte of the
status register only had the interrupt mask, the supervisor state bit
and the trace mode bit.
BLS
7:33 p.m.
On 2015-07-04 20:58, Brian L. Stuart wrote:
Ok. I didn't know it was some version of 7th ed. I didn't even know that
managed to get much beyond the PDP-11.
Anyway, it's sad, because the PDP-11 hardware can easily handle demand
paged memory. It's just that no one really found it worth the effort to
implement it when you only have 8 pages, and have way more physical
memory than the virtual memory space can address.
Yes. SUN did their own MMU, which if I understand things right, were
much more sane than the 68451.
Thanks. I was trying to remember which, but my brain failed me.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
The problems
revolve around the fact that instructions cannot be
properly restarted on the 68000. Not enough context is saved. This in
turn means you cannot do demand paging, a that will cause a memory
exception trap, from which you cannot recover.
True, but IIRC the OP was talking about a system that ran 7th Edition
UNIX, and 7th Edition didn't do demand paging. As long as you treat
it more like a big PDP-11 rather than a small VAX, you can write a
perfectly usable OS for a straight 68000. Remember that it's only a problem on bus error and
address error
interrupts. External interrupts, like a clock interrupt used for time
sharing, don't get handled until after the current instruction is
complete. Therefore, there's no need for instruction restarting.
It was the extension of the exception stack frame in the 68010
for the group 0 exceptions that made it practical to support demand
loading for the full instruction set. The stack frames for group 1
and 2 exceptions didn't change substantially.
Yes. Essentially traps which can happen in the middle of instructions.
Also, there is
no MMU from Motorola for the 68000, so you would
have to design your own.
There was the 68451, but you rarely saw those in the wild. Not
having ever had to make the design decision of whether to use
one, I can't really say whether the lack of design-in was primarily
a function of cost or of speed.
As far as designing your own goes, that's quite easy to do as long
as you're not trying to do a large number of small pages with the
capacity to recover from a page fault. Simple relocation and
protection with a modest number of pages can be done with just
a handful of latches and multiplexers. I recently did a small MMU
for a 6809 that mapped 128K of physical memory into the lower
48K of the address space in the form of mapping 8-16K pages
into 3-16K page frames. It just took 9 otherwise unused pins on
a parallel port and a pair of 74153s. Things don't start getting
particularly complicated until you start talking about putting page
tables in main memory and requiring a TLB. In addition,
there is also a potential privilege escalation problem with
the 68K if I remember right. You always have full access to the
whole processor status word in that CPU. I can't remember what
the scope of that issue is. It might only be information leak, or it
might be that you can elevate yourself as well.
It's only a leak. The move to sr and other sr modifying instructions
were privileged on all members of the family. However, the move
from sr was not privileged in the 68000, but was on the 68010. Plus
what got leaked didn't amount to much. The system byte of the
status register only had the interrupt mask, the supervisor state bit
and the trace mode bit.
9:09 p.m.
Ok. I didn't know it was some version of 7th ed. I
didn't even know that
managed to get much beyond the PDP-11.
At least that's the way I read the original message. And there were
a number of re-implementations/clones of 7th ed.
Anyway, it's sad, because the PDP-11 hardware can
easily
handle demand paged memory. It's just that no one really
found it worth the effort to implement it when you only have
8 pages, and have way more physical memory than the
virtual memory space can address.
It turns out that at one time, there was an experimental version
of UNIX at the labs that did do demand paging on an 11. They
didn't continue that line of development because it didn't end
up giving any significant benefits but ran slower than a swapping
based approach.
It's only
a leak.? ...
Thanks. I was trying to remember which, but my brain failed me.
5 Jul
5 Jul
6:46 a.m.
On 2015-07-05 03:09, Brian L. Stuart wrote:
Fair enough. And yeah. if you're not doing demand paging, a 68000 should
be enough.
Not surprised.
It is a result of the same thing. Demand paging always has a cost.
Already having all the pages in memory all the time should (obviously)
be better, and with a PDP-11 that is easily accomplished just because
there are only 8 pages, and you have plenty of physical memory compared
to virtual anyway.
Funnily enough, we are almost moving back to a similar situation today,
where people are starting to run systems without any swap space, to
reduce paging. Paging is still there for unmodified pages, though. So
not totally the same thing. But the reason it has become fashionable is
partly because you in many cases now have systems with so much physical
memory that you can do it.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
Ok. I
didn't know it was some version of 7th ed. I didn't even know that
managed to get much beyond the PDP-11.
At least that's the way I read the original message. And there were
a number of re-implementations/clones of 7th ed. Anyway,
it's sad, because the PDP-11 hardware can easily
handle demand paged memory. It's just that no one really
found it worth the effort to implement it when you only have
8 pages, and have way more physical memory than the
virtual memory space can address.
It turns out that at one time, there was an experimental version
of UNIX at the labs that did do demand paging on an 11. They
didn't continue that line of development because it didn't end
up giving any significant benefits but ran slower than a swapping
based approach. 
6 Jul
6 Jul
12:37 p.m.
On Sun, 5 Jul 2015, Johnny Billquist wrote:
The original message referred to Unix System 7 which I don't think exists so
I assumed the reference was to Unix Version 7. Xenix was Unix V7 and it ran
on all kinds of stiff including the 68000 in the TRS-80 Model 16 which Radio
Shack licensed from Microsoft who licensed it from Bell.
I found this thread peculiar from the beginning since Unix V7 was commonly
available on the 8086, the 68000, etc. under the Xenix label.
--
Richard Loken VE6BSV, Unix System Administrator : "Anybody can be a father
Athabasca University : but you have to earn
Athabasca, Alberta Canada : the title of 'daddy'"
** richardlo at admin.athabascau.ca ** : - Lynn Johnston
True, but IIRC
the OP was talking about a system that ran 7th Edition
UNIX, and 7th Edition didn't do demand paging. As long as you treat
it more like a big PDP-11 rather than a small VAX, you can write a
perfectly usable OS for a straight 68000.
Ok. I didn't know it was some version of 7th ed. I didn't even know that
managed to get much beyond the PDP-11. 
4 Jul
4 Jul
3:11 p.m.
On Jul 3, 2015, at 7:59 PM, Johnny Billquist <bqt
at update.uu.se> wrote:
...
I find it hard to believe it was a plain 68K in there. That CPU have some serious issues
that makes it close to impossible to implement virtual memory or proper usermode
protection.
True, but Apollo did it anyway. I heard a rumor they used two 68k chips, one running one
cycle behind the other. Don?t know if that?s true. Needless to say, as soon as the 68010
(or 68008?) showed up they switched.
paul
8:41 a.m.
On 07/03/2015 06:54 PM, mark at markesystems.com wrote:
In the late 80?s, I bought from a surplus/junk shop a
(by then somewhat
obsolete) Unix computer, branded UniSys, I think. It had 10 serial
ports; one was the primary console, one was intended for a printer, and
the other 8 were regular user TTYs. The processor was a 68000 (not 010,
020, or anything else), I don?t remember how much memory, and it had an
integral full-height hard drive as well (60 mB, maybe?).
When I say Unix, I mean real System-7 Unix ? not Linux or any other
*nix. I thought it was really a pretty neat system ? 8 (or 9) users and
a printer, just perfect for a small office ? or my apartment at the
time, which had a terminal or two in every room. I learned how to
program in Unix on that machine, since it matched exactly the System 7
manuals I had. Sadly, time moved on, I got married, and got rid of a
bunch of ?useless junk?, like that computer.
Recently, I?ve been reminiscing and poking around some on the Web to try
to find information about it, but it seems to have vanished completely
with nary a ripple. Has anyone else stumbled across this unit, or at
least have any knowledge of it? It was a black case, about the size of
a standard IBM-PC, with ten serial ports on the back and not much else.
I?d sure be interested to know where I might locate data about that
unit, or (gasp!) possibly even an existing one... ~~ Mark Moulding
Hmm, you could try and get hold of an NCR Tower machine; I've seen those
re-branded as Unisys, and the older ones have a configuration similar to
what you describe ('010 rather than plain 68k, ram boards were 8MB each I
think, FH ST506/412-type drive, serial for console and local printer, then
serial boards each capable of supporting 8 ttys). The cases are different -
cream, tall, narrow and floor-standing rather than a black desktop, but the
user experience would be the same.
Around 1991 I acquired a Tower 32/700, which was one of the later machines
in the line from around 1987 or so - '040 CPU, dual SCSI disks, Ethernet,
32MB of ECC battery-backed RAM and 16 serial lines. Multibus for everything
apart from the RAM. OS was SVR3, IIRC. Very nice machine, with lots of
support logic to keep the performance high (I seem to remember several
m68k-family and x86-family CPUs on the various cards) - even if the OS was
a little quirky.
cheers
Jules
3291
days inactive
3294
days old
33 comments
18 participants
participants (18)
-
ard＠p850ug1.demon.co.uk -
blstuart＠bellsouth.net -
bqt＠update.uu.se -
cclist＠sydex.com -
db＠db.net -
elson＠pico-systems.com -
glen.slick＠gmail.com -
jlo＠ludd.ltu.se -
jules.richardson99＠gmail.com -
linimon＠lonesome.com -
mark＠markesystems.com -
mouse＠Rodents-Montreal.ORG -
paulkoning＠comcast.net -
richardlo＠admin.athabascau.ca -
rickb＠bensene.com -
scaron＠umich.edu -
toby＠telegraphics.com.au -
tony.aiuto＠gmail.com