test-drb October 2010

test-drb@ccmp.vtda.org

175 participants
274 discussions

by silent700＠gmail.com

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

14 years, 1 month

Virtual memory

by bqt＠softjar.se

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

14 years, 1 month

Virtual memory

by bqt＠softjar.se

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

14 years, 1 month

Happy Birthday VAX 11/780 (influence of)

by wdonzelli＠gmail.com

> 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

14 years, 1 month

Happy Birthday VAX 11/780 (influence of)

by bqt＠softjar.se

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

14 years, 1 month

Happy Birthday VAX 11/780 (influence of)

by bqt＠softjar.se

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

14 years, 1 month

Happy Birthday VAX 11/780 (influence of)

by roger.holmes＠microspot.co.uk

> 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.

14 years, 1 month

Happy Birthday VAX 11/780 (influence of)

by bqt＠softjar.se

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

14 years, 1 month

Postscript printer and trinitron monitor available for free

by rescue＠hawkmountain.net

I know this is rather last minute... but if anyone has any interest e-mail me before 5:30PM, otherwise the following go into the recycling bin. NEC Silentwriter 95 - postscript - parallel interface - worked when last used around 2002 - toner included (unknown amount remaining) Sony? (Dell branded) 17" trinitron CRT monitor - working, nice picture - plastic yas yellowed some (uniformly) Sorry for the late notice, figured there wouldn't be much interest but I'd check. Items are for pickup in either Sharon, MA or Cambridge, MA. If there are parts you want from either, let me know, it could be arranged. -- Curt

14 years, 1 month

Byte Magazine

by elazzerini＠interfree.it

Rivista Byte dal Gennaio 1980 al Dicembre 1984 http://maben.homeip.net/static/S100/MAGAZINE/BYTE/index.html

14 years, 1 month

← Newer
1
...
5
6
7
8
9
10
11
...
28
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

test-drb October 2010