On Mon, 2 May 2016, Robert Jarratt wrote: > > 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 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: >>> 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
