Skip to main content
Home Forums Booting and gray screen... Booting and gray screen...
Thread

Booting and gray screen...

Booting and gray screen... Troubleshooting 73 posts Mar 2, 2009 — Jan 27, 2011
Cool!

And maybe the flash goes toward the front, the end, or somewhere in the middle of the data in the ROM SIMM; Maybe they could be somehow combined into one ROM image so we could actually run it in sheepsaver; I don't think sheepshaver could/would accept 2/3 files as the ROM :p

Oh, and could you email me this program

EDIT: I could PM you my email adress

This is also a bad dump. Your data bits seem fine now, but your address bits are screwed up. 1 means working, 0 means "stuck", x means not used:
MSB <---> LSB

xxxx xxxx xxxx 1000 0000 1111 1111 1111

I believe this is the way that the address bits are stuck now (not certain though!):

xxxx xxxx xxxx x010 1000 xxxx xxxx xxxx

Please be very careful; it is possible that your dumper could damage the flash chips if it isn't set up properly. I would recommend researching the pinout of the flash chips and verifying your adapters and dumper configuration.
I have just verified the way that the address bits are stuck. The above info is correct.

Couldn't you just combine the two corrupt ROMs to get a complete one?

Couldn't you just combine the two corrupt ROMs to get a complete one?
No. We have most of the information but we're still missing some.

BOTH STARTUP SOUNDS are in the digibarn flash dump. The normal one and the one nobody has ever heard.
The original flash dump contains YET DIFFERENT startup sounds. The first one is the 6300 sound on the left channel with someone saying "I know that I rescued this company" on the right. The second one is someone saying "Kill me!" I'm working on figuring out exactly how to interleave these files together so I can then figure out exactly the attributes of the audio, after which I can extract some good samples for everyone to hear!
Sounds like a Gil Amalio quote to be, although even Google didn't know.

Do you think it would be possible to install the Flash chips back into the PEX, boot into Mac OS 9, and use a software ROM dumper run right on the Mac? I'm not sure exactly how this would work with 2 separate ROMs like this, but it might be a safer approach. It could potentially work. I can de-interleave the dump back into two 512k dumps that you could then burn to new flash chips if this works.
It's also possible that you'll only get the ROM SIMM to dump this way. There's no telling.
The PEX ROM SIMM dump was generated by booting into OS 9 - apologies for not stating this. Only the 3MB is recognised - the 1mb on the flash chips doesn't seem to be counted,

This is also a bad dump. Your data bits seem fine now, but your address bits are screwed up. 1 means working, 0 means "stuck", x means not used:
MSB <---> LSB

xxxx xxxx xxxx 1000 0000 1111 1111 1111

I believe this is the way that the address bits are stuck now (not certain though!):

xxxx xxxx xxxx x010 1000 xxxx xxxx xxxx

Please be very careful; it is possible that your dumper could damage the flash chips if it isn't set up properly. I would recommend researching the pinout of the flash chips and verifying your adapters and dumper configuration.
I have just verified the way that the address bits are stuck. The above info is correct.
For reference I'm using this USB-based programmer/dumper: http://www.mcumall.com/comersus/store/comersus_viewItem.asp?idProduct=4225 with this PLLC32 adaptor http://www.mcumall.com/comersus/store/comersus_viewItem.asp?idProduct=3104.

The second alternate dump I did was using this adaptor: http://www.mcumall.com/comersus/store/comersus_viewItem.asp?idProduct=3202 but I'm going to stay away from that as I believe the other adaptor is the correct one to use.

I've only set the software to read the chip, so no accidental erasing will occur - although I take your point about the reader corrupting something. I'm going to re-dump the original flash chips that came with the board to check that the dumper can still produce a correct result. I'll then try again with the Digibarn chips.

Of course, if you've got any tips on further configuring the dumper, or processes of verification it would be much appreciated.

What's the differance between the flash chips and the rom simm?
This is a strange Mac. It has one part of the ROM stored in flash chips and a different part of the ROM stored in a ROM SIMM. They aren't redundant; both are apparently necessary to boot the Mac. We're not really sure how they work together but we do know that the startup sounds are stored in flash.
My theory is that the flash chips contain open firmware (OF) and the very low-level code to get the machine to load up OF. This is why the OF version changes when I've put the Digibarn flash chips into the motherboard. As the ROM SIMM is only 3MB I think this doesn't contain any OF.

