Re: SPARCstation 20 with SCSI2SD

[systems_glitch via cctalk]

Nice work, indeed! The clearance issue is part of why I made the repair
module boards.

Thanks,
Jonathan

On Wed, Dec 5, 2018 at 9:54 AM Maciej W. Rozycki via cctalk <
cctalk@classiccmp.org> wrote:

> On Sun, 2 Dec 2018, Jeffrey S. Worley via cctalk wrote:
>
> > The re-work of that Dallas nvram chip is just beautiful.  It makes me
> > ashamed of myself.  (I just chopped into the epoxy with a pocket knife,
> > soldered two leads, and velcroed the new batteries somewhere inside the
> > machine I installed it in.)
>
>  There is very little clearance in DECstation 5000 systems, like .1", as
> per the TURBOchannel specification, between the top of the Dallas chip and
> the bottom of any TURBOchannel option placed right above it (some have
> components underneath, including large ICs), and I think the risk of
> breaking such a non-standard wiring while shuffling option cards is not to
> be ignored either.  Also the design of the system box makes it very
> difficult to choose a suitable location for a distant battery holder that
> would not obstruct anything.
>
>  So I decided to do that properly at the cost of it taking perhaps a
> little longer to rework a single chip.
>
>  NB a CR1220 cell is supposed to last for ~8 years in this application if
> running on battery power all the time, which I think is good enough.  A
> CR2032 cell would last ~50 years, which I think is an overkill, given that
> the seal is expected to fail much earlier, like after 10 years.
>
>  An encapsulated power module could instead be used such as the Renata
> 175-0, where space permits, which would indeed last some 50 years, being
> airtight, but I haven't seen any reports of its use in this application (I
> have a couple of those on DEC NVRAM boards and last time I checked they
> still had the power to hold 1MiB SRAM memory contents after 25+ years).
>
> > I salute you sir.
>
>  :)  So far I only made 2 of these, but more are in the pipeline (waiting
> for a free weekend).
>
>   Maciej
>

Re: SPARCstation 20 with SCSI2SD

[Maciej W. Rozycki via cctalk]

On Sun, 2 Dec 2018, Jeffrey S. Worley via cctalk wrote:

> The re-work of that Dallas nvram chip is just beautiful.  It makes me
> ashamed of myself.  (I just chopped into the epoxy with a pocket knife,
> soldered two leads, and velcroed the new batteries somewhere inside the
> machine I installed it in.)

 There is very little clearance in DECstation 5000 systems, like .1", as 
per the TURBOchannel specification, between the top of the Dallas chip and 
the bottom of any TURBOchannel option placed right above it (some have 
components underneath, including large ICs), and I think the risk of 
breaking such a non-standard wiring while shuffling option cards is not to 
be ignored either.  Also the design of the system box makes it very 
difficult to choose a suitable location for a distant battery holder that 
would not obstruct anything.

 So I decided to do that properly at the cost of it taking perhaps a 
little longer to rework a single chip.

 NB a CR1220 cell is supposed to last for ~8 years in this application if 
running on battery power all the time, which I think is good enough.  A 
CR2032 cell would last ~50 years, which I think is an overkill, given that 
the seal is expected to fail much earlier, like after 10 years.

 An encapsulated power module could instead be used such as the Renata 
175-0, where space permits, which would indeed last some 50 years, being 
airtight, but I haven't seen any reports of its use in this application (I 
have a couple of those on DEC NVRAM boards and last time I checked they 
still had the power to hold 1MiB SRAM memory contents after 25+ years).

> I salute you sir.

 :)  So far I only made 2 of these, but more are in the pipeline (waiting
for a free weekend).

  Maciej

Re: SPARCstation 20 with SCSI2SD

[Jeffrey S. Worley via cctalk]

The re-work of that Dallas nvram chip is just beautiful.  It makes me
ashamed of myself.  (I just chopped into the epoxy with a pocket knife,
soldered two leads, and velcroed the new batteries somewhere inside the
machine I installed it in.)

I salute you sir.

Jeff

Re: SPARCstation 20 with SCSI2SD

[Maciej W. Rozycki via cctalk]

On Sat, 1 Dec 2018, alan--- via cctalk wrote:

> I'm not sure what the 'B' in the middle means (silicon rev?), but the DS12885
> has been around for decades.  I use them the JR-IDE project.

 Yes, the DS12885 is a standard part, still in production (with a trailing 
+ marking RoHS compliance).

 According to its datasheet the DS12B887 has an NC pin actually present in 
