Nekonomicon - 4D/240GTX troubleshooting

jan-jaap
Old Salt
Who joined June 17, 2004, 11:35 a.m.
and authored 2689 notes

Wrote the following at Dec. 23, 2009, 6:31 a.m...

Here's what I have:
* The 4D/380 has an MC2 030-0117-010 rev A, with 32*8MB SIMMs installed.
* The 4D/440 has an MC2 030-0117-034 rev C, with 32*8MB SIMMs installed.

MC2's in storage:
1 * 030-0117-034 rev B (with 32*2MB SIMMs installed).
2 * 030-0117-026 rev A.
1 * 030-0117-009 rev A.

So, my both MC2s with high density RAM are a newer rev. than yours. Unfortunately, this doesn't offer conclusive proof whether the older card is should support high density RAM.

_________________
Now this is a deep dark secret, so everybody keep it quiet

It turns out that when reset, the WD33C93 defaults to a SCSI ID of 0, and it was simpler to leave it that way... -- Dave Olson, in comp.sys.sgi
Currently in commercial service:

(2x)

In the museum: almost every MIPS/IRIX system.

zuluchas
Big Fan
Who joined June 25, 2008, 10:41 a.m.
and authored 161 notes

Wrote the following at Dec. 23, 2009, 9:03 a.m...

jan-jaap wrote:

MC2's in storage:
1 * 030-0117-034 rev B (with 32*2MB SIMMs installed).
2 * 030-0117-026 rev A.
1 * 030-0117-009 rev A.

Is there any chance you might be able to test one or more of the MC2s in storage with 8MB simms in ony of the 4d systems? We've got a great selection of boards to work with here -- now I'm really excited to see if we can pin this down to board numbers and/or PROM revisions!

_________________
:Onyx2RM:

jan-jaap
Old Salt
Who joined June 17, 2004, 11:35 a.m.
and authored 2689 notes

Wrote the following at Dec. 24, 2009, 3:15 a.m...

I can do that, but I'm not sure there's a lot to be learned from this exercise:

* If 8MB SIMM support was added to some MC2 rev, it must have been rev -010 or earlier. After all, it works in the Predator (030-0117-010 rev A). So the -034 and -026 boards will support it as well.

* The earliest specimen I have is the -009 board in storage. I could try that one, but if it works, it still does not give conclusive proof whether your problem is due to your even older MC2 rev, or your older IP5/IO2 PROM revision. Only if the -009 board works with 2MB SIMMs but not 8MB SIMMs do we learn anything.

Something else: "This old SGI" says the SIMMs have to be installed in banks of 4 . You did not mix two 2MB and two 8MB SIMMs in one bank, did you? Oh, and unlike what "This old SGI" may suggest, an MC3 belongs in an Onyx, not in a PowerSeries

I have dumps of the IP5 and the IO2 PROMs, but these were created by dumping the relevant address range on the system itself, not by pulling the EPROM chips out and reading them in in an EPROM burner. So, I have one file for the IP5 PROM but in reality it's 4 chips and I wouldn't know how to split the data and create 4 new chips. Same for he IO2 PROM.

_________________
Now this is a deep dark secret, so everybody keep it quiet

It turns out that when reset, the WD33C93 defaults to a SCSI ID of 0, and it was simpler to leave it that way... -- Dave Olson, in comp.sys.sgi
Currently in commercial service:

(2x)

In the museum: almost every MIPS/IRIX system.

zuluchas
Big Fan
Who joined June 25, 2008, 10:41 a.m.
and authored 161 notes

Wrote the following at Dec. 24, 2009, 1:34 p.m...

jan-jaap wrote:

I can do that, but I'm not sure there's a lot to be learned from this exercise:

* If 8MB SIMM support was added to some MC2 rev, it must have been rev -010 or earlier. After all, it works in the Predator (030-0117-010 rev A). So the -034 and -026 boards will support it as well.

Ah, okay, well at least we have a baseline (-010).

Quote:

* The earliest specimen I have is the -009 board in storage. I could try that one, but if it works, it still does not give conclusive proof whether your problem is due to your even older MC2 rev, or your older IP5/IO2 PROM revision. Only if the -009 board works with 2MB SIMMs but not 8MB SIMMs do we learn anything.

True, although I was thinking more in terms of if you were still interested in sending me one of them -- it'd be good to know that they did work with 8mb simms so I could then diagnose the issue as either a board or a PROM rev problem.

