1 May
2016
1 May
'16
2:57 p.m.
I want to read the DROM chip with my programmer, but I can't ID the chip. Does anyone
know what kind it is? It is in a PLCC32 package and the label on it is:
369E7
AYOMA
49/95
I am sure at least some of that is DEC stuff, unrelated to the type of chip. However, none
of those parts of the label seem to correspond to any EPROM I can find. My
programmer's software has an auto detect feature, but that also failed to ID the chip.
I don't really want to remove the label if I can avoid it.
The underside is marked
76394-23
Singapore
C4
522 (might be 322)
512X
None of these appear to match anything either.
Any ideas what it might be?
Thanks
Rob
2 May
2 May
3:13 a.m.
On Sun, 1 May 2016, Robert Jarratt wrote:
Any ideas what it might be?
I can't help with the chip, except that the manual states it's a 64-Kbyte
part. But something has struck me:
"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."
-- I think it's highly unlikely that DROM is corrupted *and* it passes the
checksum test *and* corrupt DROM code works well enough to progress
through any POST stages at all (i.e. change LEDs to anything beyond what
SROM has left). So I wonder what else might be causing the symptoms you
have seen. SROM console output undoubtedly might help here as DROM might
be reporting what it does not like, about NVRAM presumably.
One possibility I have in mind is it's something peculiar about DRAM.
As you may have been aware DROM code isn't run directly, it's loaded by
SROM into DRAM. If it fails a specific bit pattern at a specific location
for some reason, then you might see symptoms like these. So shuffling
DRAM modules might change something here.
Other than that maybe it's NVRAM after all. But what could it be then
that did not show up in your testing? Could it be that the settings and
environment variables stored there are protected with a checksum (or a
signature) which happened to be correct for the random contents after
power was restored and that in turn confused DROM diagnostics? Can you
wipe NVRAM with your program, reinstall the DROM chip and see if the error
returns?
I start running out of ideas, and sorry to have misled you into thinking
it might be DROM contents which are wrong -- given the checksum protection
I think it's highly unlikely after all.
Maciej
4:39 a.m.
-----Original Message-----
From: cctech [mailto:cctech-bounces at classiccmp.org] On Behalf Of Maciej
W. Rozycki
Sent: 02 May 2016 08:14
To: Robert Jarratt <robert.jarratt at ntlworld.com>
Cc: 'General Discussion: On-Topic Posts' <cctech at classiccmp.org>
Subject: RE: AlphaStation 200 NVRAM Problem
On Sun, 1 May 2016, Robert Jarratt wrote:
part.
Any ideas what it might be?
I can't help with the chip, except that the manual states it's a 64-Kbyte
But something has struck me:
"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."
-- I think it's highly unlikely that DROM is corrupted *and* it passes the
checksum test *and* corrupt DROM code works well enough to progress
through any POST stages at all (i.e. change LEDs to anything beyond what
SROM has left). So I wonder what else might be causing the symptoms you
have seen. SROM console output undoubtedly might help here as DROM
might be reporting what it does not like, about NVRAM presumably.
I suppose I should find or construct a diagnostic port adapter. I suppose I
am slightly put off by the effort needed to make one as I don't have the
components needed to hand. I may just have to bite this bullet.
One possibility I have in mind is it's something peculiar about DRAM.
As you may have been aware DROM code isn't run directly, it's loaded by
SROM into DRAM. If it fails a specific bit pattern at a specific location
for
some reason, then you might see symptoms like these.
So shuffling DRAM
modules might change something here.
I will give this a go, but it seems unlikely as the machine is able to run
VMS, and I assume it must be passing at least some basic memory tests.
Other than that maybe it's NVRAM after all. But what could it be then
that
did not show up in your testing? Could it be that the
settings and
environment variables stored there are protected with a checksum (or a
signature) which happened to be correct for the random contents after
power was restored and that in turn confused DROM diagnostics? Can you
wipe NVRAM with your program, reinstall the DROM chip and see if the error
returns?
This thought has crossed my mind. However, since I had to change the battery
that backs up the NVRAM in any case, then surely the memory would have been
zeroed? This NVRAM is battery backed, right? The NVRAM does contain data, I
have verified this with my program, so something is repopulating it after
the battery has been changed. I am slightly reluctant to zero the memory on
purpose in case I can no longer boot the machine (I would save the contents
before zeroing of course).
I start running out of ideas, and sorry to have misled you into thinking
it
might be DROM contents which are wrong -- given the
checksum protection I
think it's highly unlikely after all.
Not to worry, your thoughts and suggestions have helped hugely.
Thanks again
Rob
5:42 a.m.
One possibility I have in mind is it's something peculiar about DRAM.
As you may have been aware DROM code isn't run directly, it's loaded by
SROM into DRAM. If it fails a specific bit pattern at a specific location
some reason, then you might see symptoms like these. So shuffling DRAM
modules might change something here.
I will give this a go, but it seems unlikely as the machine is able to run
VMS, and I assume it must be passing at least some basic memory tests.
1:39 p.m.
-----Original Message-----
From: cctalk [mailto:cctalk-bounces at classiccmp.org] On Behalf Of Peter
Coghlan
Sent: 02 May 2016 10:42
To: General Discussion: On-Topic Posts <cctech at classiccmp.org>
Subject: RE: AlphaStation 200 NVRAM Problem
tests.
Perhaps VMS could be working around correctable memory errors that
SROM is not able to cope with? If this is the case,
$ SHOW ERROR
That just says:
%SHOW-S-NOERRORS, no device errors found
One possibility I have in mind is it's something peculiar about DRAM.
As you may have been aware DROM code isn't run directly, it's loaded
by SROM into DRAM. If it fails a specific bit pattern at a specific
location some reason, then you might see symptoms like these. So
shuffling DRAM modules might change something here.
I will give this a go, but it seems unlikely as the machine is able to
run VMS, and I assume it must be passing at least some basic memory should give a clue and there should be further
information in the error
log.
(I'm not sure how you display that since the
functioning of $ ANALYZE
/ERROR got messed up on Alpha some time ago.)
I tried SHOW MEMORY, but that seemed good. ANALYZE/ERROR said I should
install DECevent and run conversion utility. Not sure about that one.
Regards
Rob
12:47 p.m.
I suppose I should find or construct a diagnostic port
adapter. I suppose
I am
slightly put off by the effort needed to make one as I
don't have the
components needed to hand. I may just have to bite this bullet.
I decided to attempt the construction of an adapter. But it is the
connectors which always bite me because I don't know what all the types of
connector are. I naively assumed that an IDC 10-way (2x5) would do the
trick, but it is too wide to go into the male connector on the board.
What kinds of connectors exist for ribbon cables that can be used to go into
a 2x5 connector, but which don't have a lot of space at the sides?
I have posted a picture of the connector here: http://bit.ly/1SV6QBX. It is
the black 2x5 connector in the middle marked J7.
Regards
Rob
3 May
3 May
1:20 p.m.
On Mon, 2 May 2016, Robert Jarratt wrote:
I decided to attempt the construction of an adapter.
But it is the
connectors which always bite me because I don't know what all the types of
connector are. I naively assumed that an IDC 10-way (2x5) would do the
trick, but it is too wide to go into the male connector on the board.
What kinds of connectors exist for ribbon cables that can be used to go into
a 2x5 connector, but which don't have a lot of space at the sides?
I think this header is intended for a crimp wire receptacle, like:
<http://uk.rs-online.com/web/p/pcb-connector-housings/8215708/>. This is
non-polarised though; getting one that is polarised and with the right key
might be a bit of a challenge. Alternatively a PCB socket like:
<http://uk.rs-online.com/web/p/pcb-sockets/7655648/> would do too; again
getting a polarised one seems tough.
I don't know which of the two solutions the original DEC SROM "dongle"
used. I can only find 3 references quoting the part number, which is/was
96-RM001-01. It provided for a standard DECconnect cable, so I think it's
actually quite likely that it was just a small daughtercard with a PCB
socket, line driver and receiver ICs (DEC documentation quotes 1488 and
1489, but with a pair of wires used for communication that looks like an
overkill to me -- a single IC like MAX232N would do IMHO; RS sell them
individually even) and their associated passive components, and then an
MMJ socket, all on the PCB. Obviously these days you probably want a DE-9
connector instead. ;)
I wonder if I shouldn't actually make something like this myself just for
fun -- to have a way to peek at my DEC 3000's internals even though it
appears healthy overall.
Maciej
5:18 p.m.
On 03 May 2016 at 18:20 "Maciej W. Rozycki" <macro at linux-mips.org>
wrote:
On Mon, 2 May 2016, Robert Jarratt wrote:
The crimp wire one looks like it would work, thanks for the suggestion!
I decided to attempt the construction of an
adapter. But it is the
connectors which always bite me because I don't know what all the types
of
connector are. I naively assumed that an IDC 10-way (2x5) would do the
trick, but it is too wide to go into the male connector on the board.
What kinds of connectors exist for ribbon cables that can be used to go
into
a 2x5 connector, but which don't have a lot of space at the sides?
I think this header is intended for a crimp wire receptacle, like:
<http://uk.rs-online.com/web/p/pcb-connector-housings/8215708/>. This is
non-polarised though; getting one that is polarised and with the right key
might be a bit of a challenge. Alternatively a PCB socket like:
<http://uk.rs-online.com/web/p/pcb-sockets/7655648/> would do too; again
getting a polarised one seems tough.
I don't know which of the two solutions the original DEC SROM "dongle"
used. I can only find 3 references quoting the part number, which is/was
96-RM001-01. It provided for a standard DECconnect cable, so I think it's
actually quite likely that it was just a small daughtercard with a PCB
socket, line driver and receiver ICs (DEC documentation quotes 1488 and
1489, but with a pair of wires used for communication that looks like an
overkill to me -- a single IC like MAX232N would do IMHO; RS sell them
individually even) and their associated passive components, and then an
MMJ socket, all on the PCB. Obviously these days you probably want a DE-9
connector instead. ;)
I have a MAX232CPE now, just need the connectors and one more 1uF capacitor and
I should have all I need.
I wonder if I shouldn't actually make something like this myself just for
fun -- to have a way to peek at my DEC 3000's internals even though it
appears healthy overall.
Maciej
6 May
6 May
7:40 p.m.
I have been setting up a MAX232CPE to try to get serial output from the serial diagnostic
port. Trouble is I am not sure which signal is the data signal. The one that is marked
SROMCDAT in the technical manual does not appear to do anything when I look at it with the
scope. Anyone know which is the right signal to monitor?
Thanks
Rob
8:09 p.m.
On Sat, 7 May 2016, Robert Jarratt wrote:
I have been setting up a MAX232CPE to try to get
serial output from the
serial diagnostic port. Trouble is I am not sure which signal is the
data signal. The one that is marked SROMCDAT in the technical manual
does not appear to do anything when I look at it with the scope. Anyone
know which is the right signal to monitor?
That pin is the Rx side or data input, so obviously you won't see
anything interesting there. The Tx side or data output is on BSROMCLK.
I'll send you a document page with conceptual schematics of the host side
of the circuit; off the list as attachments are not allowed here I believe
no matter how small.
Maciej
2 May
2 May
5:56 p.m.
On Mon, 2 May 2016, Robert Jarratt wrote:
I don't think you can assume power-cycling NVRAM (which is effectively
what you've done here by putting a new battery) will zero it. It would if
there was some kind of a reset signal asserted at poweron that would set
the flip-flops to a known state. But the KM6264B chip does not appear to
have such a feature, nor an external reset input. So we need to assume
its contents are random after a powerup. Have you ever used Sinclair ZX
Spectrum? It had its video adapter active from powerup and you could
briefly see the random contents of video RAM on the screen.
I understand your reluctance. The NVRAM is indeed supposed to be backed
with the same battery the RTC is. There's just a slight chance the
battery circuit is not operating correctly. There's no battery status bit
in the NVRAM, but there is one in the RTC. You should be able to verify
it with:
Other than
that maybe it's NVRAM after all. But what could it be then
that
did not show up in your testing? Could it be
that the settings and
environment variables stored there are protected with a checksum (or a
signature) which happened to be correct for the random contents after
power was restored and that in turn confused DROM diagnostics? Can you
wipe NVRAM with your program, reinstall the DROM chip and see if the error
returns?
This thought has crossed my mind. However, since I had to change the battery
that backs up the NVRAM in any case, then surely the memory would have been
zeroed? This NVRAM is battery backed, right? The NVRAM does contain data, I
have verified this with my program, so something is repopulating it after
the battery has been changed. I am slightly reluctant to zero the memory on
purpose in case I can no longer boot the machine (I would save the contents
before zeroing of course). >> d -b pmem:1c0000e00 0d
>> e -b pmem:1c0000e20
this will read BQ4285 RTC chip's register D. If this comes out as 80,
then the battery is giving power to the chip. If this is 00, then there
is no battery power available. Of course a broken PCB trace could make
battery power reach one of the two chips only.
BTW, does your SRM console have a TEST command? If so, then have you
tried it? Of course it might want to call into DROM and thus fail rather
spectacularly if it's absent, but chances are it might not and you may get
useful output from it.
Maciej
3 May
3 May
5:14 p.m.
On 02 May 2016 at 22:56 "Maciej W. Rozycki" <macro at linux-mips.org>
wrote:
On Mon, 2 May 2016, Robert Jarratt wrote:
I don't think you can assume power-cycling NVRAM (which is effectively
what you've done here by putting a new battery) will zero it. It would if
there was some kind of a reset signal asserted at poweron that would set
the flip-flops to a known state. But the KM6264B chip does not appear to
have such a feature, nor an external reset input. So we need to assume
its contents are random after a powerup. Have you ever used Sinclair ZX
Spectrum? It had its video adapter active from powerup and you could
briefly see the random contents of video RAM on the screen.
I did a test last night which failed, but realised I did it wrong. I am away
Other
than that maybe it's NVRAM after all. But what could it be then
that
did not show up in your testing? Could it be that
the settings and
environment variables stored there are protected with a checksum (or a
signature) which happened to be correct for the random contents after
power was restored and that in turn confused DROM diagnostics? Can you
wipe NVRAM with your program, reinstall the DROM chip and see if the
error
returns?
This thought has crossed my mind. However, since I had to change the
battery
that backs up the NVRAM in any case, then surely the memory would have
been
zeroed? This NVRAM is battery backed, right? The NVRAM does contain
data, I
have verified this with my program, so something is repopulating it
after
the battery has been changed. I am slightly reluctant to zero the memory
on
purpose in case I can no longer boot the machine (I would save the
contents
before zeroing of course). from home again now and will try that test again, plus
the suggestions below.
Thanks
Rob
I understand your reluctance. The NVRAM is indeed supposed to be backed
with the same battery the RTC is. There's just a slight chance the
battery circuit is not operating correctly. There's no battery status bit
in the NVRAM, but there is one in the RTC. You should be able to verify
it with:
>> d -b pmem:1c0000e00 0d
>> e -b pmem:1c0000e20
this will read BQ4285 RTC chip's register D. If this comes out as 80,
then the battery is giving power to the chip. If this is 00, then there
is no battery power available. Of course a broken PCB trace could make
battery power reach one of the two chips only.
BTW, does your SRM console have a TEST command? If so, then have you
tried it? Of course it might want to call into DROM and thus fail rather
spectacularly if it's absent, but chances are it might not and you may get
useful output from it.
Maciej
2998
days inactive
3004
days old
11 comments
3 participants
participants (3)
-
cctalk＠beyondthepale.ie -
macro＠linux-mips.org -
robert.jarratt＠ntlworld.com