I know that many postings here relate to problems, so when I have a success, I post it for something different.


In early 1993, I bought a used MicroVAX 2000 (KA410), with the intent of keeping my skills sharp when I quit my then current job (which I waited too long to do…), along with several pieces of it's specific documentation (Technical Manual, Maintenance Guide kit & Addendum, Customer Hardware).

One of it's cost saving features was that it used the PC/XT era ST412/506 hard disk interface for MFM drives, although it had an early NCR 5380 SCSI chip that was only used as a tape interface to the TZK50 tape drive.  Also by the 1990s, SCSI had clearly taken over lower cost disks, including the lower cost VAXen, but no backward support in OpenVMS was available for the MV2000, although Trimarchi had advertised a SCSI disk for the MV2000 (I have a pamphlet somewhere…).

If I understand correctly, by the late 1990s, Wolfgang J. Moeller had reverse engineered the SCSI port driver used on the MicroVAX3100, which was very similar, for use with the VM2000 including patching the boot ROM images, that he named PK2K.  The PK2K kit is still avail for download: Googling "pk2k vms" gives several hits, including
ftp://ftp.gwdg.de/pub/vms/pk2k/

The PK2K kit includes the source, objects, and images for VMS 5.5-2, 6.1, 6.2, 7.1 and 7.2, patch files for five VMS images used at boot time, and a patch file for use with the boot ROMs.  When HP recently began distributing VAX/VMS 7.3 for hobbyist, I found myself wondering if it would build in VMS 7.3.

I should point out that I had burned and installed the patched boot ROMs some years ago, but never got around to updating the software.

The driver source for 7.2 with the two lines of updates applied, built without error on a SIMH VAX running VMS 7.3, but the patch files for the five images in VMS failed.  

These five images are patched to support local booting (along with the patched ROMs) to replace the TVDRIVER and MUA support of the TZK50 for the PK2KDRVR and PKA port devices: CONFIGURE.EXE, STACONFIG.EXE, STADCONF.EXE, STASYSGEN.EXE, and SYSGEN.EXE.  The three STA images are used in building the standalone backup kit, where the other two are for normal booting, SYSGEN in particular.  

In the notes in the PK2K kit, DISM32 was used to disassemble the driver that the MV3100 used, and I figured that would be the place to start with these images.  With some luck, and recalling the pattern-based guesswork from the Crash Dump Analysis class I took at a OpenVMS bootcamp from Rob Eulenstein, I was able to find the new base addresses for the 5 patch files!  I don't really believe that the tables start at these addresses, but they do enable the relative offsets to work.

I have yet to test the standalone backup kit, but SYSGEN and CONFIGURE are working correctly with two different SCSI disks (MAXTOR MXT 1240s and Quantum Fireball SE2.1S) and a TZ30.

Below are the five patch file names and the one line for each that needs to be updated.
Then the instructions in the PK2K kit can be followed.

2KCONFIGURE.COM
define acf$devdesc        = 0CD17 ! old 0CC1D

2KSTACONFIG.COM
define acf$devdesc        = 11A10 ! old 11810

2KSTANDCONF.COM
define acf$devdesc        = 0D8E0 ! old 0D7E6

2KSTASYSGEN.COM
define acf$devdesc        = 106F9 !  old 105FF

2KSYSGEN.COM
define acf$devdesc        = 0E717 ! old 0E61D


Notice that in all cases, the new base address is larger that the old.

On 28 apr, 04:51, s...@obanion.us wrote:
> I know that many postings here relate to problems, so when I have a success, I post it for something different.
>
> In early 1993, I bought a used MicroVAX 2000 (KA410), with the intent of keeping my skills sharp when I quit my then current job (which I waited too long to do…), along with several pieces of it's specific documentation (Technical Manual, Maintenance Guide kit & Addendum, Customer Hardware).
>
> One of it's cost saving features was that it used the PC/XT era ST412/506 hard disk interface for MFM drives, although it had an early NCR 5380 SCSI chip that was only used as a tape interface to the TZK50 tape drive.  Also by the 1990s, SCSI had clearly taken over lower cost disks, including the lower cost VAXen, but no backward support in OpenVMS was available for the MV2000, although Trimarchi had advertised a SCSI disk for the MV2000 (I have a pamphlet somewhere…).
>

> If I understand correctly, by the late 1990s, Wolfgang J. Moeller had reverse engineered the SCSI port driver used on the MicroVAX3100, which was very similar, for use with the VM2000 including patching the boot ROM images, that he named PK2K.  The PK2K kit is still avail for download: Googling "pk2k vms" gives several hits, includingftp://ftp.gwdg.de/pub/vms/pk2k/