Quote:

Something else: "This old SGI" says the SIMMs have to be installed in banks of 4 . You did not mix two 2MB and two 8MB SIMMs in one bank, did you? Oh, and unlike what "This old SGI" may suggest, an MC3 belongs in an Onyx, not in a PowerSeries

Yes, they were installed in sets of 4. I first tried them with 8 then with 12. They were installed in matching quads, starting from the side of the board with status LEDs, as described in "this old sgi." With eight it, it showed 16mb; with 12 it showed 24mb. So it's proportional to the number of simms, but 1/4th the total expected! No mixing of 2mb and 8mb modules -- just straight 8mb. Yes, the MC3 reference is a bit confusing.

Quote:

I have dumps of the IP5 and the IO2 PROMs, but these were created by dumping the relevant address range on the system itself, not by pulling the EPROM chips out and reading them in in an EPROM burner. So, I have one file for the IP5 PROM but in reality it's 4 chips and I wouldn't know how to split the data and create 4 new chips. Same for he IO2 PROM.

Yes, I have a feeling this is likely to be tricky without some specialized hardware and several posts to nekochan! More of a long-term project, perhaps? I do have an IO3, so maybe it would be worth trying the IP7+MC2+IO3 to see what happens?

_________________
:Onyx2RM:

Gerhard.Lenerz
Enthusiast
Who joined Jan. 15, 2004, 2:20 a.m.
and authored 280 notes

Wrote the following at Dec. 27, 2009, 1:15 a.m...

Maybe I can add some observations. I have one MC2 with 8MB SIMMs in use in a IP15/IO3 machine. That one is a "030-0117-010 Rev A".

I do have earlier boards in my collection that are also equipped with 8MB SIMMs, these are "030-0117-003 Rev B" and "030-0117-004 Rev A". So far I haven't tested them but I got them this way so I hope this is a valid configuration.

There are also a few even older MC2 boards but back then I didn't write down the type of SIMMs installed.

If it provides any insight I can check if a machine comes up nicely with one of the old rev MC2 installed.

Gerhard

_________________
www.sgistuff.net - SGI info since 2001

:4D70G:

zuluchas
Big Fan
Who joined June 25, 2008, 10:41 a.m.
and authored 161 notes

Wrote the following at Dec. 27, 2009, 5:07 a.m...

Gerhard.Lenerz wrote:

If it provides any insight I can check if a machine comes up nicely with one of the old rev MC2 installed.

Yes, thank you -- that would be great! Mine is -001, so really old!

_________________
:Onyx2RM:

Gerhard.Lenerz
Enthusiast
Who joined Jan. 15, 2004, 2:20 a.m.
and authored 280 notes

Wrote the following at Dec. 27, 2009, 8:45 a.m...

I'll see what I can do, according to my list I have at least two -001 MC2 with unknown memory installed. Only problem is that I'm back at my own flat now while most of the IRIS 4D stuff is back at my parents house. I've seen the thread before my Christmas holiday but failed to think about the possibilities earlier. Anyway, if noone steps in I'll give it a try next time I'm back home.

_________________
www.sgistuff.net - SGI info since 2001

:4D70G:

zuluchas
Big Fan
Who joined June 25, 2008, 10:41 a.m.
and authored 161 notes

Wrote the following at Jan. 26, 2010, 10:39 a.m...

A few updates:

The system is not up and running as a 4D/240VGX and IRIX 3.3.2! The SCSI bus issue was due to a bad jumper on the SCSI ID pins of one drive, it turned out. I'm still doing some investigation on the stackable drive modules.

For those that might be interested:
I ended up running the 5.3 diags on the GTX and it appears that the GM2 board may be the culprit for this particular GTX issue:

Code:

Mon Jul 17 11:26:49 PDT 1995

INFO:   (200)   GM2 Memory test:  Starting Pixel DMA test (about 90 seconds)

INFO:   (200)   GM2 Memory test:  Host to GM to Host Memory DMA test PASSED

INFO:   (311)   PP<-->GM Handshake test: Zero, Marching 1

INFO:   (311)   PP<-->GM Handshake test: FF and Marching 0

INFO:   (312)   PP Branch test: PP branch test: Zero and Marching 1

INFO:   (312)   PP Branch test: PP branch test: Marching 0