the position where the DS12885 has the RESET# line, while the remaining NC 
positions are absent due to the respective pins having been bent up (or 
"are missing by design", as the datasheet puts it).  So either a different 
core had to be used with the DS12B887 or the datasheet has an error.

 However RESET# would have to be connected to VCC for normal operation and 
there is no mention of an internal pull-up on RESET# with the DS12885, so 
I take it the DS12B887 had to use a different core and a DS12B885 seems 
like a logical match.

 The placement of RESET# right in the middle between VBAT and GND makes it 
highly unlikely an internal discrete connection has been made in the 
DS12B887 package between RESET# and VCC, as a shortage to the embedded 
lithium cell from that pin if bent up and soldered to would be virtually 
unavoidable.

  Maciej

Re: SPARCstation 20 with SCSI2SD

[alan--- via cctalk]

I'm not sure what the 'B' in the middle means (silicon rev?), but the 
DS12885 has been around for decades.  I use them the JR-IDE project.


-Alan


On 2018-12-01 17:47, Maciej W. Rozycki via cctalk wrote:

On Tue, 27 Nov 2018, systems_glitch via cctalk wrote:

I probably need to do a writeup on fully potted parts, like the 48T59 
and

DS1287.


 See a photo documentary here:
 for my
proposal of a DS1287 rework.

 I actually had a nasty surprise trying to rework a DS1287A, with a 
date

code indicating a clearly faked marking.  After removing the integrated
coin cell the marking on the embedded IC revealed showed it wasn't even 
a

DS1287A originally as the IC was a DS12B885.  This is a part I haven't
heard of existing, so I enquired Maxim, but they had no clue about it.  
I
suspect the DS12B885 was the core of the DS12B887 (wired differently 
from
both DS12887 and DS12887A), and the DS12B885 has never been marketed as 
a

part on its own.

  Maciej

Re: SPARCstation 20 with SCSI2SD

[Maciej W. Rozycki via cctalk]

On Tue, 27 Nov 2018, systems_glitch via cctalk wrote:

> I probably need to do a writeup on fully potted parts, like the 48T59 and
> DS1287.

 See a photo documentary here:
 for my 
proposal of a DS1287 rework.

 I actually had a nasty surprise trying to rework a DS1287A, with a date 
code indicating a clearly faked marking.  After removing the integrated 
coin cell the marking on the embedded IC revealed showed it wasn't even a 
DS1287A originally as the IC was a DS12B885.  This is a part I haven't 
heard of existing, so I enquired Maxim, but they had no clue about it.  I 
suspect the DS12B885 was the core of the DS12B887 (wired differently from 
both DS12887 and DS12887A), and the DS12B885 has never been marketed as a 
part on its own.

  Maciej

Re: NVRAM resuscitation (Was Re: SPARCstation 20 with SCSI2SD)

[Jim Manley via cctalk]

DEC had some employees with clearances all the way up both primary sides of
the classification ladder, General Service (GENSER, which includes some
"black" programs), and Special Compartmented Intelligence (SCI, which has
its own alphabet soup, including other kinds of "black" programs).  They
needed this because magnetic core memory was used in PDP era systems that
processed up to the highest classification levels deemed prudent to not
require completely manual handling (including typewriters and carbon paper,
at least until pressure-sensitive carbonless paper was invented).

That included communications processing systems that, when the hardware
reached end-of-life (which happened to coincide with the upgrades made for
Y2K), the software was wrapped essentially in virtual machines that ran on
current-technology hardware and OSes.  The cost of porting the original
code would have been horrific because it had been mathematically proven to
be correct, and introduction of a single bug could not be tolerated.  Long
after PDP hardware had become commercially extinct, but the government
never throws anything away, DoD was still paying DEC lots of pretty pennies
to maintain a special secure version of the RSX-11 OS for feature
enhancements until the wrapping could be performed.

Core was so expensive that it was economically necessary to repair it,
rather than just replace it, especially in overseas systems where supply
lines were tenuous, at best.  As you might have heard, core never forgets -
at the Computer History Museum, when we resurrected our 1960-vintage IBM
1401, every bit of the auto parts database that it ran when taken out of
service was still intact over 30 years later.  That meant that military
commissioned officers had to escort double-wrapped/sealed/authenticated
packages containing such core devices all the way from almost-literally
Timbuktu back to DEC.

Plus, because of two-man rule handling requirements, two people with the
necessary clearances had to keep it in their presence when it wasn't
secured in a vault, and it was signed in and out every time it moved or
changed hands.  One of the benefits of volunteering to do this when flying
space-available on leave was that such couriers got to get on military
aircraft before anyone else, so we got first choice on seats.  Well, it was
as "choice" as it gets when often on tactical aircraft with jump seats used
by special forces and conventional paratroopers.

