16 Jan
2007
16 Jan
'07
7:59 p.m.
1) To prevent one process overwriting the memory
belonging to another
process.
Segments did not HAVE to be 64k, that was their maximum size, the
minimum
was 128 bytes.
2) To provide virtual memory.
3) To protect the executive from processes.
4) To allow non contiguous physical address space to appear as a
logical contiguous address space
5) To provide mapping out of faulty blocks of memory
and probably as many reasons I have not thought of off the top of my
head.
Consider the time this was introduced. It was a $5K personal
computer from 1982 whose base configuration was 2 floppies and no
hard disk. Just about any of the above was probably held to be
superfluous by most manufacturers in that context. 
16 Jan
16 Jan
8:51 p.m.
On 16 Jan 2007 at 19:59, Roger Holmes wrote:
Well OK 5k dollars is not much, but in January the
following year for
10k, Apple's Lisa had several of the above, though I have to admit I
have seen some spectacular crashes as it was possible to corrupt the
sound buffers and also to seriously derange the CRT scanning. The
compiler generated some strange code to 'touch' the new top of stack
on subroutine entry so the OS could allocate all the extra space in
one go rather than in little bits. One enterprising British software
house even got Unix running on a Lisa with the (then) optional 5MB
profile hard disk. It wasn't C.A.P. but one of the other big ones of
the time.
The reason I mention this is because around 1981 I was working with
early steppings of the 80286. Microsoft had most of the code for
Xenix ported, but for the kernel--which they pretty much left to
Intel. Oddly, the system in the lab we were working with for our
own software was an Onyx box running, I think, V7 on a Z8000.
Consider how long it was after 1981 that the 80286 on the PeeCee
platform was running virtual memory tasks.
Doubtless the folks at Olivetti knew about the Onyx box and decided
to take a more modest approach and create a desktop "Personal
Computer".
The Lisa sold for twice the price of an M20 and contained quite a bit
more hardware. Categorizing the memory management as "virtual" is
perhaps stretching a term. A Lisa program had to "advise" the 68K
that it was going to use a physical address (i.e. you couldn't just
invent an address and use any old instruction to access it--
instructions on a single-CPU 68K weren't restartable after a fault).
So perhaps the memory was a bit more than "real physical" and less
than "virtual".
As an interesting aside, the operation I was with at about the same
time as the Lisa was being trotted out was looking to expand a bit
and needed something to supplement the VAX 11/750 that was our
workhorse. Since we didn't need another 750, I lobbied for a 730,
but one of the other founders lobbied hard for a Plexus 68K box. I
recall meeting with the Plexus sales guy and hearing him tell me that
they were working on virtual memory for their System III port. I
called him a liar and said that the 68000 was incapable of true VM.
I lost the battle and our firm bought the Plexus. It was an
incredibly slow waste of money.
For the M20's price point and market positioning, I really think that
an MMU would have been a waste of resources--and could well have been
a budget-buster.
Cheers,
Chuck
17 Jan
17 Jan
3:03 a.m.
From: "Chuck Guzis" <cclist at
sydex.com>
---snip---
For the M20's price point and market positioning, I really think that
an MMU would have been a waste of resources--and could well have been
a budget-buster.
Cheers,
Chuck
Hi
For the purpose that I can see that Olivetti used a ROM, I think it
was the right choice. For the most part it was related to logical to
physical mapping. They used a portion of the physical memory for the
video memory. This was a 16K block for B/W but it required up to
3 blocks for color. They could configure for 2, 4 or 8 colors.
To do more than one color, required expansion memory cards with
parallel to serial registers to send the video information to the video
controller chip.
The ROM could be quickly setup with jumpers for what ever combination
of memory that was needed. This simplifies the need to have additional
software to configure the system.
They also use the ROM to create windows in memory that had the
data memory mapped different than the instruction memory. This
allowed the processor to access 128K while staying within a single
segment. For applications that ran in non-segmented mode, this
allows a better use of memory while taking advantage of the smaller
code size of non-segmented code.
While both of these could have been done with a MMU, it would have
been over kill for a desk top machine.
They did make some larger machines with Z8000's. I would guess that
because of the type of machine these were, they would be expected
to have MMU's. These were called the M30 and M40. I've only seen
a picture of the M30. It was a half height rack setup.
Dwight
_________________________________________________________________
Fixing up the home? Live Search can help
http://imagine-windowslive.com/search/kits/default.aspx?kit=improve&loc…
6:31 p.m.
New subject: Lisa (was Re: Olivetti M20)
Roger Holmes wrote:
Well OK
5k dollars is not much, but in January the following year for
10k, Apple's Lisa had several of the above, though I have to admit I
have seen some spectacular crashes as it was possible to corrupt the
sound buffers and also to seriously derange the CRT scanning. Erm, I'm not
sure how this is possible as the Lisa had no sound buffers
at all. All it had was a bunch of resistors hooked up to a latch in
order to act as a volume control for the VIA's shift register. It
beeped in the same way as the Commodore PET. That is by setting timer2
on the VIA and setting a value in the SR, then setting the ACR to loop
the data in the SR. There was no sound buffer, there was no way to play
anything other than beeps.
Nothing is available to the OS to derange the CRT scanning. All you can
do is enable interrupts on the vertical retrace, or disable said
interrupts, and you can also select which 32K of memory to use as the
framebuffer. That's it.
The compiler generated some strange code to
'touch' the new top of
stack on subroutine entry so the OS could allocate all the extra space
in one go rather than in little bits. One enterprising British
software house even got Unix running on a Lisa with the (then)
optional 5MB profile hard disk. It wasn't C.A.P. but one of the other
big ones of the time.
There were two. Microsoft/SCO Xenix, and UniPlus. I'd
love to get my
hands on UniPlus, but it seems to be rare. If this was something else,
it would be wonderful to get a copy of it.
I'm not sure what the strange code is about, I suspect something to do
with the MMU. If you'd access a page that wasn't mapped to your
process, the OS would either load it from disk, or allocate more MMU
pages to your process, thus getting more memory.
7:22 p.m.
New subject: Lisa (was Re: Olivetti M20)
Ray Arachelian wrote:
Roger Holmes wrote:
Lisa (and Macintosh) used the original 68000 which was not capable of
recovering from an arbitrary access (page) fault in the middle of an
instruction (the updated 68010 fixed this, but Apple never used it).
The 68000 did lot leave enough info on the fault stack to indicate
which memory access within an instruction faulted, and which registers
might have been auto-incremented/decremented.
On the Lisa all accesses to memory that was not previously known
to be memory resident used a probe instruction (a TST.W (A0), IIRC)
that only did one memory access and did not alter the registers.
Lisa was a segmented memory architecture, not demand paged, so the
overhead was not too great. Stack extension also used this probe IIRC.
The compiler generated some strange code to
'touch' the new top of
stack on subroutine entry so the OS could allocate all the extra space
in one go rather than in little bits. One enterprising British
software house even got Unix running on a Lisa with the (then)
optional 5MB profile hard disk. It wasn't C.A.P. but one of the other
big ones of the time.
There were two. Microsoft/SCO Xenix, and UniPlus. I'd
love to get my
hands on UniPlus, but it seems to be rare. If this was something else,
it would be wonderful to get a copy of it.
I'm not sure what the strange code is about, I suspect something to do
with the MMU. If you'd access a page that wasn't mapped to your
process, the OS would either load it from disk, or allocate more MMU
pages to your process, thus getting more memory.
7:57 p.m.
New subject: Lisa (was Re: Olivetti M20)
On 17 Jan 2007 at 11:22, Don North wrote:
Lisa (and Macintosh) used the original 68000 which was
not capable of
recovering from an arbitrary access (page) fault in the middle of an
instruction (the updated 68010 fixed this, but Apple never used it).
The 68000 did lot leave enough info on the fault stack to indicate
which memory access within an instruction faulted, and which registers
might have been auto-incremented/decremented.
Exactly why I said that calling the Lisa architecture "virtual
memory" is misleading at best. One could not write a loop to move 2
megabytes using a simple MOVEM/SUBQ/BNE loop as if all of the memory
were seamlessly continuous and present.
I remember trying to make a list of 68K instructions that could be
restarted, wondering if it might be possible to construct a useful
subset. One of the gotchas was that the bus error handling in the
68K gave you a P-counter that was only guaranteed to be "in the
vicinity" of the failing instruction. I gave up after awhile.
Of course, it wasn't necessary to implement virtual memory in
hardware. JRT Pascal did it--on floppy yet. (an interesting aspect
of an otherwise miserable product).
Cheers,
Chuck
On the Lisa all accesses to memory that was not previously known
to be memory resident used a probe instruction (a TST.W (A0), IIRC)
that only did one memory access and did not alter the registers.
Lisa was a segmented memory architecture, not demand paged, so the
overhead was not too great. Stack extension also used this probe IIRC.
18 Jan
18 Jan
6:55 a.m.
New subject: Lisa (was Re: Olivetti M20)
Chuck Guzis wrote:
On 17 Jan 2007 at 11:22, Don North wrote:
The Lisa memory architecture was
demand-segmented, not demand-paged.
It was virtual in the sense that one could pull segments off the disk
on demand, but the mechanism to do this was to use a specific instruction
that was know to be 'well behaved' when it faulted.
A few years earlier Apollo Computer came out with their first system
that employed a 68000 that implemented a full demand paged virtual
memory system. The trick they used was to have two separate 68000
processors, one for the user and the other to service page faults.
When it was determined that the user processor would fault, that
68000 was frozen mid-access, then the system 68000 would service the
fault, fix memory up, and then let the user 68000 continue. Actually
kind of an innovative approach at the time.
I remember going to a tech talk when Apollo came out of 'stealth mode'.
It was in the Wang Computer building in Lowell, MA (next to Chelmsford)
in the company cafeteria. The room was jammed to overflowing with DEC,
DG, Wang, etc engineers all wanting to see and hear how they did it.
Lisa (and Macintosh) used the original 68000
which was not capable of
recovering from an arbitrary access (page) fault in the middle of an
instruction (the updated 68010 fixed this, but Apple never used it).
The 68000 did lot leave enough info on the fault stack to indicate
which memory access within an instruction faulted, and which registers
might have been auto-incremented/decremented.
Exactly why I said that calling the Lisa architecture "virtual
memory" is misleading at best. One could not write a loop to move 2
megabytes using a simple MOVEM/SUBQ/BNE loop as if all of the memory
were seamlessly continuous and present.
I remember trying to make a list of 68K instructions that could be
restarted, wondering if it might be possible to construct a useful
subset. One of the gotchas was that the bus error handling in the
68K gave you a P-counter that was only guaranteed to be "in the
vicinity" of the failing instruction. I gave up after awhile.
8:15 a.m.
New subject: Lisa (was Re: Olivetti M20)
On 1/18/07, Don North <ak6dn at mindspring.com> wrote:
A few years earlier Apollo Computer came out with
their first system
that employed a 68000 that implemented a full demand paged virtual
memory system. The trick they used was to have two separate 68000
processors, one for the user and the other to service page faults.
When it was determined that the user processor would fault, that
68000 was frozen mid-access, then the system 68000 would service the
fault, fix memory up, and then let the user 68000 continue. Actually
kind of an innovative approach at the time.
I don't know who did it first, but in the mid-1980s, I worked with a
Perkin-Elmer workstation (can't recall the exact model number (7xxx?),
running System III, ISTR) with a similar coupled 68000 page fault
scheme.
It was not a new box in 1985 when I first saw it. One distinct
feature - it had several (10?) buttons built into the lower bezel on
the console CRT that were referred to as "soft function keys". There
was some way to twiddle the bottom line of text on the console to
"label" the buttons, but we never used them. We mostly used the box
as a C->68K assembler engine to feed a home-grown assembler to make
embedded product images, but that has nothing to do with page demand
VM. ;-)
The 68010 came out a short time later, making all this effort a
historical footnote.
-ethan
8:39 a.m.
New subject: Lisa (was Re: Olivetti M20)
On 17 Jan 2007 at 22:55, Don North wrote:
A few years earlier Apollo Computer came out with
their first system
that employed a 68000 that implemented a full demand paged virtual
memory system. The trick they used was to have two separate 68000
processors, one for the user and the other to service page faults.
When it was determined that the user processor would fault, that
68000 was frozen mid-access, then the system 68000 would service the
fault, fix memory up, and then let the user 68000 continue. Actually
kind of an innovative approach at the time.
I recall hearing about that. One 68K ran a clock or so ahead of the
other. Sort of like navigating in the dark by sending someone with a
rope tied around him a few paces ahead of you. If he drops into a
pit, you can pull him out, step around the pit and keep going. My
impression is that it was a fairly expensive way to do things, but
there weren't a lot of microprocessor CPUs that could handle VM at
the time.
Cheers,
Chuck
6566
days inactive
6568
days old
8 comments
6 participants
participants (6)
-
ak6dn＠mindspring.com -
cclist＠sydex.com -
dkelvey＠hotmail.com -
ethan.dicks＠gmail.com -
ray＠arachelian.com -
roger.holmes＠microspot.co.uk