On 2013-02-09 00:59, Sampsa Laine wrote:
I'm thinking of tweaking the HECNET infoservice* on RHESUS, and figured it'd be nice if the nodes in the output of NCP SHOW KNOWN NODES were hyperlinks.
On Unix I would just replace all the "(" characters with an opening <a> + "(" tag and all the ")" with a closing </a> tag + ")" using sed.
What's the correct DCL way to do this?
sampsa
* This is the page I'm thinking of tweaking: http://rhesus.sampsa.com/cgi-bin/hecnetinfo/hecnetinfo.com
TECO? :-)
<FS($(<a>$FS)$</a>)$;>
But I don't think just a <a> tag would be enough, would it? Wouldn't you want a href in there, and so on?
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
I'm thinking of tweaking the HECNET infoservice* on RHESUS, and figured it'd be nice if the nodes in the output of NCP SHOW KNOWN NODES were hyperlinks.
On Unix I would just replace all the "(" characters with an opening <a> + "(" tag and all the ")" with a closing </a> tag + ")" using sed.
What's the correct DCL way to do this?
sampsa
* This is the page I'm thinking of tweaking: http://rhesus.sampsa.com/cgi-bin/hecnetinfo/hecnetinfo.com
On 2013-02-08 23:31, Jordi Guillaumes i Pons wrote:
El 08/02/2013, a les 23:14, Johnny Billquist <bqt at softjar.se> va escriure:
And the problem is just that the boot rom uses a more restricted disk block addressing, limiting the
booting to disks of less than 1G. (Actually, you can boot from larger disks as well, as long as the boot
rom don't need to read from anything above 1G.)
Nice to know. IIRC I read about the firmware dropping the high bits of the block address so at some point
in time the writes against the disk would "wrap around" and trash the first 4GBs... but it seems its quite
an urban legend :)
No. That is correct. And it's 1G, not 4G. SCSI commands comes in some different flavors. Old VAXstations (and some others) used 6 byte SCSI commands, which limited the block numbers to 20 bits (some say 21, but I think it is 20). Later systems use 10 byte SCSI commands, which allows for 32 bit block numbers.
What happens is that if you go above 20 bits in the SCSI commands of those old VAXen, they will just use the low 20 bits of the block number, so you will indeed wrap.
See http://labs.hoffmanlabs.com/node/218 if you want a few more details.
BTW, This is a nice sight:
$ sh net
VAX/VMS Network status for local node 7.61 BITXOO on 8-FEB-2013 23:26:08.76
The next hop to the nearest area router is node 7.60 BITXOV.
Node Links Cost Hops Next Hop to Node
7.61 BITXOO 0 0 0 (Local) -> 7.61 BITXOO
7.6 MBSERV 0 3 1 UNA-0 -> 7.6 MBSERV
7.60 BITXOV 0 3 1 UNA-0 -> 7.60 BITXOV
7.64 BITXO1 0 3 1 UNA-0 -> 7.64 BITXO1
7.65 BITXO2 0 3 1 UNA-0 -> 7.65 BITXO2
7.67 BITXO4 0 3 1 UNA-0 -> 7.67 BITXO4
7.68 BITXO5 0 3 1 UNA-0 -> 7.68 BITXO5
7.70 BITXOT 0 3 1 UNA-0 -> 7.70 BITXOT
7.71 BITXOR 0 3 1 UNA-0 -> 7.71 BITXOR
7.72 BITXOM 0 3 1 UNA-0 -> 7.72 BITXOM
7.74 BITXOW 0 3 1 UNA-0 -> 7.74 BITXOW
7.79 BITXT0 0 3 1 UNA-0 -> 7.79 BITXT0
:-)
Emulated Unibus-machine, or the real deal?
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
El 08/02/2013, a les 23:14, Johnny Billquist <bqt at softjar.se> va escriure:
And the problem is just that the boot rom uses a more restricted disk block addressing, limiting the booting to disks of less than 1G. (Actually, you can boot from larger disks as well, as long as the boot rom don't need to read from anything above 1G.)
Nice to know. IIRC I read about the firmware dropping the high bits of the block address so at some point in time the writes against the disk would "wrap around" and trash the first 4GBs... but it seems its quite an urban legend :)
BTW, This is a nice sight:
$ sh net
VAX/VMS Network status for local node 7.61 BITXOO on 8-FEB-2013 23:26:08.76
The next hop to the nearest area router is node 7.60 BITXOV.
Node Links Cost Hops Next Hop to Node
7.61 BITXOO 0 0 0 (Local) -> 7.61 BITXOO
7.6 MBSERV 0 3 1 UNA-0 -> 7.6 MBSERV
7.60 BITXOV 0 3 1 UNA-0 -> 7.60 BITXOV
7.64 BITXO1 0 3 1 UNA-0 -> 7.64 BITXO1
7.65 BITXO2 0 3 1 UNA-0 -> 7.65 BITXO2
7.67 BITXO4 0 3 1 UNA-0 -> 7.67 BITXO4
7.68 BITXO5 0 3 1 UNA-0 -> 7.68 BITXO5
7.70 BITXOT 0 3 1 UNA-0 -> 7.70 BITXOT
7.71 BITXOR 0 3 1 UNA-0 -> 7.71 BITXOR
7.72 BITXOM 0 3 1 UNA-0 -> 7.72 BITXOM
7.74 BITXOW 0 3 1 UNA-0 -> 7.74 BITXOW
7.79 BITXT0 0 3 1 UNA-0 -> 7.79 BITXT0
Now, if I could just fix poor BITXO3 (which is a VS 3100 with a toasted cache in the mobo...).
Jordi Guillaumes i Pons
jg at jordi.guillaumes.name
HECnet: BITXOV::JGUILLAUMES
On 2013-02-08 21:52, Jordi Guillaumes i Pons wrote:
Oh, now I need a disk for that machine. Right now it is running diskless as a satellite of my 4000/60,
paging via ethernet (ouch!). I have some SCA-68-50 pin adapters for SCSI disks, and I have used those
with success with 4GB drives, but I have read somewhere the vaxstation firmware can't handle disks bigger
than that. Anyone knows if that is true? Can I plug in a generic, big SCSI disk and hope it will work?
Sigh. The misinformation that keeps spreading. The problem is for specific older VAXen. I think it's even only specific 3100 models. And the problem is just that the boot rom uses a more restricted disk block addressing, limiting the booting to disks of less than 1G. (Actually, you can boot from larger disks as well, as long as the boot rom don't need to read from anything above 1G.)
Once the OS starts, it uses its own device driver, and then you don't have the restriction either.
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
El 08/02/2013, a les 22:11, Dennis Boone <drb at msu.edu> va escriure:
I thought the situation was that NOS chips were available, not new ones?
Honestly, though, I might hack on even a new one: potting a battery with
a limited life span is the dumbest thing since russian roulette with a
pistol.
Well, as I wrote, I bought 2. One of them is dead. So now I have two dead chips to practice surgery with :) The one in the 4000/60 will die one of these days too...
Jordi Guillaumes i Pons
jg at jordi.guillaumes.name
HECnet: BITXOV::JGUILLAUMES
El 08/02/2013, a les 22:10, Brian Hechinger <wonko at 4amlunch.net> va escriure:
Tell that to the 146GB SCA SCSI disks I have in my 4000/90.
One word of warning, the disk carrier won't fit back into the machine with the SCA/50-pin adapters. The cables hit the inside "wall" between the disks and 5.25" bay.
Nice! As for the ugly fitting, I have already a SCA 4GB disk in the 4000/60, so I know what are you talking about ;)
Jordi Guillaumes i Pons
jg at jordi.guillaumes.name
HECnet: BITXOV::JGUILLAUMES
I keep reading about people cracking open those chips, and I always
wonder why they bother. They're neither expensive nor difficult to find
brand-new. Why would one find it worth the time to spend an afternoon
performing surgery on that chip to replace the battery when you can get
a new one on the way for about eight bucks?
I thought the situation was that NOS chips were available, not new ones?
Honestly, though, I might hack on even a new one: potting a battery with
a limited life span is the dumbest thing since russian roulette with a
pistol.
De
On 8 Feb 2013, at 16:10, Brian Hechinger <wonko at 4amlunch.net> wrote:
On 2/8/2013 3:52 PM, Jordi Guillaumes i Pons wrote:
Oh, now I need a disk for that machine. Right now it is running diskless as a satellite of my 4000/60, paging via ethernet (ouch!). I have some SCA-68-50 pin adapters for SCSI disks, and I have used those with success with 4GB drives, but I have read somewhere the vaxstation firmware can't handle disks bigger than that. Anyone knows if that is true? Can I plug in a generic, big SCSI disk and hope it will work?
Tell that to the 146GB SCA SCSI disks I have in my 4000/90.
Nice!
One word of warning, the disk carrier won't fit back into the machine with the SCA/50-pin adapters. The cables hit the inside "wall" between the disks and 5.25" bay.
-brian
On 2/8/2013 3:52 PM, Jordi Guillaumes i Pons wrote:
Oh, now I need a disk for that machine. Right now it is running diskless as a satellite of my 4000/60, paging via ethernet (ouch!). I have some SCA-68-50 pin adapters for SCSI disks, and I have used those with success with 4GB drives, but I have read somewhere the vaxstation firmware can't handle disks bigger than that. Anyone knows if that is true? Can I plug in a generic, big SCSI disk and hope it will work?
Tell that to the 146GB SCA SCSI disks I have in my 4000/90.
One word of warning, the disk carrier won't fit back into the machine with the SCA/50-pin adapters. The cables hit the inside "wall" between the disks and 5.25" bay.
-brian