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
> I am looking for info on a Gandalf LDS120 modem, specifically the serial port pinout.
I recall it's just 2, 3, and 7, i.e. no hardware flow control, and
probably not even DTR/DSR. Now whether 2 and 3 have to be
swapped...well I always just tried it both ways until it worked :-)
And it's 4-wire leased line on the analog side, right? So no ring detect etc. either.
Tim.
The device [1] that's currently all over my bench has an empty 28 pin DIL
socket on one of the PCBs. It's alongside a 27C256 EPROM and 43256 RAM, and
has a similar pinout.
In fact the pinout is the standard JEDEC one for 28 pin memory devices
(with
A13 on pin 26, WE on pin 27, OE on pin 22, etc) with one exception. Pin 1
is
not A14, it appears to be an output, linked to an interrupt pin on the
80C85
that links to the aforementioned memory devices and this socket). Oh, and
to
an input port pin.
Any ideas? My first thoughts were an E2PROM or simular, with a ready output
on
pin 1, or a RTC/memory device with an interrupt output on pin 1, but I
can't
find any obviuos candidates.
[1] A telephone network simulator. OK, it's not a classic computer, but I
will
be using it to test and demonstrate classic computer modems, it's well over
10
years old, and contains 6 microprocessors...
-tony
--------------------------------------------------------------------
myhosting.com - Premium Microsoft? Windows? and Linux web and application
hosting - http://link.myhosting.com/myhosting