INFO:   (313)   PP Stack test: PP stack level 1 test: Zero and Marching 1

INFO:   (313)   PP Stack test: PP stack level 1 test: Marching 0

INFO:   (313)   PP Stack test: PP stack level 2 test: Zero and Marching 1

INFO:   (313)   PP Stack test: PP stack level 2 test: Marching 0

INFO:   (317)   PP DIAG test: GM WC Reg test

INFO:   (317)   PP DIAG test: Source bus tests

INFO:   (317)   PP DIAG test: PP ALU tests

INFO:   (317)   PP DIAG test: Wordcount tests

INFO:   (317)   PP DIAG test: Condition tests

INFO:   (317)   PP DIAG test: Vertex pointer test

INFO:   (315)   PP SRAM test: OK: PP sram[0] write

INFO:   (315)   PP SRAM test: OK: PP sram[0] read

INFO:   (315)   PP SRAM test: OK: PP sram[1] write

INFO:   (315)   PP SRAM test: OK: PP sram[1] read

INFO:   (315)   PP SRAM test: Beginning slow SRAM tests

INFO:   (315)   PP SRAM test: Slow test: Begin marching 1 from low order bit

INFO:   (315)   PP SRAM test: Slow test: Begin marching 1 from high order bit

INFO:   (315)   PP SRAM test: Slow test: Begin marching 0 from low order bit

INFO:   (315)   PP SRAM test: Slow test: Begin marching 0 from high order bit

INFO:   (350)   GM2 EP Reset test

INFO:   (350)   GM2 EP Sequencer tests

INFO:   (350)   GM2 EP Data test

INFO:   (350)   GM2 EP Pixelbus test: Testing SP command sanity

INFO:   (350)   GM2 EP Pixelbus test: Testing Y path on pixel bus

INFO:   (350)   GM2 EP Pixelbus test: writing Y path

INFO:   (350)   GM2 EP Pixelbus test: reading Y path

INFO:   (350)   GM2 EP Pixelbus test: Testing X path

INFO:   (350)   GM2 EP Pixelbus test: writing X path

INFO:   (350)   GM2 EP Pixelbus test: reading X path

ERROR:   (350)   GM2 EP Pixelbus test: SP X error: x = 2, y = 0, exp 0x00000002  rcv 0x00000001

07/17/95(11:29:45)

...

(lots of these errors)

Code:

...

ERROR:   (350)   GM2 EP Pixelbus test: SP X error: x = 1278, y = 0, exp 0x000004FE  rcv 0x0000027E

07/17/95(11:30:24)

INFO:   (350)   GM2 EP Pixelbus test: Testing line stipple

ERROR:   (350)   GM2 EP Pixelbus test: Line stipple error: pos 32, exp 0x00000000  rcv 0xFFFFFFFF

07/17/95(11:30:24)

...

(lots of these errors, too, then a lot of successes on other parts of the gfx subsys, then ending with)

Code:

...

CompLoop datecode: February 26, 1992

CompLoop: GE4 has NEW WEITEK 3332s installed

[1] 887

CompLoop: no alpha channel detected

/usr/tmp/grid /usr/diags/gold/nagrid.n differ: char 54, line 3

CompGrid: FAILED

BAD  - Span 1: ffffec40 fffffb04 fffffb04 fffffb04

GOOD - Span 1: bfffec40 fbfffb04 fbfffb04 fbfffb04

BAD  - Span 2: fffffb04 fffffb04 fffffb04 ffffec40

GOOD - Span 2: bfffec40 2dfffad2 c9fffb36 fbfffb04

BAD  - Span 3: 6d6718c0 5dcce1cc 5e334478 7a0004b3

GOOD - Span 3: bfffec40 fbfffb04 fbfffb04 fbfffb04

/usr/tmp/rcip /usr/diags/gold/narcip.n differ: char 98, line 4

CompRecip: FAILED

BAD  - Span 2: ec67d317 3d62255c 75e0fe0d 8d1460ad

GOOD - Span 2: 90d9d691 f19026d2 3018dc93 7a2e630d

BAD  - Span 3: f2cbc7fb 9f9d5e48 f7a93549 a544c35c

GOOD - Span 3: 9336589d f5ea5c60 23704c9e 7f855076

/usr/tmp/grid /usr/diags/gold/nagrid.n differ: char 54, line 3

CompGrid: FAILED

BAD  - Span 1: ffffec40 fffffb04 fffffb04 fffffb04

