[Info-vax] DEC Multia (UDB) issues

[John Wallace]

On Oct 17, 11:55 pm, Rich Jordan <jor... at ccs4vms.com> wrote:
> On Oct 17, 4:44 pm, MG <marcog... at SPAMxs4all.nl> wrote:
>
>
>
> > Here's an update.  Now the system starts up, the SCSI errors are still
> > there, but CDs seem to boot.  I've tried Tru64 V5.1B-6, which to my
> > great surprise booted up, but only halted because it didn't have the
> > minimally required amount of memory available (64 Mbyte, I only have
> > 32).  The NVR/TOY battery is reportedly "dead", but I've been told it
> > isn't the end of the world.
>
> > Now there's a new problem: The floppy diskette that I prepared (using
> > rawrite V0.7 for Windows) for OpenVMS Alpha V7.2 with the customized
> > boot image (MLTIAV72.FLP) don't seem to work and I get "No Floppy Disk
> > In Drive" error printed continuously.  I've used several other floppy
> > diskettes, but to no avail.  (The strange thing is, the QSBYPASS.SCR
> > and SRM.EXE files seemed to be read from the FAT-formatted diskette
> > that I prepared earlier; another step in the Multia VMS installation
> > process.)
>
> > Does this perhaps sound familiar to anyone?
>
> > Anyway, is running VMS on the Multia really worth it?  I thought it
> > would be nice, so I can attach my LK-type keyboard to it and have a
> > good editor with fully supported key mapping support at my disposal
> > (the HP IP-KVM I have doesn't recognize the LK properly, which is a
> > huge pity).
>
> > Else I might consider running Tru64, in so far possible (since I have
> > no PAKs), but then I'd need more RAM...  Not just for Tru64, actually,
> > in general I'd like more RAM.  From what I've read so far, VMS seems
> > to require more than 32 Mbyte as well.  Does anyone have memory for
> > me, or know where I can find any?  (Or part numbers for me to look
> > up.)
>
> > Thanks in advance.
>
> >   - MG
>
> If I remember correctly is #x36 bit parity RAM, 72-pin SIMMs, either
> 60 or 70 nanosecond FPO.  EDO does not work.  These were common in
> server class systems in the 486 and early pentium timeframe (I ran
> Compaq memory in my UDB back then).  Pretty sure thats the same kind
> of SIMMs used in the Alphastation 200/Alphaserver 300/400 models too.
> Just be sure of the contact materials; I think UDB was one type and
> the Alphastations were the other type (tin vs gold); you want memory
> with the same contact material as the SIMM slots.  the #x36 SIMMs we
> used in other DEC equipment; DECserver 700s, other DECserver units,
> etc.  Those were probably mostly 1x36 (4MByte) SIMMs.
>
> Sorry, none to spare, and I don't recall which systems had which
> contact metal (my AS200 is buried, the UDBs are long gone).

Careful.

Some AlphaStations started life with parity memory and it shipped as
36bit parity (aka longword parity).

Then some HQ genius spotted that in a 21064-based AlphaStation you
didn't need all 36 bits. Because all memory reads and writes were
longwords or wider, you only needed 33bit memory to make it parity
protected. So to save money they changed the relevant AlphaStation
parts to 33bit memory. They did that without changing the orderable
part numbers. Which was fine as long as you were only intending to use
that part in an AlphaStation which needed 33bit memory. If you thought
it was going to get you 36bit memory like it used to, e.g. for use on
a 21066-based system such as a "Noname" card, you got disappointed. I
know, I got disappointed at one of the times when DRAM was in short
supply and some creativity with part numbers seemed like a good idea.