Civilians would describe the seats as ballistic nylon material stretched
between round aircraft-grade aluminum tubes ... aka a high-speed, low-drag
cot ... with nylon webbing, similar to seat-belt material, cross-woven
vertically/horizontally, with gaps equal in width to the webbing, hung
behind serving as a "back rest".  Military aviation seat belts were
thoughtfully provided passing through the webbing and secured to the inside
bulkheads of the fuselage ... mostly to make it easier for recovery crews
to gather the bodies in case of a crash ...

So, yeah, there's a whole world of physical security associated with NV
memory devices, alone, even if the technology has changed.  BTW, it's not
physically possible to reliably degauss every bit on rotating magnetic
storage media with a flux density higher than about that of a 1.44 MB
floppy disk, no matter how strong a field is produced.  It has to be
physically reduced to dust smaller than a specified particle size, or
incinerated.

On Wed, Nov 28, 2018 at 7:47 AM Paul Koning via cctalk <
cctalk@classiccmp.org> wrote:

>
>
> > On Nov 28, 2018, at 9:43 AM, Ethan via cctalk 
> wrote:
> >
> >> As an aside - once upon a time I worked for a company that made their
> own Sparc boards to fit inside a supercomputer and several of them were
> inside secure military/government establishments. Sometimes a board would
> fail and have to go back for a fix - and then the RTC/NVRAM chip had to be
> removed because - you know, those 64 bytes of battery backed RAM might just
> hold some state secret or something...
> >> Fun days.
> >> -Gordon
> >
> > Surprised they knew about it!
>
> One of the documents hardware engineers have to generate is a "Statement
> of Volatility" that lists every component in the system with persistent
> memory of any kind.  For each, it says what is in that memory, where it is
> located, and how (if it can contain anything like user data or
> configuration settings) it can be erased or removed.
>
> The NVRAM chip Gordon mentioned would show up in such an SOV.
>
> paul
>

Re: NVRAM resuscitation (Was Re: SPARCstation 20 with SCSI2SD)

[Paul Koning via cctalk]

> On Nov 28, 2018, at 9:43 AM, Ethan via cctalk  wrote:
> 
>> As an aside - once upon a time I worked for a company that made their own 
>> Sparc boards to fit inside a supercomputer and several of them were inside 
>> secure military/government establishments. Sometimes a board would fail and 
>> have to go back for a fix - and then the RTC/NVRAM chip had to be removed 
>> because - you know, those 64 bytes of battery backed RAM might just hold 
>> some state secret or something...
>> Fun days.
>> -Gordon
> 
> Surprised they knew about it!

One of the documents hardware engineers have to generate is a "Statement of 
Volatility" that lists every component in the system with persistent memory of 
any kind.  For each, it says what is in that memory, where it is located, and 
how (if it can contain anything like user data or configuration settings) it 
can be erased or removed.

The NVRAM chip Gordon mentioned would show up in such an SOV.

paul

Re: NVRAM resuscitation (Was Re: SPARCstation 20 with SCSI2SD)

[Ethan via cctalk]

As an aside - once upon a time I worked for a company that made their own 
Sparc boards to fit inside a supercomputer and several of them were inside 
secure military/government establishments. Sometimes a board would fail and 
have to go back for a fix - and then the RTC/NVRAM chip had to be removed 
because - you know, those 64 bytes of battery backed RAM might just hold some 
state secret or something...

Fun days.
-Gordon


Surprised they knew about it!


--
: Ethan O'Toole

Re: NVRAM resuscitation (Was Re: SPARCstation 20 with SCSI2SD)

[Gordon Henderson via cctalk]

As an aside - once upon a time I worked for a company that made their own 
Sparc boards to fit inside a supercomputer and several of them were inside 
secure military/government establishments. Sometimes a board would fail 
and have to go back for a fix - and then the RTC/NVRAM chip had to be 
removed because - you know, those 64 bytes of battery backed RAM might 
just hold some state secret or something...


Fun days.

-Gordon

Re: NVRAM resuscitation (Was Re: SPARCstation 20 with SCSI2SD)

[allison via cctalk]

