Hi Don,

A while back you gave me some advice about fixing my ailing Sun Ultra 2
workstation. Well, shortly after that it died completely. I posted
another reply in the "Shopmade grinder with winch" thread but I had to
use Google Groups. I think you may have missed the message if you're
blocking messages from Google Groups.

The same thing has now happened to me twice. With the first workstation,
it worked for about 10 days after the clock stopped keeping time. This
time, it worked for about a month. It leads me to believe that Ultra 2
clock problems are perhaps most often caused by motherboard faults as
opposed to a dead NVRAM battery. Anyway, I have now managed to build a
working Ultra 2 from parts with 2048 MB RAM. 2048 MB seems to make the
Ultra 2 slightly faster than it was with 1280 MB. I notice it when the
machine is booting up, which surprises me as I would have expected boot
speed to be limited by hard disk speed.

This means that perhaps my old NVRAM chips are worth preserving. You
mentioned a piece of software which could be used to stop the NVRAM
clock. I searched but couldn't find it online. Looking at the NVRAM
datasheet, it seems like it is not something which can be done with a
crocodile clip. The only reference I could find was for modifying the
contents of an ancient sun4c machine's NVRAM at the "ok" prompt, and I
couldn't immediately see how to use this information with a sun4u Ultra
2. Do you know of a source for software which can be used to stop the
NVRAM clock?

I think that's all there was of importance in the post. I speculated a
little about whether common applications such as Firefox and Nautilus
are able to make good use of multiple processors on Sun workstations.
I'm still not certain. But I think that's all.

Thanks for the help.

Best wishes,

Chris

On 2009-01-02, Christopher Tidy wrote:
Hi Don,

A while back you gave me some advice about fixing my ailing Sun Ultra 2
workstation. Well, shortly after that it died completely. I posted
another reply in the "Shopmade grinder with winch" thread but I had to
use Google Groups. I think you may have missed the message if you're
blocking messages from Google Groups.

I don't always read all threads to the end. That was one which
I skipped over a lot of, when I was overloaded with articles to read.

And I'm going to be heavily occupied Saturday and Sunday,
probably not even get to the newsreader on either day -- or perhaps near
midnight on Sunday.

The same thing has now happened to me twice. With the first workstation,
it worked for about 10 days after the clock stopped keeping time. This
time, it worked for about a month. It leads me to believe that Ultra 2
clock problems are perhaps most often caused by motherboard faults as
opposed to a dead NVRAM battery. Anyway, I have now managed to build a
working Ultra 2 from parts with 2048 MB RAM. 2048 MB seems to make the
Ultra 2 slightly faster than it was with 1280 MB. I notice it when the
machine is booting up, which surprises me as I would have expected boot
speed to be limited by hard disk speed.

When it is booting it is loading a lot of programs. With plenty
of RAM, it doesn't have to swap just loaded programs to disk while it is
loading the next one.

I've noticed a significant improvement in boot speed (and in
workspace startup speed) with my boost from 3 GB of RAM to 6 GB, and
want to go to the max of 8 GB for my Sun Blade 2000 to have plenty of
RAM for when I'm doing lots of image processing (which is what is coming
over the weekend, with someone else critically involved in the project
who can't get up here very often.

This means that perhaps my old NVRAM chips are worth preserving. You
mentioned a piece of software which could be used to stop the NVRAM
clock. I searched but couldn't find it online. Looking at the NVRAM
datasheet, it seems like it is not something which can be done with a
crocodile clip. The only reference I could find was for modifying the
contents of an ancient sun4c machine's NVRAM at the "ok" prompt, and I
couldn't immediately see how to use this information with a sun4u Ultra
2. Do you know of a source for software which can be used to stop the
NVRAM clock?

I don't remember for sure where I read about it, but it was
probably in the first hit on a Google search for "Sun NVRAM FAQ"

http://www.squirrel.com/sun-nvram-hostid.faq.html

This one was posted in February of 2004, FWIW.

And I see that the procedure only mentions the Sun 3/80 (68030
CPU) and the sun 4C (SS1 SS2 IIRC).

I'm not sure whether it would work on the Ultra-2 but I don't
see any reason why it should not, if you can get to the "ok" prompt.

Check the contents of your NVRAM chips (HOSTID and Ethernet MAC
address) and keep a hardcopy version in case you need to perform the
battery surgery which is documented in the website above.

I think that's all there was of importance in the post. I speculated a
little about whether common applications such as Firefox and Nautilus
are able to make good use of multiple processors on Sun workstations.
I'm still not certain. But I think that's all.

I depends on whether they are multi-threaded. Though they will
probably use other CPUs for plugins.

Remember -- I won't be able to do any responding until really
late Sunday -- and I now don't have time to read any more of
rec.crafts.metalworking, I've got to take a bath and get to bed to
prepare for tomorrow.

Good Luck,
DoN.

--
Email: | Voice (all times): (703) 938-4564
(too) near Washington D.C. | http://www.d-and-d.com/dnichols/DoN.html
--- Black Holes are where God is dividing by zero ---

DoN. Nichols wrote:
On 2009-01-02, Christopher Tidy wrote:

Hi Don,

A while back you gave me some advice about fixing my ailing Sun Ultra 2
workstation. Well, shortly after that it died completely. I posted
another reply in the "Shopmade grinder with winch" thread but I had to
use Google Groups. I think you may have missed the message if you're
blocking messages from Google Groups.


I don't always read all threads to the end. That was one which
I skipped over a lot of, when I was overloaded with articles to read.

That's fine. It happens to all of us!

And I'm going to be heavily occupied Saturday and Sunday,
probably not even get to the newsreader on either day -- or perhaps near
midnight on Sunday.


The same thing has now happened to me twice. With the first workstation,
it worked for about 10 days after the clock stopped keeping time. This
time, it worked for about a month. It leads me to believe that Ultra 2
clock problems are perhaps most often caused by motherboard faults as
opposed to a dead NVRAM battery. Anyway, I have now managed to build a
working Ultra 2 from parts with 2048 MB RAM. 2048 MB seems to make the
Ultra 2 slightly faster than it was with 1280 MB. I notice it when the
machine is booting up, which surprises me as I would have expected boot
speed to be limited by hard disk speed.


When it is booting it is loading a lot of programs. With plenty
of RAM, it doesn't have to swap just loaded programs to disk while it is
loading the next one.

I didn't expect it to make a big difference, because I thought that most
of the programs being loaded into RAM during the boot process would be
staying in the RAM. Also, once my old machine was up and running, it
often didn't use all the of the 1280 MB RAM. But I don't know of any way
of looking at RAM usage during the boot process.

I've noticed a significant improvement in boot speed (and in
workspace startup speed) with my boost from 3 GB of RAM to 6 GB, and
want to go to the max of 8 GB for my Sun Blade 2000 to have plenty of
RAM for when I'm doing lots of image processing (which is what is coming
over the weekend, with someone else critically involved in the project
who can't get up here very often.


This means that perhaps my old NVRAM chips are worth preserving. You
mentioned a piece of software which could be used to stop the NVRAM
clock. I searched but couldn't find it online. Looking at the NVRAM
datasheet, it seems like it is not something which can be done with a
crocodile clip. The only reference I could find was for modifying the
contents of an ancient sun4c machine's NVRAM at the "ok" prompt, and I
couldn't immediately see how to use this information with a sun4u Ultra
2. Do you know of a source for software which can be used to stop the
NVRAM clock?


I don't remember for sure where I read about it, but it was
probably in the first hit on a Google search for "Sun NVRAM FAQ"

http://www.squirrel.com/sun-nvram-hostid.faq.html

That's the information that I had seen, too. I was just thinking that
there might be a piece of software which makes the process easy, but I
could not find any mention of it on that page.

This one was posted in February of 2004, FWIW.

And I see that the procedure only mentions the Sun 3/80 (68030
CPU) and the sun 4C (SS1 SS2 IIRC).

I'm not sure whether it would work on the Ultra-2 but I don't
see any reason why it should not, if you can get to the "ok" prompt.

I tried the method intended for sun4c machines on my Ultra 2. I get the
error "Fast Data Access MMU Miss" after the second command.

