9 Mar
2005
9 Mar
'05
11:28 p.m.
I believe you want something like the following (my
notes aren't handy at
the moment).
SET DU0: UNIT=0,PART=0
SET DU1: UNIT=0,PART=1
SET DU2: UNIT=0,PART=2
SET DU3: UNIT=1,PART=0
Although these will work, I have found that for purposes of simplicity,
and maximizing the ability to boot a given disk on multiple
configurations, it is best to use the lower DU unit numbers for physical
drives, and the higher ones for logical mappings.
So, for example, I would have
SET DU0 UNIT=0 PART=0
SET DU1 UNIT=1 PART=0
SET DU2 UNIT=2 PART=0
SET DU3 UNIT=3 PART=0
SET DU4 UNIT=0 PART=1
SET DU5 UNIT=0 PART=2
(when you use the 64-unit version of the driver, you're on your own...:-)
Megan Gentry
Former RT-11 Developer
+--------------------------------+-------------------------------------+
| Megan Gentry, EMT/B, PP-ASEL,ST| email: mbg at world.std.com |
| Member of Technical Staff | megan at savaje.com |
| SavaJe Technologies, Inc. | (s/ at /@/) |
| 100 Apollo Drive | URL: http://world.std.com/~mbg/ |
| Chelmsford, MA 01824 | "pdp-11 programmer - some assembler |
| (978) 256 6521 (DEC '77-'98) | required." - mbg KB1FCA |
+--------------------------------+-------------------------------------+
12 Mar
12 Mar
9:35 p.m.
Megan wrote:
Although these will work, I have found that for
purposes of simplicity,
and maximizing the ability to boot a given disk on multiple
configurations, it is best to use the lower DU unit numbers for physical
drives, and the higher ones for logical mappings.
So, for example, I would have
SET DU0 UNIT=0 PART=0
SET DU1 UNIT=1 PART=0
SET DU2 UNIT=2 PART=0
SET DU3 UNIT=3 PART=0
SET DU4 UNIT=0 PART=1
SET DU5 UNIT=0 PART=2
Jerome Fine replies:
The above works fine with an RD53. If you add a second
RD53. then add:
SET DU6: UNIT=1 PART=1
SET DU7: UNIT=1 PART=2
at which point the RX50 floppy is DU2: and DU3:
I might add that a hardware boot on an MSCP drive can
be done ONLY (well there are a few exceptions that
very experienced RT-11 users have fun with) when:
SET DUn: UNIT=n PART=0
which is why Megan and I suggest that the lower DU
unit numbers be used for the same UNIT numbers with
a PART=0.
When you use the 64-unit version of the driver,
you're on your own...:-)
Megan, if you are reading this, might it be
possible to expand the number of units to
128 or even 256? I seem to see at least
one bit that is not being used and maybe
even two bits. I know that naming would
be a problem - what about:
D00 -> D77:
for the 128 unit device drivers, then add 8 more
"hex" values to the last RAD50 character
D08: -> D0F:
...
D78: -> D7F:
for the 256 unit device drivers, then add 16 more
values to the last RAD50 character
D0G: -> D0V:
...
D7G: -> D7V:
Since all the device names are RAD50, numbering
is not really a problem. By keeping the middle
character as an octal value, the PNAME2 table
should still be happy.
If anyone else has any comments, they would be
VERY appreciated!!!!!!!!!!!!!!!!!!!!!
For 64 units, I run 3 Hitachi ESDI DK515-78 hard disk
drives as:
SET D00: -> D23: UNIT=0, PART=00 to 19
SET D30: -> D53: UNIT=1, PART=24 to 43
SET D60: -> D77: UNIT=2, PART=48 to 63
SET D54: -> D57: UNIT=2, PART=44 to 47
ASSIGN D80: D54:
ASSIGN D81: D55:
ASSIGN D82: D56:
ASSIGN D83: D57:
Sometimes I also use a 4th ESDI as temporary
scratch in which case:
SET D24: -> D27: UNIT=3, PART=20 to 23
ASSIGN D90: D24:
ASSIGN D91: D25:
ASSIGN D92: D26:
ASSIGN D93: D27:
NOTE that within the SET command values are in
DECIMAL while the command SHOW DEVICE : DU displays
the partition numbers in OCTAL. The device names
may seem the be in OCTAL, but are always RAD50.
THUS, the D8n: and D9n: can be used, but must
be assigned to the actual device names.
ALSO, while the standard distributed DEC code
for DU.MAC and UM.MAC does not include a boot
table EXCEPT for DU0: -> DU7:, I modified the
boot code to allow all 64 devices to be software
booted via DUP after RT-11 is running. Thus I
must first do a hardware boot using DU0:, then
I can boot any of the other RT-11 partitions
which have a bootable set of files. I realize
that not many RT-11 users even have this large
a real hard disk drive, but if you run SIMH, then
container files up to 64 RT-11 partitions are
possible with most Windows and probably Linux
as well. However, it is legal for hobby users
of RT-11 to run only up to V05.03 of RT-11 under
SIMH. And most hobby users will find that V05.03
of RT-11 is sufficient for almost all their needs.
Versus the fact that later versions of RT-11
are legally available only with a legal license
from DEC (prior to about 1994) or now Mentec at
about $ US 900 for a Qbus license and $ US 1600
for a binary RT-11 distribution - assuming that
Mentec will respond to any of your requests for
information. Lately, they do not respond and I
assume that at least the RT-11 DOC set for V05.06
is "out of print".
Under the commercial version of E11,
it is possible to concatenate container files
or even use raw SCSI hard drives of any size.
Finally, since I use a Sigma RQD11-EC ESDI
controller, I am able to use a passive front
panel which allows me to WRITE PROTECT UNITS
0, 1 and 2. I run that way 99.9% of the time
and remove the WRITE PROTECT only when I have
finished testing a new file which I want to save
on the hard drive. I have lost a few files this
way when I crashed during testing, but better that
than not being able to boot the system the next
day until I return to a very old backup. Usually
I can arrange to save the file (to be tested) on
the hard drive under a different name while the VM:
disk has the test file with the real name and I
am stepping through with a DEBUG program active.
After a few hours or days of testing, the original
file on the hard drive is replaced with the new
temporary file (very easy if the temporary file
is the same size - just overwrite using DUP)
and delete the temporary file. After final testing,
copy the new file to the backup partition and
BINCOM everything again.
If you are wondering how I use so many partitions,
99% of the time UNITs 1 and 2 are the backups for
UNIT 0 (and are rarely powered up). This means that
I can use BINCOM to check that each of corresponding
partitions is identical. It also means that I can:
BOOT D32:
instead of D02: when I want to make changes to D02:
which I am not positive can be done while D02: is the
system device. After the changes, I again BOOT D02:
and test. If everything checks out, I can:
COPY/DEVICE D02: D32:
to make a backup while I still have D62: in reserve
for a bit longer.
If you have any more questions, please ask.
Sincerely yours,
Jerome Fine
--
If you attempted to send a reply and the original e-mail
address has been discontinued due a high volume of junk
e-mail, then the semi-permanent e-mail address can be
obtained by replacing the four characters preceding the
'at' with the four digits of the current year.
14 Mar
14 Mar
11:59 a.m.
Megan, if you are reading this, might it be possible to
expand the number
of units to 128 or even 256? I seem to see at least one bit that is not
being used and maybe even two bits.
Depends... where are you talking about getting the two bits?
I know that naming would be a problem - what about:
D00 -> D77:
for the 128 unit device drivers, then add 8 more
"hex" values to the last RAD50 character
D08: -> D0F:
...
D78: -> D7F:
for the 256 unit device drivers, then add 16 more
values to the last RAD50 character
D0G: -> D0V:
...
D7G: -> D7V:
uggh... I'd not want to see go this route.
Since all the device names are RAD50, numbering is not
really a problem.
By keeping the middle character as an octal value, the PNAME2 table
should still be happy.
You've got me on that, I would have to look at the code to see why
PNAME2 is an issue.
As for the number of disks... I find 64 unwieldy... I'd hate to have
to worry about 2 or 4 times that number on RT. I personally would
rather see RT be able to natively handle 32-bit blocks numbers before
it went this route...
Megan Gentry
Former RT-11 Developer
+--------------------------------+-------------------------------------+
| Megan Gentry, EMT/B, PP-ASEL,ST| email: mbg at world.std.com |
| Member of Technical Staff | megan at savaje.com |
| SavaJe Technologies, Inc. | (s/ at /@/) |
| 100 Apollo Drive | URL: http://world.std.com/~mbg/ |
| Chelmsford, MA 01824 | "pdp-11 programmer - some assembler |
| (978) 256 6521 (DEC '77-'98) | required." - mbg KB1FCA |
+--------------------------------+-------------------------------------+
8:42 p.m.
Megan wrote:
Megan, if you
are reading this, might it be possible to expand the number
of units to 128 or even 256? I seem to see at least one bit that is not
being used and maybe even two bits.
Depends... where are you talking about getting the two bits?
I know that
naming would be a problem - what about:
D00 -> D77:
for the 128 unit device drivers, then add 8 more
"hex" values to the last RAD50 character
D08: -> D0F:
...
D78: -> D7F:
for the 256 unit device drivers, then add 16 more
values to the last RAD50 character
D0G: -> D0V:
...
D7G: -> D7V:
uggh... I'd not want to see go this route.
Since all the
device names are RAD50, numbering is not really a problem.
By keeping the middle character as an octal value, the PNAME2 table
should still be happy.
You've got me on that, I would have to look at the code to see why
PNAME2 is an issue.
As for the number of disks... I find 64 unwieldy...
I'd hate to have
to worry about 2 or 4 times that number on RT. I personally would
rather see RT be able to natively handle 32-bit blocks numbers before
it went this route...
I agree that 256 active RT-11 partitions which can
cover 8 GBites is more than unwieldy. Since 64 active
RT-11 partitions covers 2 GBytes, that should really
be more than enough.
HOWEVER, if you are really considering 32-bit block
numbers, that is a 512 GByte hard drive with 65536
RT-11 partitions. Should be a snap! The map entry
for each RT-11 partition is already 32 bits or 2 words
and uses (WASTES?) 16 bits for the unit number, but
allows only 8 bits (a byte) each for the port number and
RT-11 partition number. It should no be much of a
problem to swap the word for the unit number with the
byte for the partition number. Since RT-11 already
allows a 32-bit block number with ONLY 8 bits being
used from the 8 bit RT-11 partition number, ... Do you
get the point or do I need to spell out the extra
details?
If you are answering, I would be extremely useful to
know if the first set of map entries in low memory
are essential as opposed to the second set of map
entries in high memory for the DUX.SYS device driver?
I am always disappointed that the 64 unit DUX.SYS
driver requires so much extra low memory for the
extra entries in the map entry table. I never could
quite understand why two tables are present, let alone
if the one in lower memory might be located somewhere
else and initialized into high memory during a LOAD or
.Fetch from a separate area in the device driver
outside of the portion which is copied to low memory?
Perhaps both enhancements could be done at the same time,
i.e. a 32-bit block number (16 bit partition number)
and the elimination of the map entry table from low memory?
Sincerely yours,
Jerome Fine
--
If you attempted to send a reply and the original e-mail
address has been discontinued due a high volume of junk
e-mail, then the semi-permanent e-mail address can be
obtained by replacing the four characters preceding the
'at' with the four digits of the current year.
7065
days inactive
7070
days old
3 comments
2 participants
participants (2)
-
jhfinexgs2＠compsys.to -
mbg＠TheWorld.com