On 11/27/2018 03:34 PM, Jeffrey S. Worley via cctalk wrote:
> When I bought that Sparcstation 4/330 at Computer Parts Barn, the 48T02
> was one of the problems with it.  The chip looks like a piggieback rom
> encapsulated in epoxy.
>
> I was not reinventing the wheel at the time, I think, because it was
> the year 2000 or so, but I looked for a replacement and found them hard
> to come by.  So, knowing the battery was most likely the fault, I went
> about fixing that bit.
>
> The battery accounts for the high profile.  You do not have to cut the
> entire doggone batter off, the terminals are at one side, iirc, the
> right-hand side if the notch is to your left.  It is high on the epoxy,
> so all you need do is cut down an eighth of an inch in that region,
> just shave that top edge until you expose the battery terminals.  I
> forget how I determined the polarity of them, perhaps I plugged it into
> the board after and tested the terminals for power, but all you do once
> you've exposed the terminals is solder a power and a ground wire to
> them and attach a 3volt battery.  I used a pack with two AA's, in a
> case so they are user-replaceable.  They are probably STILL keeping
> time in that machine, wherever DHS took it and my MEGA ST4 and DG
> MV4000/dc...  That's another story.
>
> So refurbishing these chips is a cakewalk, takes 15 minutes (the second
> time 'round), and will work til' doomsday.
>
> Best regards,
>
> Jeff
>
I take a very simple approach:


All the ones I've ever purchased were bad out of the box (NOS parts), so
much for china but they can be repaired too.

After removing it from the board...

I use a small magnet to locate the battery.  I use a sharp wood chisel
about .25 wide and carve the plastic down
to the battery then get under one edge.   Once metal is visible I clear
the plastic and pop it out.  The wires then
are easy to locate and I mount using Hot-melt glue a new holder for the
very common 2032.    Never had to
replace one of those and a few are pushing more than 12years.  The whole
mess takes less than a few minutes
to do where access the board and getting it off the board are the bigger
part of it.  Since I have a few NOS
(but dead) parts plus pulls from old CPU cards I rarely worry if the
existing one gets damaged as I have spares.
To me its not a big deal.

Allison

Re: NVRAM resuscitation (Was Re: SPARCstation 20 with SCSI2SD)

[systems_glitch via cctalk]

I'd modified them as Jeff described in the past, but having the repair
boards saves significant time when doing a bunch. It also allows
non-precision cuts, since it doesn't matter if you accidentally destroy the
old connections down to the IC body. It also results in a repaired module
with no battery-on-a-wire, but is still short enough to fit under SBus
cards for the machines that have NVRAM under card slots. Since the repair
boards come panelized in 2x5 grids, I can assemble 10 at a time, which
again, when you're doing a heap of NVRAMs, saves a lot of time.

Thanks,
Jonathan

On Tue, Nov 27, 2018 at 4:05 PM Alan Perry via cctalk 
wrote:

> One reason that I buy the new NVRAMs is that I keep failing at modifying
> them. Got the polarity wrong and fried one. I destroyed one cutting down
> to the terminals. I got one working, but have had problems convincing
> the battery to stay in place and not rip the leads off. There is a
> reason I am a software, not a hardware, guy :)
>
> alan
>
> On 11/27/18 12:34 PM, Jeffrey S. Worley via cctalk wrote:
> > When I bought that Sparcstation 4/330 at Computer Parts Barn, the 48T02
> > was one of the problems with it.  The chip looks like a piggieback rom
> > encapsulated in epoxy.
> >
> > I was not reinventing the wheel at the time, I think, because it was
> > the year 2000 or so, but I looked for a replacement and found them hard
> > to come by.  So, knowing the battery was most likely the fault, I went
> > about fixing that bit.
> >
> > The battery accounts for the high profile.  You do not have to cut the
> > entire doggone batter off, the terminals are at one side, iirc, the
> > right-hand side if the notch is to your left.  It is high on the epoxy,
> > so all you need do is cut down an eighth of an inch in that region,
> > just shave that top edge until you expose the battery terminals.  I
> > forget how I determined the polarity of them, perhaps I plugged it into
> > the board after and tested the terminals for power, but all you do once
> > you've exposed the terminals is solder a power and a ground wire to
> > them and attach a 3volt battery.  I used a pack with two AA's, in a
> > case so they are user-replaceable.  They are probably STILL keeping
> > time in that machine, wherever DHS took it and my MEGA ST4 and DG
> > MV4000/dc...  That's another story.
> >
> > So refurbishing these chips is a cakewalk, takes 15 minutes (the second
> > time 'round), and will work til' doomsday.
> >
> > Best regards,
> >
> > Jeff
> >
>
>

Re: NVRAM resuscitation (Was Re: SPARCstation 20 with SCSI2SD)

[Alan Perry via cctalk]

One reason that I buy the new NVRAMs is that I keep failing at modifying 
them. Got the polarity wrong and fried one. I destroyed one cutting down 
to the terminals. I got one working, but have had problems convincing 
the battery to stay in place and not rip the leads off. There is a 
reason I am a software, not a hardware, guy :)


