On 11/06/10 02:03, Brent Hilpert<hilpert at cs.ubc.ca> wrote:
> Flogging a dead horse perhaps, as I believe the discussion is simply a
> matter of differing definitions of the phrase "virtual memory", but
> let's try a different approach:
Nothing like flogging dead horses... :-)
> Suppose we have a machine which at the instruction level provides
> 32-bit addresses, that is, it presents a 32-bit address space (4GB) to
> the user. However, there is only 1 MB of physical RAM memory in the
> machine.
That is one scenario, but definitely not the only one. Part of the
problem is that people seems to want to limit them self to this
scenario, and of course, if you start at that end, then you will more or
less always end up in the same place you just do here. :-)
> Without trying to go through the whole history of OS development
> (leaving out things such as overlays, shared libs, etc.), and without
> accounting for memory required by the kernel/OS for simplicity,
> consider several scenarios:
>
> - 1. User addresses map directly to physical addresses.
> User address 0 is physical address 0. The user address space is
> obviously
> limited to 1MB or less of memory and the user will be aware of such
> if an
> attempt to address beyond that is made.
Yes. And if you have several processes, they are all aware of each
others memory space, and care must be taken that they do not wander
outside their own confinements and clobber things in the system
(including the OS). Programs must be written to be memory aware, and
either PIC, or else linked to run at a specific address, since there is
no virtual memory.
> - 2. We add an MMU to map addresses.
> Multiple user address spaces may exist and can be mapped to different
> areas in physical memory. User address 0 may or may not ref physical
> address 0.
> A user is still aware of a limited address space dictated by the 1MB
> of
> physical memory. The total of the user address spaces cannot exceed
> 1MB.
Indeed. And it can be an arbitrary lower limit than 1 MB as well. And at
this point, programs can be written to not be memory aware. All programs
can be written without consideration to what addresses they use. All can
be linked to start at the same address, and run in parallel. They are
not aware of, nor do they see other programs memory space. They can be
PIC, or position dependent. They can clobber all their memory, and the
system itself is not affected.
> - 3. We add swapping-to-disk.
> The system as a whole is no longer limited to 1MB of memory, there
> may be
> multiple user address spaces totalling more than 1MB of memory. Each
> user
> however, is still limited to a max of 1MB of address space, i.e.
> each user
> is still aware of the limited physical memory.
Right. Adding swap does nothing more than grow the capacity of the
system total. For a single process, it is invisible.
> - 4. We add address-faulting, demand-paging - whatever one wants to
> call it.
> The user address space is no longer limited by physical memory. The
> user can
> hit any address in their 32-bit space and (magically) find a valid
> memory
> location there. More physical memory can be added (or removed)
> 'underneath'
> the user(s) without their awareness.
Except, or course, the OS can still limit you to use less than 1 MB.
Adding paging does nothing for the individual program as such. It is
totally invisible. You might argue that it gives you the possibility to
use more memory than physically available, and that is true, but that is
at the discretion of the OS. To get more memory, you will need to call
the OS to request more memory, and the OS can allow or deny this
request. Same as in #2 above.
> By the nomenclature I grew up with or suffer under, the term "virtual
> memory" only applies in scenario 4, although "virtual addresses" could
> be said to have been introduced in scenario 2.
The difference between 2 and 4 is only that the OS *can* allow you to
use more memory in scenario 4, not that it necessarily will allow it.
> Or, scenario 4 was my understanding of the *commonly-agreed-upon
> application* of the phrase "virtual memory", although I would not argue
> that in a very general sense it may be applied to scenario 2 or 3.
The difference between 2, 3 and 4 is actually extremely vague. The only
actual difference is that the OS *can* allow you to use more memory. But
let's say that the OS will not. Does that suddenly mean that you don't
have virtual memory, even though it is indeed using page demand loading
and all that fancy stuff?
And this also totally ignores the scenario that exists under the PDP-11,
and which started this thread. What if you have more physical memory
than can be addressed by virtual memory?
That's a whole different ballgame, and is not covered by any of your
scenarios...
All in good spirit. :-)
Johnny
I spend some more time on the severely defective 8/L core stack I have.
First I repeated the diode checks and wielded out all diodes that were more than 40mV away from the .55 V forward voltage that seems to be standard. Total number of defective diodes : 29 . Still cannot figure out why so many diodes were dead/shorted.
Also repeated the inhibit / sense wire checks :
1 sense wire open.
1 sense wire high ohmic. ( 200 ohms )
1 inhibit wire high ohmic ( 250 ohms )
Normal value for sense / inhibit wires would be around 15 ohms.
I then opened the stack by cutting through 128 X/Y wires and removing 256 wire halves...
There were several old repairs, covered with some ceramic substance, luckily all on the edges of the core mats.
The high ohmic wires were due to this old repairs, after scrubbing off the ceramic stuff and resoldering the connection the high ohmic sense wire was restored to its nominal 15 ohm value.
I still have to fix the other wires, ( i.e. 512 wire halves to remove...) and reassemble the stack, but it looks like core memory repairs are possible by amateurs.
Material needed :
- high powered, but comfortable, microscope.
- SMD pencil soldering iron. The smallest I could find, and it was still too big.
- the smallest solder I could find, still way too big.
The other core stack, with the one single bit error, is still closed, but by swapping sense wire I was able to confirm that the error is indeed in the stack.
Jos Dreesen
While browsing on ebay lately I noticed CPU scrap going for quite a bit of money, for example:
http://cgi.ebay.com/1-lb-Lot-high-yield-CPU-gold-scrap-recovery-486-/220690…
Seems like 486 era chips (ceramic) are getting melted down for gold, and those poor PPros are going to be rare as dodo birds in a decade. Kind of makes me wonder if anything is going to be around from the 90's computer era in a dozen years.
How much of the earlier stuff was saved from melting because gold was only worth $350 an ounce in the booming 90's compared to $1390 in the current depression?
TZ
Hi all --
I've made a small bit of progress with my new Terak. The power supply
seems to be working fine, and after going over everything and cleaning
the old crumbly foam out, cleaning edge connectors, and reseating
everything it now gives the impression that it's trying to boot. (And
Al's been kind enough to send me a few images from the CHM, so I have
something to try and boot!)
However, I've never actually seen one of these in action before, so I
have no idea what the expected behavior actually is. I currently get
nothing on the display (the CRT is lighting up and if I turn the
brightness up I can see a raster, so I know it's at least minimally
functional) and I get no sounds from the speaker. The drive seeks back
to track 0, pauses for 1-2 seconds and then and seems to briefly access
the disk for another second. Then, nothing.
Can anyone who has used one of these before tell me if this is anywhere
close to expected behavior? Is it possible to get a serial console on
these (and is there anything like a PDP-11 ODT prompt?)
Thanks,
Josh
I am attempting to enhance a program which runs under RSTS/E, RTEM-11,
RT-11 and TSX-Plus. Thus far, I have managed to support these enhancements
for all but RTEM-11 due to the lack of documentation on RTEM-11. When
I requested help with supporting such programs under RSTS/E, John Dundas
provided a reference document which cleared up many questions.
Does anyone know of a document (and its link if it is on the internet,
especially
at bitsavers) which describes the support provided by RTEM-11 for programs
which also run under RT-11? From the comments that I have seen, the RT-11
operating system is run under RTEM-11 with special "hooks" to interface to
RTEM-11. If my understanding is correct, then all of the RT-11 EMT requests
supported by an RT11SJ monitor will also be available when running under
RTEM-11.
There are also two other specific questions that I suspect have a simple
answer:
(a) How much memory does a user program have which runs under RTEM-11?
My assumption is that a user program has approximately the same
size of
memory available when running under RTEM-11 as it would when running
under the RT11SJ monitor on a PDP-11 with 64 KBytes of physical
memory
which usually (when no additional device drivers are present)
ends up being
approximately 48 KBytes or an address range from 0 to about
120000 octal.
(b) Whereas RT-11 actively supports the ability of device drivers to be
LOADed
and UNLOADed at any time based on which devices are in active
use, RSTS/E
and TSX-Plus require the device drivers of any device that is
active to be
LOADed at all times. It would be an assumption on my part, but I
tend to
assume that under RTEM-11, any available devices are already LOADed
by the actual operating system that controls the CPU.
Specifically, if a user
program performs the .DStatus RT-11 EMT request for an available
device,
the 3rd word of the device driver information will always be
non-zero which
specifies that the device driver in question is always in memory
and that a
.Fetch RT-11 EMT request would be redundant.
Can anyone provide any documentation sources? If anyone knows the answer
to the approximate size of memory available to a user program running under
RTEM-11 and / or the answer concerning the LOADed status of a device driver,
it would be greatly appreciated.
Jerome Fine
On 11/06/10 02:03, ard at p850ug1.demon.co.uk (Tony Duell) wrote:
>
>>>>>> > >>> > > The Philips P800 series has the PC as a general register (register 0).
>>>>> > >> >
>>>>> > >> > Could you use it like any other register?
>>> > > There were some restrictions. I don't think you could shift it (at least
>>> > > ont on the P850). But for many instructions it was just another register.
>> >
>> > Cool. So you could add to it, index by it, and so on?
> I think so. I can't find my programemrs pocekt guide fo the machine at
> the momnet. But I am pretty sure that register 0 could often be used like
> any other register.
Ok. Nice.
> There is at least one oddity. There are no autoicrement/autodecrement
> adressing modes on the P800s. However, in some cases, if you use the PC
> in some instructions it is autoincrements. For example the 'immediate'
> addrtessign mode isessentialy a (PC) operation (i.e. take the word
> pointed to by register 0) and has that bit pattern. But for obvious
> reaosns the PC is autoincrements then.
The PDP-11 actually pulls that trick on a few addressing modes as well.
Addressing mode 6 and 7 autoincrement the register if it is the PC, but
not for other registers.
(So a thing like MOV FOO,R0 is encoded as
MOV x(PC),R0
.WORD .-FOO
and the PC should obviously be incremented again here, but x(Rn) does
not exist as a variant with autoincrement of the register.)
>>> > > I guess the P800 wasn't totally ortogonal but it was a lot more
>>> > > orthogonal than many other machines.
>> >
>> > Indeed sounds nice. When did the machine appear?
> My P850 CPU service manual is copyright 1972, which alas puts it after
> the PDP11, but I thoguht the series was around a bit before that.
Hmm. Maybe still a first for the PDP-11 then...? :-)
>>>>>> > >>> > > What do you mean by condition codes here?
>>>>> > >> >
>>>>> > >> > The four low bits of PSW.
>>> > > Err... I don;t think that's helpful. Quite a lot of machines with a
>>> > > status register have a 'low 4 bits' of it:-). But that doens't make them
>>> > > condition codes. Similarly uf you hapopen to implement the same
>>> > > functionality using other bits of a status registers, doesn't that make
>>> > > them condition codes?
>>> > >
>>> > > What I was asking was what fucntionality do you require of these
>>> > > condtiion codes other than there being conditional jumps on carry, zero, etc?
>> >
>> > Sorry. I was just being lazy, and trying to explain condition codes by
>> > referring to what they are on the PDP-11.
>> >
>> > To try and be more specific then: condition codes are bits that are
>> > set/reset as a result of operations performed by the processed, and upon
>> > which you can the make conditional branches/jumps on.
> Now the P800 has a very odd way of doing this. There is a 2 bit status
> registers. It is set differnet ways according to the results of some
> instructiuos (for example, an arithmetic instruciton will set it one way
> if the result is 0, a differnet way if there's a carry out, etc). I/O
> operations set it one way for device ready, another for certain errors, etc.
>
> The condtional branches have a 3-bit condition field. You can branch on
> the status beits being any particualr value (00, 01, 10, 11), them not
> being one of 3 values 9I forget which one is omitted) or 'always'
Sounds slightly different than the condition codes of the PDP-11 then,
but not really like the immediate test and do instructions like the
PDP-10. Closer to the PDP-11, it would seem.
Johnny
On 11/06/10 02:03, "Chuck Guzis"<cclist at sydex.com> wrote:
> On 5 Nov 2010 at 15:09, Brent Hilpert wrote:
>
>> > By the nomenclature I grew up with or suffer under, the term "virtual
>> > memory" only applies in scenario 4, although "virtual addresses" could
>> > be said to have been introduced in scenario 2.
> My original definition was that "virtual memory" was the ability of a
> system (hardware, software, whatever) to fool a program into thinking
> that there was more memory present than was physically the case.
>
> Johnny (and please forgive me if I got this wrong) tied it into the
> ability to present each user with a address space, such that two
> users could use the same address space, but have different data. Key
> was the claim that a system with more physical memory than the user
> could directly address still qualified as virtual memory.
>
> I don't tie virtual memory into paging or even to multi-tasking or
> multi-user, although I'll concede that paging is a way (albeit
> rather simple-minded) to implement it. The Burroughs B5000 didn't
> employ paging and yet I think few would argue that it did not
> implement virtual memory (and quite possibly the earliest commercial
> use of it).
Yeah, you got more more or less right. Virtual memory according to me
(well, I got the definition from DEC) is the appearance of memory that
is your "own" although you in fact are running on a system with many
processes running concurrently. You can do anything with your memory,
and it will not affect anyone else. It's like your own sandbox. You can
do anything in there.
Obviously, this is not really tied into paging, nor multi-tasking (you
can have this with just one process, still protecting the OS from you).
Obviously, I do not tie memory sizes on either end to what virtual
memory is. You know, things like overlays are actually a form of paging
as well, and is a solution to allow you to have more memory used than
physically exist in the computer, and yet it don't require virtual
memory to implement this. (Heck, I just came up with an example of
paging and memory sizes that is totally disconnected to virtual memory,
or page tables, or anything close to that.)
Johnny
http://classiccmp.org/pipermail/cctalk/2010-November/293791.html
>Hi Andrew.
> I am restoring a Northstar Horizion. Would any of your boards be
suitable
>substitutes for the original NS ones?
>
>
>Regards
>?
>Rod Smallwood
Hi Rod! Thanks!
The boards would likely work in a NorthStar Horizon as it is a fairly normal
S-100 system. The boards are designed to be strictly IEEE-696 compatible so
either they would work as is or require some minor adjustment.
They are not strict NorthStar replacement parts though. They would
compliment a NorthStar system nicely I think but it would depend on the
board and how you use it. It is hard to say without knowing your specific
application though.
Allison covered the topic pretty well in her commentary. My recommendation
is to check out S100computers.com and see the documentation on the boards
and see if this would interest you. There are a lot of photos,
explanations, and videos of the various boards in action.
http://classiccmp.org/pipermail/cctalk/2010-November/293798.html
[Alexandre Souza]
> Andrew, I'm **VERY** interesting in knowing more about S-100 boards.
How
>much would it cost?
>
The S100computers.com and N8VEM S-100 boards are an all volunteer amateur
run project. They are roughly at cost for the PCB manufacturing. They are
$20 per PCB with $3 shipping in the US and $6 shipping elsewhere. These are
group purchases of boards for hobbyists by other hobbyists.
I am not soliciting sales for the boards. What I am asking is if hobbyists
are interested in getting these boards to contact me and tell which ones
they want. I will order/reorder boards when the "waiting list" for any
given board gets large enough to warrant an order.
This is not a business as I am trying to organize a group buy of the boards.
John and I are ordering boards for ourselves anyway so I thought to offer to
the community if there were other interested hobbyists. There are about
50-60 S-100 builders on the private distribution list now.
All of the boards are documented at S100computers.com and the N8VEM wiki.
The design information for hardware, software, schematics, PCB layout, parts
list, build instructions, etc are freely available and posted online. If
you can't find it please ask and hopefully I'll update the website.
I hope this helps. Thanks and have a nice day!
Andrew Lynch
From: rdawson16 at hotmail.com
To: innfoclassics at gmail.com
Subject: RE: FFS Sun monitor
Date: Mon, 8 Nov 2010 16:50:16 -0600
Paxton's got the scopes too.
Its good to see stuff go to a good home.
Fellow packrats unite!
Randy
From: rdawson16 at hotmail.com
To: innfoclassics at gmail.com
Subject: RE: FFS Sun monitor
Date: Mon, 8 Nov 2010 16:24:07 -0600
Hi Paxton,
Its yours. Call me and we will arrange things. I need to leave here by 5PM tomorrow for a ham meeting...
I also have a couple of oscilloscopes, low end, probably 5 MHz bandwidth a Sencore and a Heathkit, 5 inch CRTs if anybody wants them.
Randy
503-352-4612
> Date: Mon, 8 Nov 2010 13:46:42 -0800
> Subject: Re: FFS Sun monitor
> From: innfoclassics at gmail.com
> To: rdawson16 at hotmail.com
>
> On Mon, Nov 8, 2010 at 1:54 AM, Randy Dawson <rdawson16 at hotmail.com> wrote:
> >
> > Its large and heavy 19" ...
> >
> > Works fine with vga at hi res,and has attached cables for the sun.
> >
> > Its going to the recycle unless you guys want it.
> >
> > Randy
> >
>
>
> Hi Randy,
>
> I am interested in the monitor. I have a couple of Sun boxes that do
> not have a monitor.
>
> I am in Eugene at the moment but going back to Astoria tomorrow, Tuesday.
>
> I could stop by tomorrow afternoon on my way through if it is still available.
>
> Paxton
>
>
>
> --
> Paxton Hoag
> Astoria, OR
> USA
On 11/05/10 19:13, "Chuck Guzis"<cclist at sydex.com> wrote:
> On 3 Nov 2010 at 20:47, Johnny Billquist wrote:
>
>> > Ok. So, a program would think it addressed a memory space, which was
>> > it's own, and the addresses it used would in no way related to the
>> > actual physical memory it ended up referring to. I'd call that virtual
>> > memory. Although, having to map the whole virtual memory as one chunk
>> > to physical memory makes it a little more work, end less flexible than
>> > having pages. And it pretty much prevents you from ever being able to
>> > share memory in a reasonable way between processes.
> Well, not really. I refer you to the CDC 7000 SCOPE 2 operating
> system. There's a users' manual on bitsavers, but I suspect the
> design notebooks have long vanished from the face of the earth--so
> there's no documentation on the innards.
I tried to find any manuals on bitsavers, but I can't see anything about
a CDC 7000 there...
But while I can see that doing shared memory would be possible even with
a single mapping between virtual and physical address space, it would
mean you need to copy data between different locations between each
context switch, which would be rather heavy.
> At any rate, the CDC 7600 OS people had a peculiar problem. On the
> 6000 series of machines, PPUs are free-range; they have access to all
> of memory and at the time (say, 1968), comprised most of the
> operating system--there was almost no CPU code involved. You'd stick
> a request into your own location 1 and PP 0 would see it and detail
> off the work to the rest of the PPs. Very cool--you never gave up
> control of the CPU unless it was to yield to the job scheduler.
Gah. I have no idea what PPU mean, nor PP.
But it sounds like what you describe now would not be virtual memory. If
each process have access to all of the memory, then you'd not have your
own address space. Instead you'd have to make sure you kept within your
bondaries. Hopefully the hardware can assist with that, but maybe not.
But that is still something else. It's basically just talking about
physical memory. But I might very well totally be misunderstanding
things here, since (as I said) I don't know what these acronyms really mean.
> But this wasn't possible on the 7600, as each PP was assigned its own
> hard-wired slot in CPU memory and was unable to access anything but
> that. So the 7600 PPs were detalled off to I/O only. (Now, I'd call
> that memory-mapped I/O--you want to to talk to a certain I/O
> processor, you communicate with it through a hardware-fixed location
> in memory.) Which left the CPU to handle OS tasks such as job
> scheduling and file management. A whole new can of worms, as SCM
> (the memory that a program could execute from was very fast, but
> somewhat limited).
To me, the difference between shared memory I/O and memory mapped I/O is
about how the notification comes across between the subsystems. Is the
slave triggered by a write to the memory, or does the slave poll the
memory location. If the slave polls the memory location, then I'd called
it a shared memory design. If the slave gets triggered by a write to the
memory, then I'd call it memory mapped I/O. And what you describe here
could further be called I/O channels, I think, in IBM speak. Basically,
separate processors running their own code, which can do limited kind of
stuff, mostly related to I/O functions for the main processor. Some of
these designs even allowed you to place the "program" to be run in
shared memory, and then kick off the I/O processor to do the work, and
it signalled back when it was done.
But I digress... :-)
> A small permanently-resident "kernel" to handle PP commination and
> task swapping was written, but job processing, file management, etc.
> was performed for each job with a sort of matryoushka doll setup of
> overlapping field lengths. In other words, a user program was
> completely enclosed within the record manager which was completely
> enclosed within a buffer manager which was completely enclosed within
> the job supervisor for that job. So all user memory was shared with
> successively higher privilege level tasks, differing only at what
> location their respective location 0s were assigned to physical
> memory.
Ah, yes. That is also shared memory between different processes, but in
a somewhat limited hierarchical way. You could for all OSes say that any
process is always sharing it's memory with the operating system. :-)
> The 7600 also had a bulk core "LCM" which couldn't be executed from,
> but served for swapping and data storage.
>
> As far as piecemeal swapping, I'll leave that for another time when I
> discuss the CDC Zodiac operating system (1970), something for which I
> suspect no documentation survives.
Sounds like fun...
Johnny
