Hi folks,
Anyone got some spare Kickstart ROMs for an Amiga 4000? I'm doing an
exhibition in a couple of weeks time and completely forgot my A4000 is
only on KS 3.0! I have OS3.5 ready to install.
I also picked the wrong time to give away my DEC 3000-300s since the
one I kept blew up this afternoon, fortunately we have spares for that
at work I can 'borrow' :)
Cheers!
--
adrian/witchy
Owner of Binary Dinosaurs, the UK's biggest home computer collection?
www.binarydinosaurs.co.uk
On 2010-10-30 01:12, <arcarlini at iee.org> wrote:
> Johnny Billquist [bqt at softjar.se] wrote:
>
>> > Now, I direct you all to page 4-7 of that document, which talks about
>> > physical addresses on a VAX.
>> > Notice how a physical address on a VAX can be 34 bits, while the
> virtual
>> > address is only 32 bits.
>
> VAX virtual addresses have always been 32-bits although system space S1
> (the top 1GiB) was never defined. The XVA project allowed it to be used
> (on some hardware platforms).
Yes. And the virtual address space is divided into 4 parts (as you well
know :-) ). P0, P1, S0 and S1. Only P0 and P1 is actually process local,
while S0/S1 is system wide.
> The (related) XPA project allowed the physical address space to grow
> beyond
> 1GiB but only to 4GiB (32-bits).
Well, the design allows it to grow to 34 bits. Specific implementations
might have limited it to 32 bits, but that's another story.
> DEC STD-032 does allow for a 34-bit PA implementation but I don't know
> of
> one. The VAX 6000/7000/10000 all only implemented 32-bit PA mode
> (afaik).
> I don't know (off hand) whether the chipset could do more.
Two different things here. The NVAX chip have two different formats of
the page address. 21 bits or 25 bits. With 21 bits, you can only get 30
bit physical addresses (the old VAX model). With 25 bits, you get a
total of 34 bits of physical address. Now, I don't know if the NVAX
brought all 34 address bits out of the chip, but that is the size of the
physical address created by the MMU anyway.
The actual machines, such as the VAX 7000 on the other hand, clearly
only allowed a max of 4G. Of that, 3.5G was for physical memory, and
0.5G was reserved as I/O space. But that is a design decision of a
machine, and have less bearing on the architecture.
It is a question of the bus used in the machine, as well as where I/O
adapters will be present on the bus, and so on.
I suspect all software running on a VAX7000 to always have the top two
bits of the PFN in the PTE to always be zero. But the bits are there
none the less.
Anyhow, even with only 3.5G of physical memory, it will be more physical
memory than any one process can have virtual memory on the VAX, since a
process cannot be larger than 2G (P0,P1)
> So (barring any inormation to the contrary) I think it's only a
> theoretical
> possibility:-)
Probably. It would be interesting to see the pinout of the NVAX chip, to
see if they brought all 34 bits out on that chip. All existing VAXen
restricted physical addresses to at most 32 bits, though.
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 recently acquired a small truckload of DEC and Wang equipment which
I am starting to sort and inventory in my garage. The DEC is mostly
accounted for (tho will lead to later questions here) but I know far
less about the Wang stuff. It seems Google does, too. I've got a few
larger units plus a number of boards - it appears the stuff originally
came from a repair shop and/or dealer. I've photographed two pieces:
The first I'm not even sure of the make - its colors sort of suggest
DEC but I'm leaning toward it being a Wang printer stand:
http://picasaweb.google.com/Silent700/MysteryCart#
The second is a Wang Word Processor, model 5506-A. Google has much on
earlier WPs from them, but nothing on this model:
http://picasaweb.google.com/Silent700/Wang5506AWordProcessor#
What I find especially strange about this one is that it's called a
"Word Processor," suggesting it is a complete system, yet it has ports
for neither storage nor a printer. Could it be a terminal to a
networked (WangNet) system? Still, the only ports on the back are
Video and Keyboard - both of which it has built-in. They could be aux
video in or out, or an attachment for an add-on keyboard?
The 5506 is practically mint. The guy I got it from said he had the
original box but it was in such bad shape he tossed it :( There is
still shipping plastic on the space bar and the screen. Turning it
on shows a blank greenscreen - turning up the brightness shows
diagonal lines, so there may be a display problem.
Hoping for clues! More to come...
--
jht
On 2010-10-30 01:12, Ethan Dicks<ethan.dicks at gmail.com> wrote:
> On Fri, Oct 29, 2010 at 12:31 PM, Chuck Guzis<cclist at sydex.com> wrote:
>> > On 29 Oct 2010 at 0:11, Johnny Billquist wrote:
>> >
>>> >> Next question: Does the VAX not have virtual memory any more now that
>>> >> I've pointed this out? Or do you need to redefine virtual memory in
>>> >> yet a new and strange way to exclude the PDP-11...:-D
>> >
>> > I think that using memory address spaces to qualify the "virtualness"
>> > of memory is following the wrong animal.
>> >
>> > I would define "virtual memory" as the ability to fool a program into
>> > thinking that it has more physical memory than is actually present.
> I don't think that's an essential component of the term as I learned
> it 20+ years ago.
>
> My understanding is that in a machine that supports virtual memory,
> you have virtual address space(s) and physical address space.
> Physical addresses are something you can see with a logic analyzer and
> point to a physical chip and say "my data is right*there*". If you
> have two processes running on the same CPU, they both agree where
> 0x0000 (or 0x00000000) is and it's the same place. If one process
> writes a value there, both processes would read that value back. In
> virtual space, each process*thinks* they are writing to 0x0000, and
> they can read back the value they wrote, but not each other's values.
> In fact, unless they peek under the covers, they have no idea where in
> physical memory their own virtual 0x0000 is.
Indeed. Finally someone with the correct definition of virtual memory.
You could also draw the parallel to a virtual machine. It fakes a real
machine, making you think that you have your own. Virtual memory fakes
real memory, making you think you have your own.
Exactly how this is done is not a part of the definition. Nor is the
relation between the sizes of virtual and physical memory relevant.
If you get the impression that you have the full address range available
to do with as you please, even though you are not alone on a machine,
then you are presented with virtual memory.
> In practice, quite often virtual memory_is_ used to fool programs
> about how much physical memory there is, but the PDP-11 is a specific
> counter-example to "more than is actually present". Taking the VAX
> first (since we all know "all the world's a VAX";-), you might have
> 8MB of physical memory installed in an 11/750 in a physical memory map
> of 16MB (24 address bits). So in this model, your virtual space is 32
> bits (the size of your address registers), while your physical space
> is 24 bits. From the process side, every process "sees" 4GB (32
> bits) of space with lots of holes in it (mostly holes). If your
> program keeps requesting more and more memory from the OS, at first,
> you may be given chunks of real memory mapped into your virtual space;
> eventually that will be exhausted and your OS will most likely start
> paging and reserve storage for you until that runs out (so always
> check the return of malloc() even if you think you can't possibly run
> out of virtual memory).
Yes. You could also say that demand paging is *required* in order to
fool a program that it has more memory than what is physically
available. And virtual memory is also required to make this work, but
they are two different things. You can have virtual memory without
having demand paging.
> On the PDP-11, your process's_virtual_ space is 64KB - 16 bits, the
> size of your registers, while some PDP-11s can have up to 256KB of
> physical memory (18 bits), and many can have up to 4MB (22 bits) of
> physical memory. In this case, you still have virtual space different
> from physical space (and the same scenario where two different
> processes agree on where 0x0000 is in physical space but maintain
> their own 0x0000 in their respective virtual spaces).
Exactly!
>> > So, can a PDP-11 with 16K of memory appear to a program as if there
>> > were 32K present?
> That all depends. Back in the day, what we did was not demand-paged
> virtual memory (something supported natively on the VAX and the 68010
> (but not effectively on the 68000) - some architectures have memory
> management hardware that can "tell" if a reference is about to hit a
> patch of virtual addresses that don't have physical memory mapped to
> them and invoke some OS-specific routine to either allocate or pull
> from storage what needs to be there and resume the instigating
> instruction as if nothing happened (which is part of what
> distinguishes the 68010 from the 68000 - instruction restart).
>
> On the PDP-11, we used overlays to load, say, 32K of code into 16K of
> physical memory, pulling in routines when they were needed, but it was
> done at the application level, not the instruction level. It is not
> the same thing as demand-paged virtual memory (which_is_ used to make
> it seem that there is more memory than physically installed).
Well. A PDP-11 can restart an instruction if needed, and you get a trap
when trying to reference virtual memory that isn't enabled in the MMU.
SO all the components for demand paging is there in the hardware.
Overlays solve a different problem, so it's not really meaningful to
compare them to demand paging. Even if an OS on the PDP-11 had demand
paging, you would still need to use overlays exactly the same way as
now. Overlays solves the problem that the virtual address space is only
64K. Demand paging does not solve that. Demand paging solves the problem
of not needing to have all virtual address space mapped to physical
address space at the same time, thus saving on physical address space.
You could say that demand paging makes more efficient use of physical
memory. And it is also required if you want to map more virtual memory
than you have physical memory. (But we already hashed through that :-). )
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 2010-10-30 01:12, Rich Alderson<RichA at vulcan.com> wrote:
> From: Johnny Billquist
> Sent: Thursday, October 28, 2010 2:46 PM
>
>> > Why are people so hung up on physical memory size vs. virtual memory
>> > size when they need to define what virtual memory is?
>> > I just don't get it.:-)
> Perhaps because that's the way the term of art "virtual memory" (whether
> as segments or as pages) has been defined since it was first conceived?
>
> Virtual addressing is necessary for virtual memory. The converse is not
> true.
Well, it is obviously not a definition DEC agrees with, so I guess that
means there are two different schools (atleast) here.
And when talking about the VAX (which this thread started with), it
might be meaningful to use DEC's definition?
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
> 1. > The PDP-11 was in architectural ways more important than the VAX, if
> ? > nothing else than just because the VAX was basically just extending the
> ? > PDP-11.
Just to throw another question into the fire:
Just how important was the PDP-11 or VAX-11/780 hardware architecture
in the grand scheme of things? Did either machine really bring
anything new to the table?
Don't confuse popularity with importance - we all know that sometimes
unpopular inventions are hugely influential (Alto?).
--
Will
On 2010-10-28 23:02, Rich Alderson<RichA at vulcan.com> wrote:
> Because the VAX offered a virtual memory capability (hi, Johnny!:-), it
> did change the way Unix developed, but so did other ports (Interdata, for
> example, and even the IBM Series/1).
One more thing here. This is not directly to you, Rich, but this line is
as good an introduction for me throwing another wrench in the machinery
as any... And I do love wrenches.
It has been stipulated that the PDP-11 don't have virtual memory, but
the VAX do, and various arguments for this view.
As far as I can tell (and people, please correct me if I've gotten this
wrong) the reason for this view boils down to:
1) The physical address space is larger than the virtual on a PDP-11.
2) The PDP-11 don't load just parts of the memory and handle page faults
as a way to do demand paging.
Now, as for #2, I think I have established that some models of the
PDP-11 could in theory do this, if you just wrote the software for it.
The fact that noone have does not take away the capability. If anyone
disagree with this, I'll be happy to explain exactly how the code should
look like on the PDP-11 to do demand paging.
As for #1, I now drag out DEC STD 032 as exhibit A. It's a wonderful
document, more commonly known as the VAX Architecture Reference Manual.
More specifically, the version called EL-000 32-00.
Anyone can read it, it's on bitsavers.
http://www.bitsavers.org/pdf/dec/vax/archSpec/EL-00032-00-decStd32_Jan90.pdf
Now, I direct you all to page 4-7 of that document, which talks about
physical addresses on a VAX.
Notice how a physical address on a VAX can be 34 bits, while the virtual
address is only 32 bits.
Next question: Does the VAX not have virtual memory any more now that
I've pointed this out? Or do you need to redefine virtual memory in yet
a new and strange way to exclude the PDP-11... :-D
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 2010-10-29 17:34, Brent Hilpert <hilpert at cs.ubc.ca> wrote:
> On 2010 Oct 28, at 2:46 PM, Johnny Billquist wrote:
>> > On 2010-10-28 23:02, Brent Hilpert<hilpert at cs.ubc.ca> wrote:
>>> >> How about the notion that the PDP-11 was where several prior but
>>> >> then-topical innovations coalesced into one machine/architecture?
>> >
>> > I think that would be a very dubious, and hard to prove claim.:-)
> It may be more work than proving an individual claim of innovation, but
> it is still a plausible notion to research historically.
You're right. And it might be true. Just hard to prove.
>>> >> ...
>>> >> On the topic of memory, I would agree with Johnny about "virtual
>>> >> addresses", but differ on "virtual memory": virtual memory to me has
>>> >> always meant demand-paging where the RAM address-space seen by the
>>> >> user
>>> >> can be larger than the physical RAM, distinct from the simple mapping
>>> >> of addresses, but the use of the term is a matter of definition.
>> >
>> > Thank you.
>> > But what, pray tell, would you say a virtual address pointed to, then?
>> > Magic smoke?:-)
> Physical memory via the MMU; this is not a contradiction.
You know, a virtual address on a VAX points to physical memory via the
MMU as well. :-)
The point of virtual memory is that appears as a single, continous
memory space, even though it might be scattered all around in physical
memory, and you can have several virtual mappings for the same memory
space, which do not translate to the same physical memory.
That is what defines virtual memory, I'd say. Not how many bits there
are, or by how the OS reacts when you address memory for which you not
currently have a valid mapping.
>> > Why are people so hung up on physical memory size vs. virtual memory
>> > size when they need to define what virtual memory is?
>> > I just don't get it.:-)
> Because there is a fundamental difference between having your valid
> address space limited to available physical RAM, even if you can map a
> "virtual" address to different places in that RAM, and having a
> transparently addressable (large) address space unlimited by a lesser
> quantity of physical RAM. In the latter it*appears* (hence virtual)
> that you have more RAM than you actually do. This has always (IME) been
> the common meaning of "virtual memory".
I assume you've seen my post by now, where I point out that the physical
address space of a VAX was/is 34 bits, while the virtual address is 32
bits. So you can have the exact same scenario on a VAX that you normally
have on a PDP-11. :-)
I mean, on the PDP-11, let's pretend you had the exact same
architecture, but you limited the physical address to 12 bits, would
that then have meant that it had virtual memory? Just because you put an
arbitrary lower limit on one parameter?
> I'm too many years away from programming a PDP-11, but while it may as
> you suggest have been possible to do demand-paging in principle, how
> complex might it have been in practice? Trapping an address fault might
> be easy enough, but what about instruction restart/re-execution while
> accounting for all possible side effects that may or may not have
> occurred between the start of the instruction and the address fault.
Not complex at all. But the OS would have to keep some more data around
to be able to figure out where to page in data from when a page fault
occurred, as well as keeping track of allocated physical memory in a
different way than any current OS do. RSX (which is the OS I know best)
can keep physical memory usage tracking simpler since you always
allocate chunks of physical memory, not pages. And the executable part
of a program is just one chunk, even though it might be many pages.
And the whole chunk is moved in and out from swap.
A program can, however, have several chunks mapped in. Shared libraries
are their own chunks, and you have a lot of other kind of chunks as
well. At most, your program might be referencing around 32 chunks, I
think. (Don't remember the actual limit, or how it is enforced.)
And a chunk can be more than 64K. It's just that you cannot have more
than 64K mapped into your virtual address space at one time.
One more potential headache is that the pages on a PDP-11 are variable
in length. In addition to the page protection bits, you also have a page
length field in the MMU, so you don't need to allow just nothing, or all
8K of a page. The granularity of the length is 64 bytes. And you can
choose whether the top, or bottom part of the page is valid.
As for instruction restartability, it works just fine. DEC did think of
that. But that is also why I'm saying not all processors could do demand
paging. You need MMR3 (I think it is), which keeps a scorecard of how
much registers have been modified by the aborted instruction, so that
you can back out of it again. Older machines don't have that register,
and thus cannot undo a partially executed instruction.
> IIRC, the 68000 series ran into this problem when people started trying
> to do (demand paging) VM with it. When an address fault occurred, not
> all of the instruction state was saved and restarting the instruction
> became a problem. It was fixed in the next version but I forget where
> in the series (68010->20, 20->30, etc).
It was a problem in the original 68000. It was fixed in the 68010,
unless my memory fails me.
One more an example of how much better the PDP-11 was than the 68K. :-)
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
> From: Johnny Billquist <bqt at softjar.se>
>
> I have not seen anyone comment any of the other things I listed as
> possible firsts on the PDP-11.
> Can anyone come up with an earlier machine that used condition codes?
The ICT 1301 had up to 100 'indicators' specified by two BCD digits in the instruction. All could be tested with an unconditional jump and some could be set and unset by program too. Number zero was always on to give an unconditional jump. There were ones for equal, greater and less as well as overflow, parity error, front panel switch states, as well as various peripheral statuses. Does that count?
> How about general registers with addressing modes, which is totally
> orthogonal? How about having the PC as a general register?
Not quite the same thing but IIRC the Elliott 920A used core location zero as its program counter. To be more accurate it used 0 by default when not using interrupts. When using interrupts it used 0 for level 1, 2 for level 2, 4 for level 3 and 6 for base level code. It also used those addresses plus one for its modifier (B) register. This speeded up interrupt processing as no need to save those registers.
On 2010-10-28 23:02, Brent Hilpert <hilpert at cs.ubc.ca> wrote:
> On 2010 Oct 28, at 10:51 AM, Chuck Guzis wrote:
>> > On 28 Oct 2010 at 13:20, William Donzelli wrote:
>>> >> I was initially thinking about just the hardware architecture when the
>>> >> machines were being designed, not the software aspect, nor what the
>>> >> machines did (or influenced) after they were released. The
>>> >> aforementioned memory mapped I/O, for example.
>> >
>> > Not to be too much of a wet blanket, but how many of those DEC-unique
>> > innovations (even if you manage to assert that they originated with
>> > DEC) persist in today's hardware? Do modern PCs use memory-mapped
>> > I/O? The 68K, but for some Freescale relics, is history.
>> >
>> > Major innovations, such as virtual memory and orthogonal instruction
>> > sets and hardware-implemented stacks preceded the PDP-11.
> How about the notion that the PDP-11 was where several prior but
> then-topical innovations coalesced into one machine/architecture?
I think that would be a very dubious, and hard to prove claim. :-)
> The VAX was riding on the coattails of the market success of the -11
> and provided existing PDP-11 installations with increasing demands with
> a way forward, and it grew from there. That's a bit of a tautology, but
> it is to say it did exactly what it was designed and marketed for.
Yes. The VAX did not really innovate anything. It was more of a rather
successful merge of many things, and following in the footsteps on the
PDP-11, and building further on that foundation.
> On the topic of memory, I would agree with Johnny about "virtual
> addresses", but differ on "virtual memory": virtual memory to me has
> always meant demand-paging where the RAM address-space seen by the user
> can be larger than the physical RAM, distinct from the simple mapping
> of addresses, but the use of the term is a matter of definition.
Thank you.
But what, pray tell, would you say a virtual address pointed to, then?
Magic smoke? :-)
Why are people so hung up on physical memory size vs. virtual memory
size when they need to define what virtual memory is?
I just don't get 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
