On 4 May 2014, at 03:41, Mark Abene <phiber at phiber.com> wrote:
I was emulating a full cisco 7206VXR in dynamips/dynagen on my linux/ARM
Okay, I want to get this up and going but I have ZERO experience on Cisco, IOS or anything that emulates it. Google results are a bit confusing, so some pointers would be greatly appreciated!
--
Mark Benson
http://DECtec.info
Twitter: @DECtecInfo
HECnet: STAR69::MARK
Online Resource & Mailing List for DEC Enthusiasts.
On 2014-05-17 20:19, Brian Schenkenberger, VAXman- wrote:
Johnny Billquist <bqt at softjar.se> writes:
On 2014-05-17 20:14, Cory Smelosky wrote:
On Sat, 17 May 2014, Johnny Billquist wrote:
I got the one perfectly cleaned...but the motor appears to be failing at
times and putting a cartridge in seals its fate. If I start using it
beyond the first foot or so I'd be fine...so long as I never want to
REMOVE the cartridge.
A bit odd. I don't remember ever having that problem. I've had drives
that occasionally decided to not give the cartridge back, and I have
had to extract them and manually rewind the tape in (boring as hell),
but after some mucking around I've normally gotten them working again.
But the TK50 is not the best design around, and the operation is
confusing. The TK70 is better... And TK50 exists in different firmware
revisions, and some are quirkier than others.
Agreed with the operation being confusing. ;)
I think I'm going to end up just cleaning a DAT drive and shoving RSTS/E
install media on that.
I have Exabyte, DDS-3 and TK50 on my PDP-11 at home. I never use the
TK50. :-)
Hopefully, your Exabyte isn't the 8200. ;)
I never remember if it is an 8200 or an 8500. Either way, it's been working fine for the last 20 years or so... :-)
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On 05/17/2014 02:19 PM, Brian Schenkenberger, VAXman- wrote:
Hopefully, your Exabyte isn't the 8200. ;)
Wha. WHAT. No. NO. NOOOOOOO!!!
YYAAAAAAAAAAAAA!! *BLAM!* (<-- head explodes)
--
Dave McGuire, AK4HZ
New Kensington, PA
Johnny Billquist <bqt at softjar.se> writes:
On 2014-05-17 20:14, Cory Smelosky wrote:
On Sat, 17 May 2014, Johnny Billquist wrote:
I got the one perfectly cleaned...but the motor appears to be failing at
times and putting a cartridge in seals its fate. If I start using it
beyond the first foot or so I'd be fine...so long as I never want to
REMOVE the cartridge.
A bit odd. I don't remember ever having that problem. I've had drives
that occasionally decided to not give the cartridge back, and I have
had to extract them and manually rewind the tape in (boring as hell),
but after some mucking around I've normally gotten them working again.
But the TK50 is not the best design around, and the operation is
confusing. The TK70 is better... And TK50 exists in different firmware
revisions, and some are quirkier than others.
Agreed with the operation being confusing. ;)
I think I'm going to end up just cleaning a DAT drive and shoving RSTS/E
install media on that.
I have Exabyte, DDS-3 and TK50 on my PDP-11 at home. I never use the
TK50. :-)
Hopefully, your Exabyte isn't the 8200. ;)
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
I speak to machines with the voice of humanity.
On 2014-05-17 20:14, Cory Smelosky wrote:
On Sat, 17 May 2014, Johnny Billquist wrote:
I got the one perfectly cleaned...but the motor appears to be failing at
times and putting a cartridge in seals its fate. If I start using it
beyond the first foot or so I'd be fine...so long as I never want to
REMOVE the cartridge.
A bit odd. I don't remember ever having that problem. I've had drives
that occasionally decided to not give the cartridge back, and I have
had to extract them and manually rewind the tape in (boring as hell),
but after some mucking around I've normally gotten them working again.
But the TK50 is not the best design around, and the operation is
confusing. The TK70 is better... And TK50 exists in different firmware
revisions, and some are quirkier than others.
Agreed with the operation being confusing. ;)
I think I'm going to end up just cleaning a DAT drive and shoving RSTS/E
install media on that.
I have Exabyte, DDS-3 and TK50 on my PDP-11 at home. I never use the TK50. :-)
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
--
DECtec mailing list
http://dectec.info
To unsubscribe from this list see page at: http://dectec.info/mailman/listinfo/dectec_dectec.info
On Sat, 17 May 2014, Johnny Billquist wrote:
I got the one perfectly cleaned...but the motor appears to be failing at
times and putting a cartridge in seals its fate. If I start using it
beyond the first foot or so I'd be fine...so long as I never want to
REMOVE the cartridge.
A bit odd. I don't remember ever having that problem. I've had drives that occasionally decided to not give the cartridge back, and I have had to extract them and manually rewind the tape in (boring as hell), but after some mucking around I've normally gotten them working again.
But the TK50 is not the best design around, and the operation is confusing. The TK70 is better... And TK50 exists in different firmware revisions, and some are quirkier than others.
Agreed with the operation being confusing. ;)
I think I'm going to end up just cleaning a DAT drive and shoving RSTS/E install media on that.
Johnny
--
Cory Smelosky
http://gewt.net Personal stuff
http://gimme-sympathy.org Projects
--
DECtec mailing list
http://dectec.info
To unsubscribe from this list see page at: http://dectec.info/mailman/listinfo/dectec_dectec.info
On 2014-05-17 19:33, Cory Smelosky wrote:
On Sat, 17 May 2014, Johnny Billquist wrote:
Others have replied, but anyway.
Yes, you need to clean the TK50. Almost certain that is your problem.
And cleaning them is easy. Open the box, so that you can see the
drive. There is a cover plate over the drive, fastened by four screws.
Remove the cover plate and you'll see the head, the rollers, and the
pickup hub.
Use iso-propanol and a swab, and just clean the head.
Reassemble, and you're done.
Johnny
I got the one perfectly cleaned...but the motor appears to be failing at
times and putting a cartridge in seals its fate. If I start using it
beyond the first foot or so I'd be fine...so long as I never want to
REMOVE the cartridge.
A bit odd. I don't remember ever having that problem. I've had drives that occasionally decided to not give the cartridge back, and I have had to extract them and manually rewind the tape in (boring as hell), but after some mucking around I've normally gotten them working again.
But the TK50 is not the best design around, and the operation is confusing. The TK70 is better... And TK50 exists in different firmware revisions, and some are quirkier than others.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
--
DECtec mailing list
http://dectec.info
To unsubscribe from this list see page at: http://dectec.info/mailman/listinfo/dectec_dectec.info
On 2014-05-17 18:59, Brian Schenkenberger, VAXman- wrote:
Johnny Billquist <bqt at softjar.se> writes:
On 2014-05-11 05:11, Cory Smelosky wrote:
Evening all,
Got a nice haul of equipment today...aside from the TK50 issues and the
smoking VT340 everything seems to be okay!
However:
CARTRIDGE PRESENT
HEAD AT TRACK ZERO
POSITIONED AT BOT
TRK NUMBER 00
LOGICAL TRACK NUMBER = 0.
PHYSICAL BLK# 0000
PHYSICAL BLOCK NUMBER = 0.
LOGICAL BLK# 00
LOGICAL BLOCK NUMBER = 0.
TAPE POSITION 000EFB
TAPE POSITION = 3835.
DRIVE STATE 035E
RD/WRT STATE 1937
OPERATION FLGS 0201
CNTRLR STATUS 0C
DRIVE ERROR
DRIVE ERR CODE 93
AMPLITUDE ON HEAD 2 TOO LOW
and an error about it being unable to find calibration track 2 on the
second drive lead me to believe the drives may be faulty. The leader
isn't broken and I've reattached it to the arm on the one where it had
come off.
How would I do about cleaning one? Are the drives bad and a cleaning
wouldn't help?
(Yes, I tried multiple cartridges)
Others have replied, but anyway.
Yes, you need to clean the TK50. Almost certain that is your problem.
And cleaning them is easy. Open the box, so that you can see the drive.
There is a cover plate over the drive, fastened by four screws. Remove
the cover plate and you'll see the head, the rollers, and the pickup hub.
Use iso-propanol and a swab, and just clean the head.
Reassemble, and you're done.
Try ethanol instead! "Rubbing" ethanol is available at most drug stores
along side isopropanol. This is, of course, denatured so that it can not
(or should not) be consumed. If you want the purest, off to the liquor
store and get yoruself a bottle of grain alcohol (Everclear is one brand
names of pure grain alcohol). It's what I use simply because I've never
sussed out what is used as the denaturing addative with the drug store's
ethanol.
Isopropanol can oxidize producing a ketone. The ketone that it oxidizes
into is acetone. Not what I would prefer to have on the rubber (real or
otherwise) conponents nor to come in contact with my tapes. Depending on
what is gunked up in your TK50, some of those chemicals may suffice as a
catalyst in the oxidation thereof.
I do know that the tech wipes (small pouches with alcohol dampened cloth
or paper) we used back in the day were ethanol based. Perhaps, for this
very reason?
I have bottles from DEC saying "Tape cleaning fluid", and it's Isopropanol. All my manuals for various hardware also always say to clean using Isopropanol, so I think Isopropanol is a safe bet to use. :-)
However, pure ethanol should not be a problem either, unless it actually might be to aggressive in dissolving things.
My main concerns with ethanol would be how aggressive it might be, and secondly any possible residue left behind id it wasn't pure. I would like to have something that is at least 96% ethanol if I were to use that for cleaning. (You won't find that in normal stores in Sweden at least, since it's dangerous to consume as it is, and diluting it with water would mean you'd get a lot of alcohol without going through the state monopoly. :-) Denatured it's available at special stores, but still not my first choice then, since the denaturing is also additives that I do not want left as residue.)
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On Sat, 17 May 2014, Johnny Billquist wrote:
Others have replied, but anyway.
Yes, you need to clean the TK50. Almost certain that is your problem.
And cleaning them is easy. Open the box, so that you can see the drive. There is a cover plate over the drive, fastened by four screws. Remove the cover plate and you'll see the head, the rollers, and the pickup hub.
Use iso-propanol and a swab, and just clean the head.
Reassemble, and you're done.
Johnny
I got the one perfectly cleaned...but the motor appears to be failing at times and putting a cartridge in seals its fate. If I start using it beyond the first foot or so I'd be fine...so long as I never want to REMOVE the cartridge.
--
Cory Smelosky
http://gewt.net Personal stuff
http://gimme-sympathy.org Projects
--
DECtec mailing list
http://dectec.info
To unsubscribe from this list see page at: http://dectec.info/mailman/listinfo/dectec_dectec.info
Ethanol is denatured w ith methanol. If you'd drink it your eyesight goes on the blink, as does your liver and your brain.
Ethanol or isopropranol are both suitable solvents.
Methanol would do as well but is more poisonous.
The oxidation reaction of alcohols to aldehyde or ketones doesn't readily occur at room temperature and pressure.
Verzonden vanaf mijn BlackBerry 10-smartphone.
Origineel bericht
Van: Brian Schenkenberger, VAXman-
Verzonden: zaterdag 17 mei 2014 18:59
Aan: hecnet at Update.UU.SE
Beantwoorden: hecnet at Update.UU.SE
Onderwerp: Re: [HECnet] TK50 issues
Johnny Billquist <bqt at softjar.se> writes:
On 2014-05-11 05:11, Cory Smelosky wrote:
Evening all,
Got a nice haul of equipment today...aside from the TK50 issues and the
smoking VT340 everything seems to be okay!
However:
CARTRIDGE PRESENT
HEAD AT TRACK ZERO
POSITIONED AT BOT
TRK NUMBER 00
LOGICAL TRACK NUMBER = 0.
PHYSICAL BLK# 0000
PHYSICAL BLOCK NUMBER = 0.
LOGICAL BLK# 00
LOGICAL BLOCK NUMBER = 0.
TAPE POSITION 000EFB
TAPE POSITION = 3835.
DRIVE STATE 035E
RD/WRT STATE 1937
OPERATION FLGS 0201
CNTRLR STATUS 0C
DRIVE ERROR
DRIVE ERR CODE 93
AMPLITUDE ON HEAD 2 TOO LOW
and an error about it being unable to find calibration track 2 on the
second drive lead me to believe the drives may be faulty. The leader
isn't broken and I've reattached it to the arm on the one where it had
come off.
How would I do about cleaning one? Are the drives bad and a cleaning
wouldn't help?
(Yes, I tried multiple cartridges)
Others have replied, but anyway.
Yes, you need to clean the TK50. Almost certain that is your problem.
And cleaning them is easy. Open the box, so that you can see the drive.
There is a cover plate over the drive, fastened by four screws. Remove
the cover plate and you'll see the head, the rollers, and the pickup hub.
Use iso-propanol and a swab, and just clean the head.
Reassemble, and you're done.
Try ethanol instead! "Rubbing" ethanol is available at most drug stores
along side isopropanol. This is, of course, denatured so that it can not
(or should not) be consumed. If you want the purest, off to the liquor
store and get yoruself a bottle of grain alcohol (Everclear is one brand
names of pure grain alcohol). It's what I use simply because I've never
sussed out what is used as the denaturing addative with the drug store's
ethanol.
Isopropanol can oxidize producing a ketone. The ketone that it oxidizes
into is acetone. Not what I would prefer to have on the rubber (real or
otherwise) conponents nor to come in contact with my tapes. Depending on
what is gunked up in your TK50, some of those chemicals may suffice as a
catalyst in the oxidation thereof.
I do know that the tech wipes (small pouches with alcohol dampened cloth
or paper) we used back in the day were ethanol based. Perhaps, for this
very reason?
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
I speak to machines with the voice of humanity.
Johnny Billquist <bqt at softjar.se> writes:
On 2014-05-11 05:11, Cory Smelosky wrote:
Evening all,
Got a nice haul of equipment today...aside from the TK50 issues and the
smoking VT340 everything seems to be okay!
However:
CARTRIDGE PRESENT
HEAD AT TRACK ZERO
POSITIONED AT BOT
TRK NUMBER 00
LOGICAL TRACK NUMBER = 0.
PHYSICAL BLK# 0000
PHYSICAL BLOCK NUMBER = 0.
LOGICAL BLK# 00
LOGICAL BLOCK NUMBER = 0.
TAPE POSITION 000EFB
TAPE POSITION = 3835.
DRIVE STATE 035E
RD/WRT STATE 1937
OPERATION FLGS 0201
CNTRLR STATUS 0C
DRIVE ERROR
DRIVE ERR CODE 93
AMPLITUDE ON HEAD 2 TOO LOW
and an error about it being unable to find calibration track 2 on the
second drive lead me to believe the drives may be faulty. The leader
isn't broken and I've reattached it to the arm on the one where it had
come off.
How would I do about cleaning one? Are the drives bad and a cleaning
wouldn't help?
(Yes, I tried multiple cartridges)
Others have replied, but anyway.
Yes, you need to clean the TK50. Almost certain that is your problem.
And cleaning them is easy. Open the box, so that you can see the drive.
There is a cover plate over the drive, fastened by four screws. Remove
the cover plate and you'll see the head, the rollers, and the pickup hub.
Use iso-propanol and a swab, and just clean the head.
Reassemble, and you're done.
Try ethanol instead! "Rubbing" ethanol is available at most drug stores
along side isopropanol. This is, of course, denatured so that it can not
(or should not) be consumed. If you want the purest, off to the liquor
store and get yoruself a bottle of grain alcohol (Everclear is one brand
names of pure grain alcohol). It's what I use simply because I've never
sussed out what is used as the denaturing addative with the drug store's
ethanol.
Isopropanol can oxidize producing a ketone. The ketone that it oxidizes
into is acetone. Not what I would prefer to have on the rubber (real or
otherwise) conponents nor to come in contact with my tapes. Depending on
what is gunked up in your TK50, some of those chemicals may suffice as a
catalyst in the oxidation thereof.
I do know that the tech wipes (small pouches with alcohol dampened cloth
or paper) we used back in the day were ethanol based. Perhaps, for this
very reason?
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
I speak to machines with the voice of humanity.
On 2014-05-11 05:11, Cory Smelosky wrote:
Evening all,
Got a nice haul of equipment today...aside from the TK50 issues and the
smoking VT340 everything seems to be okay!
However:
CARTRIDGE PRESENT
HEAD AT TRACK ZERO
POSITIONED AT BOT
TRK NUMBER 00
LOGICAL TRACK NUMBER = 0.
PHYSICAL BLK# 0000
PHYSICAL BLOCK NUMBER = 0.
LOGICAL BLK# 00
LOGICAL BLOCK NUMBER = 0.
TAPE POSITION 000EFB
TAPE POSITION = 3835.
DRIVE STATE 035E
RD/WRT STATE 1937
OPERATION FLGS 0201
CNTRLR STATUS 0C
DRIVE ERROR
DRIVE ERR CODE 93
AMPLITUDE ON HEAD 2 TOO LOW
and an error about it being unable to find calibration track 2 on the
second drive lead me to believe the drives may be faulty. The leader
isn't broken and I've reattached it to the arm on the one where it had
come off.
How would I do about cleaning one? Are the drives bad and a cleaning
wouldn't help?
(Yes, I tried multiple cartridges)
Others have replied, but anyway.
Yes, you need to clean the TK50. Almost certain that is your problem.
And cleaning them is easy. Open the box, so that you can see the drive. There is a cover plate over the drive, fastened by four screws. Remove the cover plate and you'll see the head, the rollers, and the pickup hub.
Use iso-propanol and a swab, and just clean the head.
Reassemble, and you're done.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
--
DECtec mailing list
http://dectec.info
To unsubscribe from this list see page at: http://dectec.info/mailman/listinfo/dectec_dectec.info
On 2014-05-15 23:56, Dave McGuire wrote:
On 05/15/2014 05:48 PM, Cory Smelosky wrote:
I need the /physical/ drive size! Different systems give me different
sizes.
This, of course, should not happen. The host should query the drive
for its size, in blocks...I don't know why a given host OS would give
you different numbers.
It is listed as 2G...the MicroVAX 3100 I wrote it with claims it's ~570M
If it's an early MicroVAX-3100, and you're frobbing that drive via its
ROM-based monitor, that code is limited to 21-bit block numbers. Later
machines use 32-bit block numbers.
And of course, as soon as you have booted, the driver of the OS is used instead, and all I know of use 32-bit block numbers at that point, so this limitation is only really relevant during booting, and not running.
(And if you can guarantee that all operations in the boot stage hits the first 2G of the disk, it works fine to boot from larger disks on a 3100 as well.)
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On 2014-05-17 04:13, John Wilson wrote:
From: Cory Smelosky <b4 at gewt.net>
Blocks.
512-byte?
Yes. Unless you have an RA60/RA8X (and maybe RA9X?) drive from a KL10,
in which case MSCP supports 576-byte blocks too. But really just yes.
As far as I can remember, only the RA81 and RA60 supported 576 byte sectors. And only with HSC50 with a not-too-modern version of software.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
From: Cory Smelosky <b4 at gewt.net>
Blocks.
512-byte?
Yes. Unless you have an RA60/RA8X (and maybe RA9X?) drive from a KL10,
in which case MSCP supports 576-byte blocks too. But really just yes.
John Wilson
D Bit
On Fri, 16 May 2014, John Wilson wrote:
From: Cory Smelosky <b4 at gewt.net>
=op onl
Received packet:
ONLINE END
UNIT=1
UNIT SIZE=1048778
What is the unit for that?
Blocks.
512-byte?
So 512/522.
John Wilson
D Bit
--
Cory Smelosky
http://gewt.net Personal stuff
http://gimme-sympathy.org Projects
On Thu, 15 May 2014, John Wilson wrote:
a blank line after each "g" (go) command to make the program check for
response packets. "op gus" (with "unit n" and "g") does a "get unit status"
command if you want more details about the drive. "quit" halts (then 173000G
or CNTRL/BOOT or whatever, to reboot).
John Wilson
D Bit
=op onl
Received packet:
ONLINE END
UNIT=1
UNIT SIZE=1048778
What is the unit for that?
--
Cory Smelosky
http://gewt.net Personal stuff
http://gimme-sympathy.org Projects
On 05/16/2014 05:27 PM, Paul_Koning at Dell.com wrote:
First I need to find the exact size of the drive so I can set
an RAUSER to it. I can then install RSTS/E *IF* I can get SIMH
to boot and install from the RSTS/E V10.1 tape (which I can't
get it to do).
You mean you have a real drive, and you want to copy it to a
disk image file and configure that as an RA file of
user-specified size? That will work fine. RSTS can handle disks
of any size up to a limit (the RP07 is somewhat below that limit,
I d have to dig a bit to find the actual number). If you can
just dd the disk to a file, that file should serve.
Alternatively, you can always use a larger disk so long as you
don t cross a power of two. RSTS addresses disks by disk
clusters which are 16 bit numbers, and the file system layout
starts from a given disk cluster size. So if you have a pack
with 70k sectors, you can drop it into another pack of 90k
sectors but not in one of 130k sectors because that one has a
DCS double that of the original.
Are you certain that this is the only limitation? I've had the
crash-on-boot problems when they were off by quite a bit less than
a power of two. Since I found that problem the hard way, I always
make images (via simh "rauser=<n>") using the exact size of the
target physical disk.
Certainly matching the size is good. But I m pretty sure that what I
described is accurate.
I just did an experiment, with a couple of different disk images. I
don t see startup crashes and there should not be any. (Well, not
unless you mean a failure to start due to a fatal error .)
That's exactly what I mean. ;) Perhaps not the best terminology.
RSTS accepts a disk with mismatched container size so long as the
disk clustersize is unchanged and the SATT.SYS file is the correct
length. Actually, the latter condition is sufficient (it implies the
first). SATT.SYS size is container size divided by pack cluster size
(a parameter set when the pack was initialized), rounded up to an
integer.
I guess it was borderline when I tripped over it, then. That seems
odd because it wasn't just a "once in awhile" thing, it was EVERY time.
But I can certainly see it being bad luck. Now, though, I just find
out the target disk size and make my images exactly the same size, which
I'd do anyway because I'm anal about stuff like that. ;)
If you want to manipulate, or check, RSTS disk images, a useful
utility is rstsflx which you can find at
svn://akdesign.dyndns.org/flx/trunk
That sounds really handy; I will check it out, thanks!
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
On Fri, 16 May 2014, Paul_Koning at Dell.com wrote:
RSTS accepts a disk with mismatched container size so long as the disk clustersize is unchanged and the SATT.SYS file is the correct length. Actually, the latter condition is sufficient (it implies the first). SATT.SYS size is container size divided by pack cluster size (a parameter set when the pack was initialized), rounded up to an integer.
It tells me the clustersize is not (some multiple of 2)
I thought RSTS would accept a disk so long as the DCS is right but with wrong SATT if mounted read-only. That turns out to be incorrect, it insists on a good SATT even if it has no need for one (as in the read-only case). I suspect that s a leftover from the days before read-only mode was introduced.
If you want to manipulate, or check, RSTS disk images, a useful utility is rstsflx which you can find at svn://akdesign.dyndns.org/flx/trunk
I'm limited by the disk space on the RT-11 disk and what I can transfer quickly with kermit (unles someone has a DECnet stack)
paul
--
Cory Smelosky
http://gewt.net Personal stuff
http://gimme-sympathy.org Projects
On May 15, 2014, at 5:44 PM, Dave McGuire <mcguire at neurotica.com> wrote:
On 05/15/2014 05:28 PM, Paul_Koning at Dell.com wrote:
First I need to find the exact size of the drive so I can set an
RAUSER to it. I can then install RSTS/E *IF* I can get SIMH to
boot and install from the RSTS/E V10.1 tape (which I can't get it
to do).
You mean you have a real drive, and you want to copy it to a disk
image file and configure that as an RA file of user-specified size?
That will work fine. RSTS can handle disks of any size up to a limit
(the RP07 is somewhat below that limit, I d have to dig a bit to find
the actual number). If you can just dd the disk to a file, that file
should serve.
Alternatively, you can always use a larger disk so long as you don t
cross a power of two. RSTS addresses disks by disk clusters which
are 16 bit numbers, and the file system layout starts from a given
disk cluster size. So if you have a pack with 70k sectors, you can
drop it into another pack of 90k sectors but not in one of 130k
sectors because that one has a DCS double that of the original.
Are you certain that this is the only limitation? I've had the
crash-on-boot problems when they were off by quite a bit less than a
power of two. Since I found that problem the hard way, I always make
images (via simh "rauser=<n>") using the exact size of the target
physical disk.
Certainly matching the size is good. But I m pretty sure that what I described is accurate.
I just did an experiment, with a couple of different disk images. I don t see startup crashes and there should not be any. (Well, not unless you mean a failure to start due to a fatal error .)
RSTS accepts a disk with mismatched container size so long as the disk clustersize is unchanged and the SATT.SYS file is the correct length. Actually, the latter condition is sufficient (it implies the first). SATT.SYS size is container size divided by pack cluster size (a parameter set when the pack was initialized), rounded up to an integer.
I thought RSTS would accept a disk so long as the DCS is right but with wrong SATT if mounted read-only. That turns out to be incorrect, it insists on a good SATT even if it has no need for one (as in the read-only case). I suspect that s a leftover from the days before read-only mode was introduced.
If you want to manipulate, or check, RSTS disk images, a useful utility is rstsflx which you can find at svn://akdesign.dyndns.org/flx/trunk
paul
El 15/05/2014, a les 23.48, Jordi Guillaumes i Pons <jg at jordi.guillaumes.name> va escriure:
I'm thinking about a simh bug. SIMH v39 boots from that tape mounting it under tq0:
The bug has been fixed by Mark in the HEAD version of the github repository. Now the RSTS/E install tape image can be booted using a TQ device.
PDP-11 simulator V4.0-0 Beta git commit id: c0f9c2e8
boot-tq.ini-2> set cpu 11/73
boot-tq.ini-3> set cpu 4m
Disabling RK
Disabling HK
Disabling TM
boot-tq.ini-4> set tq enable
boot-tq.ini-5> set tq0 lock
boot-tq.ini-6> att tq0 rstse_v10_1_install_sep10_1992.tap
boot-tq.ini-7> boot tq0
Performing limited hardware scan.
RSTS V10.1 (MU0) INIT V10.1-0L
Today's date?
Jordi Guillaumes i Pons
jg at jordi.guillaumes.name
HECnet: BITXOV::JGUILLAUMES
On Thu, 15 May 2014, John Wilson wrote:
I took a wild guess hoping the drive was partitioned in to 4 equal drives of ~400-500M. I am currently copying my 435M disk at 38.4kbaud.
--
Cory Smelosky
http://gewt.net Personal stuff
http://gimme-sympathy.org Projects
From: <Paul_Koning at Dell.com>
Hm... disks have controller-specific boot blocks, but I thought tapes were
universal.
Yeah, the RSTS generic tape boot is quite a nice piece of black magic!
(And, not to beat a dead horse, but E11 likes it fine on all four tape
types and can mount raw real SCSI drives too, with the size you say.)
From: Cory Smelosky <b4 at gewt.net>
I need the /physical/ drive size! Different systems give me different
sizes.
If you've got it on a real PDP-11, you can try my DUTEST program (from
RT-11, or if you have some other way to load it stand-alone and start it
at 1000, it doesn't actually need an OS):
http://www.dbit.com/pub/pdp11/rt11/dutest.mac
It's a reverse-engineering tool (from when I was working on MSCP/TMSCP)
so the command set is pretty low-level, but this sequence should get you
the MSCP controller's idea of the unit size:
.RUN DUTEST
DUTEST by John Wilson <wilson at dbit.com>
Copyright (C) 1997-1999 by Digby's Bitpile, Inc. All rights reserved.
=init
Returned values: DI Step 1 bits 7:0=000 (documented as 000)
Port type = 0, reserved step 3 bits 10:8 = 0, model = 006, FW version = 02
=op scc
=g
=
Received packet:
SCC END
FLAGS=100000
Message credits: 8
=op onl
=unit 0
=g
=
Received packet:
ONLINE END
UNIT=0
UNIT SIZE=204800
Message credits: 8
=
"=" is the prompt. Change "unit 0" to the actual MSCP unit. And enter
a blank line after each "g" (go) command to make the program check for
response packets. "op gus" (with "unit n" and "g") does a "get unit status"
command if you want more details about the drive. "quit" halts (then 173000G
or CNTRL/BOOT or whatever, to reboot).
John Wilson
D Bit
On 05/15/2014 05:48 PM, Cory Smelosky wrote:
I need the /physical/ drive size! Different systems give me different
sizes.
This, of course, should not happen. The host should query the drive
for its size, in blocks...I don't know why a given host OS would give
you different numbers.
It is listed as 2G...the MicroVAX 3100 I wrote it with claims it's ~570M
If it's an early MicroVAX-3100, and you're frobbing that drive via its
ROM-based monitor, that code is limited to 21-bit block numbers. Later
machines use 32-bit block numbers.
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
