jimjamyahauk
Well-known member
Hi - Thanks for extracting the sounds. I've re-extracted the Digibarn chips and uploaded with the same file name - so please re-download.
-
Updated 2023-07-12: Hello, Guest! Welcome back, and be sure to check out this follow-up post about our outage a week or so ago.
Booting and gray screen...
- Thread starter jimjamyahauk
- Start date
Dennis Nedry
Well-known member
It appears to still have the same stuck bit. The even dump should start with 0x 4800 0008, and it still starts with 0x 5810 1018.
I suppose it must be your dumper, or the way that you've hooked it up to your dumper, seeing as how the flash chips work when installed in the PEX. It could also be a timing problem with your dumper, which could maybe be fixed by reducing the speed.
Something else that might work - maybe you could swap the data bits around? You could put them in reverse order or something. If you re-dump with a different bit stuck (so the currently missing bit gets through on a different bit), I could easily combine the dumps together into one complete, accurate dump. We can verify because the beginning your original ROM and the digibarn flash ROMs are identical.
jimjamyahauk
Well-known member
Hi,
I've re-dumped them using a different PLLC32 adaptor and uploaded them to:
http://www.jkalittle.co.uk/jkalittle.co.uk/OF2_3_dump2.zip
Please let me know if these files are fixed.
James.
Dennis Nedry
Well-known member
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.
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.
macgeek417
Well-known member
What's the differance between the flash chips and the rom simm?
Dennis Nedry
Well-known member
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.
macgeek417
Well-known member
ahhh... So the 3 meg one is rom, and the two 512k ones are flash?
macgeek417
Well-known member
Oh, and the "even" and "odd" parts are the same as the "hi" and "lo" parts I've seen on some other roms??
Dennis Nedry
Well-known member
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.
It's also possible that you'll only get the ROM SIMM to dump this way. There's no telling.
macgeek417
Well-known member
If someone can get a PM9700 running, it'd be neat to write an emulator for it 
Dennis Nedry
Well-known member
They're both ROM. The 3MB one is the ROM SIMM, and the 1MB (2*512k) is flash.
Could be. The Flash ROM is stored in two separate flash chips, and it is easier in some situations to interleave the data between the 2 chips. With this one, 4 bytes come from "lo", then the next 4 are from "hi", next 4 from "lo", etc. Back and forth like that. It's not always 4 though. I have written a small program for this that de-interleaves the two files back together into one big file so I could pull the sound samples earlier in this thread.
Once we get a proper dump of this ROM, you may be able to use it in SheepShaver. That would technically be an emulation of a 9700.If someone can get a PM9700 running, it'd be neat to write an emulator for it
macgeek417
Well-known member
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
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
macgeek417
Well-known member
Oh, and could you email me this program
EDIT: I could PM you my email adress
EDIT: I could PM you my email adress
Dennis Nedry
Well-known member
I have just verified the way that the address bits are stuck. The above info is correct.
macgeek417
Well-known member
Couldn't you just combine the two corrupt ROMs to get a complete one?
Dennis Nedry
Well-known member
No. We have most of the information but we're still missing some.
jimjamyahauk
Well-known member
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,
jimjamyahauk
Well-known member
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.
Last edited by a moderator:
jimjamyahauk
Well-known member
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
Similar threads