My best guess is that the addresses for the Write and Stop bits given in
that document for the M48T02 chip are not the correct ones for the later
M48T59Y chip, which contains more memory.

From the M48T59Y datasheet I can understand the structure of the
register in which the Write and Stop bits are held, but I cannot
understand the syntax used at the "ok" prompt (or perhaps not: the
prompt is indicated by ?) to modify the contents of the register. I
cannot find any information online about this syntax other than the
NVRAM FAQ, which does not explain the syntax used to program the NVRAM
at bit level, as opposed to byte level.

I'm sure that someone with more knowledge could figure this out, but I'm
reluctant to experiment with my working machine in case it ceases to
work. It also seems that the two failures which I thought were caused by
dead NVRAM batteries were not, so perhaps the M48T59Y has a longer
lifetime than the M48T02. There do not seem to be any documents
referring to NVRAM problems with the sun4u machines using the M48T59Y chip.

Check the contents of your NVRAM chips (HOSTID and Ethernet MAC
address) and keep a hardcopy version in case you need to perform the
battery surgery which is documented in the website above.

For both the working motherboards I have, I've written down the details
displayed on the screen when the machine boots, such as the serial
number, ethernet address and host ID. For the machine I'm using at the
moment I've also saved a copy of the output of the command "eeprom -v".
Whether or not I need the extra details such as the system board serial
number, I don't know.

I think that's all there was of importance in the post. I speculated a
little about whether common applications such as Firefox and Nautilus
are able to make good use of multiple processors on Sun workstations.
I'm still not certain. But I think that's all.


I depends on whether they are multi-threaded. Though they will
probably use other CPUs for plugins.

I did a bit of reading online and came to the conclusion that Firefox is
multi-threaded, but that one thread handles the user interface,
JavaScript, layout and image decoding. Probably this thread sometimes
gets bogged down!

Thanks for the advice.

Best wishes,

Chris

On 2009-01-05, Christopher Tidy wrote:
DoN. Nichols wrote:
On 2009-01-02, Christopher Tidy wrote:

[ ... ]

The same thing has now happened to me twice. With the first workstation,
it worked for about 10 days after the clock stopped keeping time. This
time, it worked for about a month. It leads me to believe that Ultra 2
clock problems are perhaps most often caused by motherboard faults as
opposed to a dead NVRAM battery. Anyway, I have now managed to build a
working Ultra 2 from parts with 2048 MB RAM. 2048 MB seems to make the
Ultra 2 slightly faster than it was with 1280 MB. I notice it when the
machine is booting up, which surprises me as I would have expected boot
speed to be limited by hard disk speed.


When it is booting it is loading a lot of programs. With plenty
of RAM, it doesn't have to swap just loaded programs to disk while it is
loading the next one.

I didn't expect it to make a big difference, because I thought that most
of the programs being loaded into RAM during the boot process would be
staying in the RAM. Also, once my old machine was up and running, it
often didn't use all the of the 1280 MB RAM. But I don't know of any way
of looking at RAM usage during the boot process.

Well -- you might be able to start "top -S -d1 -u -d1 40" from
one of the rc start files to capture the top 40 processes.

[ ... ]

This means that perhaps my old NVRAM chips are worth preserving. You
mentioned a piece of software which could be used to stop the NVRAM
clock. I searched but couldn't find it online. Looking at the NVRAM
datasheet, it seems like it is not something which can be done with a
crocodile clip. The only reference I could find was for modifying the
contents of an ancient sun4c machine's NVRAM at the "ok" prompt, and I
couldn't immediately see how to use this information with a sun4u Ultra
2. Do you know of a source for software which can be used to stop the
NVRAM clock?


I don't remember for sure where I read about it, but it was
probably in the first hit on a Google search for "Sun NVRAM FAQ"

http://www.squirrel.com/sun-nvram-hostid.faq.html

That's the information that I had seen, too. I was just thinking that
there might be a piece of software which makes the process easy, but I
could not find any mention of it on that page.

This one was posted in February of 2004, FWIW.

And I see that the procedure only mentions the Sun 3/80 (68030
CPU) and the sun 4C (SS1 SS2 IIRC).

I'm not sure whether it would work on the Ultra-2 but I don't
see any reason why it should not, if you can get to the "ok" prompt.

I tried the method intended for sun4c machines on my Ultra 2. I get the
error "Fast Data Access MMU Miss" after the second command.

O.K. The Ultra-2 (and the rest of the ultra systems) at the
"ok" prompt are working with a FORTH interpreter, so you need to write a
program in that to get access to the EEPROM addresses. (Examples are
used for resetting the HOSTID and MAC address on Sun4u machines.)

My best guess is that the addresses for the Write and Stop bits given in
that document for the M48T02 chip are not the correct ones for the later
M48T59Y chip, which contains more memory.

Also -- there may need to be a different starting address when
you are working in that NVRAM on those systems.

From the M48T59Y datasheet I can understand the structure of the
register in which the Write and Stop bits are held, but I cannot
understand the syntax used at the "ok" prompt (or perhaps not: the
prompt is indicated by ?) to modify the contents of the register. I
cannot find any information online about this syntax other than the
NVRAM FAQ, which does not explain the syntax used to program the NVRAM
at bit level, as opposed to byte level.

It is working at byte level. You write 0x80 to set the
write-enable bit, then after you have entered the stop bit, you re-write
the contents of the time field, with a 0x0 where you had 0x80, so you
don't really care about the lost information in the lower bits.

I'm sure that someone with more knowledge could figure this out, but I'm
reluctant to experiment with my working machine in case it ceases to
work. It also seems that the two failures which I thought were caused by
dead NVRAM batteries were not, so perhaps the M48T59Y has a longer
lifetime than the M48T02.

Or -- perhaps those machines are not old enough to have problems
yet. Remember -- as long as the machine itself is powered up, the
battery gives effectively its shelf life. Only when the machine is
powered down is the clock running from the battery instead of from the
system power.

If you really want to protect them, wire wrap a board which does
nothing but apply power to the power and ground pins for the chip. Feed
it 5V and forget about it. (Even add a battery to provde power if you
lose power to another hurricane. :-) If you wire-wrap multiple sockets
(for multiple NVRAM chips) put a sticky-note on each one to tell which
system it belongs in.

You might want to wire the address lines, and other inputs to
ground, so it won't pick up noise and get weird possible settings.

There do not seem to be any documents
referring to NVRAM problems with the sun4u machines using the M48T59Y chip.

They just aren't old enough to have been sitting around
*unpowered* for ten years or so. :-) Start counting from when the
computer center retired the macines, not from when it was made.

Check the contents of your NVRAM chips (HOSTID and Ethernet MAC
address) and keep a hardcopy version in case you need to perform the
battery surgery which is documented in the website above.

For both the working motherboards I have, I've written down the details
displayed on the screen when the machine boots, such as the serial
number, ethernet address and host ID.

Good. Tape a copy to the machine itself.

For the machine I'm using at the
moment I've also saved a copy of the output of the command "eeprom -v".

What does the "-v" option do? It is present on my Solaris 10
one, but it is not documented in the man page under Solaris 10.

Same behavior in Solaris 2.6 on a SS-5.

Whether or not I need the extra details such as the system board serial
number, I don't know.

I think that the serial number is read from the board itself,
not from the NVRAM. In any case, it is present on the barcode label on
the system board.

I think that's all there was of importance in the post. I speculated a
little about whether common applications such as Firefox and Nautilus
are able to make good use of multiple processors on Sun workstations.
I'm still not certain. But I think that's all.


I depends on whether they are multi-threaded. Though they will
probably use other CPUs for plugins.

I did a bit of reading online and came to the conclusion that Firefox is
multi-threaded, but that one thread handles the user interface,
JavaScript, layout and image decoding. Probably this thread sometimes
gets bogged down!

O.K. Try moving to a Sun Blade 2000 with dual 1.2 GHz CPUs, and
8GB of RAM. You'll *still* find a browser coming to a halt from time to
time -- based on net delays to/from whatever site you are visiting.

Enjoy,
DoN.

--
Email: | Voice (all times): (703) 938-4564
(too) near Washington D.C. | http://www.d-and-d.com/dnichols/DoN.html
--- Black Holes are where God is dividing by zero ---

