6 Feb
2014
6 Feb
'14
5:15 a.m.
So far not going well. Didn't seem to have any video from the video
board so pulled that which gives me a serial console. Trying to boot from
my emulator gives 4C DEVINACT. If I'm on the correct drive select I get
the error quicker so its seeing the emulator. TK50 is just blinking red
so I can't boot the diag tape. Online seems to say a good cleaning may
fix this.
Next tried to find the diagnostic floppies. Found these (uvax2diag1)
which may be what I want.
http://www.headcrashers.org/comp/rx50/index.html
Get same 4C DEVINACT trying to boot them. Page didn't give PUTR command
used to create images. I tried both with and without /binary.
Does anyone know of known good diagnostic floppy images hopefully with
information on how to write them back to a floppy? I assume the full
diagnostic hasn't shown up so all that is available is the stripped down
customer one.
Also what is the name you give to boot for the hard drive, floppy, and tape?
Manuals seem skimpy on details and this machine doesn't have the show command.
Also I was assuming the bottom drive is the boot drive based on the manuals
I have. Was this normal?
I haven't tried putting the real drive back in and seeing if its bootable.
Since I don't know the password I'll either have to hard shut it down if
it boots or try one of the procedures for resetting the password. Looks
like it is VMS.
6 Feb
6 Feb
10:04 a.m.
On Thu, Feb 6, 2014 at 5:15 AM, David Gesswein <djg at pdp8online.com> wrote:
Next tried to find the diagnostic floppies. Found these (uvax2diag1)
which may be what I want.
http://www.headcrashers.org/comp/rx50/index.html
Get same 4C DEVINACT trying to boot them. Page didn't give PUTR command
used to create images. I tried both with and without /binary.
Does anyone know of known good diagnostic floppy images hopefully with
information on how to write them back to a floppy? I assume the full
diagnostic hasn't shown up so all that is available is the stripped down
customer one.
I can get the UVAX2DIAG1.IMG RX50 disk image to boot on a SIMH KA655.
It makes it as far as printing the "VAXELN V2.0-00" banner then it
hangs. I assume the RX50 disk image is probably good and there is just
something about the SIMH KA655 emulation that isn't accurate enough
for the diagnostics to continue. I haven't tried to write these RX50
disk images out to physical floppies yet to try booting on real
hardware.
C:\SIMH-VAX>VAX diagconfig
VAX simulator V3.9-0
NVR: buffering file in memory
RQ: unit is read only
RQ: unit is read only
sim> SHOW CPU
CPU, idle disabled, 16MB, HALT to SIMH
sim> SHOW DEV
VAX simulator configuration
CPU, idle disabled
TLB, 2 units
ROM
NVR
SYSD, 2 units
QBA, autoconfiguration enabled
CLK, vector=C0
TTI, vector=F8
TTO, vector=FC
CSI, vector=F0
CSO, vector=F4
DZ, disabled
VH, disabled
CR, disabled
LPT, disabled
RL, disabled
RQ, address=20001468-2000146B*, no vector, 4 units
RQB, disabled
RQC, disabled
RQD, disabled
RY, disabled
TS, disabled
TQ, disabled
XQ, disabled
XQB, disabled
sim> SHOW RQ
RQ, address=20001468-2000146B*, no vector, 4 units
RQ0, 409KB, attached to UVAX2DIAG1.IMG, read only, write locked, RX50
RQ1, 409KB, attached to UVAX2DIAG2.IMG, read only, write locked, RX50
sim> BOOT CPU
KA655-B V5.3, VMB 2.7
Performing normal system tests.
40..39..38..37..36..35..34..33..32..31..30..29..28..27..26..25..
24..23..22..21..20..19..18..17..16..15..14..13..12..11..10..09..
08..07..06..05..04..03..
Tests completed.
>>SHOW MEM
Memory 0: 00000000 to 00FFFFFF,
16MB, 0 bad pages
Total of 16MB, 0 bad pages, 104 reserved pages
>>SHOW QBUS
Scan of Qbus I/O Space
-20001468 (772150) = 0000 (154) RQDX3/KDA50/RRD50/RQC25/KFQSA-DISK
-2000146A (772152) = 0B40
-20001F40 (777500) = 0020 (004) IPCR
Scan of Qbus Memory Space
>>SHOW DEV
UQSSP Disk Controller 0
(772150)
-DUA0 (RX50)
-DUA1 (RX50)
>>BOOT DUA0
(BOOT/R5:0 DUA0
2..
-DUA0
1..0..
VAXELN V2.0-00
10:41 a.m.
On Feb 6, 2014, at 1:04 PM, Glen Slick <glen.slick at gmail.com> wrote:
I can get the UVAX2DIAG1.IMG RX50 disk image to boot
on a SIMH KA655.
It makes it as far as printing the "VAXELN V2.0-00" banner then it
hangs. I assume the RX50 disk image is probably good and there is just
something about the SIMH KA655 emulation that isn't accurate enough
for the diagnostics to continue. I haven't tried to write these RX50
disk images out to physical floppies yet to try booting on real
hardware.
Should the UVAX2 diagnostics even boot on a KA655? That's a
somewhat different beast than the KA630. I have a physical
KA655 plus RAM, but my BA11-S is on the blink at the moment
(power supply woes that I haven't had time in months to look
at), but if anyone wants to borrow the set for a time, it
could be lent out (or sold, come down to it; I have slightly
more appealing VAX hardware on hand now).
- Dave
9 Feb
9 Feb
8:36 a.m.
On Thu, Feb 06, 2014 at 10:04:33AM -0800, Glen Slick wrote:
I can get the UVAX2DIAG1.IMG RX50 disk image to boot on a SIMH KA655.
It makes it as far as printing the "VAXELN V2.0-00" banner then it
hangs.
Thanks for letting me know the images were good.
Had to fix the following to get the floppies working
1) Bearings dry in the RX50. Works better if parts move.
2) Empty slot on the qbus. The video card I pulled was in the last slot.
Apparently another card was pulled before I got the machine. Used to
Omnibus where thats not a problem.
After I was able to verify the floppies were working I found that putr with
these commands made disks that would work
format a:/rx50/rt11
mount a:
copy /file/dev uvax_1.img a:
I was then able to boot the diags. With a couple fixes to the emulator
the diags read/write test and format work. The diags have the lamest
disk test. Its only able to read 500 kbytes in a minute for a sequential
read test. I put the real drive in to verify that it wasn't an emulator
problem.
I was also able to boot the VMS I read off of the RD53.
Its running MicroVMS Version V4.6 and has 12M of memory.
I didn't get any disk errors and was able to copy a directory tree. I didn't
figure out how to do an equivalent of diff -r to check the tree copy.
Any simple tests under VMS to verify that writing is working fine? With the
other tests and validating that the image file is still valid after the
testing I think its working pretty good now.
It had a few errors on the first disk check that went away with repair.
These two just keep alternating though. Anyone know what this indicates?
$ analyze /disk/repair dua0:
%VERIFY-I-BACKLINK, incorrect directory back link [SYS0]SYSMAINT.DIR;1
$ analyze /disk/repair dua0:
%VERIFY-I-BACKLINK, incorrect directory back link [000000]SYSMAINT.DIR;1
No new errors have shown up.
I will put the update code online tonight.
I also think the TK50 has a slightly too stiff bearing on one of the capstans
and the tape has the sticking problem. Looks like I'm going to have to look
into tape baking when I get to reading the tapes I have.
12:56 p.m.
was also able to boot the VMS I read off of the RD53.
Its running MicroVMS Version V4.6 and has 12M of memory.
I didn't get any disk errors and was able to copy a directory tree. I didn't
figure out how to do an equivalent of diff -r to check the tree copy.
Any simple tests under VMS to verify that writing is working fine? With the
other tests and validating that the image file is still valid after the
testing I think its working pretty good now.
$ BACKUP /COMPARE DISK:[FOO...] DISK:[BAR...]
will compare two directory trees. There is no output if everything compares
ok. Throw in /LOG to make it list each file compared for extra comfort.
$ BACKUP /IMAGE Real-disk: Emulated-Disk:
would do lots of writing and give you something to compare too.
It had a few errors on the first disk check that went away with repair.
These two just keep alternating though. Anyone know what this indicates?
$ analyze /disk/repair dua0:
%VERIFY-I-BACKLINK, incorrect directory back link [SYS0]SYSMAINT.DIR;1
$ analyze /disk/repair dua0:
%VERIFY-I-BACKLINK, incorrect directory back link [000000]SYSMAINT.DIR;1
No new errors have shown up.
Can you check on the real disk and see if they were there before you started?
If they turn up again,
$ DUMP /HEADER /BLOCK=COUNT=0 <filename>
might give some indication of what the problem is. This will list (amongst
other things) the FID of the directory the file lives in. This can be checked
with:
$ DIRECTORY /FILE_ID
Regards,
Peter Coghlan.
10 Feb
10 Feb
7:15 p.m.
On Sun, Feb 09, 2014 at 08:56:17PM +0000, Peter Coghlan wrote:
Can you check on the real disk and see if they were
there before you started?
They were.
If they turn up again,
$ DUMP /HEADER /BLOCK=COUNT=0 <filename>
Dump of file SYS$SYSROOT:[000000]SYSMAINT.DIR;1
...
File identification: (773,74,0)
Directory DUA0:[SYS0]
...
SYSMAINT.DIR;1 (773,74,0)
Directory DUA0:[000000]
...
SYSMAINT.DIR;1 (773,74,0)
Looks like the same directory is in both higher level directories.
I assume copy the directory to new, delete and analyze/repair again
and hope it cleans it up.
11 Feb
11 Feb
3:42 a.m.
Dump of file SYS$SYSROOT:[000000]SYSMAINT.DIR;1
...
File identification: (773,74,0)
Directory DUA0:[SYS0]
...
SYSMAINT.DIR;1 (773,74,0)
Directory DUA0:[000000]
...
SYSMAINT.DIR;1 (773,74,0)
Looks like the same directory is in both higher level directories.
I assume copy the directory to new, delete and analyze/repair again
and hope it cleans it up.
This is not necessarily a problem. It is allowed for a file (or a directory)
to be entered in more than one directory. Disks set up for clustering in
later versions of VMS make use of this for example.
I haven't come across a SYSMAINT.DIR entered in [000000] but it could be there
for a reason. It may be possible to get rid of it with:
$ SET FILE /REMOVE DUA0:[000000]SYSMAINT.DIR;1
if MicroVMS 4.6 has this command. Any files in DUA0:[SYSMAINT] would remain
visible from DUA0:[SYS0.SYSMAINT]. However I would leave it alone in case
something wants it there. It shouldn't do any harm.
Have a look at the field called "Back link file identification:" when you
dump the file header. This specifies the FID of the directory that the file
is entered into. If the same file is entered in more than one directory, this
information can only be correct for one of the directories.
In even slightly more recent versions of VMS, such as V5.5-2, ANALYZE /DISK
does not complain about this apparant anomaly but I think I recall vaguely
that this was not always the case.
Regards,
Peter Coghlan.
3972
days inactive
3977
days old
6 comments
4 participants
participants (4)
-
cctech＠beyondthepale.ie -
djg＠pdp8online.com -
fraveydank＠gmail.com -
glen.slick＠gmail.com