• 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.

PEx ROM Project

trag

Well-known member
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.

fw_modules_in_work1.jpg.d827ca8c39fee3ef95bdd2c1a2edea7d.jpg


fw_modules_in_work2.jpg.5add18fd53a1950defcfb4f3b230583b.jpg


fw_modules_in_work3.jpg.6cb0ebbc3a64f062021f5619cfa93f9b.jpg


 

Trash80toHP_Mini

NIGHT STALKER
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:

 

ojfd

Well-known member
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.
Could it be, perhaps, something similar to this case?

http://lowendmac.com/coventry/06/apple-ii-clones.html

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.

stolen_from_apple.gif
Full story here:

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.

?

 

trag

Well-known member
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.

 

ojfd

Well-known member
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.

 

trag

Well-known member
Ok, thanks for clarifying that!I know that some ROMs, PICs etc can be copy protected,
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.

 

trag

Well-known member
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?

 

Trash80toHP_Mini

NIGHT STALKER
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 . . . :?:

 

dougg3

Well-known member
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?

 

trag

Well-known member
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.

 

trag

Well-known member
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.

 

trag

Well-known member
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.

 

bbraun

Well-known member
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
 

trag

Well-known member
My results are here:
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.

 

dougg3

Well-known member
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

 
Top