On NewWorld ROM machines the startup from is only about 1MB in size (such as the B&W G3). Also on NewWorld machines (which load the Mac OS toolbox ROM from file) the Mac OS ROM file is 3MB. On the Beige G3 (oldworld) the ROM SIMM is 4MB.

I suggest to boot into the classic Mac OS on the PEX the following process occurs:

1) OF loads from the flash chips,

2) Boots to the default device of OF APPL,ROM

3) In this case the start memory location of APPL,ROM is within the flash chips.

4) This then plays the second startup sound and then points to a memory location which is the start of the Mac OS toolbox ROM from the SIMM.

In comparison the oldworld boot process is:

1) OF loads from the onboard ROM / ROM SIMM (in Beige G3s)

2) Boots to the default device of OF APPL,ROM, which then loads the Mac OS toolbox ROM (stored on the onboard ROM/ROM SIMM)

The newworld boot process is:

1) OF loads from the flash chips on the motherboard

2) OF locates the Mac OS ROM file on the chosen boot device

3) This is stitched into the OF memory and APPL,ROM is defined in memory as the boot device.

4) Boots to the default device of OF APPL,ROM, which then loads the Mac OS toolbox ROM

Normally a ROM SIMM added into a board would complete disable an existing onboard ROM, but as people have noted they seems to coexist. It's almost a half-way house between the oldworld and newworld ROM architectures.

I found the documents below useful reading in understanding the classic Mac OS boot process. Mac OS X simply uses OF to load BootX and the Kernel, and does not use the Mac OS toolbox ROM at all.

http://developer.apple.com/documentation/Hardware/DeviceManagers/pci_srvcs/pci_cards_drivers/PCI_BOOK.26.html#pgfId=3296

http://support.apple.com/kb/TA29027?viewlocale=en_US

A couple of things I'll try tonight are the tips in this forum about seating the device, as one of the problems with the Digibarn chips is getting the Device ID recognised:

http://www.mcumall.com/forum/topic.asp?TOPIC_ID=1568&SearchTerms=am29f040

