Hello!
It'll work. But you need to worry about the timing.....
-----
Gregg C Levine gregg.drwho8 at gmail.com
"This signature fought the Time Wars, time and again."
On Wed, Jan 1, 2014 at 8:41 PM, Cory Smelosky <b4 at gewt.net> wrote:
On Wed, 1 Jan 2014, Cory Smelosky wrote:
Evening,
Do RX50 schematics exist on bitsavers, fiche, or elsewhere? I have one
here and it doesn't appear to work. Testing is showing either a busted
motor or something wrong in the voltage control stuff.
Thanks!
Oops. Just found 'em up on bitsavers. Let's hope it's helpful with test
point values. I have no idea if TP1 should be 2.4008VDC or it should be a
specific waveform.
--
Cory Smelosky
http://gewt.net Personal stuff
http://gimme-sympathy.org Projects
On Wed, 1 Jan 2014, Cory Smelosky wrote:
Evening,
Do RX50 schematics exist on bitsavers, fiche, or elsewhere? I have one
here and it doesn't appear to work. Testing is showing either a busted
motor or something wrong in the voltage control stuff.
Thanks!
Oops. Just found 'em up on bitsavers. Let's hope it's helpful with test
point values. I have no idea if TP1 should be 2.4008VDC or it should be a
specific waveform.
--
Cory Smelosky
http://gewt.net Personal stuff
http://gimme-sympathy.org Projects
Evening,
Do RX50 schematics exist on bitsavers, fiche, or elsewhere? I have one
here and it doesn't appear to work. Testing is showing either a busted
motor or something wrong in the voltage control stuff.
Thanks!
--
Cory Smelosky
http://gewt.net Personal stuff
http://gimme-sympathy.org Projects
On 2014-01-01 21:32, Jerome H. Fine wrote:
>Johnny Billquist wrote:
In M+ the ability is even better, as device driver loading and
unloading is not related to devices being online or offline.
RT-11 has the same ability. A hard drive can be online
without the device driver being LOADed. If a background
program requests access to a drive, the program can perform
a temporary .FETCH to bring the device driver into memory
and then .RELEASE the device driver when finished. A system
job can't request RT-11 to perform a FETCH, so any disk
drive needed by the program must have the device driver
LOADed before the program uses the disk drive. In theory,
a system job could pause and the user could then LOAD
the device driver just before the system job uses it. MACRO-11
always attempts a .FETCH when a device driver is not already
LOADed.
Ah! Now I know what you are talking about. It's the same in OS/8.
And no, this is not at all the same thing as in RSX.
(If I have things wrong here, I apologize, since now I'm going to make a comparision between RSX and OS/8, and assume that RT-11 indeed do work the same.)
A FETCH loads a device driver from disk into memory. It's an operation you do before performing any I/O to the device. However, you can only fetch a device driver that is known to the OS. The device driver is installed by a different process, which just makes the system aware that the driver exists. You also get some sort of handle in return from a fetch, which is what you use to do I/O to the device.
In RSX, LOAD means installing the device driver into the running system. Prior to the LOAD command, RSX have no clue that the device driver exists. You never have a device driver as a part of your own address space, and several tasks can do I/O to a device concurrently.
When a device driver is loaded into the system, all device driver databases are populated, and the actual code get put somewhere in memory. Don't care where. The LOAD command do that fiddling, and the device driver databases holds enough information that the OS then can invoke the driver when needed. LOAD is a user command, which do a lot of complex operations, and is not something any program ever do on its own. It's a user initiated operation to install a (new) device driver into a running system.
However, for I/O to actually go through to the device, it must also be online.
Online can mean *two* things. The physical device itself (which is what you talk about, Jerome) must obviously be online. But the device must also be online from the driver point of view, which is a separate question. You can load a device driver in RSX, but if a physical device is not present to match it, the device driver will be offline, and any I/O to it will fail before it even comes to the device driver code.
If a physical device later comes online, the driver database does not necessarily become updated to be online. So you can have a physical device online, but still have the device driver offline, but loaded.
Unloading a device driver in RSX means that the driver code is removed from memory, the device driver database marks the device as offline, and that's it. Any memory used by the device driver is freed, so it can be used by other things, such as programs. However, the device driver database is not removed. It's not feasible to remove all possible references to the database.
So, in RSX, all programs can always do I/O to *all* devices known to the system. And without any special preparations or setups. LOAD is for adding even more devices to the known list.
(all within the restrictions of protection and device allocation, of course, which can restrict access)
Not sure exactly what your distinction between unload and remove is.
In RSX terms, you LOAD and UNLOAD device drivers. In 11M, an implicit
online of a device is done when you load it, and offline is done on a
device before unloading it. In M+ the offline and online steps are
separate commands, which just requires that a device driver is loaded.
In RT-11, a device driver must be INSTALLed and the
name placed into the Permanent Physical Device Table
before a LOAD can be performed. The INSTALL code
checks that the device driver is compatible with the
operating system parameters, among other things. A
user may then UNLOAD and REMOVE (in that order)
a device driver if a different version of the device driver
is needed, such as for testing a new version.
Yes, I see where you are coming from now. So, the RSX LOAD (which is done on the running system) is actually equivalent to the INSTALL in RT-11. There is no equivalent to the RT-11 LOAD, all devices are always available.
Even more fun is M+ is that device drivers do not need to be
recompiled if you recompile the kernel. Device drivers are totally
independent of the kernel.
Likewise in RT-11. In fact, I believe RT-11 has always
been that way.
Remember, I'm talking about the equivalent of RT-11 INSTALL here... Ie, I can do a SYSGEN, and build a totally new RSX system, but still use a device driver from a previous SYSGEN just fine. Even though the new kernel have different stuff compiled in, and databases and routines have moved to different addresses.
In respect of RSTS/E, is this possible as well or does RSTS/E
have the same requirement as TSX-Plus?
I think RSTS/E is less flexible, from what I can remember.
TSX-Plus is similar. All device drivers must be LOADed and
permanently resident at boot time.
So, how is it with RT-11. Can you INSTALL a new device driver into a running system and use it, without performing a reboot?
Johnny
On 2014-01-01 16:36, Lee Gleason wrote:
On the 11/74 you more or less had this, in the form of hotplugging
whole bus segments. One a bus segment was disconnected, you could
power it off, and remove controllers if you wanted.
This reminds me of a conversation I overheard at an RSX Magic Session,
at a DECUS symposium in the 80s. A customer was asking Brian McCarthy, a
noted RSX developer, a lot of questions about the legendary 11/74 and
the RSX11M+ additions that had been made to support it. They were
discussing the multiple Unibuses (Unibusen? Unibeese?) and the software
that controls them. The user pointed out that the three letter task name
for the Host Reconfiguration Task (HRC...) was a little tortured - it
would have made more sense to be HRT. Brian said that internally they
had called it Hercules, and HRC was the three letter abbreviation they
chose for it. The user asks, "Why Hercules?". Brian said that it took a
Hercules to wrestle the three headed dog that was the device
configuration databases involved into submission.
I think I've heard the story before. Pretty much the same thing. It would be nice to talk with Brian at some point...
And I totally understand. HRC is very complex and capable. Managing that flexibility at runtime is impressive. Current mP systems usually can not do it the way RSX can (could). There is only one thing that is tied to a specific CPU in RSX. Everything else can be done on any CPU. And that one thing is the updating of the system clock. That is done by the boot CPU. However, if the boot CPU is taken offline, I believe that task is migrated to another CPU, but I would need to check.
Johnny
>Johnny Billquist wrote:
>On 2014-01-01 14:19, Jerome H. Fine wrote:
>Johnny Billquist wrote:
RSX can boot from virtual devices.
Also, you can load and unload device drivers in RSX, but you don't
normally do that just to bring devices offline or online. That is a
separate operation from loading and unloading device drivers. But yes,
if you want to disconnect devices, buses, CPUs or memory, you can do
that just fine on a running RSX system. And bring them online again
later, if you want to. Any other trick you'd like to do? :-)
While it is extremely unlikely that I will ever run RSX-11, the
above ability surprises me. Please clarify to make sure that
I understand. It is my impression that RSX-11 requires
all device drivers to be LOADed at boot time and always
be kept LOADed. TSX-Plus has this requirement and I
guess I assumed that RSX-11 was similar.
Based on your information, I understand that RSX-11 does
support a device driver UNLOAD and REMOVE commands
(or whatever syntax is used in RSX-11 since I just used the
RT-11 syntax). So please confirm.
Yes. That is correct. You can load and unload device drivers at runtime. That is actually a very important design feature in RSX.
So your understanding about RSX have been totally wrong.
Device drivers that are currently in use can not be unloaded, however. Which means that the boot device can't be unloaded, for instance.
YES!! RT-11 has the same requirement. Sort of obvious to
anyone who actually uses the operating system.
In M+ the ability is even better, as device driver loading and unloading is not related to devices being online or offline.
RT-11 has the same ability. A hard drive can be online
without the device driver being LOADed. If a background
program requests access to a drive, the program can perform
a temporary .FETCH to bring the device driver into memory
and then .RELEASE the device driver when finished. A system
job can't request RT-11 to perform a FETCH, so any disk
drive needed by the program must have the device driver
LOADed before the program uses the disk drive. In theory,
a system job could pause and the user could then LOAD
the device driver just before the system job uses it. MACRO-11
always attempts a .FETCH when a device driver is not already
LOADed.
One aspect of the FETCH is that for a Mapped version of
RT-11, the code can be placed in an address which is not
allowed for LOADed device drivers. This often takes place
when a background job is executed as a virtual job under
the program VBGEXE and the Low Memory from 1000
octal to 40000 octal is then available. At least a stub of
all device drivers much be in Low Memory even if the
device driver also uses Extended Memory (one of the
other things that INSTALL does is to set up the Extended
Memory portion of any device driver).
Not sure exactly what your distinction between unload and remove is.
In RSX terms, you LOAD and UNLOAD device drivers. In 11M, an implicit online of a device is done when you load it, and offline is done on a device before unloading it. In M+ the offline and online steps are separate commands, which just requires that a device driver is loaded.
In RT-11, a device driver must be INSTALLed and the
name placed into the Permanent Physical Device Table
before a LOAD can be performed. The INSTALL code
checks that the device driver is compatible with the
operating system parameters, among other things. A
user may then UNLOAD and REMOVE (in that order)
a device driver if a different version of the device driver
is needed, such as for testing a new version.
Even more fun is M+ is that device drivers do not need to be recompiled if you recompile the kernel. Device drivers are totally independent of the kernel.
Likewise in RT-11. In fact, I believe RT-11 has always
been that way.
Also, file systems are also separate, and handled by something called an ACP, which is a separate task. This means that you can have different types of file systems on different disks.
ACPs hook into device drivers, but device drivers have no clue about ACPs.
Not available in RT-11 except maybe as part of the actual
user program.
In respect of RSTS/E, is this possible as well or does RSTS/E
have the same requirement as TSX-Plus?
I think RSTS/E is less flexible, from what I can remember.
TSX-Plus is similar. All device drivers must be LOADed and
permanently resident at boot time.
Jerome Fine
From: "Lee Gleason" <lee.gleason at comcast.net>
multiple Unibuses (Unibusen? Unibeese?)
"Unibi".
The
user asks, "Why Hercules?". Brian said that it took a Hercules to wrestle
the three headed dog that was the device configuration databases involved
into submission.
Nice. Well I guess if TGHA makes sense ("The Great Heuristic Algorithm" --
um, for spare columns in ECC memory, right?), this makes a lot more sense...
John Wilson
D Bit
From: "Jerome H. Fine" <jhfinedp3k at compsys.to>
In respect of RSTS/E, is this possible as well or does RSTS/E
have the same requirement as TSX-Plus?
RSTS doesn't have loadable drivers, so it all has to be genned into the
system (and user-written drivers aren't officially supported). On the plus
side, RSTS autosizes the system on every boot (including floating CSRs, and
all vectors except card readers are autodetected so they don't need to follow
the rules at all -- user-written drivers would have to be hooked up to this
too), and passes CSR/vector/model information to the drivers that it enables.
So while RSTS requires the drivers to be linked to the system, it's not a
totally rigid mass that works only on the exact config it was built for.
You can run a monitor on totally different hardware and as long as it has
drivers for enough of the existing peripherals to work, you're all set.
Also, you can have multiple monitors (built different ways) on the same
pack and tell the pre-boot thingy (INIT.SYS) which one to boot.
John Wilson
D Bit
On the 11/74 you more or less had this, in the form of hotplugging whole bus segments. One a bus segment was disconnected, you could power it off, and remove controllers if you wanted.
This reminds me of a conversation I overheard at an RSX Magic Session, at a DECUS symposium in the 80s. A customer was asking Brian McCarthy, a noted RSX developer, a lot of questions about the legendary 11/74 and the RSX11M+ additions that had been made to support it. They were discussing the multiple Unibuses (Unibusen? Unibeese?) and the software that controls them. The user pointed out that the three letter task name for the Host Reconfiguration Task (HRC...) was a little tortured - it would have made more sense to be HRT. Brian said that internally they had called it Hercules, and HRC was the three letter abbreviation they chose for it. The user asks, "Why Hercules?". Brian said that it took a Hercules to wrestle the three headed dog that was the device configuration databases involved into submission.
--
Lee K. Gleason N5ZMR
Control-G Consultants
lee.gleason at comcast.net
---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com
On 2014-01-01 14:19, Jerome H. Fine wrote:
>Johnny Billquist wrote:
RSX can boot from virtual devices.
Also, you can load and unload device drivers in RSX, but you don't
normally do that just to bring devices offline or online. That is a
separate operation from loading and unloading device drivers. But yes,
if you want to disconnect devices, buses, CPUs or memory, you can do
that just fine on a running RSX system. And bring them online again
later, if you want to. Any other trick you'd like to do? :-)
While it is extremely unlikely that I will ever run RSX-11, the
above ability surprises me. Please clarify to make sure that
I understand. It is my impression that RSX-11 requires
all device drivers to be LOADed at boot time and always
be kept LOADed. TSX-Plus has this requirement and I
guess I assumed that RSX-11 was similar.
Based on your information, I understand that RSX-11 does
support a device driver UNLOAD and REMOVE commands
(or whatever syntax is used in RSX-11 since I just used the
RT-11 syntax). So please confirm.
Yes. That is correct. You can load and unload device drivers at runtime. That is actually a very important design feature in RSX.
So your understanding about RSX have been totally wrong.
Device drivers that are currently in use can not be unloaded, however. Which means that the boot device can't be unloaded, for instance.
In M+ the ability is even better, as device driver loading and unloading is not related to devices being online or offline.
Not sure exactly what your distinction between unload and remove is.
In RSX terms, you LOAD and UNLOAD device drivers. In 11M, an implicit online of a device is done when you load it, and offline is done on a device before unloading it. In M+ the offline and online steps are separate commands, which just requires that a device driver is loaded.
Even more fun is M+ is that device drivers do not need to be recompiled if you recompile the kernel. Device drivers are totally independent of the kernel.
Also, file systems are also separate, and handled by something called an ACP, which is a separate task. This means that you can have different types of file systems on different disks.
ACPs hook into device drivers, but device drivers have no clue about ACPs.
In respect of RSTS/E, is this possible as well or does RSTS/E
have the same requirement as TSX-Plus?
I think RSTS/E is less flexible, from what I can remember.
Johnny
>Johnny Billquist wrote:
RSX can boot from virtual devices.
Also, you can load and unload device drivers in RSX, but you don't normally do that just to bring devices offline or online. That is a separate operation from loading and unloading device drivers. But yes, if you want to disconnect devices, buses, CPUs or memory, you can do that just fine on a running RSX system. And bring them online again later, if you want to. Any other trick you'd like to do? :-)
While it is extremely unlikely that I will ever run RSX-11, the
above ability surprises me. Please clarify to make sure that
I understand. It is my impression that RSX-11 requires
all device drivers to be LOADed at boot time and always
be kept LOADed. TSX-Plus has this requirement and I
guess I assumed that RSX-11 was similar.
Based on your information, I understand that RSX-11 does
support a device driver UNLOAD and REMOVE commands
(or whatever syntax is used in RSX-11 since I just used the
RT-11 syntax). So please confirm.
In respect of RSTS/E, is this possible as well or does RSTS/E
have the same requirement as TSX-Plus?
Jerome Fine
On 2014-01-01 08:33, Cory Smelosky wrote:
On Wed, 1 Jan 2014, Johnny Billquist wrote:
RSX can boot from virtual devices.
Also, you can load and unload device drivers in RSX, but you don't normally do
that just to bring devices offline or online. That is a separate operation
from loading and unloading device drivers. But yes, if you want to disconnect
devices, buses, CPUs or memory, you can do that just fine on a running RSX
system. And bring them online again later, if you want to. Any other trick
you'd like to do? :-)
Now if only UNIBUS hotplug/hotremove existed. ;)
On the 11/74 you more or less had this, in the form of hotplugging whole bus segments. One a bus segment was disconnected, you could power it off, and remove controllers if you wanted.
Johnny
From: Cory Smelosky <b4 at gewt.net>
Now if only UNIBUS hotplug/hotremove existed. ;)
Officially, it does (if you have a DT03 or DT07 bus switch).
Pretty rare though...
John Wilson
D Bit
On Wed, 1 Jan 2014, Johnny Billquist wrote:
RSX can boot from virtual devices.
Also, you can load and unload device drivers in RSX, but you don't normally do
that just to bring devices offline or online. That is a separate operation
from loading and unloading device drivers. But yes, if you want to disconnect
devices, buses, CPUs or memory, you can do that just fine on a running RSX
system. And bring them online again later, if you want to. Any other trick
you'd like to do? :-)
Now if only UNIBUS hotplug/hotremove existed. ;)
Johnny
--
Cory Smelosky
http://gewt.net Personal stuff
http://gimme-sympathy.org Projects
On 2014-01-01 00:52, Jerome H. Fine wrote:
>John Wilson wrote:
The order of dependence on strictly working (and/or accurately emulated)
hardware goes: RT => RSX => RSTS. So the fact that something works
with RT proves *nothing*! (I've learned this the hard way so many
times.)
Of course, looked at another way, it's nice of RT to be willing to run
on hardware that's not long for this world...
... OR the CSR for the hardware and the device driver do not
match. Fortunately, RT-11 allows the user to change the
CSR after the boot (for a data device obviously). After that,
the user can INSTALL and LOAD.
RT-11 also supports UNLOAD and REMOVE if a user
needs to power down a data hard drive and physically replace
that drive with a different hard drive. This is really especially
helpful with MSCP devices. If the user has ONLY the single
controller to boot RT-11, VM: can be used to hold the few
essential files required by the operating system. At that point,
the hard drive on an MSCP device can have the power
and cable removed (after the RT-11 UNLOAD and REMOVE)
and a different hard drive substituted (followed by the RT-11
INSTALL and LOAD commands). Try doing that on RSX-11
or RSTS/E.
RSX can boot from virtual devices.
Also, you can load and unload device drivers in RSX, but you don't normally do that just to bring devices offline or online. That is a separate operation from loading and unloading device drivers. But yes, if you want to disconnect devices, buses, CPUs or memory, you can do that just fine on a running RSX system. And bring them online again later, if you want to. Any other trick you'd like to do? :-)
Johnny
On Tue, 31 Dec 2013, Dave McGuire wrote:
...or rather, sidestepped. I asked about this issue yesterday in case
anyone had a quick "problem X can definitely cause that" response,
before diving in with XXDP, etc. I checked power and configuration, all
good, so I...dove in with XXDP.
I have three 11/24 CPUs. Two of them drop to ODT when I run the JKDA
diag, for the F11 MMU. Those two also report errors in every MS11-P
board that I have (about eight) at the end of every 16KB "page" of
memory during the ZMSP test. The third board passes all tests, and runs
RSX11M's ACF without hanging. It's running sysgen now, and I expect the
new executive to boot fine.
Aren't memory errors annoying? They cause problems somewhere...but not
elsewhere!
Something is clearly up with those other two boards.
-Dave
--
Cory Smelosky
http://gewt.net Personal stuff
http://gimme-sympathy.org Projects
>John Wilson wrote:
The order of dependence on strictly working (and/or accurately emulated)
hardware goes: RT => RSX => RSTS. So the fact that something works
with RT proves *nothing*! (I've learned this the hard way so many times.)
Of course, looked at another way, it's nice of RT to be willing to run
on hardware that's not long for this world...
... OR the CSR for the hardware and the device driver do not
match. Fortunately, RT-11 allows the user to change the
CSR after the boot (for a data device obviously). After that,
the user can INSTALL and LOAD.
RT-11 also supports UNLOAD and REMOVE if a user
needs to power down a data hard drive and physically replace
that drive with a different hard drive. This is really especially
helpful with MSCP devices. If the user has ONLY the single
controller to boot RT-11, VM: can be used to hold the few
essential files required by the operating system. At that point,
the hard drive on an MSCP device can have the power
and cable removed (after the RT-11 UNLOAD and REMOVE)
and a different hard drive substituted (followed by the RT-11
INSTALL and LOAD commands). Try doing that on RSX-11
or RSTS/E.
Jerome Fine
Sure thing.
Michael Holmes
5922 Langton Drive
Alexandria, VA 22310
USA
Sent from my iPhone
On Dec 30, 2013, at 7:29 PM, "Sampsa Laine" <sampsa at mac.com> wrote:
Dude,
I'm pretty sure you're gonna win this with like less than 24 hours to go, can you send me your mailing address so I can mail the cert + prize to you :)
sampsa <sampsa at mac.com>
mobile +44 7961 149465
On 30 Nov 2013, at 03:18, Michael Holmes <mholmes10 at hotmail.com> wrote:
hey Sampas,
I played and got a high score..
Not sure how to "screen shot" on Mac, but cut and pasted the following from terminal to help verify it.
Oct TETRIS Mark Wickens 7640 1 TETRIS Mike Holmes 9816 18
Sep TETRIS DRB 1040 2 SAMPSA 130 1
Aug SAMPSA [A 126
Jul TETRIS Lanny 740
Jun TETRIS volal 11860
May TETRIS tiguco 2799
Apr TETRIS 14
Mar TETRIS TooCool4Web 4430
Feb TETRIS u 1567
Jan TETRIS 268
Dec TETRIS 128
Nov TETRIS 585
You Are Seated At 1 In tetris Previous Score 2000
Enter Your Name [ Return to Leave ] Current Score 9816
%DCL-E-CAPTINT, captive account - interactive access denied
TETRIS logged out at 30-NOV-2013 03:46:58.48
%REM-S-END, control returned to node MASON::
$
thanks Mike
----------------------------------------
From: sampsa at mac.com
Subject: [HECnet] CHIMPY Retro Tetris Update
Date: Fri, 15 Nov 2013 12:47:15 +0200
To: hecnet at Update.UU.SE
CHIMPY Retro Tetris Update:
Mark Wickens is in the lead with a score of 7,640, followed by Vilaca with 1,574 (score not verified with screenshot so might not count).
Guys, we're still running until 23:59:00 GMT on 31-DEC-2013 so there's plenty of time to win random Arabic money AND certificates of Tetris awesomeness.
Telnet to CHIMPY.SAMPSA.COM or SET HOST CHIMPY, log in as TETRIS.
REMEMBER TO SCREENSHOT YOUR RESULT IF YOU GET A NEW HIGHSCORE. Or at least write down what date/time/node you came from if SET HOST, so I can verify the score..
sampsa <sampsa at mac.com>
mobile +358 40 7208932
On 12/31/2013 01:03 PM, John Wilson wrote:
When do you say it hangs, do you mean it's looping (executing PDP-11
code -- might be worth seeing what and/or looking at the stack to see
how it got there), or that the bus is hung and the CPU is stuck?
I didn't investigate to that level. I just figured I'd fire the
question at the gang here since it'd been so long since I'd messed with RSX.
The hardware is, as far as I can tell, otherwise fine. I built the
system up from parts a few weeks ago, and have exercised it with RT-11.
The order of dependence on strictly working (and/or accurately emulated)
hardware goes: RT => RSX => RSTS. So the fact that something works
with RT proves *nothing*! (I've learned this the hard way so many times.)
Indeed...I've been bitten by that a few times as well. Like this time. ;)
Of course, looked at another way, it's nice of RT to be willing to run
on hardware that's not long for this world...
True. ;)
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
...or rather, sidestepped. I asked about this issue yesterday in case
anyone had a quick "problem X can definitely cause that" response,
before diving in with XXDP, etc. I checked power and configuration, all
good, so I...dove in with XXDP.
I have three 11/24 CPUs. Two of them drop to ODT when I run the JKDA
diag, for the F11 MMU. Those two also report errors in every MS11-P
board that I have (about eight) at the end of every 16KB "page" of
memory during the ZMSP test. The third board passes all tests, and runs
RSX11M's ACF without hanging. It's running sysgen now, and I expect the
new executive to boot fine.
Something is clearly up with those other two boards.
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
From: Dave McGuire <mcguire at neurotica.com>
I've run into a snag, though. I'm trying to allow sysgen to
autoconfigure the hardware via ACF, and it hangs on my 11/24 system.
I've tried with both 4.3 and 4.6. Thinking it might have something to
do with my recently-installed and untested DELUA, I removed it, but I
get the same result.
No guarantees but might give useful data: do you have any RSTS lying
around? Its INIT.SYS (the pre-boot system) is *very* ladylike about
frotzed hardware, so it may well pop up a message that leads directly
to the problem, just on the way to that first prompt (and if you do get
that far, "HA LI" might tell you about surprises in your config).
When do you say it hangs, do you mean it's looping (executing PDP-11
code -- might be worth seeing what and/or looking at the stack to see
how it got there), or that the bus is hung and the CPU is stuck?
The hardware is, as far as I can tell, otherwise fine. I built the
system up from parts a few weeks ago, and have exercised it with RT-11.
The order of dependence on strictly working (and/or accurately emulated)
hardware goes: RT => RSX => RSTS. So the fact that something works
with RT proves *nothing*! (I've learned this the hard way so many times.)
Of course, looked at another way, it's nice of RT to be willing to run
on hardware that's not long for this world...
John Wilson
D Bit
>Johnny Billquist wrote:
>On 2013-12-31 02:53, Dave McGuire wrote:
>On 12/27/2013 04:16 AM, goran ahling wrote:
As I remember the SYSGEN/NETGEN task, the controller intended for DECnet
should NOT be taken into SYSGEN at all, but later, at the totally
separate task of performing NETGEN once Your OS. is up and running, it
should be included there. So, no need to redo your SYSGEN when playing
with different Ethernet cards.
Ahh, excellent. Thank you.
I've run into a snag, though. I'm trying to allow sysgen to
autoconfigure the hardware via ACF, and it hangs on my 11/24 system.
I've tried with both 4.3 and 4.6. Thinking it might have something to
do with my recently-installed and untested DELUA, I removed it, but I
get the same result.
So I completed sysgens via manual hardware configuration entry, both
with and without the DELUA. Both sysgen runs completed successfully,
but the system hangs when I try to boot the new executive.
The hardware is, as far as I can tell, otherwise fine. I built the
system up from parts a few weeks ago, and have exercised it with RT-11.
Everything seems ok. The baseline RSX system boots just fine.
I've set up an identically-configured instance of simh, and run
through the same process on that, and it works.
My next step is to pull it out of the rack and triple check things
like the memory boards' CSRs and such, etc., but I thought I'd ask here
first.
I last ran an RSX sysgen almost thirty years ago, and I barely
remember it at all...but I'm certain nothing like this happened. That
was on an 11/34 with RL01s, RL02s, and RK07s.
Any thoughts?
Others have come with some suggestions. I'll stick my neck out and say that some device isn't working properly. RSX probes and kicks devices at startup (check that they respond to their CSRs, and for some check that they generate interrupts). I don't think RT-11 do that as much. Also, it might be that the device in question isn't even configured in RT-11.
When both autoconfigure fails and a generated system fails, it's one of the controllers that you have genned in that is causing you problems.
Anyway. My first suspicion would be a DMA controller with the NPR wire still in place. But there might be some other controller broken as well.
I do not think you have power problems, although I wouldn't totally rule it out. But I would expect you to see problems with RT-11 as well, if that was the case. Or with the Baseline RSX system.
What you do see is typical of one specific controller blocking you. Unfortunately, with 11M it isn't that easy to spot which one, as the probing of the controller are done automatically right at the start of the booting.
In M+ it is done in a different way, which makes it easier to troubleshoot.
Happy New Year to everyone who uses the Common Era calendar,
since by the time this reply is read, New Year's day of 2014 will have
already started for some individuals.
In addition, if anyone who is reading this still uses RT-11 to change
RT-11 programs and uses the RT-11 Symbolic Debugger, SD:, I
have a question at the very end.
I can offer a few comments on the basic operations which occur when
RT-11 boots, but only at the operating system level. I am not aware of
exactly what occurs within each device driver, let alone the exact details
of the code in the installation section of any device driver.
During an RT-11 boot, other than the device driver which is used as the
system device, RT-11 only attempts to INSTALL the other device drivers.
If I remember correctly, RT-11 checks all the files on the system device
to determine if they are valid device drivers for the operating system
which is being booted. Both Mapped and UnMapped operating
systems (specifically the file for the operating system) can coexist on
the same system device along with separate device drivers for both
types of operating systems.
The primary boot code for RT-11 (at least after V04.00 of RT-11
in 1980) was a single block in block zero of the system device and was
obtained from the device driver and written into block zero along
with the secondary boot code in blocks 2, 3, 4 and 5 via:
COPY/BOOT DL0:RT11FB.SYS DL0:
as just one example for the RL01 / RL02 devices with an UnMapped
variant of the RT-11 operating system. The primary boot code is from
the device driver, DL0:DL.SYS, while the secondary boot code is from
the operating system file, DL0:RT11FB.SYS
During the RT-11 boot, RT-11 attempts to INSTALL all the device
drivers on the system device which are compatible with the operating
system. In general, RT-11 attempts to execute the installation code
from each compatible device driver which, except for the resident
system device, consists of an access to the IOPAGE registers that
are used by the device driver. Sometimes the device driver file
contains additional code, but if I remember correctly, no data device
driver (all devices are data devices if they are not the system device)
in RT-11 requires any interrupts.
So if booting RSX-11 requires device interrupts, that might be the reason.
You could attempt to isolate the device responsible in RT-11 by an
attempt to use each device driver after RT-11 boots.
As for using SD: (the RT-11 Symbolic Debugger), does anyone find
that SDHX.SYS uses too much low memory (1125 words)? Would
having an option to retain the Program Counter Locations (at least
the last 1000 addresses executed - in a circular buffer, of course) be
of help in debugging RT-11 code? Another option which I would
appreciate would be the ability to support the temporary execution
of other jobs while the current job being execution is placed into
.Wait state. Does anyone else agree? Under TSX-Plus and RSX-11,
that happens automatically, in addition to using VDT under RT-11.
BUT, SDHX.SYS freezes the complete RT-11 system when the
code being debugged is stopped at a break point.
Jerome Fine
On 2013-12-31 02:53, Dave McGuire wrote:
On 12/27/2013 04:16 AM, goran ahling wrote:
As I remember the SYSGEN/NETGEN task, the controller intended for DECnet
should NOT be taken into SYSGEN at all, but later, at the totally
separate task of performing NETGEN once Your OS. is up and running, it
should be included there. So, no need to redo your SYSGEN when playing
with different Ethernet cards.
Ahh, excellent. Thank you.
I've run into a snag, though. I'm trying to allow sysgen to
autoconfigure the hardware via ACF, and it hangs on my 11/24 system.
I've tried with both 4.3 and 4.6. Thinking it might have something to
do with my recently-installed and untested DELUA, I removed it, but I
get the same result.
So I completed sysgens via manual hardware configuration entry, both
with and without the DELUA. Both sysgen runs completed successfully,
but the system hangs when I try to boot the new executive.
The hardware is, as far as I can tell, otherwise fine. I built the
system up from parts a few weeks ago, and have exercised it with RT-11.
Everything seems ok. The baseline RSX system boots just fine.
I've set up an identically-configured instance of simh, and run
through the same process on that, and it works.
My next step is to pull it out of the rack and triple check things
like the memory boards' CSRs and such, etc., but I thought I'd ask here
first.
I last ran an RSX sysgen almost thirty years ago, and I barely
remember it at all...but I'm certain nothing like this happened. That
was on an 11/34 with RL01s, RL02s, and RK07s.
Any thoughts?
Others have come with some suggestions. I'll stick my neck out and say that some device isn't working properly. RSX probes and kicks devices at startup (check that they respond to their CSRs, and for some check that they generate interrupts). I don't think RT-11 do that as much. Also, it might be that the device in question isn't even configured in RT-11.
When both autoconfigure fails and a generated system fails, it's one of the controllers that you have genned in that is causing you problems.
Anyway. My first suspicion would be a DMA controller with the NPR wire still in place. But there might be some other controller broken as well.
I do not think you have power problems, although I wouldn't totally rule it out. But I would expect you to see problems with RT-11 as well, if that was the case. Or with the Baseline RSX system.
What you do see is typical of one specific controller blocking you. Unfortunately, with 11M it isn't that easy to spot which one, as the probing of the controller are done automatically right at the start of the booting.
In M+ it is done in a different way, which makes it easier to troubleshoot.
Johnny
Hello!
Cory being right around here is almost dangerous, especially since its
dangerous to be too right too soon. (Or however that goes.)
Actually that is always the first thing to consider.
-----
Gregg C Levine gregg.drwho8 at gmail.com
"This signature fought the Time Wars, time and again."
On Mon, Dec 30, 2013 at 11:16 PM, Cory Smelosky <b4 at gewt.net> wrote:
On Mon, 30 Dec 2013, Gregg Levine wrote:
Hello!
Do what I do when I get confronted by a very unhappy system. Examine
all of the steps you followed to get that far. And remember, the
system you are looking at has a reason for being unhappy, and it
probably isn't yourself.
I stick with my PSU theory. ;>
-----
Gregg C Levine gregg.drwho8 at gmail.com
"This signature fought the Time Wars, time and again."
On Mon, Dec 30, 2013 at 8:53 PM, Dave McGuire <mcguire at neurotica.com> wrote:
On 12/27/2013 04:16 AM, goran ahling wrote:
As I remember the SYSGEN/NETGEN task, the controller intended for DECnet
should NOT be taken into SYSGEN at all, but later, at the totally
separate task of performing NETGEN once Your OS. is up and running, it
should be included there. So, no need to redo your SYSGEN when playing
with different Ethernet cards.
Ahh, excellent. Thank you.
I've run into a snag, though. I'm trying to allow sysgen to
autoconfigure the hardware via ACF, and it hangs on my 11/24 system.
I've tried with both 4.3 and 4.6. Thinking it might have something to
do with my recently-installed and untested DELUA, I removed it, but I
get the same result.
So I completed sysgens via manual hardware configuration entry, both
with and without the DELUA. Both sysgen runs completed successfully,
but the system hangs when I try to boot the new executive.
The hardware is, as far as I can tell, otherwise fine. I built the
system up from parts a few weeks ago, and have exercised it with RT-11.
Everything seems ok. The baseline RSX system boots just fine.
I've set up an identically-configured instance of simh, and run
through the same process on that, and it works.
My next step is to pull it out of the rack and triple check things
like the memory boards' CSRs and such, etc., but I thought I'd ask here
first.
I last ran an RSX sysgen almost thirty years ago, and I barely
remember it at all...but I'm certain nothing like this happened. That
was on an 11/34 with RL01s, RL02s, and RK07s.
Any thoughts?
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
--
Cory Smelosky
http://gewt.net Personal stuff
http://gimme-sympathy.org Projects
On Mon, 30 Dec 2013, Gregg Levine wrote:
Hello!
Do what I do when I get confronted by a very unhappy system. Examine
all of the steps you followed to get that far. And remember, the
system you are looking at has a reason for being unhappy, and it
probably isn't yourself.
I stick with my PSU theory. ;>
-----
Gregg C Levine gregg.drwho8 at gmail.com
"This signature fought the Time Wars, time and again."
On Mon, Dec 30, 2013 at 8:53 PM, Dave McGuire <mcguire at neurotica.com> wrote:
On 12/27/2013 04:16 AM, goran ahling wrote:
As I remember the SYSGEN/NETGEN task, the controller intended for DECnet
should NOT be taken into SYSGEN at all, but later, at the totally
separate task of performing NETGEN once Your OS. is up and running, it
should be included there. So, no need to redo your SYSGEN when playing
with different Ethernet cards.
Ahh, excellent. Thank you.
I've run into a snag, though. I'm trying to allow sysgen to
autoconfigure the hardware via ACF, and it hangs on my 11/24 system.
I've tried with both 4.3 and 4.6. Thinking it might have something to
do with my recently-installed and untested DELUA, I removed it, but I
get the same result.
So I completed sysgens via manual hardware configuration entry, both
with and without the DELUA. Both sysgen runs completed successfully,
but the system hangs when I try to boot the new executive.
The hardware is, as far as I can tell, otherwise fine. I built the
system up from parts a few weeks ago, and have exercised it with RT-11.
Everything seems ok. The baseline RSX system boots just fine.
I've set up an identically-configured instance of simh, and run
through the same process on that, and it works.
My next step is to pull it out of the rack and triple check things
like the memory boards' CSRs and such, etc., but I thought I'd ask here
first.
I last ran an RSX sysgen almost thirty years ago, and I barely
remember it at all...but I'm certain nothing like this happened. That
was on an 11/34 with RL01s, RL02s, and RK07s.
Any thoughts?
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
--
Cory Smelosky
http://gewt.net Personal stuff
http://gimme-sympathy.org Projects
