On 2012-07-09 03:01, Bob Armstrong wrote: I don't know if you understand the concept of memory partitions in RSX properly. No, I guess not. The usefulness of partitions in an unmapped system is easy to see - since tasks have to be linked (er, "TKBed") to run at a specific virtual address and all tasks have to share the same address space at the same time, you have to fit the tasks into memory. It's really the address space that's being partitioned as much as it is the memory. The concept is not unlike overlays. Well, on an unmapped system, not only do you have to worry about the region, but you actually have to task build your program for a specific address in that region, since you don't have virtual memory. Once you have an MMU, you (almost) stop worrying about the address offset parts of regions in TKB, but you still have to say which partition it should request the memory in. Of course, you can always override which region a program tries to run in when you install it. The information specified in TKB is just the default values. Nothing force you to actually use those values. This is what the help in RSX says: .help tkb opt par PAR=par-name[:base:length] PAR specifies the partition for which the task is built. In a mapped system, you can install your task in any system partition or user partition large enough to contain it. In an unmapped system, your task is bound to physical memory. Therefore, you must install your task in a partition starting at the same memory address as that of the partition for which it was built. But once you have an MMU the whole procedure is pointless. Every task and every processor mode can have its own contiguous virtual address space. Right. Except that contiguous virtual address space does not necessarily map to a contiguous physical address space. Nobody needs to share virtual address space with anybody else. And the mapping to physical memory is (for practical purposes) completely arbitrary and easily changed on the fly. What's gained by partitioning physical memory into fixed chunks that are allocated only to specific uses and can't be shared? Tasks that share the same region compete for the memory resources. Tasks in separate regions do not. Also, sometimes tasks want to share parts of their memory space with others. Also, memory partitions are not allocated to a specific user. Memory partitions are managed by the system manager, and are normally set up at boot time (even if this can be handled and modified at any point). Actually I thought RSX worked the way you described for M+ -> everything ran in a "GEN" partition, and the system just made as many GEN partitions as it wanted. Only if you were unmapped did you care which partition something ran in. Um... No. There is only one GEN partition. There can only be one partion called GEN. The name of a partition needs to be unique. A memory partition is more like a meta object. When a task is run, it allocates region within the partition. Many tasks can run in the GEN partition (for example), but they all have their own regions. Otherwise they would all share the same memory. And if more tasks try to allocate memory in a region than there is room for, they are constantly swapped in and out by the scheduler, based on their swapping priority. When you don't have the ability to lock regions in memory, you can constantly be swapped out if some other process in the same partition requests more memory than there is free in that region. Good idea. But there are SCSI controllers for the Q-bus, as well as the KDA50... I have both of those, but I'm not going to waste 'em on a 11/23! :-) :-) Actually that's a pretty realistic attitude back in the day - these are more expensive mass storage devices and anybody who could have afforded them probably would have bought a faster CPU too. I know of places who still ran 11/23+ machine in production at least until only a couple of years ago. Moved from RQDX2 to SCSI about 6 years ago... 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