23 Apr
2016
23 Apr
'16
1:28 p.m.
On Sat, 23 Apr 2016, Robert Jarratt wrote:
First of all you might be able to run some SRAM diagnostics yourself,
either from the console (if it has a tool for this; at worst you could
poke at it manually with deposit/examine commands, but the complicated
flashbus access protocol will make it a tedious task unless there is a way
to script it) or from the OS (can't help how to do this from VMS; under
Linux you could mmap(2) /dev/mem at the right address and then poke at it
with a little program doing the right dance to get the flashbus access
protocol right), to see if it shows any symptoms of misbehaviour.
To experiment with DROM you might be able to find a DIP-to-PLCC socket
adapter, pinouts for ROMs are pretty standard I believe. A ROM emulator
might help too if you can get your hands on one, second-hand units are not
exactly expensive nowadays as they went out of favour it would seem.
Overall, hard to say which failure case would be better (or worse). It
looks to me like at this point you have several options to proceed with.
Good luck with your investigation and recovery! I wish I had one of
these machines, they are sweet and they run Linux out of the box. ;)
Maciej
Second: it
may also be that DROM itself is faulty, a bit may have flipped
for
example; NB this is UV EPROM, so things happen.
Maybe someone can
share a known-good image.
When I put the DROM back the failure returned. So it is either a bad SRAM, a
short/open somewhere, or the DROM code itself. I have a PROM programmer, but
it is only for DIP packages, I don't have the facilities to read a PROM in
this type of package. I will have another look round for any obvious
problems on the board, but it looked OK to me when I checked. Getting the
SROM diags out might help too, I will have a look at that.