which starts I believe this reversion back to AlphaBios does indeed apply to the AlphaStation 200 too. But in my case nothing appears on the monitor and nothing appears on the serial port either, I just get some beeps and a LED diagnostic code. It is possible that I have a cabling issue with the serial port, but I did try a few combinations. If I know that I should expect output on the serial port despite an NVRAM self-test failure then I could investigate that further with my breakout box (don't have a protocol analyser). Regards Rob

<SNIP> I posted a while back about this problem. I am wondering if I have a chance of reviving this system or if it is beyond repair (by me)? I can't get anything out of the console port, and I don't know if I should expect to be able to get output from there or not. If I know that I should expect output on the serial port despite an NVRAM self-test failure then I could investigate that further with my breakout box (don't have a protocol analyser). I have been unable to identify the NVRAM chips either. Thanks for any help. Regards Rob

Yes I did :-( But I can check it again. Regards Rob

module be the In my case there is just a CR2032, and no Dallas module. I will try replacing the CR2032 again. Regards Rob

On 23/04/2016 00:35, ethan at 757.org wrote: Yep, used to be a problem even in the mid-1990s with some Suns. We used to keep a copy of at least every MAC address so we could reprogram them, and advocated keeping a dump of the rest of the contents too. Similar problem on SGIs later, which reminds me of a trick an SGI engineer showed me for Indys. If you need to replace the Dallas chip, especially with one "borrowed" fom another machine,first put it in backwards. That wipes it - most importantly, the MAC address, on which some licences depend - and lets the machine boot to the PROM as far as you need to reprogram the necessary variables. I accept no responsibility for any problems arising from testing this however! -- Pete

On 23/04/2016 00:37, Robert Jarratt wrote: Then the CMOS RAM - which is what the battery is for - has lost its memory. The CMOS could be an individual chip but it's more likely to be part of something else, like a Motorola real time clock IC - and hopefully socketed as Ethan suggested, otherwise you get more practice with your desoldering gun ;-) -- Pete

On Fri, 22 Apr 2016, Robert Jarratt wrote: If all else fails, then perhaps you could try the SROM mini console to get further information, or maybe even recover as there are commands there to poke at hardware. Information on using that is however scarce and scattered, you can find some here to start: <http://labs.hoffmanlabs.com/node/1286> and then the pinout for the serial diagnostic port is included here: <http://manx.classiccmp.org/collections/mds-199909/cd1/alpha/pcdsatia.pdf> (the boot sequence is also described here, so you'll know that an NVRAM failure is reported by DROM code, i.e. before the final SRM or ARC console takes over and is able to use the regular serial port). That's a bit cryptic, but knowing that this is a low-level CPU interface you can gather the wiring from this document: <http://h18000.www1.hp.com/cpq-alphaserver/technology/literature/164lxtrm.pdf>. So BSROMCLK is Tx and SROMCDAT is Rx, but as noted here and in the discussion in the first reference you need an EIA/TIA 232 driver and receiver (there is power available on the diagnostic port, so you can use it for the circuit), and of course you need to cross the lines wiring them to your host. Finally the SROM console command reference is here: <http://h18000.www1.hp.com/cpq-alphaserver/technology/literature/srommini.pdf>. This manual doesn't specifically cover the Avanti, but I'd expect the user interface to be similar -- it's a low-level tool close to the CPU after all. NB on Avanti the 8kB NVRAM is separate from the TOY/NVR chip (which is a Benchmarq BQ4285, providing 114B of general storage only). Hope this helps and good luck with system recovery! Maciej

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. Also you might be able to correct configuration, e.g. by poking at NVRAM or elsewhere appropriately; 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. It's up to you if you want to try this of course, I just thought it might help as the existence of this SROM console might not be universally known. It is separately decoded on the flashbus (among flashROM, DROM, diagnostic LEDs and jumpers), so I doubt it's in an ASIC, that would be too arcane. I suspect they wanted to keep it separate from flashROM for safety. 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, Maciej

On Sat, 23 Apr 2016, Robert Jarratt wrote: 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. 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. 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. 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). 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

check mini-console CPU's create will Well! I took out the DROM and switched it on again. The machine bleeped at me, but then it gave me a console and I was able to boot VMS! I will have to see if the NVRAM is now populated and whether it will continue to work with the DROM installed. Thanks! Rob

easier, and Yes that is exactly the code I get on the LEDs. for 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. Regards Rob

The equivelant in VMS is sys$crmpsc. I can supply a sample program (in macro32) which calls it to read the firmware in a VAXStation 2000. I don't know the right addresses to use for an Alphastation 200 though. (Congratulations on the progress made so far. Maybe there is hope yet for my two DEC 3000/600 machines which have similar symptoms.) Regards, Peter Coghlan.

On Sat, 23 Apr 2016, Peter Coghlan wrote: Reminds me to revive my 3000/700, once I get the mechanical issues from mishandling in shipping sorted out. I hope it hasn't rotted from disuse -- it was alright, booted OSF/1 even, when I last powered it on ~10 years ago. I should have done it sooner. Having a physical box I might be able to help even more, check things, etc. The only difference is the clock rate I believe. Maciej

On 24/04/16 15:46, Robert Jarratt wrote: If you post a few lines of code, someone might spot the problem. I assume you are getting SS$_ACCVIO as return? So either return_va_64 or return_length_64 wasn't passed by reference (or wasn't long enough but you'd have to be really lucky to pass in a 32-bit value that sat at the very end of a page ...) Antonio -- Antonio Carlini arcarlini at iee.org

close can My program to test the NVRAM is not going well. When I try to write to what I think is the flashbus index register, I kill the machine stone dead. I'd just like to validate my approach, see if it makes sense: The docs says the index register is at 0x1.0000.0000 (physical I assume). On the assumption that the Alpha has an 8K page size that means the Page Frame Number for the physical page will be at 0x8.0000. So I am using sys$crmpsc_pfn_64 to start at that PFN. Correct? When I get the address back it is right at the start of page, so that is the address I access from my code. I was also unsure which region to use and I have tried P0 and P2, P2 seemed to not crash the machine but would give me ACCVIO instead, except that in my latest test P2 also crashed the machine. I am also specifying USER mode. I can post the code if that helps. Any ideas where I am going wrong here? Thanks Rob

On Sun, 24 Apr 2016, Maciej W. Rozycki wrote: Ah, BTW, a general note: make sure you request an uncached mapping, if your interface has such control, mark your pointers `volatile' and use appropriate synchronisation barriers between accesses. Maciej

On Mon, 25 Apr 2016, Robert Jarratt wrote: Hmm, I wonder if: would make a difference. I guess not, but probably worth checking. I'm sure they're physical (see Chapter 3 too). One possibility is SRM unmaps them when it takes over from SROM, for safety maybe -- so as not to let one corrupt flash by accident easily (BTW, I do recommend write-protecting flash with its jumper for these experiments -- with DROM not working correctly and hence no way to load SRM from a floppy you'd be doomed if flash broke too). The symptoms should look like ones you've got, though of course plain poking at the wrong area would look the same. You could check if flashbus is mapped by peeking at bank 8 memory controller registers and seeing if the contents provide the necessary wiring (in particular if bit #0 aka `s8_Valid' in the 16-bit word at 0x180000b00 is 1). These registers are listed in the same manual -- with a further reference to the (rather fat) memory controller manual. If not, then you'd have to set them yourself. There could be PALcode entry points to access flashbus too I suppose, although regrettably my Alpha-fu is not so deep as to know this offhand. NB all the address space from 0x100000000 through to 0x1ffffffff is uncacheable it would seem, so no need to be concerned about this part. Maciej

On Tue, 26 Apr 2016, Robert Jarratt wrote: Well, the symptoms appear consistent then (I thought in OpenVMS you got a freeze), so I suspect my guess about unmapping is right. Correct -- if you do get a machine check as early as accessing the index register, then it looks like the glue logic for flashbus doesn't respond to a write cycle (there's no decoding enabled for the address requested) and you get a bus timeout/abort. Given that at this point you are only about to select a particular device on flashbus it would equally happen for any, including the LEDs. Unless there is a timing requirement for the data register to see an access soon enough after an index write or a bus error happens -- which I highly doubt given the crudeness of the logic (i.e. even the read/write signal is explicit rather than decoded from the data register access bus cycle). OK, just shout if you find yourself lost. Maciej

It chance I and the perhaps space. up It turns out that I only needed to flip the bit in the bank 8 config register and I can now access the flashbus. I can write to the LEDs, it turns out that writing a 0 turns the LED on, rather than off, which is why I thought it hadn't worked. I can now do test code for the NVRAM, I will start with repeated reads to see if I get different values on different occasions. Then I will save it and write patterns etc. It may be a checksum that is failing of course. Or the DROM itself, which I can't verify until I get the PLCC adapter for my PROM programmer and someone else to read their DROM. Thanks for all the help I have a way forward for a little while now. Although anyone with one of these machines who could read the DROM would be helpful. I will be able to supply a VMS program to read it, so need to remove it from the machine or to have a programmer. Regards Rob

see Tru64. There Many thanks for the suggestion. Only trouble is I am in the UK and shipping tends to be expensive from the USA. I'll check on ebay in the UK, as long as it doesn't cost too much. Regards Rob

On Wed, 27 Apr 2016, Maciej W. Rozycki wrote: I'll ask, Mighty Maciej. I have a couple of other vendors, too (partners with my $job). I'll forward your message to them. They are guys with service companies who fix the Alphas and IBM Power machines our clients use. They have so much stuff in their warehouses, it wouldn't surprise me if they had what you need. They mostly buy in bulk at auctions. I work with them all the time, so who knows, maybe they will help. I'll send you an email with any details they give me. -Swift

see if write itself, and What size PLCC? I have some PLCC to DIL adaptors... remove Dave G4UGM

On Tue, 26 Apr 2016, Robert Jarratt wrote: Oh, I thought you would try 0x55 or suchlike pattern -- given that you did not know whether it is active-high or active-low logic being used by the circuit. And active-low is actually what I'd expect here given that you get all the LEDs lit at reset. I just hope it's not a heisenbug of some sort and with NVRAM supposedly now eliminated as the cause it is DROM contents indeed. The DROM part at least can be fixed without soldering, which is always a bit of a challenge with finer pitch components. You are welcome! Good luck tracking down a DROM image soon -- that's beyond me I'm afraid, I only have TURBOchannel stuff really. Maciej

On Tue, 26 Apr 2016, Robert Jarratt wrote: Both correct: * 0x4000 << (23 - 5) => 0x100000000 * 0x0136: s8_Check => 0b0 -- ECC/parity disabled s8_ColSel => 0b100 -- row/column bits: 9/9 s8_SubEna => 0b1 -- subbanks enabled s8_Size => 0b1011 -- bankset size: 2MB s8_Valid => 0b0 -- access disabled Clearly the index and the data register are wired as individual subbanks each. Indeed; memory controller register addresses are hardwired IIUC, so they're always there. As to the bankset configuration register: * 0x0069: s0_ColSel => 0b001 -- row/column bits: 12/10 or 11/11 s0_SubEna => 0b1 -- subbanks enabled s0_Size => 0b0100 -- bankset size: 64MB s0_Valid => 0b1 -- access enabled I take it it corresponds to your memory module installed. You won't read LEDs back as it's a write-only location, a plain octal D flip-flop presumably. Is it not a 74F273 that I can see right below the unfortunate NVRAM chip on your photo? That would be it then. Its outputs are rated 20mA each, plenty to drive LEDs without additional circuitry. Have you tried using your C program instead to poke at these LEDs? SRM might be interfering, e.g. accessing NVRAM or maybe LEDs even between your commands, and consequently your data register writes issued with `deposit' may go elsewhere as the index register has been since changed under your feet. While experimenting with C code make sure you synchronise accesses -- insert `asm("mb")' or suchlike (whatever OpenVMS C compiler supports) just after each flashbus index or data register access and read back the index register before accessing the data register to avoid weak ordering effects in the chipsed, just as noted in the system manual. Timings are documented in the chipset datasheet, though this is all cryptic of course as we don't know what the requirements are for flashbus. We could assume though that they're the same for the index and data side and then try to match them to the NVRAM being 70ns. Perhaps you could post them too? Well, but didn't it poke at LEDs? It also tried to load DROM before loading SRM and PALcode from flash, both of which are on flashbus, so it must have got bank 8 right. If anything it's SRM or PALcode interfering here probably. Maciej

This thread has been making me wonder about my two AS200?s, I?ve been meaning to revive the one with 768MB of RAM for VMS. I really should also check out my XP1000/667 as well, though I last booted it a year or so ago, when I needed to research a VMS problem for work. Zane

either script it) I have been trying to work out how to do that very thing. I don't think there is quite enough info in the technical manual. to If necessary I should be able to install linux, but still, working out the address doesn't seem trivial. I have ordered an adapter so I can read the ROM. Would be good, as you suggest, to read someone else's to compare... looks to these Many thanks for all your help today! Regards Rob