alan

On 11/27/18 12:34 PM, Jeffrey S. Worley via cctalk wrote:

When I bought that Sparcstation 4/330 at Computer Parts Barn, the 48T02
was one of the problems with it.  The chip looks like a piggieback rom
encapsulated in epoxy.

I was not reinventing the wheel at the time, I think, because it was
the year 2000 or so, but I looked for a replacement and found them hard
to come by.  So, knowing the battery was most likely the fault, I went
about fixing that bit.

The battery accounts for the high profile.  You do not have to cut the
entire doggone batter off, the terminals are at one side, iirc, the
right-hand side if the notch is to your left.  It is high on the epoxy,
so all you need do is cut down an eighth of an inch in that region,
just shave that top edge until you expose the battery terminals.  I
forget how I determined the polarity of them, perhaps I plugged it into
the board after and tested the terminals for power, but all you do once
you've exposed the terminals is solder a power and a ground wire to
them and attach a 3volt battery.  I used a pack with two AA's, in a
case so they are user-replaceable.  They are probably STILL keeping
time in that machine, wherever DHS took it and my MEGA ST4 and DG
MV4000/dc...  That's another story.

So refurbishing these chips is a cakewalk, takes 15 minutes (the second
time 'round), and will work til' doomsday.

Best regards,

Jeff

NVRAM resuscitation (Was Re: SPARCstation 20 with SCSI2SD)

[Jeffrey S. Worley via cctalk]

When I bought that Sparcstation 4/330 at Computer Parts Barn, the 48T02
was one of the problems with it.  The chip looks like a piggieback rom
encapsulated in epoxy.

I was not reinventing the wheel at the time, I think, because it was
the year 2000 or so, but I looked for a replacement and found them hard
to come by.  So, knowing the battery was most likely the fault, I went
about fixing that bit.

The battery accounts for the high profile.  You do not have to cut the
entire doggone batter off, the terminals are at one side, iirc, the
right-hand side if the notch is to your left.  It is high on the epoxy,
so all you need do is cut down an eighth of an inch in that region,
just shave that top edge until you expose the battery terminals.  I
forget how I determined the polarity of them, perhaps I plugged it into
the board after and tested the terminals for power, but all you do once
you've exposed the terminals is solder a power and a ground wire to
them and attach a 3volt battery.  I used a pack with two AA's, in a
case so they are user-replaceable.  They are probably STILL keeping
time in that machine, wherever DHS took it and my MEGA ST4 and DG
MV4000/dc...  That's another story.

So refurbishing these chips is a cakewalk, takes 15 minutes (the second
time 'round), and will work til' doomsday.

Best regards,

Jeff

Re: SPARCstation 20 with SCSI2SD

[Ethan Dicks via cctalk]

On Tue, Nov 27, 2018 at 10:44 AM Kyle Owen via cctalk
 wrote:
> Does anyone have a 3/60 hard disk image of SunOS 3.4 or 3.5, by chance?

I'll check.  I was playing with TME earlier this year but I'm
forgetting which version of SunOS I was working on.  I had a need to
test out some ancient SunOS m68k binaries (and was ultimately
successful).  It might be 4.1.1, which might not help you so much.

I'm on the road this week so I won't have access to that platform
until the weekend, but I will check when I get home.

-ethan

Re: SPARCstation 20 with SCSI2SD

[Kyle Owen via cctalk]

On Sun, Nov 25, 2018 at 9:50 PM  wrote:

>
> Ah cool. I was at a friend's brother's house on a work trip out to Silicon
> Valley. One of his friends was there, with something amazing running in
> QEMU. It was a work in progress, but he said that there were a lot of
> issues because QEMU was too accurate in emulating the MIPS procressors and
> in addition to this, there was bugs in his former employer's hardware that
> had software work-arounds in the real OS. So when trying to run that OS on
> the emulated system the accuracy worked against him.
>

Yikes! I've been thinking, since the Previous (NeXT) emulator works so
well, what would it take to turn it into a Sun emulator? I haven't looked
at the Previous source yet, but it seems like that would be a good starting
point.

>
> > Trying to build MazeWar results in:
> >
> > ld: Undefined symbol
> >   ___bb_init_func
> >   DREG_SEG
> > *** Error code 2
> >
> > Not sure yet what to look for, but the source does say it was tested on
> > SunOS 3.1 and 3.4. So, I am trying to compile it on something a bit
> later.
>
> Sun compiler I assume and not a GCC?
>

Yes, the Sun compiler. At some point, I'll see if I can get my 3/60 booted,
but I'm lacking the right SCSI cable, I think. I also don't know how well
SCSI2SD will work emulating a streaming tape device, if at all.

Does anyone have a 3/60 hard disk image of SunOS 3.4 or 3.5, by chance?

Thanks,

Kyle

Re: SPARCstation 20 with SCSI2SD

[systems_glitch via cctalk]

For fully potted parts like the 48T59, I make four cuts along the sides of
the encapsulation, on the short ends I cut until I hit metal (pins coming
up from the IC to the crystal/battery). On the long ends I just cut deep
enough to get through the pot shell and into the potting compound a little.
Then I put a small chisel or large screwdriver in one of the cuts on the
short ends, and strike it with a small ball peen hammer. This will usually
split the encapsulation right off, but sometimes you have to flip it over
and do the same on the other short end.

I probably need to do a writeup on fully potted parts, like the 48T59 and
DS1287.

Thanks,
Jonathan

On Tue, Nov 27, 2018 at 6:52 AM Al Kossow via cctalk 
wrote:

>
>
> On 11/26/18 2:42 PM, systems_glitch via cctalk wrote:
> > I'm not sure, I don't personally see it as something worthwhile to
> > investigate when you can just rebuild the old NVRAMs.
>
> What is the best way to decap 28 pin parts? 24-pin ones come apart pretty
> easily but they don't leave a gap on the 28 pin ones.
>
>
>

Re: SPARCstation 20 with SCSI2SD

[Al Kossow via cctalk]

On 11/26/18 2:42 PM, systems_glitch via cctalk wrote:
> I'm not sure, I don't personally see it as something worthwhile to
> investigate when you can just rebuild the old NVRAMs.

What is the best way to decap 28 pin parts? 24-pin ones come apart pretty
easily but they don't leave a gap on the 28 pin ones.

Re: SPARCstation 20 with SCSI2SD

[systems_glitch via cctalk]

I'm not sure, I don't personally see it as something worthwhile to
investigate when you can just rebuild the old NVRAMs. Even if you do use a
SNAPHAT type replacement, you're still stuck with proprietary batteries
that will one day no longer be made, versus an extremely common CR1225
cell. I've made total replacements for NVRAMs that are not easily rebuilt,
such as the Dallas DS1244:

http://www.glitchwrks.com/2018/03/17/gw-1244-1

But, that's a lot more effort and expense than just sawing the top off a
dead 48T02, gluing on one of my repair boards, and soldering the leads :P

Thanks,
Jonathan

On Mon, Nov 26, 2018 at 5:40 PM  wrote:

> > Also, to anyone buying NVRAMs on eBay, don't expect anything from China
> to
> > actually be new NVRAMs. I've bought a bunch to disassemble, in the course
>
> Are any of the SMD NVRAMs with the battery caps compatible? Throw them on
> a DIP to SOIC PCB?
>
> - Ethan
>
>
> --
> : Ethan O'Toole
>
>
>

Re: SPARCstation 20 with SCSI2SD

[Ethan via cctalk]

Also, to anyone buying NVRAMs on eBay, don't expect anything from China to
actually be new NVRAMs. I've bought a bunch to disassemble, in the course


Are any of the SMD NVRAMs with the battery caps compatible? Throw them on 
a DIP to SOIC PCB?


- Ethan


--
: Ethan O'Toole

Re: SPARCstation 20 with SCSI2SD

[systems_glitch via cctalk]

> Don't have any spare modules? What happened to the half dozen that I sent
you? :)

In the queue somewhere! They'll likely go to replace the modules I'd stolen
from other machines over the years, as I get around to fixing them.

Also, to anyone buying NVRAMs on eBay, don't expect anything from China to
actually be new NVRAMs. I've bought a bunch to disassemble, in the course
of making repair boards for a number of different NVRAMs/RTCs, and every
single one has been a relabel. All had low battery voltages, on the few
where I actually totally destroyed the encapsulation to examine the
innards, the batteries often carried dates 10+ years old, even though the
outside markings suggested it was a year or two old. Not that fakes/remarks
from China should be a surprise.

Thanks,
Jonathan


On Mon, Nov 26, 2018 at 5:20 PM Alan Perry via cctalk 
wrote:

>
>
> On 11/26/18 2:08 PM, systems_glitch wrote:
> >
> >
> > I don't have any spare modules to rebuild, so I don't have premade
> > replacements up at the moment. I've been rebuilding them for people
> > when they send in their dead modules, but I'd guess most people here
> > can do the rebuild themselves, time permitting. I wouldn't cut into
> > the encapsulation with a powered tool like a Dremel, unless you're
> > going to wear a face mask. I use a hacksaw with Lenox fine kerf
> > blades. Any blade will do if you're only rebuilding a few NVRAMs.
> >
> >
> Don't have any spare modules? What happened to the half dozen that I
> sent you? :)
>
> alan
>
> P.S. Out of my dozen Sun systems, almost all of them are using new IDPROMs.
>
>
>