The forum post also confirms that the PLCC32-DIP32 is the correct adapter to use (http://www.mcumall.com/comersus/store/comersus_viewItem.asp?idProduct=3104)

I've checked the the software has the correct device id for the chip, which it does:

http://www.ourchip.com/NZILIAO/chips/memory/AM29F040.pdf states that the manufacturer id is 01 and the device id is A4.

The software has this entry for the chip (applies to 29F040 and 29F040B):

Name="AM29F040B",ID="01A4",Class="29F040B",Category="FLASH",MFG="AMD";

Your setup is a good one; I don't think you have to worry about damaging the chips.

Interesting that your original flash ROMs dumped properly but not the Digibarn ones.

I would try to reduce the speed of the dumping process if you can. I would think that's the most likely to make it work. RAM/ROM can be very picky about timing.

Next, if that doesn't work, I would dig out a 32-pin DIP socket with long leads, similar to this:

12005_socket.jpg


You can see the pinout here of the ROM with and without your PLCC <-> DIP adapter:

pinout.png


Insert your flash ROM into the adapter, and now the pinout of the adapter is the same as the left, DIP pinout in the image above. Insert the adapter (containing the ROM) into the DIP socket (top image), and simply bend DQ3 out of the way, and then DQ4 into its place.

If this works, the dump will still be screwed up, but it should now contain the missing bit, making it possible to mathematically derive a good dump from it, combined with your previous dumps.

There are some other experienced people here that could verify that swapping data bits like this is not a dangerous thing to do if you feel uneasy about it.

Right, I think I've got a proper dump this time - selected the slowest speed and it worked fine for the even ROM chip and was a bit more flakey on the odd ROM chip - but eventually got a successful ID check, read and verify.

The latest dump is here: http://www.jkalittle.co.uk/jkalittle.co.uk/OF_2_3_dump3.zip

The even dump now starts with 0x 4800 0008

James.

Right, I think I've got a proper dump this time - selected the slowest speed and it worked fine for the even ROM chip and was a bit more flakey on the odd ROM chip - but eventually got a successful ID check, read and verify.
The latest dump is here: http://www.jkalittle.co.uk/jkalittle.co.uk/OF_2_3_dump3.zip

The even dump now starts with 0x 4800 0008

James.
Dump 3 was successful!

Original, de-interleaved into one file:

http://www.d.umn.edu/~bold0070/temporary/original_interleaved.bin.zip

Dump 3, de-interleaved into one file:

http://www.d.umn.edu/~bold0070/temporary/dump3_interleaved.bin.zip

Dump 3 sound 1:

http://www.d.umn.edu/~bold0070/temporary/digibarn1.aif

Dump 3 sound 2 (PEX sound):

http://www.d.umn.edu/~bold0070/temporary/digibarn2.aif

Original sounds (same as before):

http://www.d.umn.edu/~bold0070/temporary/OF_2.0a9.aif

The PEX sound is cut short, but it also has a subtle fade-out at the end which clearly indicates to me that this was on purpose. I believe these dumps are all good now.

Cool!

So... Any way to combinr the SIMM dump and the Flash dump so I can run it in sheepshaver?

Cool!
So... Any way to combinr the SIMM dump and the Flash dump so I can run it in sheepshaver?
I don't know. Maybe but it's probably not worth the trouble. I don't see how it would work any different than, say, a 9600 ROM. You would probably have to tweak SheepShaver. Notice that SS doesn't have a startup sound when you first launch it. So it isn't probably using the whole ROM anyway.

...Or sound emulation hasn't started yet?

Duplicating the Flash chips should be easy now, but do you have any plans to duplicate the ROM SIMM?

Duplicating the Flash chips should be easy now, but do you have any plans to duplicate the ROM SIMM?
Yes - I bought a tape of 10 same model AMD FLash chips to ue to duplicate the flash dumps on - will be doing this and testing them soon.

I will try to duplicate the rom simm - or design one which has removal flash chips for the rom simm socket.

Somone on the applefritter forums already has pcb layout schematics and pinouts for rom chips that he helped design/manufacture for powersurge/beige g3s and clones.

If you know anyone that knows anyhting about this that would be good to know.

The guy saying " I know that I rescued this company" is Gil Amelio. That voice matches up with his in an apple press release.

The guy saying " I know that I rescued this company" is Gil Amelio. That voice matches up with his in an apple press release.
Fascinating - my other half doesn't like this startup tone - says it creeps her out!

Do you happen to have a link to an audio press release of Gil Amelio - I've tried Google but to no avail.

If you have your own custom sound that is the same length of time, we could insert that into the flash dumps and reburn them. Wouldn't THAT be cool - a Mac that you could customize the startup sound.

I don't know of another Mac with such easily-modified ROM.

Right, I think I've got a proper dump this time - selected the slowest speed and it worked fine for the even ROM chip and was a bit more flakey on the odd ROM chip - but eventually got a successful ID check, read and verify.
The latest dump is here: http://www.jkalittle.co.uk/jkalittle.co.uk/OF_2_3_dump3.zip

The even dump now starts with 0x 4800 0008

James.
Dump 3 was successful!

Original, de-interleaved into one file:

http://www.d.umn.edu/~bold0070/temporary/original_interleaved.bin.zip

Dump 3, de-interleaved into one file:

http://www.d.umn.edu/~bold0070/temporary/dump3_interleaved.bin.zip

Dump 3 sound 1:

http://www.d.umn.edu/~bold0070/temporary/digibarn1.aif

Dump 3 sound 2 (PEX sound):

http://www.d.umn.edu/~bold0070/temporary/digibarn2.aif

Original sounds (same as before):

http://www.d.umn.edu/~bold0070/temporary/OF_2.0a9.aif

The PEX sound is cut short, but it also has a subtle fade-out at the end which clearly indicates to me that this was on purpose. I believe these dumps are all good now.
For some reason I can't get these files to play under OS X.5.6.

What gives? I really want to hear them.

Thanks.

Option-click the links to download, then open the files in QuickTime player. These are ordinary AIFF files.

The movie file could not be opened.

The end of the file was reached.

I re-downloaded them and had the same problem.

They originally d/l with .AIF, i changed them to .AIFF and still no go with quicktime.

10.5.6, everything up to date.

EDIT:

Massive FAIL!

Not really.

The file digibarn.aif is 263 bytes.

The others files are fine.

The file digibarn.aif is 263 bytes.
The others files are fine.
Digibarn1.aif is 256k

Digibarn2.aif is 256k

OF_2.0a9.aif is 512k

These are the only 3 files. I just downloaded each of them and they play fine for me. There was another audio file from a bad dump earlier in this thread which was the same as Digibarn2.aif, but it sounded bad. I may have deleted this file from my web space, you may actually be downloading a small 404 HTML file which QuickTime Player can't play.

Weirdness than.

I must have done something to d/l a 263 byte file, what it is I don't know.

I have all 3 working files now.

Must say that new startup sound is awesome.

Wonder if I could hard code it into my PBG4.

That'd piss Steve off good.

Weirdness than.
I must have done something to d/l a 263 byte file, what it is I don't know.
That's probably because of the minimum block size on your hard drive. Often times files will show up a few kilobytes bigger than they actually are.

Wonder if I could hard code it into my PBG4.
That'd piss Steve off good.
If you can edit the ROM you can.

Beware that the normal startup sound is 22kHz stereo and I think this PEX one is 44kHz stereo so you may either have to downsample the audio to 22kHz or hack the actual playback sample rate somehow.

I'm going to dig up this thread. I can't honestly believe that I missed it during the original post cycle, being such an avid Macintosh PowerExpress fan myself. I still have copies of CaptainZ's MP3 audio dumps from years ago:

Macintosh PowerExpress (9700) Boot Chime (60kb)

Macintosh PowerExpress "Manhattan" Death Chime "Kill Me!" (116kb)

Macintosh PowerExpress "Manhattan" Boot Chime "Gil Amelio" (128kb)

Unfortunately that's all I can offer since the rest of my knowledge is all up there in the ol' brain. Interesting thread though, and congratulations on getting the mythical beast to boot. :D

If you have your own custom sound that is the same length of time, we could insert that into the flash dumps and reburn them. Wouldn't THAT be cool - a Mac that you could customize the startup sound.
I don't know of another Mac with such easily-modified ROM.

Well, I wish I hadn't missed this thread before.

Now that James has found sockets for the PSOP-44 chips, it would actually be pretty easy to modify the ROMs on the entire x500 and x200 family--oh, and probably the x100 family as well.

Remove the existing ROMs, install the sockets, then program/reprogram PSOP-44 8 Mbit Flash chips with ROM code.

I've done some work where I've desoldered and replaced the ROM chips with Flash chips with the Kansas ROM. My Umax S900 which is my main machine at home has Kansas ROMs installed.

The original soldering job might be a little challenging (routine for me), but after that you just need a programmer which will handle the 44 pin PSOP flash.

If you have a Power Computing ROM SIMM it can be a little more interesting. Replace the ROM chips with PSOP-44 sockets again. Find the 1Kohm resistor which ties pin 116 of the ROM module to GND. Remove the resistor and connect the pad which connects to pin 116 to 5V.

In the x500 (and 7200) family of Macintoshes, pin 116 of the ROM DIMM socket is connected to the CE_ (chip enable) pins of the logic board ROM chips. These pins are active low and they are weakly (~4Kohms) tied to ground. If you tie pin 116 of a ROM module to 5V and then plug in the ROM module, it will tie all the CE_ pins to 5V and disable the logic board ROM chips, allowing the chips on the ROM module to take over.

So, once you have such a module, you can plug it into an x500/x600/x200 family machine and reprogram the socketed chips as desired.

Here is the pinout for the ROM module. The PS stands for Power Surge which is the x500/x600 family. The Beige, PowerSurge and NuBus Power Macs all use the same pinout. The Beige uses the 3.3V pins for power supply, while the others use the 5V pins.

http://www.io.com/~trag/Apple_pinouts/Firmware_Module_Pinout.txt

I've had the hardware ability to modify the ROMs for about seven years, but I'm not much of a programmer/hacker.

mp.ls