GOOD - Span 1: bfffec40 fbfffb04 fbfffb04 fbfffb04

BAD  - Span 2: fffffb04 fffffb04 fffffb04 ffffec40

GOOD - Span 2: bfffec40 2dfffad2 c9fffb36 fbfffb04

BAD  - Span 3: 2f6712e1 31334746 2799ab31 67ccd20a

GOOD - Span 3: bfffec40 fbfffb04 fbfffb04 fbfffb04

/usr/tmp/rcip /usr/diags/gold/narcip.n differ: char 98, line 4

CompRecip: FAILED

BAD  - Span 2: ec67d317 3d62255c 75e0fe0d 8d1460ad

GOOD - Span 2: 90d9d691 f19026d2 3018dc93 7a2e630d

BAD  - Span 3: ea1c2c1c 9ae34191 f3c1e932 a0e8efd1

GOOD - Span 3: 9336589d f5ea5c60 23704c9e 7f855076

/usr/tmp/grid /usr/diags/gold/nagrid.n differ: char 54, line 3

CompGrid: FAILED

BAD  - Span 1: ffffec40 fffffb04 fffffb04 fffffb04

GOOD - Span 1: bfffec40 fbfffb04 fbfffb04 fbfffb04

BAD  - Span 2: fffffb04 fffffb04 fffffb04 ffffec40

GOOD - Span 2: bfffec40 2dfffad2 c9fffb36 fbfffb04

BAD  - Span 3: 3d33df7d 3f00153f 34001184 7300051d

GOOD - Span 3: bfffec40 fbfffb04 fbfffb04 fbfffb04

/usr/tmp/rcip /usr/diags/gold/narcip.n differ: char 98, line 4

CompRecip: FAILED

BAD  - Span 2: ec67d317 3d62255c 75e0fe0d 8d1460ad

GOOD - Span 2: 90d9d691 f19026d2 3018dc93 7a2e630d

BAD  - Span 3: eeff1700 a0da7109 f6af7e18 a7bbe0f8

GOOD - Span 3: 9336589d f5ea5c60 23704c9e 7f855076

/usr/tmp/grid /usr/diags/gold/nagrid.n differ: char 54, line 3

CompGrid: FAILED

BAD  - Span 1: ffffec40 fffffb04 fffffb04 fffffb04

GOOD - Span 1: bfffec40 fbfffb04 fbfffb04 fbfffb04

BAD  - Span 2: fffffb04 fffffb04 fffffb04 ffffec40

GOOD - Span 2: bfffec40 2dfffad2 c9fffb36 fbfffb04

BAD  - Span 3: 57671234 2433461d 19667779 543337d5

GOOD - Span 3: bfffec40 fbfffb04 fbfffb04 fbfffb04

/usr/tmp/rcip /usr/diags/gold/narcip.n differ: char 98, line 4

CompRecip: FAILED

BAD  - Span 2: ec67d317 3d62255c 75e0fe0d 8d1460ad

GOOD - Span 2: 90d9d691 f19026d2 3018dc93 7a2e630d

BAD  - Span 3: deb6caf3 839c4ce0 e55e0ae8 8bce5568

GOOD - Span 3: 9336589d f5ea5c60 23704c9e 7f855076

/usr/tmp/grid /usr/diags/gold/nagrid.n differ: char 54, line 3

CompGrid: FAILED

BAD  - Span 1: ffffec40 fffffb04 fffffb04 fffffb04

GOOD - Span 1: bfffec40 fbfffb04 fbfffb04 fbfffb04

BAD  - Span 2: fffffb04 fffffb04 fffffb04 ffffec40

GOOD - Span 2: bfffec40 2dfffad2 c9fffb36 fbfffb04

BAD  - Span 3: 2d9a4608 2ecce041 2fccde55 60ccd1fc

GOOD - Span 3: bfffec40 fbfffb04 fbfffb04 fbfffb04

/usr/tmp/rcip /usr/diags/gold/narcip.n differ: char 98, line 4

CompRecip: FAILED

BAD  - Span 2: ec67d317 3d62255c 75e0fe0d 8d1460ad

GOOD - Span 2: 90d9d691 f19026d2 3018dc93 7a2e630d

BAD  - Span 3: db054aa3 7fab3dea e4b94c9f 86a7d66c

GOOD - Span 3: 9336589d f5ea5c60 23704c9e 7f855076

