AlphaStation 200 NVRAM Problem

[Maciej W. Rozycki]

On Sat, 23 Apr 2016, Robert Jarratt wrote:

> >  But from the discussion referred I gather DROM outputs its diagnostics to
> > this port too and you might be able to learn what exactly about NVRAM it
> > complains.
> 
> 
> Ah OK, so you think the DROM console also outputs to the SROM diagnostics?

 Yes, it does -- see the dumps reported in the discussion I referred. 

 The diagnostic port is just a primitive (bit-banged) serial port driven 
directly by the CPU.  Any software can poke/peek at it via three CPU pins 
(mapped to the SL_XMIT and SL_RCV internal processor registers) -- which 
is why it is available early on.  There is PALcode support for that port 
actually, saving the user of this interface from the need to calculate 
timings and to handle individual bits presumably.

 The real serial port used for regular operation is wired far away from 
the CPU, behind PCI and the ISA bridge (southbridge), off a Super-I/O 
chip.  You need to have all the hardware almost fully initialised to be 
able to talk to that port, so it's of no use before SRM/ARC has taken 
over.  Also lots of logic has to function correctly for that port to be 
accessible, so it's not as usable in diagnostics.

> I'd need to build some kind of adapter to do that. I'll have to research
> this. Is there a standard part?

 DEC had it internally, obviously, but I don't think you can come across 
one.  I think wiring an EIA/TIA 232 driver/receiver chip, maybe with the 
aid of a small prototyping board, shouldn't be much hassle though -- 
there's surely schematics for that already available somewhere online.

>  Also you might be able to correct configuration, e.g. by poking at
> > NVRAM or elsewhere appropriately;
> 
> 
> Not really sure how to poke the NVRAM without the console, or is that what
> you are suggesting?

 As I say you can use the SROM mini-console for that, flip J1 to enable 
it.  The interface is obviously crude (mind that you're running code out 
of I$, not much space there to fit fancy stuff) and you need to know the 
internals of the machine, to get at the right addresses.  But the manual: 
<http://manx.classiccmp.org/collections/mds-199909/cd1/alpha/pcdsatia.pdf> 
I already referred seems to cover all you need.

> > notice that the manual also suggests
> > you might be able to bypass the DROM sequence and go to SRM/ARC
> > directly, which might help recovery too.
> 
> 
> I have definitely missed that bit. Which manual says this?

 Same manual as above:

"When the SROM code has completed its tasks, it normally loads the DROM 
code and turns control over to it.  The SROM checks to see if the DROM 
contains the proper header and that the checksum is correct.  If either 
check fails, the SROM code reads a location in the TOY NVRAM.  The 
location indicates which console firmware (the SRM or the ARC) should be 
loaded.

"When the console firmware is loaded, the header check and the checksum 
are checked.  If either is in error, the SROM code jumps to its 
mini-console routine.  With the appropriate adapter, you can attach a 
terminal to the CPU's serial port and use the mini-console.  Typically, 
this port is used in the manufacturing environment."

-- so it looks to me you could temporarily pull DROM from its socket to 
bypass this step.  You won't have the ability to load the console from a 
floppy then of course as this is handled by DROM code, and you may need to 
set the TOY NVRAM location for SRM vs ARC correctly (though IIRC the 
Avanti series have enough flash space to keep both consoles at once; many 
years ago I had access to a Melmac machine, which is very similar to 
yours, up to the same form factor).

> >  It is battery backed indeed and it sits right in the upper right hand
> > corner: <http://web.mit.edu/6.111/www/s2007/datasheets/KM6264B.pdf>,
> > next to the other flashbus devices, as expected -- next to the left there
> is a
> > pair of flashROMs (and a pair of sockets for another two of the four
> > supported total), and a socketed DROM chip.  Being decoded as a DRAM
> > bank they are also close to DRAM sockets.  Jumpers and LEDs are elsewhere,
> > but obviously they have less strict PCB routing requirements.
> > 
> >  HTH,
> 
> Yes it does help! Thanks for that. At least I now know where the NVRAM
> actually is. I have found some parts on Ebay, but I have no idea how to deal
> with surface mount though, another research area...

 Somehow I doubt an SRAM chip has failed TBH, so replacing it might not 
help, there could be something else causing the problem.  It would be good 
to know what exactly has failed, and with DROM output on the diagnostic 
serial port and/or the SROM mini-console you might actually be able to 
figure out what's going on here (e.g. fill NVRAM with some bit patterns, 
see if they come back right, and if they stick across a power cycle).

 Ah, and may I suggest wiping the dust in this area; I dare not think it 
might be causing a short or something.

  Maciej