Thanks Jonathan for the offer. Meanwhile X-rayed the 1643 as well and connected a really big battery. Here again: Had to start the oscillator before the UltraBook passed the POST and turned on the display - it is up and running again now - UltraBook and UltraBook IIi restored. So my final report:
(1) Failing UltraBooks and UltraBooks IIi can get a "new" NVRAM, but need them erazed and the oscillator started. After that, they power up again. (2) The procedure given in the Sun NVRAM-FAQ for using the OpenFirmware to set Machine Type 0x80, MAC, HostID and checksum works as given there (using the mkp command). This information goes into NVRAM adresses 0x1FD9 and following. (3) Also OpenBoot and the command idprom@ can be used to read the information (again according to the table in the FAQ) from NVRAM. (4) real-machine-type and update-system-idprom are not implemented in the UltraBooks and they are not necessary as well (information is written to the NVRAM immeiately with the mkp command). (5) During booting, Solaris may complain on a wrong date format in the NVRAM - but this message goes away after time was set using the OS's date command. (6) The contents of the NVRAM for lower addresses look different between UltraBook and UltraBook IIi, so it does not make sense using NVRAM contents from one type on the other one (boot order is at 0x2CB for both, but TTY-settings differ). (7) The Open-Firmware manual lists some interesting additional STOP sequences on top of STOP-A which may be of help if encountering problems - e.g. for resetting NVRAM or starting a Forth interpreter on TTYA for debugging of hardware problems - see page 107 in 901-7042. Happy computing and thanks to all who responded or participated in one way or another...