CompLoop: GRID SCREEN COMPARE   passed 0 times

CompLoop: GRID SCREEN COMPARE   failed 5 times

CompLoop: RECIP SCREEN COMPARE  passed 0 times

CompLoop: RECIP SCREEN COMPARE  failed 5 times

CompLoop: pass 1  completed.

End of Full GTX Subsystem Test

Mon Jul 17 12:12:35 PDT 1995

Attachment:

File comment: This is that the demos included in the 5.3 diags looked like.

2010-01-23 00.30.39.jpg [ 680.43 KiB | Viewed 49 times ]

Thanks for all the help so far!

_________________
:Onyx2RM:

zuluchas
Big Fan
Who joined June 25, 2008, 10:41 a.m.
and authored 161 notes

Wrote the following at Jan. 26, 2010, 11:04 a.m...

So the next big item is probably replacing the NVRAM battery on the IO2:

jan-jaap wrote:

Wow, I've never seen a PowerSeries with a dead NVRAM battery, but it seems it can happen after all.
The battery is on the the IO2.

What am I looking for on the IO2? Is it something similar to the combination NVRAM+battery sandwich mentioned here? viewtopic.php?f=3&t=12137

There's a tall sandwiched component at position L2J0 labeled Sony CXK5816PS-12L, but underneath it is just another chip -- Dallas DS1216-8912D3:

Attachment:

2010-01-26 13.16.19.jpg [ 510.98 KiB | Viewed 42 times ]

Nothing else on the board looks large/tall enough to hide a battery underneath! Any thoughts on where it might be hiding?

Attachment:

2010-01-26 13.16.41.jpg [ 550.25 KiB | Viewed 42 times ]

Also, once we do find the battery, what do folks suggest I replace it/them with these days?

Thanks!

_________________
:Onyx2RM:

skywriter
Old Salt
Who joined March 14, 2003, 6:22 a.m.
and authored 2275 notes

Wrote the following at Jan. 26, 2010, 1:07 p.m...

the dallas carrier is the battery. they either come like that or the battery is embedded in with the ram. dallas is the vendor that make those battery backed rams in that era.

those EPROMS are generally even/odd address pairs. the LSB of the address is used as a part select. 4 parts would mean two even/odd pairs.

_________________
I love my iPad!!!

zuluchas
Big Fan
Who joined June 25, 2008, 10:41 a.m.
and authored 161 notes

Wrote the following at Jan. 26, 2010, 1:58 p.m...

skywriter wrote:

the dallas carrier is the battery. they either come like that or the battery is embedded in with the ram. dallas is the vendor that make those battery backed rams in that era.

those EPROMS are generally even/odd address pairs. the LSB of the address is used as a part select. 4 parts would mean two even/odd pairs.

Would it be a better idea to try to find a replacement carrier with new battery (do such things exist now?) or to solder in some pin sockets and connect an external battery? If the latter, what spec battery am I looking for? Here's a close-up of the dallas chip and carrier:

Attachment:

2010-01-26 15.57.30.jpg [ 515.02 KiB | Viewed 151 times ]

I've been pretty ginger with it, not wanting to do any serious damage to the carrier, but I don't see how to get it apart. It looks glued together or at least very, very snug. Soldering pin sockets on should be pretty easy, though, as long as I know exactly where to put them!

Attachment:

2010-01-26 15.47.03.jpg [ 514.63 KiB | Viewed 151 times ]

_________________
:Onyx2RM:

skywriter
Old Salt
Who joined March 14, 2003, 6:22 a.m.
and authored 2275 notes

Wrote the following at Jan. 26, 2010, 2:14 p.m...

they're only spec for ten year usually.

_________________
I love my iPad!!!

SAQ
Old Salt
Who joined July 19, 2006, 8:37 a.m.
and authored 3874 notes

Wrote the following at Jan. 26, 2010, 5:09 p.m...

Poke around on the pins with a voltmeter. There should be a little something still there.

_________________
Damn the torpedoes, full speed ahead!

:Indigo:

rscottdrysdale
Journeyman
Who joined Jan. 19, 2010, 2:45 p.m.
and authored 42 notes

Wrote the following at Jan. 26, 2010, 5:51 p.m...

i've never played with that particular dallas chip, but have done the external battery hack to to the type doesn't have the socket on top, but a square of black epoxy which conceals the battery. on that model, there is no circuit board - the RAM and clock are in a 24/28 pin chip with the battery on top covered in goop.