Re: SPARCstation 20 with SCSI2SD

[Alan Perry via cctalk]

On 11/26/18 2:08 PM, systems_glitch wrote:



I don't have any spare modules to rebuild, so I don't have premade 
replacements up at the moment. I've been rebuilding them for people 
when they send in their dead modules, but I'd guess most people here 
can do the rebuild themselves, time permitting. I wouldn't cut into 
the encapsulation with a powered tool like a Dremel, unless you're 
going to wear a face mask. I use a hacksaw with Lenox fine kerf 
blades. Any blade will do if you're only rebuilding a few NVRAMs.



Don't have any spare modules? What happened to the half dozen that I 
sent you? :)


alan

P.S. Out of my dozen Sun systems, almost all of them are using new IDPROMs.

Re: SPARCstation 20 with SCSI2SD

[systems_glitch via cctalk]

They're still made, but the new ones don't always work in place of the old
ones -- not 100% anyway. It's been my experience that, on sun4c and sun4m,
new 48T02s and 48T08s aren't 100% compatible. I've mentioned others'
suggestions on what the differences are in my Tindie listings, and on the
writeup on my site. That's why I designed the rebuild modules I've got
available, I had around 50 48T02s to process! Writeup here:

http://www.glitchwrks.com/2017/08/01/gw-48t02-1

