test-drb

test-drb@ccmp.vtda.org

101090 discussions

by bqt＠softjar.se

"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

15 years, 8 months

Original Commodore64 boxes

by jplist2008＠kiwigeek.com

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)

15 years, 8 months

Colour Digital Logo on DECwindows Login

by legalize＠xmission.com

In article <004d01cb2e20$b68016b0$23804410$@jarratt at ntlworld.com>, "Rob Jarratt" <robert.jarratt at ntlworld.com> writes: > What I neglected to say was that I *do* get colour, but only after logging > in. Sorry I forgot to mention that, I realise it is probably quite an > important detail. It is only the login screen that is monochrome. Are you using xdm? <http://en.wikipedia.org/wiki/X_display_manager_(program_type)> -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/> Legalize Adulthood! <http://legalizeadulthood.wordpress.com>

15 years, 8 months

IRQs and such (was Re: Serial interfaces)

by ethan.dicks＠gmail.com

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

15 years, 8 months

Colour Digital Logo on DECwindows Login

by mdavidson1963＠gmail.com

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

15 years, 8 months

Colour Digital Logo on DECwindows Login

by mcguire＠neurotica.com

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

15 years, 8 months

Colour Digital Logo on DECwindows Login

by robert.jarratt＠ntlworld.com

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

15 years, 8 months

Fwd: [rescue] Sun Systems Free for pickup in 27518

by silent700＠gmail.com

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.

15 years, 8 months

2026

2025

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