Hi Don,

Thanks for the advice. Sorry I've taken a week to reply.

I didn't expect it to make a big difference, because I thought that most
of the programs being loaded into RAM during the boot process would be
staying in the RAM. Also, once my old machine was up and running, it
often didn't use all the of the 1280 MB RAM. But I don't know of any way
of looking at RAM usage during the boot process.


Well -- you might be able to start "top -S -d1 -u -d1 40" from
one of the rc start files to capture the top 40 processes.

That's starting to sound complicated. For something which is a matter of
curiousity, anyway :-).

This means that perhaps my old NVRAM chips are worth preserving. You
mentioned a piece of software which could be used to stop the NVRAM
clock. I searched but couldn't find it online. Looking at the NVRAM
datasheet, it seems like it is not something which can be done with a
crocodile clip. The only reference I could find was for modifying the
contents of an ancient sun4c machine's NVRAM at the "ok" prompt, and I
couldn't immediately see how to use this information with a sun4u Ultra
2. Do you know of a source for software which can be used to stop the
NVRAM clock?


I don't remember for sure where I read about it, but it was
probably in the first hit on a Google search for "Sun NVRAM FAQ"

http://www.squirrel.com/sun-nvram-hostid.faq.html

That's the information that I had seen, too. I was just thinking that
there might be a piece of software which makes the process easy, but I
could not find any mention of it on that page.


This one was posted in February of 2004, FWIW.

And I see that the procedure only mentions the Sun 3/80 (68030
CPU) and the sun 4C (SS1 SS2 IIRC).

I'm not sure whether it would work on the Ultra-2 but I don't
see any reason why it should not, if you can get to the "ok" prompt.

I tried the method intended for sun4c machines on my Ultra 2. I get the
error "Fast Data Access MMU Miss" after the second command.


O.K. The Ultra-2 (and the rest of the ultra systems) at the
"ok" prompt are working with a FORTH interpreter, so you need to write a
program in that to get access to the EEPROM addresses. (Examples are
used for resetting the HOSTID and MAC address on Sun4u machines.)

That's useful to know. The "ok" prompt has always been something of a
mystery to me, even though I've figured out how to use it for a few
basic things.

My best guess is that the addresses for the Write and Stop bits given in
that document for the M48T02 chip are not the correct ones for the later
M48T59Y chip, which contains more memory.


Also -- there may need to be a different starting address when
you are working in that NVRAM on those systems.

Indeed. I was trying to figure this out from the data sheet, but failed.

From the M48T59Y datasheet I can understand the structure of the
register in which the Write and Stop bits are held, but I cannot
understand the syntax used at the "ok" prompt (or perhaps not: the
prompt is indicated by ?) to modify the contents of the register. I
cannot find any information online about this syntax other than the
NVRAM FAQ, which does not explain the syntax used to program the NVRAM
at bit level, as opposed to byte level.


It is working at byte level. You write 0x80 to set the
write-enable bit, then after you have entered the stop bit, you re-write
the contents of the time field, with a 0x0 where you had 0x80, so you
don't really care about the lost information in the lower bits.

How does 0x80 correspond to setting the write-enable bit to 1?

I'm sure that someone with more knowledge could figure this out, but I'm
reluctant to experiment with my working machine in case it ceases to
work. It also seems that the two failures which I thought were caused by
dead NVRAM batteries were not, so perhaps the M48T59Y has a longer
lifetime than the M48T02.


Or -- perhaps those machines are not old enough to have problems
yet. Remember -- as long as the machine itself is powered up, the
battery gives effectively its shelf life. Only when the machine is
powered down is the clock running from the battery instead of from the
system power.

Quite likely. Maybe I just need to wait a few years for the information
to appear.

If you really want to protect them, wire wrap a board which does
nothing but apply power to the power and ground pins for the chip. Feed
it 5V and forget about it. (Even add a battery to provde power if you
lose power to another hurricane. :-) If you wire-wrap multiple sockets
(for multiple NVRAM chips) put a sticky-note on each one to tell which
system it belongs in.

You might want to wire the address lines, and other inputs to
ground, so it won't pick up noise and get weird possible settings.

Good idea. This might be a simpler solution. I think I have a 5 V "wall
wart" adaptor somewhere. Or I guess I could just power up the unused
machine now and then, but that might not be so effective at preserving
the battery life.

Incidentally, what exactly does the phrase "wire wrap" mean? I think
I've followed your meaning, but I've not come across that phrase before.

There do not seem to be any documents
referring to NVRAM problems with the sun4u machines using the M48T59Y chip.


They just aren't old enough to have been sitting around
*unpowered* for ten years or so. :-) Start counting from when the
computer center retired the macines, not from when it was made.


Check the contents of your NVRAM chips (HOSTID and Ethernet MAC
address) and keep a hardcopy version in case you need to perform the
battery surgery which is documented in the website above.

For both the working motherboards I have, I've written down the details
displayed on the screen when the machine boots, such as the serial
number, ethernet address and host ID.


Good. Tape a copy to the machine itself.


For the machine I'm using at the
moment I've also saved a copy of the output of the command "eeprom -v".


What does the "-v" option do? It is present on my Solaris 10
one, but it is not documented in the man page under Solaris 10.

Same behavior in Solaris 2.6 on a SS-5.

I thought "-v" was a verbose option, which listed all the data stored in
the NVRAM. But it actually seems to give the same data as "eeprom"
alone, so the verbose option probably doesn't exist. I am probably
confusing it with "prtdiag -v", "prtconf -v" and "psrinfo -v".

Whether or not I need the extra details such as the system board serial
number, I don't know.


I think that the serial number is read from the board itself,
not from the NVRAM. In any case, it is present on the barcode label on
the system board.


I think that's all there was of importance in the post. I speculated a
little about whether common applications such as Firefox and Nautilus
are able to make good use of multiple processors on Sun workstations.
I'm still not certain. But I think that's all.


I depends on whether they are multi-threaded. Though they will
probably use other CPUs for plugins.

I did a bit of reading online and came to the conclusion that Firefox is
multi-threaded, but that one thread handles the user interface,
JavaScript, layout and image decoding. Probably this thread sometimes
gets bogged down!


O.K. Try moving to a Sun Blade 2000 with dual 1.2 GHz CPUs, and
8GB of RAM. You'll *still* find a browser coming to a halt from time to
time -- based on net delays to/from whatever site you are visiting.

The thing is, with a web browser, you often can't be sure what's causing
the delay.

At least with Sun machines, they don't seem to get slower with time like
Windows machines. One of my friends once said that Windows had a half
life of six months: i.e., the speed of your computer for most practical
purposes halves every six months.

Best wishes,

Chris

On 2009-01-14, Christopher Tidy wrote:
Hi Don,

Thanks for the advice. Sorry I've taken a week to reply.

I didn't expect it to make a big difference, because I thought that most
of the programs being loaded into RAM during the boot process would be
staying in the RAM. Also, once my old machine was up and running, it
often didn't use all the of the 1280 MB RAM. But I don't know of any way
of looking at RAM usage during the boot process.


Well -- you might be able to start "top -S -d1 -u -d1 40" from
one of the rc start files to capture the top 40 processes.

That's starting to sound complicated. For something which is a matter of
curiousity, anyway :-).