(it's for the 48T02, but the process is the same...just the GW-48T08-1 is a
little longer)

The "not 100% compatible" symptom is that the clock fails power-on
diagnostics, and some machines will drop to OpenBoot/firmware monitor
prompt when that happens. NVRAM settings will be retained, but the clock
may or may not run, and some machines won't auto-boot.

I don't have any spare modules to rebuild, so I don't have premade
replacements up at the moment. I've been rebuilding them for people when
they send in their dead modules, but I'd guess most people here can do the
rebuild themselves, time permitting. I wouldn't cut into the encapsulation
with a powered tool like a Dremel, unless you're going to wear a face mask.
I use a hacksaw with Lenox fine kerf blades. Any blade will do if you're
only rebuilding a few NVRAMs.

Thanks,
Jonathan

On Sun, Nov 25, 2018 at 11:30 PM Alan Perry via cctalk <
cctalk@classiccmp.org> wrote:

>
>
> On 11/25/18 7:49 PM, Ethan via cctalk wrote:
> >
> >
> >> The NVRAM is totally dead; I've been reloading the IDPROM contents each
> >> time. I've already ordered replacement NVRAMs from China; we'll see how
> >> they do. Otherwise, I'll be going with the filing/coin cell trick.
> >
> > Interesting. Are they no longer made? I should get one for my Voyager.
> >
> They are still made. I usually get M48T08s or M48T18s from Mouser.
>
> In the long run, it is probably a good idea to mod the IDPROM to use an
> external, replaceable battery, Glitch Works makes a board that one can
> solder on to do that
> (
> https://www.tindie.com/products/glitchwrks/gw-48t08-1-repair-board-module/
> ).
>
> alan
>
>

Re: SPARCstation 20 with SCSI2SD

[Alan Perry via cctalk]

On 11/25/18 7:49 PM, Ethan via cctalk wrote:




The NVRAM is totally dead; I've been reloading the IDPROM contents each
time. I've already ordered replacement NVRAMs from China; we'll see how
they do. Otherwise, I'll be going with the filing/coin cell trick.


Interesting. Are they no longer made? I should get one for my Voyager.


They are still made. I usually get M48T08s or M48T18s from Mouser.

In the long run, it is probably a good idea to mod the IDPROM to use an 
external, replaceable battery, Glitch Works makes a board that one can 
solder on to do that 
(https://www.tindie.com/products/glitchwrks/gw-48t08-1-repair-board-module/).


alan

Re: SPARCstation 20 with SCSI2SD

[Ethan via cctalk]

I was hoping to just emulate it for now to avoid potentially bad hardware,
but seems like I need to use the real hardware to avoid potentially bad
software! :)