to hack that guy, you dremel away the epoxy above two of the pins, which exposes the battery leads. cut them and solder a new external battery in place, and viola.

i'm guessing that on your flavor of dallas chip, the battery is under the circuit board hosting the RAM socket. it's probably a safe bet that the four pads visible on the circuit board are indeed the battery connections - but since the battery is probably dead as a doornail at this point, figuring out which is which is gonna be difficult.

solution 1:

it looks from your photo that the underside is shiny - in other words, they've got the battery tucked under there and covered with epoxy.

if you're friendly with a doctor or dentist, get it x-rayed

then you know where to drill into the epoxy to find the battery terminals. once exposed, you can ohm to find out where they go on the chip, then disconnect the old battery and solder a new one in a more exposed place. the battery is likely 3.3V, but i'd do some research first.

solution 2:

get the datasheet ( http://datasheets.maxim-ic.com/en/ds/DS1216-DS1216H.pdf ) and compare to current dallas "timekeeper RAM" products. you might find one that's nearly pin compatible and nearly register compatible, build an adapter socket, and see if the firmware is willing to talk to it.

solution 3:

i didn't find anything in quick search (and didn't read through the datasheet), but if you can find the pinout of the 1216 chip on the circuit board, you could just cut a trace or nip a pin to disconnect the old battery, and wire a new outboard one.

_________________
amigas and panheads and guns, oh my!
two :Indy:

, Amiga 3000UX, Amiga 1200+50MHz 68030, Commodore 128, two iMac G3, eMac G4, Tandy 1000, two 486DX66, several P4/P3 XP/linux boxes

zuluchas
Big Fan
Who joined June 25, 2008, 10:41 a.m.
and authored 161 notes

Wrote the following at Jan. 26, 2010, 11:42 p.m...

Thanks for the datasheet and pointers. This is, indeed, a DS1216B packaging, with the shiny bottom indicating the battery is epoxied in and otherwise unreachable without tearing the whole assembly apart. The SRAM chip is 24-pin so it looks like I could possibly just wire in the positive side of a 3V battery to pin 26 of the 28-pin socket (marked Vcc B in the datasheet diagram) and the negative side into pin 14 (GND). Should I go with a coin cell-type 3V battery?

This Old SGI mentions the DS1216, but I guess he never got around to doing any mods to it: http://www.nekochan.net/wiki/index.php/ ... y_problems

Otherwise, there is at least one supplier of new DS1216B's, asking about $25 per item for small orders.
https://shop.maxim-ic.com/storefront/pr ... er=DS1216B

I didn't find a datasheet for the SRAM chip's exact P/N, but here's one for CXK5816PN/M: http://220.231.180.119:811/goods_files/ ... 5816PN.pdf
It indicates that the minimum voltage for data retention is 2V, with a normal supply of 5V -- so, same basic idea as shown in the modern-day 1216B specs. So a 3-ish Volt battery should do the job, right?

I'm thinking the low-tech battery wire-in is more economical and easier to replace in the future. Thoughts?

_________________
:Onyx2RM:

rscottdrysdale
Journeyman
Who joined Jan. 19, 2010, 2:45 p.m.
and authored 42 notes

Wrote the following at Jan. 27, 2010, 8:55 a.m...

zuluchas wrote:

The SRAM chip is 24-pin so it looks like I could possibly just wire in the positive side of a 3V battery to pin 26 of the 28-pin socket (marked Vcc B in the datasheet diagram) and the negative side into pin 14 (GND). Should I go with a coin cell-type 3V battery?

essentially, yes. pull the RAM chip and bend it's VCC pin skyward. solder a small (wire-wrap) wire from VCC on the dallas carrier through a diode to the RAM's VCC pin. hook up the "+" of your new battery through another diode to the same RAM VCC pin. the diodes will drop .7V (so the RAM VCC pin will see .7V less than board VCC or battery backup voltage), but it should work. of course, don't forget to hook the battery "-" to GND.

however, you will have achieved NVRAM retention only. the clock (in the dallas chip) will not keep time when power is off, as it's still (not) powered by the old (dead) battery. once your system comes up, you could have it get time via an NTP server, but in the mean time logs and filesytem timestamps will be wrong.

_________________
amigas and panheads and guns, oh my!
two :Indy:

, Amiga 3000UX, Amiga 1200+50MHz 68030, Commodore 128, two iMac G3, eMac G4, Tandy 1000, two 486DX66, several P4/P3 XP/linux boxes

SAQ
Old Salt
Who joined July 19, 2006, 8:37 a.m.
and authored 3874 notes

Wrote the following at Jan. 27, 2010, 7:48 p.m...

zuluchas wrote:

I'm thinking the low-tech battery wire-in is more economical and easier to replace in the future. Thoughts?

Have you been over the Dallas chip with a voltmeter yet? If there's something there (even fractions of a volt) you can find out which pin is connected to the battery and you can wire the battery in where it's supposed to be.

_________________
Damn the torpedoes, full speed ahead!

:Indigo:

zuluchas
Big Fan
Who joined June 25, 2008, 10:41 a.m.
and authored 161 notes

Wrote the following at Jan. 27, 2010, 8:46 p.m...

zuluchas wrote:

Just out of interest, I'll try replicating the IP17 mix of 8MB and 2MB on the same board (in the Crimson, of course, not the 4D) and let you know what happens (and what version of the PROM that system is using).

I've tried the following configurations which prove that you can mix 8MB and 2MB simms on an IP17 board:

8x 8MB + 8x 2MB, recognized as 80MB, installed in identical sets of eight, one adjacent pair per bank, populated from the LED side of the board, largest capacity simms first.

4x 8MB + 4x 2MB, recognized as 16MB, installed in identical sets of four, in matching slots in each bank, populated from the LED side of the board, largest capacity simms first. (Not recommended, but it does make it to the PROM.)

This is with PROM revision 4.0.3 IP17.

_________________
:Onyx2RM:

zuluchas
Big Fan
Who joined June 25, 2008, 10:41 a.m.
and authored 161 notes

Wrote the following at Jan. 27, 2010, 9:13 p.m...

SAQ wrote:

Have you been over the Dallas chip with a voltmeter yet? If there's something there (even fractions of a volt) you can find out which pin is connected to the battery and you can wire the battery in where it's supposed to be.

So here goes: there are four contacts that are easy to get to on the top of the Dallas chip assembly, which I've labeled A, B, C, and D in red. The top diagram is borrowed from the modern DS1216B datasheet and may help illustrate what we're looking at. Here are the measured potential differences across the contacts:
C to A: ~ +58 mV
D to A & B to A: ~ +95mV
everything else zero.

(edit) OOps -- forgot the attachment!

Attachment:

ds_chip_voltages.jpg [ 60.66 KiB | Viewed 69 times ]

_________________
:Onyx2RM:

jan-jaap
Old Salt
Who joined June 17, 2004, 11:35 a.m.
and authored 2689 notes

Wrote the following at Jan. 28, 2010, 2:32 a.m...

zuluchas wrote:

I've tried the following configurations which prove that you can mix 8MB and 2MB simms on an IP17 board:

8x 8MB + 8x 2MB, recognized as 80MB, installed in identical sets of eight, one adjacent pair per bank, populated from the LED side of the board.

Yeah, I ran my first Crimson for a couple of years like this.

zuluchas wrote:

This is with PROM revision 4.0.3 IP17,

AFAIK, there is only one PROM revision for IP17, and it's on both the 100 and 150MHz boards

zuluchas wrote:

So here goes: there are four contacts that are easy to get to on the top of the Dallas chip assembly, which I've labeled A, B, C, and D in red. The top diagram is borrowed from the modern DS1216B datasheet and may help illustrate what we're looking at. Here are the measured potential differences across the contacts:
C to A: ~ +58 mV
D to A & B to A: ~ +95mV
everything else zero.

Can we see this diagram? Do I get this right, can we rebuild this battery backup using a suitable coin cell, a socket, some hot glue and maybe some soldering? In that case I like this better than the dremeling required for later Dallas parts. I still have working IO2's and IO3's, if it helps I can remove a battery/socket assembly and measure the voltages.

_________________
Now this is a deep dark secret, so everybody keep it quiet

It turns out that when reset, the WD33C93 defaults to a SCSI ID of 0, and it was simpler to leave it that way... -- Dave Olson, in comp.sys.sgi
Currently in commercial service:

(2x)

In the museum: almost every MIPS/IRIX system.

SGI: Hardware

4D/240GTX troubleshooting - Page 2