Normally, you can just use "top" to see what the most active
processes running are at any given time. The 40 there is to select 40
lines of output (for the top 40 processes), and some of the others are
to redirect a single snapshot to a file instead of constantly updating on
the screen as is the default (You are wanting to see this from before
you probably have a command line to use, which is why you put it in a rc
file so the machine runs it instead of you.

[ ... ]

I tried the method intended for sun4c machines on my Ultra 2. I get the
error "Fast Data Access MMU Miss" after the second command.


O.K. The Ultra-2 (and the rest of the ultra systems) at the
"ok" prompt are working with a FORTH interpreter, so you need to write a
program in that to get access to the EEPROM addresses. (Examples are
used for resetting the HOSTID and MAC address on Sun4u machines.)

That's useful to know. The "ok" prompt has always been something of a
mystery to me, even though I've figured out how to use it for a few
basic things.

Download a booklet from Sun's site on the commands present in
your major version of the OBP firmware.

My best guess is that the addresses for the Write and Stop bits given in
that document for the M48T02 chip are not the correct ones for the later
M48T59Y chip, which contains more memory.


Also -- there may need to be a different starting address when
you are working in that NVRAM on those systems.

Indeed. I was trying to figure this out from the data sheet, but failed.

The problem is that you have no way of knowing where it is
placed in the machine's address space -- it could start anywhere, and be
remapped anywhere else by the firmware.

[ ... ]

It is working at byte level. You write 0x80 to set the
write-enable bit, then after you have entered the stop bit, you re-write
the contents of the time field, with a 0x0 where you had 0x80, so you
don't really care about the lost information in the lower bits.

How does 0x80 correspond to setting the write-enable bit to 1?

The register uses the MSB for the write-enable bit according to
the data which we have. 0x80 is the symbol for hex 80, which in binary
is: 1000 0000 (Broken into upper and lower nybbles corresponding to the
digits in the hex number.) So -- it sets the MSB (the write-enable bit)
to 1, and all others to zero.

I'm sure that someone with more knowledge could figure this out, but I'm
reluctant to experiment with my working machine in case it ceases to
work. It also seems that the two failures which I thought were caused by
dead NVRAM batteries were not, so perhaps the M48T59Y has a longer
lifetime than the M48T02.


Or -- perhaps those machines are not old enough to have problems
yet. Remember -- as long as the machine itself is powered up, the
battery gives effectively its shelf life. Only when the machine is
powered down is the clock running from the battery instead of from the
system power.

Quite likely. Maybe I just need to wait a few years for the information
to appear.

:-)

And bear in mind that the Sun Blade 2000 (presumably and later
Sun machines) uses serial EPROMS for the NVRAM which does not need
battery backup -- and runs the clock chip from a coin cell in a holder
on the system board, so it no longer matters. :-)

If you really want to protect them, wire wrap a board which does
nothing but apply power to the power and ground pins for the chip. Feed
it 5V and forget about it. (Even add a battery to provide power if you
lose power to another hurricane. :-) If you wire-wrap multiple sockets
(for multiple NVRAM chips) put a sticky-note on each one to tell which
system it belongs in.

You might want to wire the address lines, and other inputs to
ground, so it won't pick up noise and get weird possible settings.

Good idea. This might be a simpler solution. I think I have a 5 V "wall
wart" adaptor somewhere. Or I guess I could just power up the unused
machine now and then, but that might not be so effective at preserving
the battery life.

Nope -- you need to power the chips *full* *time* to preserve
the battery life -- and they will eventually die just from shelf life
anyway. :-)

Incidentally, what exactly does the phrase "wire wrap" mean? I think
I've followed your meaning, but I've not come across that phrase before.

A method of construction which I like for quick-and-dirty
experiments. You don't have to make a PC board for it. Essentially,
each pin on each socket has a long square shaft with sharp edges. The
wire-wrap tool takes the 30 Ga solid wire and wraps it ten times around
the square pin under tension. There is enough pin length to allow three
wires to be terminated on there. There are tools which you can twirl
between thumb and index finger, or tools which operate by squeezing a
handle to get the 10 turns, or electrically or air powered guns for the
task. I have examples of all but the air powered version, and have
built entire CPU boards for a SWTP 6800 (to separate the baud rate
generation from the CPU clock generation so I could go to the full 2MHz
on the later 68B00 CPU chips). And I have built a special purpose
computer at work with mulitipile dual-port memory boards for a project.

It works quite well, and it is easy to revise the design at
need.

[ ... ]

For both the working motherboards I have, I've written down the details
displayed on the screen when the machine boots, such as the serial
number, ethernet address and host ID.


Good. Tape a copy to the machine itself.


For the machine I'm using at the
moment I've also saved a copy of the output of the command "eeprom -v".


What does the "-v" option do? It is present on my Solaris 10
one, but it is not documented in the man page under Solaris 10.

Same behavior in Solaris 2.6 on a SS-5.

I thought "-v" was a verbose option, which listed all the data stored in
the NVRAM. But it actually seems to give the same data as "eeprom"
alone, so the verbose option probably doesn't exist. I am probably
confusing it with "prtdiag -v", "prtconf -v" and "psrinfo -v".

BTW -- for most things, unless you have set unusual things into
the EEPROM settings, such as a special boot device, you can simply use
the command "set-defaults" at the "ok" prompt. This does nothing to
restore the HOSTID and the MAC address, unfortunately. :-)

[ ... ]

I did a bit of reading online and came to the conclusion that Firefox is
multi-threaded, but that one thread handles the user interface,
JavaScript, layout and image decoding. Probably this thread sometimes
gets bogged down!


O.K. Try moving to a Sun Blade 2000 with dual 1.2 GHz CPUs, and
8GB of RAM. You'll *still* find a browser coming to a halt from time to
time -- based on net delays to/from whatever site you are visiting.

The thing is, with a web browser, you often can't be sure what's causing
the delay.

Agreed.

My won favorite browser is Opera -- for the UltraSPARC machines
and several other flavors made by other companies, but not for the older
Sun machines. (Hmm ... it is compiled as 32-bit code, so maybe it will
work with the older systems -- if the needed shared libs are present.
Of course, I download the static version, so it is less sensitive to
changes in shared libs.

At least with Sun machines, they don't seem to get slower with time like
Windows machines. One of my friends once said that Windows had a half
life of six months: i.e., the speed of your computer for most practical
purposes halves every six months.

Well ... part of that is that they get bogged down with spyware
and malware which starts chewing up CPU cycles.

Also -- the filesystem needs regular defragmenting.

And Microsoft keeps "improving" them by loading yet more stuff
in there with every service pack. :-)

And -- it all still has to continue working with ancient
programs which make it harder to patch for fixing security holes. :-)

Enjoy,
DoN.

--
Email: | Voice (all times): (703) 938-4564
(too) near Washington D.C. | http://www.d-and-d.com/dnichols/DoN.html
--- Black Holes are where God is dividing by zero ---

On 2009-01-29, Christopher Tidy wrote:
Hi Don,

Yes, that is the version of GIMP that I have installed. I think it's
version 1.2. I found it more stable and faster than every copy of
version 2 that I could find.

As far as the speed is concerned, I find 2.0.2 is quite fast
enough -- at least on a Sun Blade 2000 with dual 1.2 GHz CPUs. And the
thing which makes the biggest difference in speed for *any* serious
image processor is the amount of RAM present. Running the Ultra-2 with
a full 2 GB of RAM made a significant difference. Running my SB-2K with
6 GB of RAM (instead of the 3 GB which I was running before) makes a big
difference in the speed of gimp 2.0.2.

BTW -- "the GIMP" is now up to version 2.6.?, though I am
running 2.0.2.


The version which I am running (from an earlier Solaris 10
distribution) is 2.0.2

I think 1.2 was the last version which Sun distributed with Solaris 9,
unless it has been updated in the last year or so, and I don't think it has.

I believe that it was included in the Software_Companion in
earlier versions of Solaris 10 as well (installing in /opt/sfw), while
gimp 2.?.? came standard in /usr/sfw.

But sadly it won't write PNG or GIF files.
Yet I'm sure that there was a version of GIMP 1.2 that could write those
files.


2.0.2 will save both.

As would one version of GIMP 1.2, or possibly 1.x, which I had from
http://www.blastwave.org/ in 2004. And it was stable. But I can only use
it now if I use all the software dating from 2004.

Wrong! Install once and run "ldd `which gimp`" on it.

Note where it finds each shared lib. Here is what my gimp on
the SB-2K shows up:


================================================== ====================
Katana:dnichols 21:33:28 ldd `which gimp`
libgimpwidgets-2.0.so.0 = /usr/sfw/lib/libgimpwidgets-2.0.so.0
libgimpcolor-2.0.so.0 = /usr/sfw/lib/libgimpcolor-2.0.so.0
libgimpmodule-2.0.so.0 = /usr/sfw/lib/libgimpmodule-2.0.so.0
libgimpbase-2.0.so.0 = /usr/sfw/lib/libgimpbase-2.0.so.0
libgimpthumb-2.0.so.0 = /usr/sfw/lib/libgimpthumb-2.0.so.0
libgimpmath-2.0.so.0 = /usr/sfw/lib/libgimpmath-2.0.so.0
libgtk-x11-2.0.so.0 = /usr/lib/libgtk-x11-2.0.so.0
libgdk-x11-2.0.so.0 = /usr/lib/libgdk-x11-2.0.so.0
libatk-1.0.so.0 = /usr/lib/libatk-1.0.so.0
libgdk_pixbuf-2.0.so.0 = /usr/lib/libgdk_pixbuf-2.0.so.0
libm.so.2 = /usr/lib/libm.so.2
libmlib.so.2 = /usr/lib/libmlib.so.2
libpangoxft-1.0.so.0 = /usr/lib/libpangoxft-1.0.so.0
libpangox-1.0.so.0 = /usr/lib/libpangox-1.0.so.0
libart_lgpl_2.so.2 = /usr/lib/libart_lgpl_2.so.2
libpangoft2-1.0.so.0 = /usr/lib/libpangoft2-1.0.so.0
libpango-1.0.so.0 = /usr/lib/libpango-1.0.so.0
libgobject-2.0.so.0 = /usr/lib/libgobject-2.0.so.0
libgmodule-2.0.so.0 = /usr/lib/libgmodule-2.0.so.0
libglib-2.0.so.0 = /usr/lib/libglib-2.0.so.0
libfontconfig.so.1 = /usr/lib/libfontconfig.so.1
libfreetype.so.6 = /usr/local/lib/libfreetype.so.6
libpthread.so.1 = /usr/lib/libpthread.so.1
libc.so.1 = /usr/lib/libc.so.1
libsocket.so.1 = /usr/lib/libsocket.so.1
libnsl.so.1 = /usr/lib/libnsl.so.1
libXft.so.2 = /usr/openwin/lib/libXft.so.2
libXrender.so.1 = /usr/sfw/lib/libXrender.so.1
libX11.so.4 = /usr/openwin/lib/libX11.so.4
libXrandr.so.2 = /usr/lib/libXrandr.so.2
libXi.so.5 = /usr/openwin/lib/libXi.so.5
libXext.so.0 = /usr/openwin/lib/libXext.so.0
libz.so.1 = /usr/lib/libz.so.1
libexpat.so.0 = /usr/sfw/lib/libexpat.so.0
libgcc_s.so.1 = /opt/gcc/lib/libgcc_s.so.1
libmp.so.2 = /usr/lib/libmp.so.2
libmd.so.1 = /usr/lib/libmd.so.1
libscf.so.1 = /usr/lib/libscf.so.1
libdl.so.1 = /usr/lib/libdl.so.1
libdoor.so.1 = /usr/lib/libdoor.so.1
libuutil.so.1 = /usr/lib/libuutil.so.1
libgen.so.1 = /usr/lib/libgen.so.1
/usr/lib/cpu/sparcv9+vis2/libmlib.so.2
/platform/SUNW,Sun-Blade-1000/lib/libc_psr.so.1
/platform/SUNW,Sun-Blade-1000/lib/libmd_psr.so.1
================================================== ====================

Next -- copy each of those shared libs into a directory and burn
a CD-ROM of it. Many of the shared libs are in /usr/lib, or perhaps
/usr/openwin/lib. Others in /usr/sfw/lib.

Next, copy the program to your newer system (e.g. my Solaris
10), put all of these libraries in (except probably the
/platform/SUNW.... ones), set up a wrapper script which sets
LD_LIBRARY_PATH to look at the directory of shared libs you just built,
and try running that version of gimp. (Or even just run ldd on that
gimp and look for "not found" reports.)

Try removing (moving into a subdirectory) one shared lib at a
time. starting with the /usr/lib ones, and see if ldd gimp still finds
all the shared libs without complaint. Usually the newer shared libs
which come with the system will work fine. It is just that BlastWave's
installer doesn't know this, and insists on installing up-to-date libs
for everything, whether they are needed or not.

I'll bet that at the end, you will find only a very few shared
libs which need to be added. Keep them in the directory, and keep
invoking gimp via the wrapper. If you discover that *all* of the shared
libs can be removed form that directory, you will have proven that it
will work without needing to add anything to the system.

I wish I could find a version of GIMP 1.2 which would save GIF and PNG
and was not dependent on shared libraries.

Compile your own! It will require a bit of tweaking of the
configure script and the produced Makefile, (and probably re-compiling
of some of the other things to provide a static library to link when you
compile gimp).

Remember that the primary form of "the GIMP" is freely
distributable source code, not pre-compiled binaries. :-)

Even if I can find a stable
version of GIMP 2, it was seriously slow when I tried it. Any idea where
I might find a later version of GIMP 1.2?

Here is the latest version (1.2.5) at this URL (and others):

http://mirror.umoss.org/gimp/gimp/v1.2/v1.2.5/


================================================== ====================
Name Last Modified Size Type
Parent Directory/ - Directory
README 2003-Jun-14 14:17:30 0.4K application/octet-stream
gimp-1.2.5.tar.bz2 2003-Jun-14 14:21:30 10.3M application/x-bzip
gimp-data-extras-1.2.0.tar.bz2 2000-Dec-24 19:16:30 4.2M application/x-bzip
gimp-data-extras-1.2.0.tar.gz 2000-Dec-24 19:14:30 4.5M application/x-gzip
patch-1.2.4-1.2.5.bz2 2003-Jun-14 14:35:30 153.3K application/x-bzip
================================================== ====================

But again, this is in source code form, and you have the great fun of
compiling it (and all the needed libraries which you don't have). And,
you'll probably need a lot of them, if you insist in sticking with
Solaris 9. :-)

[ ... ]

PNG was developed as a work-around for the fact that no open
source programs could save GIF files. (Actually, early versions of 'xv'
*did* write GIF files -- until the owners of the patents started
enforcing it.

Was it Compuserve's patent?

I believe so.

I'm trying to remember. I seem to remember
that at one time there was an anti-GIF movement and banners which said
"This is a GIF-free site", etc. But I haven't seen one in a long time.
Both standards seem to be in common use.

Now that the patent has expired.

[ ... ]

The biggest problem I've had is when you try to install a new piece of
software months after installing everything else. The new piece of
software requiries the latest shared libraries, so you have to update
everything. At least that's the way it works with the
http://www.blastwave.org/ packages.


That is because you are downloading pre-compiled packages, which
have (of course) been compiled against the most recent packages.
Normally shared libs are backwards compatible, and you will often find
several shortened names of shared libs which are symlinks to the current
name, so the program can call for it by any of a number of version
names. The links are not created where a newer version introduces an
incompatibility with an older one.

If you were to download the source for the packages, and compile
it locally, you would (usually) be able to compile it to use the shared
libs which you already have.

Except for ones which you might need to download.

[ ... ]

So -- get the GNOME source from the earlier version which you
like, and compile it under Solaris 10 after pkg removing the current
version.

I would, but right now I feel there are more urgent things I should do.
I can live with Solaris 9 a bit longer.

:-)

[ ... ]

I thought ST would have been smart enough to use one of these
rechargeable types in the NVRAM chip, but it seems not.


Physical size, what to do with the hydrogen from charging the
cell while it is potted in epoxy, wrong voltage, and not available when
the chip was first designed and made.

You get hydrogen from those little button cells? I'm surprised.


From *any* rechargeable battery while it is being recharged.

Does it come from water in the battery? If so, does it eventually cause
the battery to dry out?

It comes from the chemical reactions in the battery. Any acid,
combining with any base, should release hydrogen in the process -- *or*
produce water.

[ ... ]

With soldered connections, there is a point where the wire
exits the solder blob where it is going to flex the most, and where it
is most likely to fail in the presence of vibration.

That makes sense, but surely you've got to have some pretty serious
vibration to fatigue the wires, haven't you?


And what do you think happens in a telephone exchange, with
relays of all sizes vibrating the frames all the time.

I don't know. I've never been in a telephone exchange. But many of the
relays are solid state now, aren't they?

Probably so -- but you would have been amazed at the noise in a
dial telephone exchange in the early 1960s.

Same for circuits in aircraft or automobiles.

