[cctalk] Re: Tadpole/RDI UltraBooks - UNIX notebooks - species needs rescue...
I did not check for that. Here is a pic https://vintagecomputer.net/RDI/PowerLite/RDI_PowerLite_PLX800-1200-32.jpg On Sat, Oct 28, 2023, 1:22 PM erik--- via cctalk wrote: > Thanks Bill, that is cool! So failing display means it is black, but you > hear it booting from the HDD? Do you know what type of NVRAM was used in > the PowerLite? (Would be interesting if their NVRAM also has a "stop > oscillator" bit which I attribute to the problems) >
[cctalk] Re: Tadpole/RDI UltraBooks - UNIX notebooks - species needs rescue...
Thanks Bill, that is cool! So failing display means it is black, but you hear it booting from the HDD? Do you know what type of NVRAM was used in the PowerLite? (Would be interesting if their NVRAM also has a "stop oscillator" bit which I attribute to the problems)
[cctalk] Re: Tadpole/RDI UltraBooks - UNIX notebooks - species needs rescue...
Fired up my three PowerLites...all three need nvram batteries, no surprise. One has a failing display, one has a dead display or an issue with power but they all at least boot up. Bill On Sun, Oct 22, 2023, 3:36 PM erik--- via cctalk wrote: > 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... >
[cctalk] Re: Tadpole/RDI UltraBooks - UNIX notebooks - species needs rescue...
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...
[cctalk] Re: Tadpole/RDI UltraBooks - UNIX notebooks - species needs rescue...
> Next step will be trying the same on my UltraBook (DS1643 instead of DS1553 > on the UltraBook IIi). But need to Xray that one first before attaching a new > battery. I have a DS1643 replacement prototype if you're interested. Thanks, Jonathan
[cctalk] Re: Tadpole/RDI UltraBooks - UNIX notebooks - species needs rescue...
After some silence I can report SUCCESS on that issue! YEAH! Happy I am: After first repairing the TopMax programmer, digging out my old GALEP3 prgrammer and building a very special adapter socket for the DS1553, I was able to have a detailed analysis: (1) The DS1643 and DS1553 chips can stop the oscillator to save some energy when stored away. (2) After attaching a new battery to very old chips (i.e. if battery voltage goes below ~0.9V) the chips automatically revert to the "oscillator stopped" condition, even if new battery is connected. (3) So with new DS1553 and old one with new battery connected, the clock is stopped! (4) The OpenBoot firmware, before powering the screen and running self test, seems to rely on a running clock, i.e. it is not coming up at all if the oscillator is stopped! (5) To me that is a bug in the startup code of the UltraBook IIi's firmware - it does obviously not start the oscillator by itself! After activating the oscillator and clearing my NV-RAM the UltraBook IIi is coming up into the OpenBoot Firmware again!!! Lesson for others: If your battery voltage drops below 2V, you will see the "NVRAM invalid message", but the machine will boot/work. But after some more years when the battery voltage gets low enough for the oscillator to stop you will run into trouble! Next step will be trying the same on my UltraBook (DS1643 instead of DS1553 on the UltraBook IIi). But need to Xray that one first before attaching a new battery.
[cctalk] Re: Tadpole/RDI UltraBooks - UNIX notebooks - species needs rescue...
Before heading to some short vacation first of all: Thanks to all contributers! I built an adapter for reading the NVRAMs in my programmers (CE2 pulled to VCC using a resistor, pin 1 isolated) - this adapter us usable for both the DS1643 and the DS1553. The TopMax2 software has got a bug - it reads 1643 only as 4k device so I read all NVRAMs selecting the DS1225 using my Galep-III (software Galep32) and my TopMax2. Results: (1) The contents of the 1643s (unmodified from UltraBooks) showed varying content with lot of 55 and AA as in Santo's dump above. Writing to NVRAM is of course not persistent. (2) The contents of my modified 1553 (from UltraBookIIi with the external battery attached) are stable (so the battery works) but the content is ramdom. The oscillator is stopped hence no update of the clock. After starting that in the UltraBookIIi the clock still is stopped, so the device is in its factory-fresh mode and the firmware does not start clock. I can write the data section and any modification is persistent (again: the external battery works). After my vacation I will zero the RAM, start the clock, set reasonable values for the watchdog and hostid and give it a new try. The problems to be solved before: The TopMax2 just died and the Galep-III can not write the configuration section - it writes all bytes in one run and than does a verify, but to write the upper 16 bytes first the write bit needs to be set, than data should be written and it gets latched only in clearing the write bit again. That process simply is not present in the Galep32 software because the device gets powered down before verify :-( Stay tuned...
[cctalk] Re: Tadpole/RDI UltraBooks - UNIX notebooks - species needs rescue...
In addition to my last message, I forgot to add the second page of NVRAM settings. Attached. Santo On Thu, Sep 28, 2023 at 2:56 PM Santo Nucifora wrote: > Erik, do you have any of the documentation for the Ultrabook? > > Attached are the NVRAM settings for the Ultrabook found in the > "Ultrabook Hardware Reference Guide". Also attached is an NVRAM recovery > procedure that Sun put out on the Ultrabook. > > Santo > > On Thu, Sep 28, 2023 at 2:46 PM erik--- via cctalk > wrote: > >> Yeah - reading the source code of QEMU I found the structure of the NVRAM >> - >> >> EVEN BETTER there was a WEB page with a good description of the various >> NVRAMs on Sun machines up to Ultra1. Yes, there "was". >> >> FORTUNATELY via archive.org, that page can be accessed - Tad- >> here it is: >> >> https://web.archive.org/web/20151107014449/http://www.squirrel.com/squirrel/sun-nvram-hostid.faq.html >> >> HOT: As I suspected: The first byte of the hostID in some systems defines >> the machine type. >> >> PERFECT: There are also commands given to read/write the NVRAM from the >> firmware. >> >> Thanks Ethan, the hint to check the emulation was great! >> >
[cctalk] Re: Tadpole/RDI UltraBooks - UNIX notebooks - species needs rescue...
Erik, do you have any of the documentation for the Ultrabook? Attached are the NVRAM settings for the Ultrabook found in the "Ultrabook Hardware Reference Guide". Also attached is an NVRAM recovery procedure that Sun put out on the Ultrabook. Santo On Thu, Sep 28, 2023 at 2:46 PM erik--- via cctalk wrote: > Yeah - reading the source code of QEMU I found the structure of the NVRAM > - > > EVEN BETTER there was a WEB page with a good description of the various > NVRAMs on Sun machines up to Ultra1. Yes, there "was". > > FORTUNATELY via archive.org, that page can be accessed - Tad- > here it is: > > https://web.archive.org/web/20151107014449/http://www.squirrel.com/squirrel/sun-nvram-hostid.faq.html > > HOT: As I suspected: The first byte of the hostID in some systems defines > the machine type. > > PERFECT: There are also commands given to read/write the NVRAM from the > firmware. > > Thanks Ethan, the hint to check the emulation was great! >
[cctalk] Re: Tadpole/RDI UltraBooks - UNIX notebooks - species needs rescue...
Yeah - reading the source code of QEMU I found the structure of the NVRAM - EVEN BETTER there was a WEB page with a good description of the various NVRAMs on Sun machines up to Ultra1. Yes, there "was". FORTUNATELY via archive.org, that page can be accessed - Tad- here it is: https://web.archive.org/web/20151107014449/http://www.squirrel.com/squirrel/sun-nvram-hostid.faq.html HOT: As I suspected: The first byte of the hostID in some systems defines the machine type. PERFECT: There are also commands given to read/write the NVRAM from the firmware. Thanks Ethan, the hint to check the emulation was great!
[cctalk] Re: Tadpole/RDI UltraBooks - UNIX notebooks - species needs rescue...
Awesome! Didn't realize MAME ws limited to 32-Bit SPARC. But the emulators can definitely be handy, or at least get you partly there! - Ethan Hi Ethan, thanks for suggesting MAME - did some research and somehow I do not think it emulates UltraSparc but only 32bit Sarc. But saw, that QEMU has a UltraSparc emulation and they... https://www.qemu.org/docs/master/system/target-sparc64.html ...explicitly claim that a NVRAM is emulated, although they are doing a M48T59 there is at least some chance that the memory address can be found in the QEMU sources. Will take a look in the next weeks ;-) -- : Ethan O'Toole
[cctalk] Re: Tadpole/RDI UltraBooks - UNIX notebooks - species needs rescue...
Hi Ethan, thanks for suggesting MAME - did some research and somehow I do not think it emulates UltraSparc but only 32bit Sarc. But saw, that QEMU has a UltraSparc emulation and they... https://www.qemu.org/docs/master/system/target-sparc64.html ...explicitly claim that a NVRAM is emulated, although they are doing a M48T59 there is at least some chance that the memory address can be found in the QEMU sources. Will take a look in the next weeks ;-)
[cctalk] Re: Tadpole/RDI UltraBooks - UNIX notebooks - species needs rescue...
Hi Santo, as promised I took pictures of the caddy of UltraBook and UltraBook II (it is the same). The harddrives are slim PATA notebook drives and I ran (until failure) 10GB...160GB drives in the UltraBooks. CAUTION: Fitting a PATA SSD did not work for me - somehow they are probably to fast for at least Solaris 2.6. Here a thorough documentation of caddy and the electrical connections (without warranty): http://www.baigar.de/UltraBook/UltraBook-HDDcaddy-EBaigar-20230928.pdf CAUTION: The plug listed there probably is, what you find within the Notebooks, so it should fit the adapter (again no warrranty!). For those interested: Here a X-Ray of the DS1553 I used for quickly finding the battery pins for connecting an external battery: http://www.baigar.de/UltraBook/DS1553WrongOrientation20230923_121643.jpg Hope to report Saturday on the NVRAM results and vacation after that until 10/6/2023..
[cctalk] Re: Tadpole/RDI UltraBooks - UNIX notebooks - species needs rescue...
Hi Jonathan, will try that soon and I have got GALEP3 and a TopMax, so reading a 1643 with pins left out should be easy. Zeroing is a good idea for the beginning - just needing some content there that brings me to the Firmware ;-)
[cctalk] Re: Tadpole/RDI UltraBooks - UNIX notebooks - species needs rescue...
Booted the SPARCbook 3, its battery is in fact dead, and aside from taking a little longer to come up (totally expected) it's fine. Thanks, Jonathan --- Original Message --- On Thursday, September 28th, 2023 at 07:41, Jonathan Chapman via cctalk wrote: > > > Yet we have a few datapoints showing that a dead NVRAM/RTC still boot > UltraBooks just fine! As I said, I personally confirmed with my UltraBook > IIe. Pretty sure the NVRAM is dead in my SPARCbook too, I can confirm that > today. > > Thanks, > Jonathan > > --- Original Message --- > On Thursday, September 28th, 2023 at 05:08, erik--- via cctalk > cctalk@classiccmp.org wrote: > > > > > > Hmmm, not sure on that one actually. So it does not boot up at all? > > > > Yes - exactly! > > > > > In the desktop Sun workstations and e.g. the Tadpole SparcBook, a lost > > > NVRAM at least > > > shows the firmware prompt on the screen (no HOSTID and no ethernet MAC). > > > > Yes, that is different in the UltraBooks. There is very likely some deep > > hardware specific stuff in the NVRAM. In Tafpoles, SparcStations and > > similar (I have some of them) there is NEVER a sticker with the serial > > numer on the NVRAM, but in the UltraBooks there is. That is also > > anindication for me, that the NVRAM is paired to the hardware. > > > > > situation is not as severe as with the UltraBooks where the screen > > > remains black/dark and > > > no interaction is possible! > > > > Exactly - and therefore I fear, that all the UltraBooks will die, once the > > relevant bytes get lost. Mine operated for some years with the "Invalid > > NVRAM" message until I attached the battery to the NVRAM and herein > > completely erased it because it was completely without power for some time > > (old battery was down to 0.426V).
[cctalk] Re: Tadpole/RDI UltraBooks - UNIX notebooks - species needs rescue...
My Ultrabook is a U20-14-1X-128C3. Hope that helps, Santo On Thu, Sep 28, 2023 at 1:54 AM erik--- via cctalk wrote: > @Jonathan: Wow, amazing project in creating the replacement NVRAM. You > really spent lot of time and efforts into that one. To attach the external > battery I took a X-Ray to know where to have access to the battery pins > most easily - was just 1 hour of work but far less cool of course! Thanks > for sharing! > > @Santo: MANY thanks for dumping your NVRAM - looks interesting. I must > admit that the plenty of 55 and AA look like lot of bits flipped from zero > to 1 already (that is what happens with many memory chips) but yes, the > lower section is all zeros. I will give that one a try in the next > opportunity! By the way: What type of UltraBook was that from precisely > (U14.?)? >
[cctalk] Re: Tadpole/RDI UltraBooks - UNIX notebooks - species needs rescue...
Yet we have a few datapoints showing that a dead NVRAM/RTC still boot UltraBooks just fine! As I said, I personally confirmed with my UltraBook IIe. Pretty sure the NVRAM is dead in my SPARCbook too, I can confirm that today. Thanks, Jonathan --- Original Message --- On Thursday, September 28th, 2023 at 05:08, erik--- via cctalk wrote: > > > > Hmmm, not sure on that one actually. So it does not boot up at all? > > > Yes - exactly! > > > In the desktop Sun workstations and e.g. the Tadpole SparcBook, a lost > > NVRAM at least > > shows the firmware prompt on the screen (no HOSTID and no ethernet MAC). > > > Yes, that is different in the UltraBooks. There is very likely some deep > hardware specific stuff in the NVRAM. In Tafpoles, SparcStations and similar > (I have some of them) there is NEVER a sticker with the serial numer on the > NVRAM, but in the UltraBooks there is. That is also anindication for me, that > the NVRAM is paired to the hardware. > > > situation is not as severe as with the UltraBooks where the screen remains > > black/dark and > > no interaction is possible! > > > Exactly - and therefore I fear, that all the UltraBooks will die, once the > relevant bytes get lost. Mine operated for some years with the "Invalid > NVRAM" message until I attached the battery to the NVRAM and herein > completely erased it because it was completely without power for some time > (old battery was down to 0.426V).
[cctalk] Re: Tadpole/RDI UltraBooks - UNIX notebooks - species needs rescue...
> Hmmm, not sure on that one actually. So it does not boot up at all? Yes - exactly! > In the desktop Sun workstations and e.g. the Tadpole SparcBook, a lost NVRAM > at least > shows the firmware prompt on the screen (no HOSTID and no ethernet MAC). Yes, that is different in the UltraBooks. There is very likely some deep hardware specific stuff in the NVRAM. In Tafpoles, SparcStations and similar (I have some of them) there is NEVER a sticker with the serial numer on the NVRAM, but in the UltraBooks there is. That is also anindication for me, that the NVRAM is paired to the hardware. > situation is not as severe as with the UltraBooks where the screen remains > black/dark and > no interaction is possible! Exactly - and therefore I fear, that all the UltraBooks will die, once the relevant bytes get lost. Mine operated for some years with the "Invalid NVRAM" message until I attached the battery to the NVRAM and herein completely erased it because it was completely without power for some time (old battery was down to 0.426V).
[cctalk] Re: Tadpole/RDI UltraBooks - UNIX notebooks - species needs rescue...
@Jonathan: Wow, amazing project in creating the replacement NVRAM. You really spent lot of time and efforts into that one. To attach the external battery I took a X-Ray to know where to have access to the battery pins most easily - was just 1 hour of work but far less cool of course! Thanks for sharing! @Santo: MANY thanks for dumping your NVRAM - looks interesting. I must admit that the plenty of 55 and AA look like lot of bits flipped from zero to 1 already (that is what happens with many memory chips) but yes, the lower section is all zeros. I will give that one a try in the next opportunity! By the way: What type of UltraBook was that from precisely (U14.?)?
[cctalk] Re: Tadpole/RDI UltraBooks - UNIX notebooks - species needs rescue...
Thanks Jonathan. I'm not sure this is correct as I needed to select a DS1643 after I tied pin 26 and pin 27 to pin 28 (and cut 26 and 27 in a chip socket/adapter) but I did manage to dump it. It is very small though. All zeros until data starts at 0x1800. Would you have an idea if this is accurate? Reading as a DS1225 got all zeros. https://vintagecomputer.ca/files/Tadpole/Ultrabook2-8528496.bin Maybe if Eric can write this to his Dallas chip, he might be in business if it's good? Santo On Wed, Sep 27, 2023 at 4:35 PM Jonathan Chapman via cctalk < cctalk@classiccmp.org> wrote: > > Speaking of dumping... > > > > Is it possible to read a Dallas DS1643 in programmer? That's what's in my > > Ultrabook. I just tried with a Topmax II that supports it and I get all > > zeros. :( > > You probably need to make a shim socket and pull pin 26 to VCC (pin 28), > then read it as a DS1225. I'd also pull pin 27 (*WE) to VCC to avoid errant > writes. > > Thanks, > Jonathan >
[cctalk] Re: Tadpole/RDI UltraBooks - UNIX notebooks - species needs rescue...
> Hi Jonathan, thanks for your thoughs. I am still using the same NVRAM, just > with external battery attached, so no Chineese counterfeit. > My hypothesis is: With the battery losing voltage, some bits flip first. They > cause the error message you see and values get set to proper values. But > there are some bytes which must not flip because they determine e.g. the type > of graphics, processor, speed, RAM timing etc. If one of these bits flips > first, than one is lost because the machine does not reach the OpenBoot > firmware because it tries to test non-existing hardware etc. etc. I wouldn't think that's possible, the small portion of NVRAM used to set parameters is checksummed, so it's unlikely a random combination would also result in a correct checksum. Still, to rule that out, try blanking the NVRAM by writing all zeroes to it. You may be able to do that with something like a TL866+ and a shim socket -- don't just plug the DS1553 right in, as it's got two output pins that may cause a conflict! Thanks, Jonathan
[cctalk] Re: Tadpole/RDI UltraBooks - UNIX notebooks - species needs rescue...
> Interesting - did you youse some modern technology for > doing that? Modern "special sauce" replacements from Dallas/Maxim/Analog/etc., plus a fast, low-power SRAM, all packaged on a circuit board with Batten & Allen DIP leadframe pins, like this: https://users.glitchwrks.com/~glitch/2018/03/17/gw-1244-1 (note that the Phantom RTC chip used in that is *not* what would be needed for Sun-style NVRAMs) Thanks, Jonathan
[cctalk] Re: Tadpole/RDI UltraBooks - UNIX notebooks - species needs rescue...
> Speaking of dumping... > > Is it possible to read a Dallas DS1643 in programmer? That's what's in my > Ultrabook. I just tried with a Topmax II that supports it and I get all > zeros. :( You probably need to make a shim socket and pull pin 26 to VCC (pin 28), then read it as a DS1225. I'd also pull pin 27 (*WE) to VCC to avoid errant writes. Thanks, Jonathan
[cctalk] Re: Tadpole/RDI UltraBooks - UNIX notebooks - species needs rescue...
Speaking of dumping... Is it possible to read a Dallas DS1643 in programmer? That's what's in my Ultrabook. I just tried with a Topmax II that supports it and I get all zeros. :( Santo On Wed, Sep 27, 2023 at 4:14 PM Ethan O'Toole via cctalk < cctalk@classiccmp.org> wrote: > > Interesting - did you youse some modern technology for > > doing that? I already thought to attach a logic analyzer to the > > NVRAM to see which bytes are read first (e.g. for dtermining > > the hardware configuration). > > Late to the convo, but it's interesting. > > You might be able to dump the ROMs and find someone who knows Sparc > assembly to run it through a debugger/emulator and trace it? Hard part > would probably be knowing where the NVRAM lives in memory space (memory > map.) > > Maybe the MAME people would have an idea? Some of the old arcade games > suffer from the exact same issue - they store variables in the ST > Microelectronics Timekeepers and once it dies game won't boot due to a > byte or two. > > MAME has SPARC emulation. > > Other thing is people with a working Tadpoles needs to dump their NVRAMS > ASAP because it sounds like all of them are about to quit working? > > > -- > : Ethan O'Toole > > >
[cctalk] Re: Tadpole/RDI UltraBooks - UNIX notebooks - species needs rescue...
Hi Ethan - yes, I think that may be a severe issue and getting hands on a dump/making users aware was already in my first post and therefore it is also titled "species needs rescue" ;-) Never looked into MAME - if they run the OpenBoot firmware, that would indeed be an opion! Thanks for the hint...
[cctalk] Re: Tadpole/RDI UltraBooks - UNIX notebooks - species needs rescue...
Interesting - did you youse some modern technology for doing that? I already thought to attach a logic analyzer to the NVRAM to see which bytes are read first (e.g. for dtermining the hardware configuration). Late to the convo, but it's interesting. You might be able to dump the ROMs and find someone who knows Sparc assembly to run it through a debugger/emulator and trace it? Hard part would probably be knowing where the NVRAM lives in memory space (memory map.) Maybe the MAME people would have an idea? Some of the old arcade games suffer from the exact same issue - they store variables in the ST Microelectronics Timekeepers and once it dies game won't boot due to a byte or two. MAME has SPARC emulation. Other thing is people with a working Tadpoles needs to dump their NVRAMS ASAP because it sounds like all of them are about to quit working? -- : Ethan O'Toole
[cctalk] Re: Tadpole/RDI UltraBooks - UNIX notebooks - species needs rescue...
Hi Jonathan! > Now the good news is, I can probably make replacements > for the DS1553W. I already have a prototype replacement > for the DS1643 Interesting - did you youse some modern technology for doing that? I already thought to attach a logic analyzer to the NVRAM to see which bytes are read first (e.g. for dtermining the hardware configuration).
[cctalk] Re: Tadpole/RDI UltraBooks - UNIX notebooks - species needs rescue...
Hi Jonathan, thanks for your thoughs. I am still using the same NVRAM, just with external battery attached, so no Chineese counterfeit. My hypothesis is: With the battery losing voltage, some bits flip first. They cause the error message you see and values get set to proper values. But there are some bytes which must not flip because they determine e.g. the type of graphics, processor, speed, RAM timing etc. If one of these bits flips first, than one is lost because the machine does not reach the OpenBoot firmware because it tries to test non-existing hardware etc. etc.
[cctalk] Re: Tadpole/RDI UltraBooks - UNIX notebooks - species needs rescue...
Hi Santo, thanks for your efforts in taking the vid that looks different from my behaviour on all UltraBooks! Drive Caddy: They are silly devices - no smart stuff. I can take pictures on the weekend and make a wiring chart if you want. I have a 160GB drive, WD1600BEVE for the OS. Erik.
[cctalk] Re: Tadpole/RDI UltraBooks - UNIX notebooks - species needs rescue...
/me hears mention of dead NVRAMs and materializes Pulled out my UltraBook IIe today, it's fine with a dead NVRAM, just gives you the usual "IDPROM contents are invalid" message you see on Suns. If I'd have to guess, based on past experience, you likely have a counterfeit DS1553W or you ordered the DS1553 without the W suffix. The W means 3.3V part. On a 3.3V system, the DS1553 5V part will never release write lock-out; furthermore, the DS1553 has a power-on reset comparator and will never de-assert reset either! I don't know if the UltraBooks use this reset output, but if I were designing a system and using the DS1553/W, I certainly would. A missing DS1742W in a SGI Tezro stops it dead, as does a DS1742 5V part (W suffix is, again, 3.3V). Part of what took so long on my designing a replacement for the DS1742W was the sacrificial modules that were sent to me were...wait for it...Chinese counterfeits! The part numbers from the dissected modules were all 5V parts! Now the good news is, I can probably make replacements for the DS1553W. I already have a prototype replacement for the DS1643, some customer must've needed it for a one-off as I've never run more, but that should already be a solved problem. I have one or two GW-1643-1 prototypes on hand for testing. Thanks, Jonathan
[cctalk] Re: Tadpole/RDI UltraBooks - UNIX notebooks - species needs rescue...
Hi Erik, I just happen to have mine out and took a quick video of boot up. Mine does not have a floppy drive or hard drive (I don't have a caddy) so it boots pretty quickly to the "ok" prompt but you can see the LCD display and when the LCD comes up. Here's a quick video. https://vintagecomputer.ca/files/Tadpole/Ultrabook-boot.mp4 On another note: Still hoping to find an Ultrabook hard drive caddy if anyone has a spare or even internal pictures to see if it has any smarts or if it's just an EIDE drive that goes pin-for-pin to the internal 40 pin SCSI-5 connector. I've been checking eBay for years now :( Hope this helps, Santo On Wed, Sep 27, 2023 at 2:19 PM erik--- via cctalk wrote: > Did some experiments in removing/swapping NVRAMs and none of my UltraBooks > is reaching the OpenFirmware or even turning on the backlight/LCD, so I > have no way of trying to read the NVRAM contents from there :-( > > Symptoms (i.e. behaviour of the LCD display) of the UltraBooks differ with > contents of NVRAM or if there is no NVRAM at all. So without some > known-valid NVRAM contents I fear I am lost :-( > > Symtpoms I see: Power symbols coming up always then (a) only tock-tock > from speaker (b) blank, only the inverse A flashing several times, later a > single time again and then blank forever (c) heart beat and speaker > flashing, later the inverse A coming on as well. > > Can anyone out there at least tell me what their LCDis showing during > startup? > > I will archive the contents of the NVRAMs as they are now although they > are probably not of much use... >
[cctalk] Re: Tadpole/RDI UltraBooks - UNIX notebooks - species needs rescue...
Did some experiments in removing/swapping NVRAMs and none of my UltraBooks is reaching the OpenFirmware or even turning on the backlight/LCD, so I have no way of trying to read the NVRAM contents from there :-( Symptoms (i.e. behaviour of the LCD display) of the UltraBooks differ with contents of NVRAM or if there is no NVRAM at all. So without some known-valid NVRAM contents I fear I am lost :-( Symtpoms I see: Power symbols coming up always then (a) only tock-tock from speaker (b) blank, only the inverse A flashing several times, later a single time again and then blank forever (c) heart beat and speaker flashing, later the inverse A coming on as well. Can anyone out there at least tell me what their LCDis showing during startup? I will archive the contents of the NVRAMs as they are now although they are probably not of much use...
[cctalk] Re: Tadpole/RDI UltraBooks - UNIX notebooks - species needs rescue...
I have an older one and it seems like, I recall, openboot has a name for the nvram. possible caMel or similar. Dwight From: erik--- via cctalk Sent: Sunday, September 24, 2023 1:35 PM To: cctalk@classiccmp.org Cc: e...@baigar.de Subject: [cctalk] Re: Tadpole/RDI UltraBooks - UNIX notebooks - species needs rescue... Played a little around - and the OpenFirmware's "dump" command on my older SparcBook 3GX (so no Ultra, but 4m architecture) is able to dump virtual memory. Obeying to the forth syntax, the following command... 1000 100 dump ...dumps 256 bytes starting at address 1000. Of course, reading undefined (=unmapped) memory leads to an access violation. But as the firmware manual describes, devices can be selected and than it is possible to dump their io-space and I bet somewhere in there, the NVRAM is hidden. At ffee I see populated memory in the 3GX - the dumpable range starts at ffee and ends at ffef (in total 128k). So having a running UltraBook that would be the way to seach for the NVRAM?
[cctalk] Re: Tadpole/RDI UltraBooks - UNIX notebooks - species needs rescue...
Played a little around - and the OpenFirmware's "dump" command on my older SparcBook 3GX (so no Ultra, but 4m architecture) is able to dump virtual memory. Obeying to the forth syntax, the following command... 1000 100 dump ...dumps 256 bytes starting at address 1000. Of course, reading undefined (=unmapped) memory leads to an access violation. But as the firmware manual describes, devices can be selected and than it is possible to dump their io-space and I bet somewhere in there, the NVRAM is hidden. At ffee I see populated memory in the 3GX - the dumpable range starts at ffee and ends at ffef (in total 128k). So having a running UltraBook that would be the way to seach for the NVRAM?
[cctalk] Re: Tadpole/RDI UltraBooks - UNIX notebooks - species needs rescue...
Once upon a time DS... was (other things apart) Dallas, then Maxim, now Analog Devices. Mouser says DS 1553 & DS1643 are obsolete. However, there appears to be aftermarket activity: - https://www.radwell.co.uk/en-GB/Search/?q=ds1553 - https://www.radwell.co.uk/en-GB/Search/?q=ds1643 - which implies purchase & DIY possibilities ... Seems to be the sort of part under discussion HtH, Martin -Original Message- From: erik--- via cctalk [mailto:cctalk@classiccmp.org] Sent: 24 September 2023 17:24 To: cctalk@classiccmp.org Cc: e...@baigar.de Subject: [cctalk] Re: Tadpole/RDI UltraBooks - UNIX notebooks - species needs rescue... Just checked the datasheets: The NVRAMs of the UltraBooks I know of are the DS1643 and the DS1553. Both should be similar enough to be read/write by any reader that supports the DS1643 or the DS1553. Of course I'd offer creating an modified Arduino doing the task, to test it and to supply it to anyone who is willing to dump his NVRAM!!!
[cctalk] Re: Tadpole/RDI UltraBooks - UNIX notebooks - species needs rescue...
Hmmm, did littel reading in the OpenFirmware manual I linked above. There is an example how to use show-devs for listing the existing devices. The example contains... /virtual-memory@0,0 /memory@0,0 /counter-timer@1,f300 /eeprom@1,f200 /openprom So being lucky, the hex numbers given are the physical (non-mapped) address of memory, eeprom and counter-timer (=NVRAM). A check would be using the firmware's read commands to see if there is information starting at f300 and more specific whether the locations f3001ff9 - 73001fff show any change (that is the location where the real time clock should appear if there is a NVRAM at this location.
[cctalk] Re: Tadpole/RDI UltraBooks - UNIX notebooks - species needs rescue...
Yes, but usually that process does only reset the boot flags described in in the maunal, it does not reset the hardware relevant stuff like the hostID and MAC (those are lost in the Sparc Stations when the NVRAM is pulled or completely empty). But of course one can not be entirely sure - I ordered a "new" NVRAM for the UltraBookII just in case it did not like getting pulled and the battery attached. Upon reading the NVRAM withoug pullig it and using a hardware reader device: I guess that with the peek commands (see OpenFirmware guide, https://docs.oracle.com/cd/E19457-01/801-7042/801-7042.pdf) one can read the NVRAM contents. Of course no idea how to find the memory address where it is located. The adress space is huge compared to the 8k of the NVRAM...
[cctalk] Re: Tadpole/RDI UltraBooks - UNIX notebooks - species needs rescue...
> Interesting. So you still have got the hostid and the MAC address which might > indicate, that the contents are not completely lost yet. Maybe just a few > bits flipped leading to a wrong checksum (and the diag-switch? being set to > true, leading to lng POST times)? Maybe, but it also says "Setting NVRAM parameters to default values." which suggests it has default values stored somewhere to set NVRAM to. I don't know much about these systems' boot process, however. -- personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckai...@floodgap.com -- It's bad luck to be suspicious. -- Andrew W. Mathis
[cctalk] Re: Tadpole/RDI UltraBooks - UNIX notebooks - species needs rescue...
Interesting. So you still have got the hostid and the MAC address which might indicate, that the contents are not completely lost yet. Maybe just a few bits flipped leading to a wrong checksum (and the diag-switch? being set to true, leading to lng POST times)?
[cctalk] Re: Tadpole/RDI UltraBooks - UNIX notebooks - species needs rescue...
> Do anyone out there have got UltraBooks or UltraBooks IIi up and running? > Would > highly be interested in a dump of the NVRAM/Timekeeper!!! > > The failed first generation UltraBook are (DS1643 NVRAM): > (*) U20-14-9-512P with three (!!) hard drives, no battery port > (*) U20-14-3-128B two hard drives, battery port > > And my beloved UltraBook IIi (TimeKeeper DS1553-070) > (*) U40-14-1X-1024C one harddrive, battery port and creator graphics. I just got out my own UltraBook IIi to test and while it makes a lot of complaints during POST (which takes a good couple minutes), it does eventually come up into OpenBoot and will start Solaris. I note that it states it seems to have already lost its NVRAM contents but appears to have spontaneously self-recovered. Typing verbatim from the boot screen, Starting real time clock... Incorrect configuration checksum; Setting NVRAM parameters to default values. Setting diag-switch? NVRAM parameter to true. Reset Control: BXIR:0 BPOR:0 SXIR:0 SPOR:1 POR:0 UltraSPARC-IIi Version 9.1 (E$=1MB) 2-2 module Advanced PCI Bridge Version 1.3 Probing Memory Group #0 256 + 256 : 512 Megabytes Probing Memory Group #2 0 + 0 : 0 Megabytes Probing Floppy: No drives detected Probing UPA Slot at 1e,0 Nothing there Probing /pci@1f,0/pci@1,1 at Device 1 network Probing /pci@1f,0/pci@1,1 at Device 2 Nothing there Probing /pci@1f,0/pci@1,1 at Device 4 Nothing there Probing /pci@1f,0/pci@1,1 at Device 3 ide disk cdrom Probing /pci@1f,0/pci@1 at Device 1 pcma pcma Probing /pci@1f,0/pci@1 at Device 2 ATI,3D-Expression Probing /pci@1f,0/pci@1 at Device 3 scsi disk tape -- Ultrabook IIi (UltraSPARC-IIi 400MHz), Sun Keyboard -- OpenBoot 3.10.7 Tadpole-RDI 1.06, 512MB memory, Serial #[censored] -- Ethernet address [censored], Host ID: [censored]. The IDPROM contents are invalid Creator card not detected Boot device: net File and args: >From there it times out, drops to an ok prompt, and I can start Solaris. -- personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckai...@floodgap.com -- si non confectus, non reficiat -
[cctalk] Re: Tadpole/RDI UltraBooks - UNIX notebooks - species needs rescue...
Exactly that is what I did lot of times with my sparc stations already. But last week, the UltraBook IIi showed for the first time inconsistent NVRAM and following that, I replaced the NVRAM by one with an external battery but in my sillyness I had not saved the contens as I was not aware of the consequences :-( So teh main reason for my post is to make other owners aware and getting hand on the contens of a matching NVRAM!!!
[cctalk] Re: Tadpole/RDI UltraBooks - UNIX notebooks - species needs rescue...
There are solutions to the dying DS chips. I have seen replacement with newer ones (but sometimes those have old cells too), surgery to replace the internal cell https://www.youtube.com/watch?v=kZJDlNoJk7M, and replacement with a clone https://www.tindie.com/search/?q=dallas. However the critical thing would be to replace the data with something that doesn't hang on booting (perhaps even incorrect information from another unit would be close). On Sun, Sep 24, 2023 at 5:23 PM erik--- via cctalk wrote: > Just checked the datasheets: The NVRAMs of the UltraBooks I know of are > the DS1643 and the DS1553. Both should be similar enough to be read/write > by any reader that supports the DS1643 or the DS1553. Of course I'd offer > creating an modified Arduino doing the task, to test it and to supply it to > anyone who is willing to dump his NVRAM!!! >
[cctalk] Re: Tadpole/RDI UltraBooks - UNIX notebooks - species needs rescue...
Hmmm, not sure on that one actually. So it does not boot up at all? In the desktop Sun workstations and e.g. the Tadpole SparcBook, a lost NVRAM at least shows the firmware prompt on the screen (no HOSTID and no ethernet MAC). So there the situation is not as severe as with the UltraBooks where the screen remains black/dark and no interaction is possible!
[cctalk] Re: Tadpole/RDI UltraBooks - UNIX notebooks - species needs rescue...
Just checked the datasheets: The NVRAMs of the UltraBooks I know of are the DS1643 and the DS1553. Both should be similar enough to be read/write by any reader that supports the DS1643 or the DS1553. Of course I'd offer creating an modified Arduino doing the task, to test it and to supply it to anyone who is willing to dump his NVRAM!!!
[cctalk] Re: Tadpole/RDI UltraBooks - UNIX notebooks - species needs rescue...
I have RDI Powerlite 85's. The box says "RDI/Tadpole" Bill On Sun, Sep 24, 2023 at 12:21 PM erik--- via cctalk wrote: > The more are joining the higher the probability, that we will be able to > solve it somehow ;-) What kind of UltraBook do you have got? >
[cctalk] Re: Tadpole/RDI UltraBooks - UNIX notebooks - species needs rescue...
The more are joining the higher the probability, that we will be able to solve it somehow ;-) What kind of UltraBook do you have got?
[cctalk] Re: Tadpole/RDI UltraBooks - UNIX notebooks - species needs rescue...
Quite sad and I really hate that type of "limited lifetime" :-( Unfortunately the manufacturer RDI/Cupertino/US was acquired in 1998 by Tadpole and they dissolved in "General Dynamics" in 2005. The remains are now taken care of by Flextronics/Flex, but I do not have got much hope, they will be of help :-(
[cctalk] Re: Tadpole/RDI UltraBooks - UNIX notebooks - species needs rescue...
I have the same situation, would love to know how to resolve this as well. Bill On Sun, Sep 24, 2023 at 11:31 AM erik--- via cctalk wrote: > Hi there, > > in the last weeks my last two working UltraBooks died. Today I > investigated the problem > and obviously in these RDI made notebooks, the NVRAMs not only contain the > boot information, > the host ID and the MAC address but also the hardware configuration. > > Hence: Once the NVRAM is completeley dead, absent or replaced, the unit > will not > start up any more - it gets stuck in the power on test BEFORE the screen > shows any > information. > > Do anyone out there have got UltraBooks or UltraBooks IIi up and running? > Would > highly be interested in a dump of the NVRAM/Timekeeper!!! > > The failed first generation UltraBook are (DS1643 NVRAM): > (*) U20-14-9-512P with three (!!) hard drives, no battery port > (*) U20-14-3-128B two hard drives, battery port > > And my beloved UltraBook IIi (TimeKeeper DS1553-070) > (*) U40-14-1X-1024C one harddrive, battery port and creator graphics. > > Reply here or PM e...@baigar.de, > > Thanks > > ''~`` > ( o o ) > +--.oooO--(_)--Oooo.-+ > | Dr. Erik Baigar Inertial Navigation & | > | Salzstrasse 1 .oooOVintage Computer | > | D87616 Marktoberdorf ( ) Oooo.Hobbyist / Physicist | > | e...@baigar.de +--\ (( )---+ > | www.baigar.de| \_)) / > +--+ (_/ > > > > So advice to all owners: Backup your NVRAM contents and I'd be more than > happy > to get in touch with you! > > Not affected seem to be the PrecisionBooks (e.g. H16-12-8-512L2, two hard- > drives and battery port) as they do not contain an NVRAM/TimeKeeper. >
[cctalk] Re: Tadpole/RDI UltraBooks - UNIX notebooks - species needs rescue...
I have seen similar behavior on all Force2CE VME boards with empty NVRAM. On Sunday, September 24, 2023, erik--- via cctalk wrote: > Hi there, > > in the last weeks my last two working UltraBooks died. Today I > investigated the problem > and obviously in these RDI made notebooks, the NVRAMs not only contain the > boot information, > the host ID and the MAC address but also the hardware configuration. > > Hence: Once the NVRAM is completeley dead, absent or replaced, the unit > will not > start up any more - it gets stuck in the power on test BEFORE the screen > shows any > information. > > Do anyone out there have got UltraBooks or UltraBooks IIi up and running? > Would > highly be interested in a dump of the NVRAM/Timekeeper!!! > > The failed first generation UltraBook are (DS1643 NVRAM): > (*) U20-14-9-512P with three (!!) hard drives, no battery port > (*) U20-14-3-128B two hard drives, battery port > > And my beloved UltraBook IIi (TimeKeeper DS1553-070) > (*) U40-14-1X-1024C one harddrive, battery port and creator graphics. > > Reply here or PM e...@baigar.de, > > Thanks > > ''~`` > ( o o ) > +--.oooO--(_)--Oooo.-+ > | Dr. Erik Baigar Inertial Navigation & | > | Salzstrasse 1 .oooOVintage Computer | > | D87616 Marktoberdorf ( ) Oooo.Hobbyist / Physicist | > | e...@baigar.de +--\ (( )---+ > | www.baigar.de| \_)) / > +--+ (_/ > > > > So advice to all owners: Backup your NVRAM contents and I'd be more than > happy > to get in touch with you! > > Not affected seem to be the PrecisionBooks (e.g. H16-12-8-512L2, two hard- > drives and battery port) as they do not contain an NVRAM/TimeKeeper. >