>
> The PK2K kit includes the source, objects, and images for VMS 5.5-2, 6.1, 6.2, 7.1 and 7.2, patch files for five VMS images used at boot time, and a patch file for use with the boot ROMs.  When HP recently began distributing VAX/VMS 7.3 for hobbyist, I found myself wondering if it would build in VMS 7.3.
>
> I should point out that I had burned and installed the patched boot ROMs some years ago, but never got around to updating the software.
>
> The driver source for 7.2 with the two lines of updates applied, built without error on a SIMH VAX running VMS 7.3, but the patch files for the five images in VMS failed.
>
> These five images are patched to support local booting (along with the patched ROMs) to replace the TVDRIVER and MUA support of the TZK50 for the PK2KDRVR and PKA port devices: CONFIGURE.EXE, STACONFIG.EXE, STADCONF.EXE, STASYSGEN.EXE, and SYSGEN.EXE.  The three STA images are used in building the standalone backup kit, where the other two are for normal booting, SYSGEN in particular.
>
> In the notes in the PK2K kit, DISM32 was used to disassemble the driver that the MV3100 used, and I figured that would be the place to start with these images.  With some luck, and recalling the pattern-based guesswork from the Crash Dump Analysis class I took at a OpenVMS bootcamp from Rob Eulenstein, I was able to find the new base addresses for the 5 patch files!  I don't really believe that the tables start at these addresses, but they do enable the relative offsets to work.
>
> I have yet to test the standalone backup kit, but SYSGEN and CONFIGURE are working correctly with two different SCSI disks (MAXTOR MXT 1240s and Quantum Fireball SE2.1S) and a TZ30.
>
> Below are the five patch file names and the one line for each that needs to be updated.
> Then the instructions in the PK2K kit can be followed.
>
> 2KCONFIGURE.COM
> define acf$devdesc      = 0CD17 ! old 0CC1D
>
> 2KSTACONFIG.COM
> define acf$devdesc      = 11A10 ! old 11810
>
> 2KSTANDCONF.COM
> define acf$devdesc      = 0D8E0 ! old 0D7E6
>
> 2KSTASYSGEN.COM
> define acf$devdesc      = 106F9 !  old 105FF
>
> 2KSYSGEN.COM
> define acf$devdesc      = 0E717 ! old 0E61D
>
> Notice that in all cases, the new base address is larger that the old.

That is an interesting post. I own two VAXstation 2000's. One houses a
dead RD54 and the other an RD53 and the latter still worked when it
was last booted, about a year ago. I'm aware of the work of Wolfgang
Moeller and what has kept me from applying the results is that you
must burn your own ROMs, right?
Is that a costly process? I'm all in favour of learning new things but
within the limits my wallet imposes...
Hans

> That is an interesting post. I own two VAXstation 2000's. One houses a
> dead RD54 and the other an RD53 and the latter still worked when it
> was last booted, about a year ago. I'm aware of the work of Wolfgang
> Moeller and what has kept me from applying the results is that you
> must burn your own ROMs, right?
> Is that a costly process? I'm all in favour of learning new things but
> within the limits my wallet imposes...
> Hans

Yes, you do have to burn your own EPROMs.

On ebay today, 27512-20 EPROM, 10 for $15, and a burner & software for about $100 and an UV eraser for $20-$30 .  I didn't get the eraser and should have: three of the ten EPROMs I bought did not verify, and I suspect that they and not been erased completely.


Sean

> [...] I didn't get the eraser [...]

   It's been many years, but I seem to recall a day or two
facing a normal fluorescent tube doing a good (enough) job.
(I never tried direct sunlight.)

> [...] I suspect that they and not been erased completely.

   Can't a typical programmer verify the initial condition?

Steven Schweda <sms.a...@gmail.com> wrote:
>> [...] I didn't get the eraser [...]

>   It's been many years, but I seem to recall a day or two
> facing a normal fluorescent tube doing a good (enough) job.
> (I never tried direct sunlight.)

The numbers are on the data sheet, but I forget them now.

I believe it is days in the sun, weeks under fluorescent lamps.

>> [...] I suspect that they and not been erased completely.

>   Can't a typical programmer verify the initial condition?

Yes, but for marginal bits they are sensitive to conditions,
especially Vcc.

Programmed bit verification is done with Vcc=6V to be extra
sure. To be sure of erased bits, it should be done below 5V,
but I don't know that any do that.

-- glen

> >   It's been many years, but I seem to recall a day or two
> > facing a normal fluorescent tube doing a good (enough) job.
> > (I never tried direct sunlight.)
>
> The numbers are on the data sheet, but I forget them now.
>
> I believe it is days in the sun, weeks under fluorescent lamps.

   Believe what you want, but I ran the experiment.  "Facing"
here meant quartz-touching-glass, not just being in a room
exposed to ("under") fluorescent ceiling lamps.  (My memory
says that a few hours was not enough, while one day was
plenty, but I conservatized my recommendation.)  Not all the
UV emission from the mercury vapor gets converted by the
phosphors, or stopped by the glass.

   It was enough to convince me of the value of covering the
window with a label after programming.

I'm in the uk, but have a prom eraser and a couple of programmers
Am quite happy to program a batch of the eproms if needed. It's
easier to copy from single master to several blank, but can also
program from a binary image file, S record, Intel hex format etc...

Regards,

Chris

On Friday, April 27, 2012 7:51:34 PM UTC-7, se...@obanion.us wrote:

>
> I have yet to test the standalone backup kit, ...
>

An update: I have been able to create a bootable standalone backup kit burned to a CD, and booted the MV2000 from it.

I used a SIMH emulator run under OS X 10.6.8 to create a 650MB disk volume, with the container file using the extension ."iso", mounting the volume cluster wide such that the MV2000 could write to it.  I pointed STABACK.COM to that volume, and once complete, dismounted the volume and shutdown the SIMH emulator, to make sure the container file was closed.

I then burned a CD using the container file as the source for the OS X Disk Utility, and then booted the MV2000 from it.


Sean

> [...] a 650MB disk volume [..]

   Of which you needed what, perhaps 3MB (V5.5-2)?

> [...] using the extension ."iso" [...]

   Does Disk Utility actually care?  (Does anyone?)  Disk
Utility does, as I recall, have some options, and knowing
which of _those_ you used might be more interesting.