Presumably it's only a problem in the high vibration regions such as on
the engine itself, isn't it? Cars still have a fair number of soldered
joints, particularly on printed circuit boards.

Solder joints for mounting components to PC boards are fine --
though there is usually something done to keep the component from
vibrating.

However -- wires from the car's wiring harness to the boards are
almost always connected via crimp-on connectors, or crimp terminated
ring terminals mounted to screws on barrier strips and the like. A
*good* crimp-on terminal will have not only a crimp on the exposed wire,
but a support crimp on the insulation of the wire to control vibration
and keep it from flexing the wire between the insulation and the
terminal.

[ ... ]

[ ... backwards compatibility ... ]

snip

Hmm ... "rare and expensive". Try an ebay search for:

Toshiba DVD-ROM SCSI M1401

1) $14.99

2) $49.00 (In a Sun UniPack external chassis)

3) $9.99

4) $25.00

5) $49.99 (five drives not just one)

6) $39.99

Sorry, I made a mistake. At the time I was searching for a SCSI DVD
writer, as I wanted to have just a single drive in the machine. At the
time, those were rare and expensive.

O.K. For that, you want an ACArd bridge card to convert IDE to
50-pin SCSI. With that, you can mount an IDE DVD burner in the system
in place of the original SCSI drive. I have such a drive in my Sun
Blade 2000, and another one in a FlexiPack (like a UniPack, except that
it holds two drives). That one is connected via an ACard bridge card
which adapts to 68-pin SCSI instead of 50-pin. This particular ACard
can be a pain in the system, but outside with a 68-pin interface, it
works nicely.

The only problem is that while the IDE DVD-burners are quite
inexpensive, the ACard is something like $59.00 or so. :-)

I would think that some of those would be cheap enough to use
for the task. It saves a *lot* of CD swapping, and of waiting around
for the right time to swap when loading Solaris 10 (5 CD-ROMs or one
DVD-ROM. :-)

I even put a spare into an ancient SGI Indigo 2, and it works
fine with CDs and DVDs.

What do you think of the Indigo 2?

Slow once I'm using a Sun Blade 2000 with dual 1.2 GHz CPU
modules. :-) This particular Indigo 2 is the Teal colored one, and
happens to have an unusual CPU -- the R8000 -- only 75 MHz, but it can
do floating-point math as fast as integer math.

I've been disappointed trying to get it to work with a (SCSI) HP
ScanJet 5p, because the driver supplied with the 6.2 version of the OS
stops at the ScanJet III. However, I managed to get sane working in the
SB-2K (a couple of tricky things but I have the latest version running,
and just used it to scan all of the text section of a Bridgeport BOSS-3
and BOSS-4 manual. Unfortunately, the schematics are fold-outs, and
will either have to be scanned in multiple parts and then pasted back
together later, or I'll have to find a scanner which will handle 11x17"
pages. :-)

I love the colour. It looks
remarkable, especially the genuine indigo-coloured R10000 machine.

Pretty much all of their machines are colorful. But then recent
Sun machines have been getting more colorful. Look at the SB-2K for
example. (Of course, you will see two apparent colors in eBay auction
photos -- the duller ones were photographed by incandescent or
fluorescent lights, while the more garish ones were photographed by
electronic flash. :-)

I
almost bought one in 2003, but then I got a Sun Ultra 2 for nothing instead.

This one was free, too.

But I now need to get one of the original DAT drives for what I
wish to use it for -- transferring audio DATs to computer files, which
can then be burned into audio CDs.

Enjoy,
DoN.

--
Email: | Voice (all times): (703) 938-4564
(too) near Washington D.C. | http://www.d-and-d.com/dnichols/DoN.html
--- Black Holes are where God is dividing by zero ---

Hi Don,

Yes, that is the version of GIMP that I have installed. I think it's
version 1.2. I found it more stable and faster than every copy of
version 2 that I could find.


As far as the speed is concerned, I find 2.0.2 is quite fast
enough -- at least on a Sun Blade 2000 with dual 1.2 GHz CPUs. And the
thing which makes the biggest difference in speed for *any* serious
image processor is the amount of RAM present. Running the Ultra-2 with
a full 2 GB of RAM made a significant difference. Running my SB-2K with
6 GB of RAM (instead of the 3 GB which I was running before) makes a big
difference in the speed of gimp 2.0.2.

It wasn't the speed once it was up and running, it was the start-up
time. On the same machine, GIMP 1.2 was quick, whereas GIMP 2 seemed to
take forever!

BTW -- "the GIMP" is now up to version 2.6.?, though I am
running 2.0.2.


The version which I am running (from an earlier Solaris 10
distribution) is 2.0.2

I think 1.2 was the last version which Sun distributed with Solaris 9,
unless it has been updated in the last year or so, and I don't think it has.


I believe that it was included in the Software_Companion in
earlier versions of Solaris 10 as well (installing in /opt/sfw), while
gimp 2.?.? came standard in /usr/sfw.


But sadly it won't write PNG or GIF files.
Yet I'm sure that there was a version of GIMP 1.2 that could write those
files.


2.0.2 will save both.

As would one version of GIMP 1.2, or possibly 1.x, which I had from
http://www.blastwave.org/ in 2004. And it was stable. But I can only use
it now if I use all the software dating from 2004.


Wrong! Install once and run "ldd `which gimp`" on it.

Note where it finds each shared lib. Here is what my gimp on
the SB-2K shows up:


================================================== ====================
Katana:dnichols 21:33:28 ldd `which gimp`
libgimpwidgets-2.0.so.0 = /usr/sfw/lib/libgimpwidgets-2.0.so.0
libgimpcolor-2.0.so.0 = /usr/sfw/lib/libgimpcolor-2.0.so.0
libgimpmodule-2.0.so.0 = /usr/sfw/lib/libgimpmodule-2.0.so.0
libgimpbase-2.0.so.0 = /usr/sfw/lib/libgimpbase-2.0.so.0
libgimpthumb-2.0.so.0 = /usr/sfw/lib/libgimpthumb-2.0.so.0
libgimpmath-2.0.so.0 = /usr/sfw/lib/libgimpmath-2.0.so.0
libgtk-x11-2.0.so.0 = /usr/lib/libgtk-x11-2.0.so.0
libgdk-x11-2.0.so.0 = /usr/lib/libgdk-x11-2.0.so.0
libatk-1.0.so.0 = /usr/lib/libatk-1.0.so.0
libgdk_pixbuf-2.0.so.0 = /usr/lib/libgdk_pixbuf-2.0.so.0
libm.so.2 = /usr/lib/libm.so.2
libmlib.so.2 = /usr/lib/libmlib.so.2
libpangoxft-1.0.so.0 = /usr/lib/libpangoxft-1.0.so.0
libpangox-1.0.so.0 = /usr/lib/libpangox-1.0.so.0
libart_lgpl_2.so.2 = /usr/lib/libart_lgpl_2.so.2
libpangoft2-1.0.so.0 = /usr/lib/libpangoft2-1.0.so.0
libpango-1.0.so.0 = /usr/lib/libpango-1.0.so.0
libgobject-2.0.so.0 = /usr/lib/libgobject-2.0.so.0
libgmodule-2.0.so.0 = /usr/lib/libgmodule-2.0.so.0
libglib-2.0.so.0 = /usr/lib/libglib-2.0.so.0
libfontconfig.so.1 = /usr/lib/libfontconfig.so.1
libfreetype.so.6 = /usr/local/lib/libfreetype.so.6
libpthread.so.1 = /usr/lib/libpthread.so.1
libc.so.1 = /usr/lib/libc.so.1
libsocket.so.1 = /usr/lib/libsocket.so.1
libnsl.so.1 = /usr/lib/libnsl.so.1
libXft.so.2 = /usr/openwin/lib/libXft.so.2
libXrender.so.1 = /usr/sfw/lib/libXrender.so.1
libX11.so.4 = /usr/openwin/lib/libX11.so.4
libXrandr.so.2 = /usr/lib/libXrandr.so.2
libXi.so.5 = /usr/openwin/lib/libXi.so.5
libXext.so.0 = /usr/openwin/lib/libXext.so.0
libz.so.1 = /usr/lib/libz.so.1
libexpat.so.0 = /usr/sfw/lib/libexpat.so.0
libgcc_s.so.1 = /opt/gcc/lib/libgcc_s.so.1
libmp.so.2 = /usr/lib/libmp.so.2
libmd.so.1 = /usr/lib/libmd.so.1
libscf.so.1 = /usr/lib/libscf.so.1
libdl.so.1 = /usr/lib/libdl.so.1
libdoor.so.1 = /usr/lib/libdoor.so.1
libuutil.so.1 = /usr/lib/libuutil.so.1
libgen.so.1 = /usr/lib/libgen.so.1
/usr/lib/cpu/sparcv9+vis2/libmlib.so.2
/platform/SUNW,Sun-Blade-1000/lib/libc_psr.so.1
/platform/SUNW,Sun-Blade-1000/lib/libmd_psr.so.1
================================================== ====================

