"Jerome H. Fine" <jhfinedp3k at compsys.to> wrote:
>Johnny Billquist wrote:
>>> >> Agreed! The problem is that I have been unable to locate any
>>> >> documentation for which RT-11 EMT requests are handled by
>>> >> the RTEM-11 RTS along with the differences between RT-11
>>> >> and the RTEM-11 RTS.
>> >
>> > *sigh* Still not an RTS... RTEM-11 is a program, not an RTS. There is
>> > no RTS concept in RSX.
>
> I agree. I forget to use the correct terminology. If you can indulge me
> now that I have turned 72 years old, that would be appreciated.
I'll try. But please try to read, understand, and apply what I write, or
else we'll not get anywhere.
>>> >> But for RTEM-11, I don't have any documentation at all.
>> >
>> > The obvious answer is that this is documented in the manual that came
>> > with RTEM-11. Now, you just need to find someone who has it... (not me)
>
> Well, since we both agree that it is extremely unlikely that RTEM-11 will
> ever be used, ...
>
>>> >> I have access to both V7 and V10.1 or RSTS/E. However, I have not
>>> >> found the
>>> >> program in V10.1 which copies files from RT-11 files structures to
>>> >> RSTS/E file
>>> >> structures.
>> >
>> > And this has just about nothing to do with the question on how RSTS/E
>> > determines which RTS a program runs under, but anyway...
>
> Obviously, but it is difficult to test a program when I can't even "RUN"
> it.
Yes, but don't mix questions. Keep the thread of each question intact,
and start a new question when you have something else you wonder about,
or use whatever thread already exists that deal with that specific
topic. And I use "thread" very loosely here. This mail have several
different threads dealing with different topics related to RT-11,
RSTS/E, RTEM and various other issues.
So, for the question on how RSTS/E figures out which RTS a program
should run under should not suddenly be the question on how to copy a
file from an RT-11 media into RSTS/E V10.
>> > As I've said before, I know about FIT. If DEC replaced FIT with
>> > something else in RSTS/E V10, then you just have to search around in
>> > the system. Look at the help files. That's usually a good place to
>> > start searching. Read the manuals. I think the V10 manuals are online
>> > somewhere as well.
>
> The work around that I use is to MOUNT DL0: which already has
> the files (Having been copied by FIT from DY0: to DL0:).
Yes. You have a working work-around. Which is good.
> If anyone else is reading this, can you suggest anything?
I did suggest how you should go about finding the answer yourself. You
are of course free to keep asking if someone else already have the
answer for you, but noone have responded yet...
>> > And is still done to this day in RSTS/E and RSX. And while exactly the
>> > same, something similar is done in Unix systems, Windows systems, VMS
>> > systems, and any other system I can think of.
>> > The reason being that for debugging you don't want a compiler to
>> > optimize things, and you want to include symbol tables in the compiled
>> > image for debugging purposes, while you do not want that stuff for the
>> > finished program, since it takes space and makes the program slower
>> > (symbol table and non-optimization).
>
> Actually, for VMS systems, if my faulty memory is able to remember
> correctly, the
> compiler builds symbol tables outside of the code and data in a manner which
> does not impact at all on the program when debugging is NOT taking place.
Well, not entirely true. You will still take up a lot more space on disk
for the image. And the symbol table is still around in memory even when
not needed. It is true that it does not impact on the speed, nor the
actual physical memory used by the program, since pages are only mapped
in when needed, but there is (as always) more to it than that.
In a way, the same is always true. The symbol table is always outside of
the actual image. Be it in a separate section of the binary, or a
separate file (RSX places the information in a separate file, which is
only created if you ask for it).
But for the optimization, that you cannot avoid. When you want to debug
a program, you do not want the compiler to optimize the code, because
that can, and normally will produce code that is very different from
what you wrote.
> From what I remember, the FORTRAN compiler set up the symbol tables for
> debugging so that there was no impact on the code when debugging was not
> active.
Your view of "impact" is way to narrow.
>> > Modern systems however, usually allows the debugger to be dynamically
>> > attached to a running program so you don't have to include that bit
>> > already at the link stage.
>
> Under RT-11, the SD(X).SYS device driver traps the BPT instruction when
> it is executed no matter what state the hardware is in. Of course, this
> also
> STOPS ALL other code from executing as well. This is not considered a
> problem under RT-11.
No, but it would be a major problem under RSX and RSTS/E, which is why a
similar solution cannot exist for them, despite what you think you read
in the sources of the SD(X).SYS driver for RT-11.
> Under TSX-Plus, the debugger STOPS only the code for that job on that
> terminal from running. There is also a separate debugger for the TSX-Plus
> operating system which does stop everything in the system.
Correct me if I'm wrong, but don't TSX more or less provide like a
virtual PDP-11 for each user, so that it appears as if they have all of
a machine for them self, so in essence, it would work just as fine as on
a real RT-11 system?
>>> >> However, by V05.04 of RT-11, DEC developed the SD(X).SYS device
>>> >> driver which allowed a program to have a BPT instruction without the
>>> >> requirement to include ODT as part of the code. If the user LOADed
>>> >> SDX.SYS prior to executing the program with the BPT, but without
>>> >> ODT included, the code in SDX.SYS initialized the required VECTOR
>>> >> to trap the BPT instruction when SDX.SYS was LOADed. The code
>>> >> in SDX.SYS then performed all of the functions that ODT supported
>>> >> (and a few others as well) without adding any extra code to the program
>>> >> being tested. It is even possible to place a BPT in the monitor code
>>> >> and test those instructions as well.
>> >
>> > Ok. So, no symbol table stuff, and no possibility to add breakpoints,
>> > watchpoints and other stuff in the program until you hit atleast one
>> > BPT in the code which cause the code in SDX to be called?
>
> Actually, no! A symbol table is allowed, but I normally never use one
> since the listing of the program has always been sufficient. Also, if the
> code is already loaded into a known location in memory (e.g. the RT-11
> Resident Monitor), it is possible to place a BPT in the desired instruction.
How does the device driver know what symbol table to load? Or is it just
that you can load a symbol table when you are in the debugger, if you
want to? And hopefully you will load the right symbol table at that
point, if you are interested?
>> > RT11 is a single user system, where the OS do so much less for you
>> > that this concept is even possible. For more complex systems, you
>> > cannot do things this way.
>
> AGREED!!
Good. So then we can perhaps lay the idea of this SD(X).SYS driver in
any form being available, or even possible, under RSTS/E or RSX to rest. :-)
Johnny
Hey;
I was going to bin these, but I thought I'd ask just in case anyone placed
any value on them (I can't imagine it, but you never know).
I have three or four Commodore64 boxes, including packing foam (I think),
three breadbox style, one C64c. I do -not- have the Commodores that match
the serial numbers on the box, so they're of no interest to me.
Free for pickup or shipping. I'll wait until the weekend and then
ceremonially burn them while reading excerpts from my Technical Reference
Manual and sprinkling the ground with Jolt Cola.
- JP
Hampton, Iowa (50441)
On 7/27/10, Charlie Carothers <csquared3 at tx.rr.com> wrote:
> Tony Duell wrote:
>> All decent buses allow you to share interrupts -- the ''design' of the
>> interrupt suystem on the ISA bus is one reason to hate that bus..
>>
>> Very well designed buses (Unibus :-)) have each card send an interrupt
>> vector which directs the CPU to the right ISR.
>
> ... I'm just curious as to how each card knows what interrupt
> vector value to send? Jumpers/switches on each card?
Can be done that way...
> A "Unibus Interrupt Vector Value Guru" somewhere who assigns the values?
In a sense, yes....
All the way back to 1970, DEC published lists in various system
handbooks about their own breakdown of assigned CSRs (Control Status
Register - typically the first I/O address that the card responds do,
though there's no way to magically know how many addresses a card will
answer at) an interrupt vectors for disk controllers, comms
controllers, etc. For older devices, DEC would reserve up to four
locations for a given interface, allowing for primary through
quaternary cards to be installed on the same bus. Later, there was
typically a primary address given, then a scheme to calculate a
non-conflicting "floating" address, but by then folks were rarely
installing four of anything except perhaps serial interfaces or MSCP
disk interfaces.
I can give an example of how this worked in practice by describing a
3rd-party device I used to make and maintain, the COMBOARD. It wasn't
on DEC's list, so we picked an arbitrary CSR up in "unassigned" space.
We gave our customers a list of eight preferred CSR addresses to use,
though any address in the I/O page would work. The user set the CSR
address on a 10-position DIP switch, then, once the machine was
powered on and running, would load the driver and tell it, via setup
files, what CSR the card(s) will respond at. Our product had a 16-bit
double-one-way register we called "the window". If the PDP-11/VAX
wrote a value, the 68000 on the card could read it, and if the 68000
wrote a value, the PDP-11/VAX could read it (a processor could never
read back the value that it just wrote). One of the values passed
during initialization was the vector to use (as stated in a config
file that was written by the user, or by us as a factory default).
The board would retain that value and drop it on the bus during an
interrupt request.
So for our product, the CSR was set by switches that were not meant to
be changed, but the interrupt vector could be changed at every reboot.
Real DEC devices did a number of different things, the older ones
typically relying on jumpers or switches, the newer devices relying on
some mechanism to assign or calculate the values dynamically.
In practice, there weren't as many kinds of interfaces for the Unibus
as there ended up being for the ISA bus, so it may sound like anarchy,
but it wasn't. I think in 20-ish years of the hey-day of the Unibus,
they only ever reassigned CSR addresses once or twice, but it was
extremely unlikely that you'd have a particular obscure peripheral
>from 1970, literally, on the same bus as a stack of c. 1990 disk
controllers and Ethernet interfaces. Electrically, they would work
together, but logically, a user would have no need to use 20-year-old
devices. The only "old" device we ever used on our VAX-11/750 was an
LP11, an original line-printer interface. The rest of the cards in
our machine were manufactured 10-15 years later. Some of our devices,
then, had a DIP switch for CSR assignment, but not for vector
assignment. Something older, like a PDP-11/34, was probably a
different story.
-ethan
That is indeed odd. I have a DEC PWS running OpenVM S8.3 with
DecWindows and Motif... I've been meaning to get it finished and wired
into the home network. As it just so happens, I just won a sealed
copy of Exceed on EBay, which I could try out...
This won't happen immediately (large to-do list, plus I need to run to
Fry's for a network switch and some cable), but I'll give it a shot...
I've already warned my very-tolerant girlfriend that there's going to
be an ethernet cable running from the office down the hall to the
wireless router at the TV (I have U-Verse, so it has to be that way).
Mark
On Tue, Jul 27, 2010 at 3:09 PM, Rob Jarratt
<robert.jarratt at ntlworld.com> wrote:
> I would agree that it sounds odd, but the person telling me knows his stuff
> and this has been his experience. I suspect the SHM thing could be why it
> works on a real workstation, or perhaps it is some DEC-specific thing? I
> have a real workstation to try this on, I will have to dig it out and give
> it a go myself.
>
> Regards
>
> Rob
>
>> -----Original Message-----
>> From: cctalk-bounces at classiccmp.org [mailto:cctalk-
>> bounces at classiccmp.org] On Behalf Of Dave McGuire
>> Sent: 27 July 2010 22:34
>> To: General Discussion: On-Topic and Off-Topic Posts
>> Subject: Re: Colour Digital Logo on DECwindows Login
>>
>> On 7/27/10 5:27 PM, Rob Jarratt wrote:
>> > I am using Exceed to run an X server on my PC. I would like it to
>> show a
>> > colour logo like in this screenshot: :
>> > http://toastytech.com/guis/DWlogin.gif but all I get is monochrome on
>> the
>> > login screen. A friend has suggested that you only get colour on real
>> > workstations. Does anyone know how to get the colour login on Exceed?
>>
>> ? I don't know anything about Exceed so I can't answer your specific
>> question, but your friend doesn't know jack squat about X. ;) ?X
>> doesn't
>> "know" whether it's on a "real workstation" (whatever that is!) or not.
>> ?I've run dozens upon dozens of color X terminals.
>>
>> ? X clients (programs that interact with the user) connect to X servers
>> (that control keyboards/mice/video hardware) over TCP connections,
>> DECnet connections, or local sockets. ?The stuff on each end is fully
>> abstracted and has no idea of how the actual protocol data is getting
>> from place to place. ?The only time this changes that I'm aware of is
>> when the SHM (SHared Memory) extension is present and in use. ?With
>> SHM,
>> clients can pass "big" data (images and such) to the X server in a much
>> faster way.
>>
>> ? ? ? ? ? ? ?-Dave
>>
>> --
>> Dave McGuire
>> Port Charlotte, FL
>
>
On 7/27/10 5:27 PM, Rob Jarratt wrote:
> I am using Exceed to run an X server on my PC. I would like it to show a
> colour logo like in this screenshot: :
> http://toastytech.com/guis/DWlogin.gif but all I get is monochrome on the
> login screen. A friend has suggested that you only get colour on real
> workstations. Does anyone know how to get the colour login on Exceed?
I don't know anything about Exceed so I can't answer your specific
question, but your friend doesn't know jack squat about X. ;) X doesn't
"know" whether it's on a "real workstation" (whatever that is!) or not.
I've run dozens upon dozens of color X terminals.
X clients (programs that interact with the user) connect to X servers
(that control keyboards/mice/video hardware) over TCP connections,
DECnet connections, or local sockets. The stuff on each end is fully
abstracted and has no idea of how the actual protocol data is getting
>from place to place. The only time this changes that I'm aware of is
when the SHM (SHared Memory) extension is present and in use. With SHM,
clients can pass "big" data (images and such) to the X server in a much
faster way.
-Dave
--
Dave McGuire
Port Charlotte, FL
I am using Exceed to run an X server on my PC. I would like it to show a
colour logo like in this screenshot: :
http://toastytech.com/guis/DWlogin.gif but all I get is monochrome on the
login screen. A friend has suggested that you only get colour on real
workstations. Does anyone know how to get the colour login on Exceed?
Incidentally, I am also trying to use Xming as my X server (the last version
in the public domain), but I am having pretty limited success in getting
that to work with DECwindows. Does anyone have this working with DECwindows
at all?
Regards
Rob
Not my stuff; forwarded from [rescue.] Too much good stuff to get trashed, tho:
---------- Forwarded message ----------
From: Tom "spot" Callaway <tcallawa at redhat.com>
Date: Tue, Jul 27, 2010 at 2:04 PM
Subject: [rescue] Sun Systems Free for pickup in 27518
To: The Rescue List <rescue at sunhelp.org>
A friend of mine, knowing my interest in SPARCs, mentioned that his
company was about to throw away all of their SPARC systems, and asked if
I wanted them. Sadly, he's in North Carolina, and I can't justify paying
shipping on any of these, but I'd prefer to see them find good homes
than end up in a dumpster.
Here's what he's got:
1 Sparcstation 5
1 Sparcstation 20
1 Sun Ultra 5
1 Sunblade 100
2 Sun Ultra 30 ("creator")
1 Sun Ultra 60 ("creator3D")
4 Sun Ultra 10 (3 are "creator3D", 1 is "elite3D")
1 Sun Ultra 1 ("creator")
1 Sun Enterprise 220R
1 Sun Ultra Enterprise 150
These systems will likely end up in the trash in the next 24 hours
unless they're claimed. If you're interested, email Tanner
<clubjuggler at gmail.com>.
They're in Cary, NC (27518). He will not ship them, you have to pick
them up. First come, first serve.
I have no idea if this will help, but a google search for "IEEE_SEND"
brings up three references including an MT-488 PDF Technical Reference.
Chuck Guzis wrote:
> It doesn't correspond to anything that I can identify, including a
> PDP11. I'm hoping that some HP aficionado will save me the time of
> plowing through a bunch of HP reference manuals trying to identify
> this thing.
>
> Again, it might not be HP at all, but the GPIB references may be a
> clue.
I have a LA30 dot matrix printer style terminal that I am trying to get local
loop back working. It is more or less in working condition however the cord that
includes a switch that is attached to the wirewrap posts has disconnected. So if
any one has some info to where the loop back switch connects too I would be very
thankful.
Chris