Ah cool. I was at a friend's brother's house on a work trip out to Silicon 
Valley. One of his friends was there, with something amazing running in 
QEMU. It was a work in progress, but he said that there were a lot of 
issues because QEMU was too accurate in emulating the MIPS procressors and 
in addition to this, there was bugs in his former employer's hardware that 
had software work-arounds in the real OS. So when trying to run that OS on 
the emulated system the accuracy worked against him.



The NVRAM is totally dead; I've been reloading the IDPROM contents each
time. I've already ordered replacement NVRAMs from China; we'll see how
they do. Otherwise, I'll be going with the filing/coin cell trick.


Interesting. Are they no longer made? I should get one for my Voyager.


Not sure; but, I can say, I've got SunOS 4.1.3 finally installed, and am
now looking at a sparse SunView desktop.


Very cool


Trying to build MazeWar results in:

ld: Undefined symbol
  ___bb_init_func
  DREG_SEG
*** Error code 2

Not sure yet what to look for, but the source does say it was tested on
SunOS 3.1 and 3.4. So, I am trying to compile it on something a bit later.


Sun compiler I assume and not a GCC?


--
: Ethan O'Toole

Re: SPARCstation 20 with SCSI2SD

[Kyle Owen via cctalk]

On Sun, Nov 25, 2018 at 9:14 PM  wrote:

> Since you said QEMU, you are emulating this? If on the real hardware, is
>
the NVRAM memory dead? Looks like it doesn't know what kind of hardware it
> is. Real hardware will loose nvram battery and need to be replaced and
> reprogrammed, or you can file it down and jumper a battery into it.
>

I was hoping to just emulate it for now to avoid potentially bad hardware,
but seems like I need to use the real hardware to avoid potentially bad
software! :)

The NVRAM is totally dead; I've been reloading the IDPROM contents each
time. I've already ordered replacement NVRAMs from China; we'll see how
they do. Otherwise, I'll be going with the filing/coin cell trick.

There is also probably a bunch of environment variables in the NVRAM as to
> the CD-ROM SCSI path and OS scsi path and stuff on the Sun. It's been a
> long time since Sun boxes for me, so unfortuantely I've forgotten a lot of
> it. But if it's all reset or non-existant it could be a source of issues
> if my memory is right (It definitely is on SGI hardware.)
>

Not sure; but, I can say, I've got SunOS 4.1.3 finally installed, and am
now looking at a sparse SunView desktop.

Trying to build MazeWar results in:

ld: Undefined symbol
   ___bb_init_func
   DREG_SEG
*** Error code 2

Not sure yet what to look for, but the source does say it was tested on
SunOS 3.1 and 3.4. So, I am trying to compile it on something a bit later.

Thanks,

Kyle

Re: SPARCstation 20 with SCSI2SD

[Ethan via cctalk]

Well, got the last problem solved rather quickly: I tried using 512 byte
sectors for the emulated CDROM instead of SCSI2SD's default of 2048 for a
CDROM, and that did the trick. Working my way through the SunOS 4.1.3
installation process now on the SS-20.


Was just thinking the 512 byte thing might be an issue. Early Toshiba 
Cd-ROMs had a solder jumper that would switch this, and is was needed for 
some early systems. SGI Indigo R3000 and below was one, and I guess Sun 
was another. I think NeXT also requires the 512 byte block CD-ROM.


Since you said QEMU, you are emulating this? If on the real hardware, is 
the NVRAM memory dead? Looks like it doesn't know what kind of hardware it 
is. Real hardware will loose nvram battery and need to be replaced and 
reprogrammed, or you can file it down and jumper a battery into it.


There is also probably a bunch of environment variables in the NVRAM as to 
the CD-ROM SCSI path and OS scsi path and stuff on the Sun. It's been a 
long time since Sun boxes for me, so unfortuantely I've forgotten a lot of 
it. But if it's all reset or non-existant it could be a source of issues 
if my memory is right (It definitely is on SGI hardware.)



--
: Ethan O'Toole

Re: SPARCstation 20 with SCSI2SD

[Kyle Owen via cctalk]

Well, got the last problem solved rather quickly: I tried using 512 byte
sectors for the emulated CDROM instead of SCSI2SD's default of 2048 for a
CDROM, and that did the trick. Working my way through the SunOS 4.1.3
installation process now on the SS-20.

>
If anyone has some advice on how to get QEMU or TME working, I'd still be
all ears.

Thanks,

Kyle