Next -- copy each of those shared libs into a directory and burn
a CD-ROM of it. Many of the shared libs are in /usr/lib, or perhaps
/usr/openwin/lib. Others in /usr/sfw/lib.

Next, copy the program to your newer system (e.g. my Solaris
10), put all of these libraries in (except probably the
/platform/SUNW.... ones), set up a wrapper script which sets
LD_LIBRARY_PATH to look at the directory of shared libs you just built,
and try running that version of gimp. (Or even just run ldd on that
gimp and look for "not found" reports.)

Try removing (moving into a subdirectory) one shared lib at a
time. starting with the /usr/lib ones, and see if ldd gimp still finds
all the shared libs without complaint. Usually the newer shared libs
which come with the system will work fine. It is just that BlastWave's
installer doesn't know this, and insists on installing up-to-date libs
for everything, whether they are needed or not.

I'll bet that at the end, you will find only a very few shared
libs which need to be added. Keep them in the directory, and keep
invoking gimp via the wrapper. If you discover that *all* of the shared
libs can be removed form that directory, you will have proven that it
will work without needing to add anything to the system.

As with many things in Unix which appear at first to be impossible, I
can see that this can be done, with quite a bit of work. One day I'd
like to try it, but right now I need to do some programming which will
make me cash :-).

I wish I could find a version of GIMP 1.2 which would save GIF and PNG
and was not dependent on shared libraries.


Compile your own! It will require a bit of tweaking of the
configure script and the produced Makefile, (and probably re-compiling
of some of the other things to provide a static library to link when you
compile gimp).

Remember that the primary form of "the GIMP" is freely
distributable source code, not pre-compiled binaries. :-)


Even if I can find a stable
version of GIMP 2, it was seriously slow when I tried it. Any idea where
I might find a later version of GIMP 1.2?


Here is the latest version (1.2.5) at this URL (and others):

http://mirror.umoss.org/gimp/gimp/v1.2/v1.2.5/


================================================== ====================
Name Last Modified Size Type
Parent Directory/ - Directory
README 2003-Jun-14 14:17:30 0.4K application/octet-stream
gimp-1.2.5.tar.bz2 2003-Jun-14 14:21:30 10.3M application/x-bzip
gimp-data-extras-1.2.0.tar.bz2 2000-Dec-24 19:16:30 4.2M application/x-bzip
gimp-data-extras-1.2.0.tar.gz 2000-Dec-24 19:14:30 4.5M application/x-gzip
patch-1.2.4-1.2.5.bz2 2003-Jun-14 14:35:30 153.3K application/x-bzip
================================================== ====================

But again, this is in source code form, and you have the great fun of
compiling it (and all the needed libraries which you don't have). And,
you'll probably need a lot of them, if you insist in sticking with
Solaris 9. :-)

Thanks for the link. I began to download that source code, but the
server kept dropping the connection. I'll try again later.

snip

Hmm ... "rare and expensive". Try an ebay search for:

Toshiba DVD-ROM SCSI M1401

1) $14.99

2) $49.00 (In a Sun UniPack external chassis)

3) $9.99

4) $25.00

5) $49.99 (five drives not just one)

6) $39.99

Sorry, I made a mistake. At the time I was searching for a SCSI DVD
writer, as I wanted to have just a single drive in the machine. At the
time, those were rare and expensive.


O.K. For that, you want an ACArd bridge card to convert IDE to
50-pin SCSI. With that, you can mount an IDE DVD burner in the system
in place of the original SCSI drive. I have such a drive in my Sun
Blade 2000, and another one in a FlexiPack (like a UniPack, except that
it holds two drives). That one is connected via an ACard bridge card
which adapts to 68-pin SCSI instead of 50-pin. This particular ACard
can be a pain in the system, but outside with a 68-pin interface, it
works nicely.

The only problem is that while the IDE DVD-burners are quite
inexpensive, the ACard is something like $59.00 or so. :-)

Are those things any good? I remember when they first came out - sold
for hard disks rather than CD-Roms - I heard some complaints that they
were more trouble than they were worth.

And right now, CDs suit my needs. The only reason a DVD burner might be
good is to back up the CDs of photographs I already have (they come on
CDs from the lab; I don't burn them myself). So far I've had no problems
with those CDs, but the oldest are over 5 years old now and I'm not sure
how long they'll last.

I would think that some of those would be cheap enough to use
for the task. It saves a *lot* of CD swapping, and of waiting around
for the right time to swap when loading Solaris 10 (5 CD-ROMs or one
DVD-ROM. :-)

I even put a spare into an ancient SGI Indigo 2, and it works
fine with CDs and DVDs.

What do you think of the Indigo 2?


Slow once I'm using a Sun Blade 2000 with dual 1.2 GHz CPU
modules. :-) This particular Indigo 2 is the Teal colored one, and
happens to have an unusual CPU -- the R8000 -- only 75 MHz, but it can
do floating-point math as fast as integer math.

I was thinking in comparison to a Sun Ultra 2? I figured at the time
that my free 2 x 300 MHz Ultra 2 was probably the better machine, but
was never quite sure. That bright purple case had an effect on my mind.

I did have a Personal Iris for a while. Probably weighed about 80 lbs. I
gave it to a computer museum.

Best wishes,

Chris

On 2009-02-04, Christopher Tidy wrote:
Hi Don,

Yes, that is the version of GIMP that I have installed. I think it's
version 1.2. I found it more stable and faster than every copy of
version 2 that I could find.


As far as the speed is concerned, I find 2.0.2 is quite fast
enough -- at least on a Sun Blade 2000 with dual 1.2 GHz CPUs. And the
thing which makes the biggest difference in speed for *any* serious
image processor is the amount of RAM present. Running the Ultra-2 with
a full 2 GB of RAM made a significant difference. Running my SB-2K with
6 GB of RAM (instead of the 3 GB which I was running before) makes a big
difference in the speed of gimp 2.0.2.

It wasn't the speed once it was up and running, it was the start-up
time. On the same machine, GIMP 1.2 was quick, whereas GIMP 2 seemed to
take forever!

Hmm ... IIRC, "the GIMP" -- either version -- will load a ton of
plug-ins at the first time it is run by root -- and will then
automatically force a core dump and process that into an executable
which has everything pre-loaded. Emacs does the same thing.

If you always started it as a user, and never as root, it would
never get the chance to do the "core dump and turn into executable" magic,
so it would always be slow to start.

Maybe the later Solaris 10 distributions did that for you before
packaging it.

I certainly don't notice the long delay -- but with two 1.2 GHz
CPUs, I guess that I would not. :-)

O.K. It does still load the plugins at start time, and it takes
15 seconds from the [Enter] key to it having everything displayed and
ready to work. I guess that with your 300 MHz CPUs, it would take on
the order of a full minute -- depending on how much of that is the disk
speed instead of the CPU speed.

[ ... ]

2.0.2 will save both.

As would one version of GIMP 1.2, or possibly 1.x, which I had from
http://www.blastwave.org/ in 2004. And it was stable. But I can only use
it now if I use all the software dating from 2004.


Wrong! Install once and run "ldd `which gimp`" on it.

Note where it finds each shared lib. Here is what my gimp on
the SB-2K shows up:

[ ... ]

