Thread
PEx ROM Project
I'm trying to actually get to the point where I build this thing. Here are some pictures of the modules I've worked on, used for testing, etc. along the way.
The ones with sockets were intended for the PEx. Because the PEx module is the same as the 9600 and because these have sockets, I was able to install chips with 9600 ROM code and test them in a 9600. They don't work. The modules with soldered down chips work fine in a 9600 with 9600 ROM code. Sigh.
Next step, since I'm out of blank circuit boards, is to desolder the chips or sockets from one of these and solder down Flash programmed with the PEx code.
The big question mark is whether the downloads we have of the PEx code is an actual accurate copy of what's on the chips of the PEx ROM. When I compare downloaded 9600 code to what I read directly off the 9600 ROMs, it does not match.
The ones with sockets were intended for the PEx. Because the PEx module is the same as the 9600 and because these have sockets, I was able to install chips with 9600 ROM code and test them in a 9600. They don't work. The modules with soldered down chips work fine in a 9600 with 9600 ROM code. Sigh.
Next step, since I'm out of blank circuit boards, is to desolder the chips or sockets from one of these and solder down Flash programmed with the PEx code.
The big question mark is whether the downloads we have of the PEx code is an actual accurate copy of what's on the chips of the PEx ROM. When I compare downloaded 9600 code to what I read directly off the 9600 ROMs, it does not match.
If you place one of those tan ZIF connector bases over the TOP of one of the ROMs, will the contacts mate up with the top of the of the legs on the surface mounted ROMs of the PEx DIMM?
Back in the day, we sometimes used to "clip" a wire wrap socket to the Target ROM with a ribbon cable PCB Mount inserted into it leading to another Cable connector inserted into the ROM Reader.
If you can file the edges of the ZIF socket down to the level where its contacts are in solid contact with the top of the surface mounted Target ROM's legs while it's clamped to one of them in an inverted position, you should be able to power up and select just that one ROM to get a good read of its contents. It worked great for 32 & 64 bit soldered thru-hole EPROM arrays back in the Neolithic Age! [
] ]'>
You may need to etch an adapter to solder down the ZIF plate if it doesn't have enough physical integrity on its own to just solder patch wires to its contacts. That might actually work at both ends, have you got a pic or spec of ROM ROM Reader's connector interface & cables/adapters? [}
] ]'>
A picture is worth a milllion words to a visual thinker. :approve:
edit: if you've got a couple of ZIF Sockets to spare, I could rip the sides off one, put them on edge so they'll definitely make contact, etch an adapter PCB so it'll make good contact to one of the 8100 ROM DIMMs I bought as blanks for the project. I can splay the contacts out to match any ribbon cable you spec and provide interleaved ground lines to prevent crosstalk on the cables.
Is epoxy conductive? I could use that to shore up the outside edges of the adapter halves. :approve:
edit: while beginning to doze off, I came up with a KISS based approach, I'll just lay out a single PCB that splays out the pad pattern to the cable thru-holes and leave long handles protruding from the top with hole patterns for a hinge . . .
. . . mount a pair together with the hinges attached to a, properly sized, drilled & tapped block of 1/2" plexi . . .
. . . add rubber bands and, voila, a custom SMT IC Chip Clip is born! :approve:
Back in the day, we sometimes used to "clip" a wire wrap socket to the Target ROM with a ribbon cable PCB Mount inserted into it leading to another Cable connector inserted into the ROM Reader.
If you can file the edges of the ZIF socket down to the level where its contacts are in solid contact with the top of the surface mounted Target ROM's legs while it's clamped to one of them in an inverted position, you should be able to power up and select just that one ROM to get a good read of its contents. It worked great for 32 & 64 bit soldered thru-hole EPROM arrays back in the Neolithic Age! [
] ]'>You may need to etch an adapter to solder down the ZIF plate if it doesn't have enough physical integrity on its own to just solder patch wires to its contacts. That might actually work at both ends, have you got a pic or spec of ROM ROM Reader's connector interface & cables/adapters? [}
] ]'>A picture is worth a milllion words to a visual thinker. :approve:
edit: if you've got a couple of ZIF Sockets to spare, I could rip the sides off one, put them on edge so they'll definitely make contact, etch an adapter PCB so it'll make good contact to one of the 8100 ROM DIMMs I bought as blanks for the project. I can splay the contacts out to match any ribbon cable you spec and provide interleaved ground lines to prevent crosstalk on the cables.
Is epoxy conductive? I could use that to shore up the outside edges of the adapter halves. :approve:
edit: while beginning to doze off, I came up with a KISS based approach, I'll just lay out a single PCB that splays out the pad pattern to the cable thru-holes and leave long handles protruding from the top with hole patterns for a hinge . . .
. . . mount a pair together with the hinges attached to a, properly sized, drilled & tapped block of 1/2" plexi . . .
. . . add rubber bands and, voila, a custom SMT IC Chip Clip is born! :approve:
What's PEx for? Is that the PowerExpress / PowerMac 9700?
Correct.
Could it be, perhaps, something similar to this case?
http://lowendmac.com/coventry/06/apple-ii-clones.html
Full story here:Because of the Apple vs. Franklin case, a small icon that said "Stolen!! © Apple" was hidden in the ROM during the development of the original Macintosh. Susan Kare designed the icon, and Steve Capps and Andy Hertzfeld worked on implementing it, so that when the ROM was copied, the icon would appear.
http://folklore.org/StoryView.py?project=Macintosh&story=Stolen_From_Apple.txt
By that I mean, that it is quite possible that the ROM is somehow protected and modifies dumped data while it is being copied.
?
That article is a bit misleading. The ROM does not modify dumped data in any way. No ROM can do that, because if it did, the computer using it would have to process the ROM contents before they could be used. The ROM can't tell whether it's inside a computer or on a chip programmer when it's being read.
All that article is saying is that they installed an image in the ROM analogous to a watermark image in a photo, so that if someone just copied the ROM directly, that image would be accessible in the copied machines.
All that article is saying is that they installed an image in the ROM analogous to a watermark image in a photo, so that if someone just copied the ROM directly, that image would be accessible in the copied machines.
Ok, thanks for clarifying that!
I know that some ROMs, PICs etc can be copy protected, so I thought there might be something going on in the process of copying PEx ROM, that you're not aware.
I know that some ROMs, PICs etc can be copy protected, so I thought there might be something going on in the process of copying PEx ROM, that you're not aware.
Ah, in the case of a PIC, there's a microcontroller and a ROM on the same chip. After programming the ROM, it can be locked/copy protected. After that, it cannot (easily) be read from off the chip. However, the PIC on the chip still has normal access to the contents.
For a stand-alone ROM, if there were some method of locking it, it would be useless because nothing would be able to access its contents, because all accesses are from off the chip.
Okay, it looks like I may have a little bit of time to work on this this summer. The boy is away at sleep-away camp for a couple more weeks. So there's no baseball, etc. Of course, there's still home-ownership, the fish/aquariums, etc.
I'd like your thoughts on my next steps.
Anyway, here's the summary:
Goal: Create a usable ROM module for the PowerExpress machines floating around out in the wild. One of our list members first approached me about this back around Feb. of 2009.
Background: A large number of Mac models use what is essentially the same ROM DIMM module (printed circuit board), from the NuBus PowerMacs through the Beige G3. There are some minor variations. As far as we could tell, the PEx ROM module is identical (form and pinout, not ROM contents, obviously) to the X500/X600 family ROM module.
I have, in the past, built a 9600 Kansas ROM module and installed it in a 9500 and other machines, and seen that it changes the machine type/behaviour.
So, building a working PEx ROM is very analogous to building a working 9500/9600 ROM, except that the stored code on the Flash/ROM chips is different.
I do not own a PEx. I own some 9500 and 9600 logic boards. I had two unused ROM DIMM circuit boards left over from an earlier project. I have several other assembled ROM DIMMs on hand, including a few 9600 ROM DIMMs. I have the code for the 9600 ROM backed-up from the ROM chips of one of my 9600 logic boards, stored on the computer that runs my chip programmer.
1st Approach: Being unsure of the PEx ROM contents and our ability to get them, we decided to create a ROM module (circuit board) with Flash chip sockets on board. We chose 44 pin PSOP Flash chips and sockets because I already had some of the required printed circuit boards on hand, left-over from an older project.
If we had been starting from scratch, we probably would have used the easier-to-work-with 32 pin PLCC, but that would have required creating a whole new circuit board, and would have been hundreds of dollars expensive (four layer board).
James found some 44-pin PSOP sockets and supplied those. I put them on the module circuit board. In order to test them I programmed a set of 44 pin PSOP Flash chips with the PM9600 ROM code and installed the chips in the sockets. Then I tested it in a PM9600.
The module did not work.
I built a second module with sockets.
The second module did not work.
I tried various tests, and double and triple checked the continuity between the sockets and the circuit boards, etc. Nothing I tried would make either socketed board work.
It looks like this failure was complete around Feb. 2010.
2nd Approach: Just build a module with soldered down ROMs. This should work. The 9600 modules with soldered chips work fine. However, if the code on the chips is wrong, it will require difficult soldering to change it.
The only method we came up with to obtain the PEx ROM code was to get a PEx ROM module from a computer museum and install it in James' PEx and then use CopyROM to extract the code.
However, when I use CopyROM to extract the code from my PM 9600, it does not match the code that I read directly off the ROM chips! This implies that a module built with soldered chips programmed with the CopyROM extracted code from the PEx won't work.
And this problem has been bothering me ever since.
Note: The ROM image extracted by CopyROM from a IIci does match the code read directly from the ROM chips pulled off of a IIci logic board.
Latest Plan So, I've been pondering this off and on for the last couple of years. I could just:
1) Program the CopyROM PEx data to chips, solder them down, and hope for the best. It might be a worthwhile test, any way.
But, I think the chance for success is not great.
Here's what I think is a good approach:
2) a) Build a 9600 ROM module using CopyROM extracted code and see if it works. If it works, great, do the same for the PEx and ship it out for testing.
B) If the CopyROM extracted 9600 code does not work, post the CopyROM extracted code, and the code copied directly from 9600 ROM chips, and ask the 68kmla community to figure out how one turns into the other. It could be something as simple as a Big Endian vs. Little Endian issue or some such.
c) Use what is figured out from ( B) to convert the CopyROM PEx code into usable code
d) Solder chips with the usable code onto ROM modules.
e) At this point all my modules are populated and will need to be desoldered before they can be reused. Use a module for (d) which has already been shown to work as a 9600 module. That way we know the circuit board isn't defective -- low probability, but still possible. This (e) really belongs between © and (d).
Does that sound like a logical approach?
I'd like your thoughts on my next steps.
Anyway, here's the summary:
Goal: Create a usable ROM module for the PowerExpress machines floating around out in the wild. One of our list members first approached me about this back around Feb. of 2009.
Background: A large number of Mac models use what is essentially the same ROM DIMM module (printed circuit board), from the NuBus PowerMacs through the Beige G3. There are some minor variations. As far as we could tell, the PEx ROM module is identical (form and pinout, not ROM contents, obviously) to the X500/X600 family ROM module.
I have, in the past, built a 9600 Kansas ROM module and installed it in a 9500 and other machines, and seen that it changes the machine type/behaviour.
So, building a working PEx ROM is very analogous to building a working 9500/9600 ROM, except that the stored code on the Flash/ROM chips is different.
I do not own a PEx. I own some 9500 and 9600 logic boards. I had two unused ROM DIMM circuit boards left over from an earlier project. I have several other assembled ROM DIMMs on hand, including a few 9600 ROM DIMMs. I have the code for the 9600 ROM backed-up from the ROM chips of one of my 9600 logic boards, stored on the computer that runs my chip programmer.
1st Approach: Being unsure of the PEx ROM contents and our ability to get them, we decided to create a ROM module (circuit board) with Flash chip sockets on board. We chose 44 pin PSOP Flash chips and sockets because I already had some of the required printed circuit boards on hand, left-over from an older project.
If we had been starting from scratch, we probably would have used the easier-to-work-with 32 pin PLCC, but that would have required creating a whole new circuit board, and would have been hundreds of dollars expensive (four layer board).
James found some 44-pin PSOP sockets and supplied those. I put them on the module circuit board. In order to test them I programmed a set of 44 pin PSOP Flash chips with the PM9600 ROM code and installed the chips in the sockets. Then I tested it in a PM9600.
The module did not work.
I built a second module with sockets.
The second module did not work.
I tried various tests, and double and triple checked the continuity between the sockets and the circuit boards, etc. Nothing I tried would make either socketed board work.
It looks like this failure was complete around Feb. 2010.
2nd Approach: Just build a module with soldered down ROMs. This should work. The 9600 modules with soldered chips work fine. However, if the code on the chips is wrong, it will require difficult soldering to change it.
The only method we came up with to obtain the PEx ROM code was to get a PEx ROM module from a computer museum and install it in James' PEx and then use CopyROM to extract the code.
However, when I use CopyROM to extract the code from my PM 9600, it does not match the code that I read directly off the ROM chips! This implies that a module built with soldered chips programmed with the CopyROM extracted code from the PEx won't work.
And this problem has been bothering me ever since.
Note: The ROM image extracted by CopyROM from a IIci does match the code read directly from the ROM chips pulled off of a IIci logic board.
Latest Plan So, I've been pondering this off and on for the last couple of years. I could just:
1) Program the CopyROM PEx data to chips, solder them down, and hope for the best. It might be a worthwhile test, any way.
But, I think the chance for success is not great.
Here's what I think is a good approach:
2) a) Build a 9600 ROM module using CopyROM extracted code and see if it works. If it works, great, do the same for the PEx and ship it out for testing.
B) If the CopyROM extracted 9600 code does not work, post the CopyROM extracted code, and the code copied directly from 9600 ROM chips, and ask the 68kmla community to figure out how one turns into the other. It could be something as simple as a Big Endian vs. Little Endian issue or some such.
c) Use what is figured out from ( B) to convert the CopyROM PEx code into usable code
d) Solder chips with the usable code onto ROM modules.
e) At this point all my modules are populated and will need to be desoldered before they can be reused. Use a module for (d) which has already been shown to work as a 9600 module. That way we know the circuit board isn't defective -- low probability, but still possible. This (e) really belongs between © and (d).
Does that sound like a logical approach?
In the ROM Emulator project, back in the day, we were translating Type 3 Postscript Fonts and Postscript Exports from CorelDraw into the host system's native, Multiple ROM based, Font Cartridge Format.
I the formatting, there were Blocks of Data mapped according to information on a tiny ROM present on the Cartridges for some reason or other. It was probably due to the different sizes and combinations of the ROMs used on the Font Cartridges according to specific storage needs.
Could your equivocal ROM Dump results be the result of such mapping being done from information present within the, lower level, socketed PLCC ROM pair? This mapping could have changed several times over the course of the PEx Board and ROM development.
Dunno, just thought I'd ask . . . :?:
I the formatting, there were Blocks of Data mapped according to information on a tiny ROM present on the Cartridges for some reason or other. It was probably due to the different sizes and combinations of the ROMs used on the Font Cartridges according to specific storage needs.
Could your equivocal ROM Dump results be the result of such mapping being done from information present within the, lower level, socketed PLCC ROM pair? This mapping could have changed several times over the course of the PEx Board and ROM development.
Dunno, just thought I'd ask . . . :?:
Could Apple have used some kind of hardware decryption algorithm between the contents of the chips and the actual ROM data being put on the bus?
The reason I'm wondering this is:
In my IIci hack thread, I was working with olePigeon to get his Turbo 040 card to work with my custom ROM. He dumped the Turbo 040 ROM contents for me (version 4.01) using a program I wrote to grab them in-system (similar to CopyROM), and I compared his in-system dump against your raw chip dump of version 4.01. His ROM contents were completely different and had many human-readable strings relating to the Turbo 040 card and valid 68k machine code. The raw chip dump looked like gobbledygook. So assuming your chip dump worked correctly on the Turbo 040, Daystar was known to use a hardware ROM encryption scheme. Maybe it's possible Apple did the same thing on these x500/x600/PEx machines?
The reason I'm wondering this is:
In my IIci hack thread, I was working with olePigeon to get his Turbo 040 card to work with my custom ROM. He dumped the Turbo 040 ROM contents for me (version 4.01) using a program I wrote to grab them in-system (similar to CopyROM), and I compared his in-system dump against your raw chip dump of version 4.01. His ROM contents were completely different and had many human-readable strings relating to the Turbo 040 card and valid 68k machine code. The raw chip dump looked like gobbledygook. So assuming your chip dump worked correctly on the Turbo 040, Daystar was known to use a hardware ROM encryption scheme. Maybe it's possible Apple did the same thing on these x500/x600/PEx machines?
Okay, I've uploaded the 9600 based test files.
At:
http://www.prismnet.com/~trag/Firmware/
you'll find Kansas.ROM, from7.ROM and from9.ROM. These are all copyrom extractions. I need to run diff on them to check whether their identical. The latter two were made using copyrom under System 7.6.1 and under 9.1 respectively, to check whether the OS had any affect on copyrom's output. Ideally, it should not.
In the directory Kansas_parts:
http://www.prismnet.com/~trag/Firmware/Kansas_parts/
are four files, Kansas_U1.bin, Kansas_U2.bin, Kansas_U3.bin, and Kansas_U4.bin. These are the actual contents of the four ROM chips. When interleaved together (instructions below) they should be identical to the copyrom output for the same machine.
To interleave U1, U2, U3 and U4 back into a complete whole, take 2 bytes from each file at a time. The order is U4, U3, U2, U1.
So, to make the complete file, take 2 bytes from U4, then 2 bytes from U3, then 2 bytes from U2, then 2 bytes from U1, and repeat.
This should recreate the copyrom extraction found in Kansas.ROM. But, unless I am very confused, it does not.
I'd appreciate the help of anyone who wants to look at the files and see if they can find some kind of reordering that makes it work.
At:
http://www.prismnet.com/~trag/Firmware/
you'll find Kansas.ROM, from7.ROM and from9.ROM. These are all copyrom extractions. I need to run diff on them to check whether their identical. The latter two were made using copyrom under System 7.6.1 and under 9.1 respectively, to check whether the OS had any affect on copyrom's output. Ideally, it should not.
In the directory Kansas_parts:
http://www.prismnet.com/~trag/Firmware/Kansas_parts/
are four files, Kansas_U1.bin, Kansas_U2.bin, Kansas_U3.bin, and Kansas_U4.bin. These are the actual contents of the four ROM chips. When interleaved together (instructions below) they should be identical to the copyrom output for the same machine.
To interleave U1, U2, U3 and U4 back into a complete whole, take 2 bytes from each file at a time. The order is U4, U3, U2, U1.
So, to make the complete file, take 2 bytes from U4, then 2 bytes from U3, then 2 bytes from U2, then 2 bytes from U1, and repeat.
This should recreate the copyrom extraction found in Kansas.ROM. But, unless I am very confused, it does not.
I'd appreciate the help of anyone who wants to look at the files and see if they can find some kind of reordering that makes it work.
Doug, it's possible that they used some kind of encryption scheme, but I expect it to be unlikely. Any such arrangement would ultimately slow down machine performance.
I hope that it's a simple situation in which all the bits of each 64 bit word are reversed or some such. I just haven't had time to look at it myself yet, and I'm not as skilled at such analysis as many of your folks. So, in my previous post, I put it out here for others to examine.
Besides, it would be good to be able to get a useful backup of our X500/X600 machines using Copyrom.
I hope that it's a simple situation in which all the bits of each 64 bit word are reversed or some such. I just haven't had time to look at it myself yet, and I'm not as skilled at such analysis as many of your folks. So, in my previous post, I put it out here for others to examine.
Besides, it would be good to be able to get a useful backup of our X500/X600 machines using Copyrom.
I started taking a little look at the files after posting, and I am going to tentatively say that Kansas.ROM is a bad extraction and that from7 and from9 (identical, according to diff) are probably good.
My reason for surmising that is that at location 0x0000 0C80 I find the text:
Sony..Sound...EDisk...Backlight.display.device_type.....class-code..driver-ref..
in the latter two, but only garbage in the Kansas.ROM file.
Going to 0x0000 0320 (C80 / 4) in U4, I find:
oSDEaB.t.yt_..ocvi..
Which does seem to indicate a reversal of the byte order, but it also doesn't quite match up to a four to one ratio. I wonder if Copyrom inserted some extraneous bytes. Hmmm, but the total bytes are correct.
Let's see, at 0x0000 0320 (C80 / 4) in U3, I find:
yn.d.kilpsiv.esa..r-
At 0x0000 0320 (C80 / 4) in U2, I find:
......hgalec..-srdfen
At 0x0000 0320 (C80 / 4) in U1, I find:
oSnusikcidedpylcedremHp
Then interleaving these 2 bytes at a time and reversing the byte order yields
Sony..SoEDd...un
Hmmmm.. That's not working so good. What if I switch U4 and U1, so now I do U1, U3, U2, U4
Sony..Sound...EDisk...Backlight.display.device_type.....class-code..driver-ref..
Huh. Well, I wonder if that's all there is to it. Anyone want to write a little script to test it for the whole file? I could but it would take me days. So if one of the folks who's good at scripting would like to do it I would really appreciate it.
Ideally, such a script should take from7.ROM or from9.ROM, deinterleave them two bytes at a time into four segments. But reverse the order of the two bytes when putting them into each segment.
My reason for surmising that is that at location 0x0000 0C80 I find the text:
Sony..Sound...EDisk...Backlight.display.device_type.....class-code..driver-ref..
in the latter two, but only garbage in the Kansas.ROM file.
Going to 0x0000 0320 (C80 / 4) in U4, I find:
oSDEaB.t.yt_..ocvi..
Which does seem to indicate a reversal of the byte order, but it also doesn't quite match up to a four to one ratio. I wonder if Copyrom inserted some extraneous bytes. Hmmm, but the total bytes are correct.
Let's see, at 0x0000 0320 (C80 / 4) in U3, I find:
yn.d.kilpsiv.esa..r-
At 0x0000 0320 (C80 / 4) in U2, I find:
......hgalec..-srdfen
At 0x0000 0320 (C80 / 4) in U1, I find:
oSnusikcidedpylcedremHp
Then interleaving these 2 bytes at a time and reversing the byte order yields
Sony..SoEDd...un
Hmmmm.. That's not working so good. What if I switch U4 and U1, so now I do U1, U3, U2, U4
Sony..Sound...EDisk...Backlight.display.device_type.....class-code..driver-ref..
Huh. Well, I wonder if that's all there is to it. Anyone want to write a little script to test it for the whole file? I could but it would take me days. So if one of the folks who's good at scripting would like to do it I would really appreciate it.
Ideally, such a script should take from7.ROM or from9.ROM, deinterleave them two bytes at a time into four segments. But reverse the order of the two bytes when putting them into each segment.
My results are here:
Code:
$ gcc kansas_deinterleave.c
$ ./a.out from7.ROM
$ md5sum kansas_deinterleaved_U*
dcb9c84bbeaab166bd99d44882c1e9b1 kansas_deinterleaved_U1.bin
ca50e54c2619a98e1c6f84cbfb721f34 kansas_deinterleaved_U2.bin
4dec259aa83081b5e7d58ddae516fa36 kansas_deinterleaved_U3.bin
595874aa22e6db1c974ac7d0f4c7f7ea kansas_deinterleaved_U4.bin
$ md5sum Kansas_U*
dcb9c84bbeaab166bd99d44882c1e9b1 Kansas_U1.bin
4dec259aa83081b5e7d58ddae516fa36 Kansas_U2.bin
ca50e54c2619a98e1c6f84cbfb721f34 Kansas_U3.bin
595874aa22e6db1c974ac7d0f4c7f7ea Kansas_U4.bin
Ooo. Someone have a 9700 with which to test it?
Someone across the pond and lil'-'ole me too! [
] ]'>
] ]'>Excellently cool, bbraun! Thank you!
I don't seem to have permission to download those files. I see that the checksums match. Although file U2 and U3 are reversed, which is no matter, as long as I remember that the deinterleaver's U2 is my U3 and vice versa.
I want to run a Unix diff on them, although that shouldn't really tell me anything new. That is so cool.
So it was a big vs. little endian thing, I think.
And I learned that I have the chip ordering of U1, U2, U3, U4 wrong with respect to the ordering of the data bus. I know how that happened. I used a Beige G3 ROM with just two 32 bit wide chips on it to determine the data order. One of the chips was labeled High and one was labeled Low, and I assumed that referred to the most significant double-bytes, but it apparently referred to the least significant double-bytes.
So instead of Low containing 1 - 32, it contained 1 - 16 and 33 - 48. While High contains 17 - 32 and 49 - 64, where I thought it contained 33 - 64.
This caused me to mis-order the four chips on the conventional ROM.
It never affected me before now, because I've been using data read directly from the chips, and I know which chips the data came from. But now, I need to be able to relate the portions of full words, to their correct 16 bit segments in the ROM chips.
Will I need to install gcc to run the deinterleave program? How difficult will that be? I should be able to throw up or point to that PEx extraction, if you're willing to run your deinterleaver on that.
Then OlePigeon, comes the next part. Put the deinterleaved code on chips. Solder the chips to one of my modules (after desoldering the current occupants) and then off to James in the UK, or to JT more locally for testing. Once it's working, I'll make another one, so they both can have one.
The only thing left to worry about is whether the PEx uses the same byte ordering as the x500/x600. There's really no reason that the data lines on the ROM module can't be swapped in any order from machine model to machine model. But I don't see any way we could determine that without re-borrowing the PEx ROM module from the computer museum where James borrowed it in the first place. And even then, I think I'd have to desolder and read at least one of the chips on the module.
So, fingers crossed that the data lines are in the same order from X500/X600 to PEx. Hmmm. I have the Beige G3 data at home. I could boot it up, run CopyROM on it. And do the same deinterleaver comparison between the chip information and the copyrom extraction. If the Beige G3 (same generation as PEx) uses the same byte ordering as the X500/X600, then there's a very very good chance that the PEx does too.
Hey, great! I'm glad you guys got it all figured out with the interleaving. Good to know it wasn't some obscure encryption algorithm.
Sorry to sound clueless here, but what exactly is this project? I think it started before I was around so I'm only seeing half of the story. Do you have an in-system dump of a PEx ROM that you are going to try (using your custom ROM DIMM) with some ROM-less PEx machines to bring them back to life?
Can't wait to see the results :-D
Sorry to sound clueless here, but what exactly is this project? I think it started before I was around so I'm only seeing half of the story. Do you have an in-system dump of a PEx ROM that you are going to try (using your custom ROM DIMM) with some ROM-less PEx machines to bring them back to life?
Can't wait to see the results :-D
I've fixed the permissions, sorry about that.
I've also included a 32bit Ubuntu binary and a 64bit SnowLeopard (OSX 10.6) binary of the program. If you've got another system, you'll need gcc or some other compiler to build the binary, but once built you won't need gcc to run it. If you're on a unix-like system, that should be pretty easy although the process varies by system. If you're on Windows, I can't really help you much.
I've also included a 32bit Ubuntu binary and a 64bit SnowLeopard (OSX 10.6) binary of the program. If you've got another system, you'll need gcc or some other compiler to build the binary, but once built you won't need gcc to run it. If you're on a unix-like system, that should be pretty easy although the process varies by system. If you're on Windows, I can't really help you much.
Nevermind my question earlier. I did some Googling and I think I'm caught up now. This is exciting, and I hope it works!
Edit (response to jt below): yep, found them all!
Edit (response to jt below): yep, found them all!
DQ, you found the PEx threads over on 'fritter and here as well? :?:
Thank you, again, bbraun. I really appreciate it.
I'll need to look into installing gcc on a local machine. I do not have any machines that can run 10.6 -- no Intel Macs yet. And my partner's MDD (Tiger) is down at the moment. It's hard drive gave its final gasp last week. Would you be willing to run the software for me two more times? I think two more de-interleavings and this project will be all but finished.
I didn't have any time this weekend to work on it, unfortunately.
Anyway, here's my plan based on what we learned last week:
1) I'll upload the files for the Beige G3, just like for the 9600. So I'll upload the four files for the ROM chips I've read from the Beige G3. And I'll make a CopyROM dump of the Beige G3 and upload that. Then compare the files and, I hope, find that they have the same relationship to each other found for the 9600.
2) If the Beige G3 follows the same pattern, then it would be very strange if the PEx does not as well. So, deinterleave the PEx extraction(s) that we have, and burn the resulting files to chips and mount them on a ROM module.
I'll need to look into installing gcc on a local machine. I do not have any machines that can run 10.6 -- no Intel Macs yet. And my partner's MDD (Tiger) is down at the moment. It's hard drive gave its final gasp last week. Would you be willing to run the software for me two more times? I think two more de-interleavings and this project will be all but finished.
I didn't have any time this weekend to work on it, unfortunately.
Anyway, here's my plan based on what we learned last week:
1) I'll upload the files for the Beige G3, just like for the 9600. So I'll upload the four files for the ROM chips I've read from the Beige G3. And I'll make a CopyROM dump of the Beige G3 and upload that. Then compare the files and, I hope, find that they have the same relationship to each other found for the 9600.
2) If the Beige G3 follows the same pattern, then it would be very strange if the PEx does not as well. So, deinterleave the PEx extraction(s) that we have, and burn the resulting files to chips and mount them on a ROM module.
Last night I uploaded the Beige ROM chip contents to:
http://www.prismnet.com/~trag/Firmware/Beige/
The files Beige_C_U1.bin, Beige_C_U2.bin, Beige_C_U3.bin, and Beige_C_U4.bin are the files for the chips.
I also made four dumps of my Beige G3 and put them in that folder, but none of them match each other, and for reasons explained below, I believe that all four of them are garbage.
I pulled some code out of the chip files at address (you need a hex editor to see what I'm discussing here) 0x0000 0310:
U1:
..OY. . P"uN.d.ker..mHp.. C./
U3:
sn./@ .gR ......ne.. . Q .../
U2:
dr . ) . oSDECB....n U$ A #./
U4:
.f."" . .NnusicS....mHjH. #
Interleaving it by taking two bytes at a time from each chip, and reversing the order of those two bytes (characters), yields the following:
..nsrdf.YO/. ". . @ . . .g. ) ."P R .N.Nu..Sound...EDisk...BCScreen............Hm nHm.p .$UHj . QA .C ..# # /./././<
Which is not to be found anywhere in the extracts I made, but it is found starting at address 0x0C40 (0x0310 X 4) in the extract at the Mac ROM archive.
There's another big useful chunk of text at 0x1ACB in the Beige extract and it corresponds with text found in the chip files a little before 0x06B0, although I haven't done a full decode to be absolutely certain.
So, this suggests that the interleave/deinterleave method is the same for the Beige G3 as for the 9600, which is promising when it comes to deinterleaving the PEx extract.
Now, on to the PEx extracts. I have various ones on hand. I'll try to get those uploaded soon. The question will be how do they differ, and which one do I use? There are 3 MB and 4 MB versions, and I hope that all the 3 MB versions are identical to each other and all the 4 MB versions are identical to each other. That would simplify matters to choosing between those two, or using them both and seeing which one works.
http://www.prismnet.com/~trag/Firmware/Beige/
The files Beige_C_U1.bin, Beige_C_U2.bin, Beige_C_U3.bin, and Beige_C_U4.bin are the files for the chips.
I also made four dumps of my Beige G3 and put them in that folder, but none of them match each other, and for reasons explained below, I believe that all four of them are garbage.
I pulled some code out of the chip files at address (you need a hex editor to see what I'm discussing here) 0x0000 0310:
U1:
..OY. . P"uN.d.ker..mHp.. C./
U3:
sn./@ .gR ......ne.. . Q .../
U2:
dr . ) . oSDECB....n U$ A #./
U4:
.f."" . .NnusicS....mHjH. #
Interleaving it by taking two bytes at a time from each chip, and reversing the order of those two bytes (characters), yields the following:
..nsrdf.YO/. ". . @ . . .g. ) ."P R .N.Nu..Sound...EDisk...BCScreen............Hm nHm.p .$UHj . QA .C ..# # /./././<
Which is not to be found anywhere in the extracts I made, but it is found starting at address 0x0C40 (0x0310 X 4) in the extract at the Mac ROM archive.
There's another big useful chunk of text at 0x1ACB in the Beige extract and it corresponds with text found in the chip files a little before 0x06B0, although I haven't done a full decode to be absolutely certain.
So, this suggests that the interleave/deinterleave method is the same for the Beige G3 as for the 9600, which is promising when it comes to deinterleaving the PEx extract.
Now, on to the PEx extracts. I have various ones on hand. I'll try to get those uploaded soon. The question will be how do they differ, and which one do I use? There are 3 MB and 4 MB versions, and I hope that all the 3 MB versions are identical to each other and all the 4 MB versions are identical to each other. That would simplify matters to choosing between those two, or using them both and seeing which one works.
FWIW, I ran the deinterleaver on the Beige_from_archive.ROM and this is what I got, for comparison. Looks the same as the 9600.
Code:
6dda0485f44f7f6f95359c8f9589a498 Beige_C_U1.bin
3ace31899d7eda8dc8db8d22630384ec Beige_C_U2.bin
7d98cb7730188ccb1950f2b0ac0ddf7a Beige_C_U3.bin
41f300d0f7c7ac6b635eb68e55835c37 Beige_C_U4.bin
6dda0485f44f7f6f95359c8f9589a498 beige_deinterleaved_U1.bin
7d98cb7730188ccb1950f2b0ac0ddf7a beige_deinterleaved_U2.bin
3ace31899d7eda8dc8db8d22630384ec beige_deinterleaved_U3.bin
41f300d0f7c7ac6b635eb68e55835c37 beige_deinterleaved_U4.bin
Okay, I put a bunch of PEx extractions into:
http://www.prismnet.com/~trag/Firmware/PEx/
I ran a Hex Compare of the files and all the 3MB files are identical, including the one from the ROM archive which they called a bad dump.
The 4MB files are identical to each other, and they are identical to the 3MB files through the first 3MB. In other words, the 4MB files have extra stuff at the end.
The 4MB files are the ROM_grabber... files. Everything else is 3MB.
So, which do I use?
If I make a ROM with the 3MB files, the upper 1MB is going to be blank, or unprogrammed. I may as well use the 4MB files. I can't see where loading that upper 1MB with garbage would be worse than leaving it blank.
http://www.prismnet.com/~trag/Firmware/PEx/
I ran a Hex Compare of the files and all the 3MB files are identical, including the one from the ROM archive which they called a bad dump.
The 4MB files are identical to each other, and they are identical to the 3MB files through the first 3MB. In other words, the 4MB files have extra stuff at the end.
The 4MB files are the ROM_grabber... files. Everything else is 3MB.
So, which do I use?
If I make a ROM with the 3MB files, the upper 1MB is going to be blank, or unprogrammed. I may as well use the 4MB files. I can't see where loading that upper 1MB with garbage would be worse than leaving it blank.
As my Pex Board lacks the Video Subsystem, that PLCC ROM pair in it probably matches up with the smaller of the ROM SIMM versions . . .
. . . in the case that it matches either of the two versions. :-/
Does James have a fully populated revision of the PEx ProtoBoard?
Where, oh where, are you Captain Z? :?:
trag, do you know how hawaaiicruiser's 'fritter PEx Boot Campaign turned out?
. . . in the case that it matches either of the two versions. :-/
Does James have a fully populated revision of the PEx ProtoBoard?
Where, oh where, are you Captain Z? :?:
trag, do you know how hawaaiicruiser's 'fritter PEx Boot Campaign turned out?
Excellent. Thank you! That was fast work. I was going to PM you, but no need.
Would you please run it one more time, on one of the get_ROM_pex_0[n] files located here:
http://www.prismnet.com/~trag/Firmware/PEx/
And would you please put the resulting files where I can download them? That should complete the decoding portion of this project and all that will remain is to put the code onto modules and see if it works.
I also ran a hex compare of the PEx and Beige files, but the utility I used is pretty bad (and they want $15 for it in 29 days). The code is very similar up to a point and then one gets offset from the other by about ten bytes (or maybe 26) and then the compare utility claims that they're different, but eyeballing it, it's still mostly the same code, just offset by a some bytes.
JT are you saying you're lacking the two PLCC flash chips as well as the firmware/ROM module?
James sent me copies of the PLCC chip contents, so I could probably whip up a pair of those. He's labeled them odd and even, so we'll need to figure out which goes in what socket. If he doesn't comment here, I'll email him.
James has a board with the PLCC sockets filled, but lacking the ROM module. He was able to borrow a ROM module long enough to make the PEx extractions which I've put up.
I think I read the Fritter thread(s) but it was so long ago I don't remember any details.
James sent me copies of the PLCC chip contents, so I could probably whip up a pair of those. He's labeled them odd and even, so we'll need to figure out which goes in what socket. If he doesn't comment here, I'll email him.
James has a board with the PLCC sockets filled, but lacking the ROM module. He was able to borrow a ROM module long enough to make the PEx extractions which I've put up.
I think I read the Fritter thread(s) but it was so long ago I don't remember any details.