24 Sep
2023
24 Sep
'23
8:31 a.m.
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 erik(a)baigar.de,
Thanks
''~``
( o o )
+--------------------------.oooO--(_)--Oooo.-------------------------+
| Dr. Erik Baigar Inertial Navigation & |
| Salzstrasse 1 .oooO Vintage Computer |
| D87616 Marktoberdorf ( ) Oooo. Hobbyist / Physicist |
| erik(a)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.
24 Sep
24 Sep
8:36 a.m.
I have seen similar behavior on all Force2CE VME boards with empty NVRAM.
On Sunday, September 24, 2023, erik--- via cctalk <cctalk(a)classiccmp.org>
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 erik(a)baigar.de,
Thanks
''~``
( o o )
+--------------------------.oooO--(_)--Oooo.-------------------------+
| Dr. Erik Baigar Inertial Navigation & |
| Salzstrasse 1 .oooO Vintage Computer |
| D87616 Marktoberdorf ( ) Oooo. Hobbyist / Physicist |
| erik(a)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.
9:11 a.m.
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 :-(
8:52 a.m.
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 <cctalk(a)classiccmp.org>
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 erik(a)baigar.de,
Thanks
''~``
( o o )
+--------------------------.oooO--(_)--Oooo.-------------------------+
| Dr. Erik Baigar Inertial Navigation & |
| Salzstrasse 1 .oooO Vintage Computer |
| D87616 Marktoberdorf ( ) Oooo. Hobbyist / Physicist |
| erik(a)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.
9:21 a.m.
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?
9:22 a.m.
I have RDI Powerlite 85's. The box says "RDI/Tadpole"
Bill
On Sun, Sep 24, 2023 at 12:21 PM erik--- via cctalk <cctalk(a)classiccmp.org>
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?
9:33 a.m.
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!
28 Sep
28 Sep
2:08 a.m.
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).
4:41 a.m.
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(a)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).
5:48 a.m.
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
<cctalk(a)classiccmp.org> 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(a)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).
24 Sep
24 Sep
9:23 a.m.
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!!!
9:36 a.m.
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 <cctalk(a)classiccmp.org>
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!!!
9:48 a.m.
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!!!
1:26 p.m.
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(a)classiccmp.org
Cc: erik(a)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!!!
11:28 a.m.
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 * ckaiser(a)floodgap.com
-- si non confectus, non reficiat ---------------------------------------------
11:39 a.m.
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 loooong POST times)?
11:41 a.m.
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 loooong 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 * ckaiser(a)floodgap.com
-- It's bad luck to be suspicious. -- Andrew W. Mathis ------------------------
11:56 a.m.
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...
12:22 p.m.
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,f3000000
/eeprom@1,f2000000
/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 f3000000 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.
1:35 p.m.
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 ffee0000 I see populated memory in the 3GX - the dumpable range starts
at ffee0000 and ends at ffefffff (in total 128k). So having a running UltraBook that would
be the way to seach for the NVRAM?
3 p.m.
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 <cctalk(a)classiccmp.org>
Sent: Sunday, September 24, 2023 1:35 PM
To: cctalk(a)classiccmp.org <cctalk(a)classiccmp.org>
Cc: erik(a)baigar.de <erik(a)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 ffee0000 I see populated memory in the 3GX - the dumpable range starts
at ffee0000 and ends at ffefffff (in total 128k). So having a running UltraBook that would
be the way to seach for the NVRAM?
27 Sep
27 Sep
11:19 a.m.
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...
11:59 a.m.
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 <cctalk(a)classiccmp.org>
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...
1 p.m.
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.
28 Sep
28 Sep
10:22 a.m.
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..
27 Sep
27 Sep
12:14 p.m.
/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
1:03 p.m.
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.
1:39 p.m.
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
28 Sep
28 Sep
7:13 a.m.
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 ;-)
27 Sep
27 Sep
1:06 p.m.
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).
1:14 p.m.
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
1:20 p.m.
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...
1:21 p.m.
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(a)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
1:35 p.m.
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
2:13 p.m.
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(a)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
28 Sep
28 Sep
11:25 a.m.
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 ;-)
11:34 a.m.
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
11:46 a.m.
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 - Tadaaaaaaaa- here it is:
https://web.archive.org/web/20151107014449/http://www.squirrel.com/squirrel…
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!
11:56 a.m.
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 <cctalk(a)classiccmp.org>
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 - Tadaaaaaaaa-
here it is:
https://web.archive.org/web/20151107014449/http://www.squirrel.com/squirrel…
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!
12:06 p.m.
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 <santo.nucifora(a)gmail.com>
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 <cctalk(a)classiccmp.org>
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 - Tadaaaaaaaa-
here it is:
https://web.archive.org/web/20151107014449/http://www.squirrel.com/squirrel…
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!
27 Sep
27 Sep
1:37 p.m.
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
10:54 p.m.
@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.....?)?
28 Sep
28 Sep
4:58 a.m.
My Ultrabook is a U20-14-1X-128C3.
Hope that helps,
Santo
On Thu, Sep 28, 2023 at 1:54 AM erik--- via cctalk <cctalk(a)classiccmp.org>
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.....?)?
29 Sep
29 Sep
2:16 p.m.
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...
15 Oct
15 Oct
2:12 p.m.
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.
22 Oct
22 Oct
12:36 p.m.
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...
27 Oct
27 Oct
3:59 p.m.
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 <cctalk(a)classiccmp.org>
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...
28 Oct
28 Oct
10:22 a.m.
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)
12:06 p.m.
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 <cctalk(a)classiccmp.org>
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)
193
days inactive
227
days old
49 comments
10 participants
participants (10)
-
Adrian Godwin -
Bill Degnan -
Cameron Kaiser -
dwight -
erik＠baigar.de -
Ethan O'Toole -
Jonathan Chapman -
Martin Bishop -
Plamen Mihaylov -
Santo Nucifora