Next -- copy each of those shared libs into a directory and burn
a CD-ROM of it. Many of the shared libs are in /usr/lib, or perhaps
/usr/openwin/lib. Others in /usr/sfw/lib.

[ ... ]

I'll bet that at the end, you will find only a very few shared
libs which need to be added. Keep them in the directory, and keep
invoking gimp via the wrapper. If you discover that *all* of the shared
libs can be removed form that directory, you will have proven that it
will work without needing to add anything to the system.

As with many things in Unix which appear at first to be impossible, I
can see that this can be done, with quite a bit of work. One day I'd
like to try it, but right now I need to do some programming which will
make me cash :-).

I first read that as "Make me crash". :-)

I wish I could find a version of GIMP 1.2 which would save GIF and PNG
and was not dependent on shared libraries.

[ ... ]

Even if I can find a stable
version of GIMP 2, it was seriously slow when I tried it. Any idea where
I might find a later version of GIMP 1.2?


Here is the latest version (1.2.5) at this URL (and others):

http://mirror.umoss.org/gimp/gimp/v1.2/v1.2.5/

[ ... ]

But again, this is in source code form, and you have the great fun of
compiling it (and all the needed libraries which you don't have). And,
you'll probably need a lot of them, if you insist in sticking with
Solaris 9. :-)

Thanks for the link. I began to download that source code, but the
server kept dropping the connection. I'll try again later.

O.K. Good luck there.

snip

Hmm ... "rare and expensive". Try an ebay search for:

Toshiba DVD-ROM SCSI M1401

[ ... ]

Sorry, I made a mistake. At the time I was searching for a SCSI DVD
writer, as I wanted to have just a single drive in the machine. At the
time, those were rare and expensive.


O.K. For that, you want an ACArd bridge card to convert IDE to
50-pin SCSI. With that, you can mount an IDE DVD burner in the system
in place of the original SCSI drive. I have such a drive in my Sun
Blade 2000, and another one in a FlexiPack (like a UniPack, except that
it holds two drives). That one is connected via an ACard bridge card
which adapts to 68-pin SCSI instead of 50-pin. This particular ACard
can be a pain in the system, but outside with a 68-pin interface, it
works nicely.

The only problem is that while the IDE DVD-burners are quite
inexpensive, the ACard is something like $59.00 or so. :-)

Are those things any good? I remember when they first came out - sold
for hard disks rather than CD-Roms - I heard some complaints that they
were more trouble than they were worth.

I am using one quite frequently for a DVD burner mounted in my
SB-2000. It shows up as:

================================================== ====================
'_NEC ' 'DVD_RW ND-3520A ' '1.04' Removable CD-ROM
================================================== ====================

The main thing is to be sure to go to ACard's own site, and look for the
one which is 50-pin SCSI instead of 68-pin SCSI, at least if you intend
to use it as an internal drive.

I had a 68-pin one, which would not make a bootable DVD drive,
especially in the system, and it took forever to argue with the system
over whether to use narrow or wide SCSI, since both ends were
identifying as wide, but the internal connection to the DVD-drive was
only narrow SCSI. :-)

And right now, CDs suit my needs. The only reason a DVD burner might be
good is to back up the CDs of photographs I already have (they come on
CDs from the lab; I don't burn them myself). So far I've had no problems
with those CDs, but the oldest are over 5 years old now and I'm not sure
how long they'll last.

Understood.

I would think that some of those would be cheap enough to use
for the task. It saves a *lot* of CD swapping, and of waiting around
for the right time to swap when loading Solaris 10 (5 CD-ROMs or one
DVD-ROM. :-)

I even put a spare into an ancient SGI Indigo 2, and it works
fine with CDs and DVDs.

What do you think of the Indigo 2?


Slow once I'm using a Sun Blade 2000 with dual 1.2 GHz CPU
modules. :-) This particular Indigo 2 is the Teal colored one, and
happens to have an unusual CPU -- the R8000 -- only 75 MHz, but it can
do floating-point math as fast as integer math.

I was thinking in comparison to a Sun Ultra 2? I figured at the time
that my free 2 x 300 MHz Ultra 2 was probably the better machine, but
was never quite sure. That bright purple case had an effect on my mind.

Remember -- this one was a 75 MHz CPU. About the only time it
*might* do better than the Sun Ultra-2 would be if you were doing
something which was almost exclusively *heavy* floating-point math.
That one had a separate floating-point processor which was as fast as
(or faster than) the integer math. I think that the SB-2K may well be
equally designed for very fast floating point.

I did have a Personal Iris for a while. Probably weighed about 80 lbs. I
gave it to a computer museum.

Got tired of heating the house with it?

Enjoy,
DoN.

--
Email: | Voice (all times): (703) 938-4564
(too) near Washington D.C. | http://www.d-and-d.com/dnichols/DoN.html
--- Black Holes are where God is dividing by zero ---

DoN. Nichols wrote:

Hmm ... IIRC, "the GIMP" -- either version -- will load a ton of
plug-ins at the first time it is run by root -- and will then
automatically force a core dump and process that into an executable
which has everything pre-loaded. Emacs does the same thing.

If you always started it as a user, and never as root, it would
never get the chance to do the "core dump and turn into executable" magic,
so it would always be slow to start.

I was running GIMP 2 as root when I observed it to be slow. I might have
persisted with it for longer, except that the version I had was also
very unstable. So it didn't seem worth the trouble.

Maybe the later Solaris 10 distributions did that for you before
packaging it.

I certainly don't notice the long delay -- but with two 1.2 GHz
CPUs, I guess that I would not. :-)

O.K. It does still load the plugins at start time, and it takes
15 seconds from the [Enter] key to it having everything displayed and
ready to work. I guess that with your 300 MHz CPUs, it would take on
the order of a full minute -- depending on how much of that is the disk
speed instead of the CPU speed.

Maybe you're more patient than me. GIMP 1.2 takes 4 seconds to load on
my Ultra 2. I'd have said GIMP 2 probably took 15 or 20 seconds to load.
But I'm always opening and closing it, so I really notice the time it
takes to load.

snip

As with many things in Unix which appear at first to be impossible, I
can see that this can be done, with quite a bit of work. One day I'd
like to try it, but right now I need to do some programming which will
make me cash :-).


I first read that as "Make me crash". :-)

Possibly, but I hope not :-).

snip

I am using one quite frequently for a DVD burner mounted in my
SB-2000. It shows up as:

================================================== ====================
'_NEC ' 'DVD_RW ND-3520A ' '1.04' Removable CD-ROM
================================================== ====================

The main thing is to be sure to go to ACard's own site, and look for the
one which is 50-pin SCSI instead of 68-pin SCSI, at least if you intend
to use it as an internal drive.

I had a 68-pin one, which would not make a bootable DVD drive,
especially in the system, and it took forever to argue with the system
over whether to use narrow or wide SCSI, since both ends were
identifying as wide, but the internal connection to the DVD-drive was
only narrow SCSI. :-)

I had a similar problem with a Teac SCSI CD-Rom. I couldn't seem to make
it bootable, until I discovered that an unexpected combination of
jumpers on the back of the drive did the trick. I don't remember the
combination of jumpers, but I wrote it down on the top of the drive. I
can check if you want to know.

snip

I was thinking in comparison to a Sun Ultra 2? I figured at the time
that my free 2 x 300 MHz Ultra 2 was probably the better machine, but
was never quite sure. That bright purple case had an effect on my mind.


Remember -- this one was a 75 MHz CPU. About the only time it
*might* do better than the Sun Ultra-2 would be if you were doing
something which was almost exclusively *heavy* floating-point math.
That one had a separate floating-point processor which was as fast as
(or faster than) the integer math. I think that the SB-2K may well be
equally designed for very fast floating point.

I remember being told that the Indigo 2 had hardware which made it very
fast at alpha blending, though I never fully understood what that was.

I did have a Personal Iris for a while. Probably weighed about 80 lbs. I
gave it to a computer museum.


Got tired of heating the house with it?

I was a bit reluctant to part with the Personal Iris actually. It was a
very interesting machine and built like a tank. But it had the Year 2000
problem and wasn't actually very useful, so I had to let it go. Sadly I
can't keep everything, although most people think I try. I'm glad I gave
it to a museum, though.

Best wishes,

Chris