Anonymous
User login
Please support the defense of Ukraine.
Direct or via Unclutter App
Active forum topics
Recent content
Navigation
No Ads.
No Trackers.
No Social Media.
All Content Locally Hosted.
Built on Free Software.
We have complied with zero government requests for information.
Hi,
It actually based on a blank one that Trag had left over from when he manufactuered some for Beige G3s... so the board is already done, it's a case of soldering all the components on.
It's a 4-layer design, and a design file is available from Trag.
I've asked Trag if he had any more spare ones, but he said this is the last one left - although there might be a way of finding some more... will PM you with his details...
James.
If this thing has been set up so it can actually be _used_ to the full potential for which it was designed, that would be worthy of earning you a medal!
So far the project is on the back-burner. Trag is currently assembling a flashable copy of the ROM SIMM from the Digibarn machine.
When this has been done I'll be trying to get it boot OS X again.
On the 68kMLA forum Mark Crutchfield has posted the follwing:
It's interesting to note that as his machine is probably the one that would have been mass-produced, or an extremely late testing prototype, that he notes that all of the customs chips have been removed (Denali /99/Radical). This would likely mean that any of the software support needed for this didn't make it into the OS (7.6/8) of the time, but may have been present in beta builds before the hardware was changed.
This should mean that whilst the standard functions work the additional chips and VCI slot on my prototype are unlikely to be supported fully in the classic Mac OS, and certainly not in OS X - which barely had support for the Beige G3 (and never did support the video options properly on these machines).
Will post again when the ROM SIMM arrives.
Slow but steady progress has been made with duplicating the ROM SIMM. Trag has asked me to confirm some of the layout pins on the ROM SIMM (which is actually a DIMM as the pins on both sides are different).
The details are:
I shipped him over some parts for the ROM DIMM, and he's also using some leftovers of his own to construct it.
Just thought I'd post an update in case anyone is still reading...
I'm still working on the ROM DIMM. The original plan was for me to simply make a ROM DIMM with sockets for the chips. Then James could program his own chips as needed until he got something working.
Now this is tricky, as the PEX is in the UK and I'm in Texas and ordinarily there wouldn't be any way to test that the ROM DIMM worked.
However, the ROM DIMM (the circuit board, not the chip contents) for the PEX is the same as was used in the x100 (NuBus) through the Beige G3 machines. The X500 and X600 machines use the same ROM DIMM. In the Beige G3 the Vcc (power supply) pins are shifted to different pins. This is because the Beige G3 DIMM uses 3.3V and the earlier ones (and the PEX) use 5V. That way, if you stick a 5V DIMM in a 3.3V machine or vice versa, the DIMM just doesn't get any power. This may shed some light on the results several threads back when someone tried putting a Beige G3 ROM in their PEX.
Okay, so the PEX ROM DIMM is the same. I ran off about 200 circuit boards several years ago to use as Apple ROM DIMMs and I had a few boards left over. The idea was to put chip sockets on these boards.
James supplied the sockets (PSOP44 chips) and I did that. Then to test it (see three paragraphs back) I installed PM9600 ROM chips and tried it in a PM9600. And it didn't work.
After much gnashing of teeth and pulling of hair, I decided that I just can't get these sockets to work. Not too surprising as PSOP44 sockets are tricky. But darn it. They should work.
Then I went back and confirmed that I really did know how to build a 9600 ROM and that I was using the correct chips in the correct sockets, by soldering chips directly to the boards, which has always worked for me. So that was more months (at my glacial pace) of time.
So, where we are now, almost two years after James first contacted me (yes, I'm lame and slow, but *), is I plan to solder PEX programmed chips directly to the board and send it to James. The problems with that are 1) No way to test it after I build the thing, unless Mark Crutchfield still lives in Austin, TX? 2) We're not 100% that what James has dumped from the PEX using ROM dumping utilities is an accurate reflection of what's on the ROM DIMM.
* From paranthetical comment above:
..., but, in my defense, I had the original socketed DIMM built within six months of getting the sockets from James, which was also slow, but I told him I'd be slow. So that was reasonable. It's all the testing and writhing since then that has really eaten up the time. If all the excuse making sounds like I feel guilty, well, yes, that's very perceptive of you.
Good to hear that some progress is being made. I would have hated to have this just fade away completely.
well,
even without the ROM Simm wouldn't it be possible to:
-install 0SX (10.1 or 10.2) on a PCI PowerMac with XPF 4
-get the NVRAM settings from this mac, copy them..
-install the disk in the PEX
-apply these nvram boot args with right /dev etc to the PEX nvram
?
can't get no sleep...
Hi,
This might be possible on more finished versions of the PEX (aka DigiBarn's) but the ROM SIMM seems to be needed on mine to get even a proper Open Firmware boot working.
I've tried a lot with the original PEX PLCC chips (and the updated ones that I've copied from the DigiBarn) but it really seems to need the ROM SIMM to actually boot.
However, I have not managed to get any version of OS X to boot from openfirmware under these 'ideal' conditions - so you're right this still might be a possibility without the rest of the ROM for booting OS X.
Hi,
I saw that your PEX has now a ROM SIMM and boots fine to Classic OS, then it might be possible to run XPF 4 and install 10.2?
.. or OS X Server 1.2 aka Rhapsody (the system disk CP requires then MacOS 8.6)
My return with a gem for all.
My name is Jeremy, some of you might know my by my former handle of TiMacLover, who frequented the 68kmla forum many moons ago.
I was clearing our an old storage unit of mine this past weekend, when I stumbled upon what I believe is a PEX motherboard, I acquired it some years ago through an eBay auction by a former Apple hardware engineer.
Please examine the following photos. It does not have the ROM stick
I would like to sell the item to someone who will put it to good use and value it highly. I'm not looking to roll the bank and I am considering to place it on eBay.
http://i41.tinypic.com/257hfrr.jpg
http://i41.tinypic.com/2l8kbqd.jpg
http://i42.tinypic.com/xoecme.jpg
http://i41.tinypic.com/24b850x.jpg
http://i41.tinypic.com/59u9j.jpg
Probably way too late, but that is not a PEx logic board. It looks like a development board for the 7200. It is identical to the 7200, except that the ROM chips seem to be missing, and there are some DIP switches installed, where, I think, the 7200 has resistors. It would be interesting to know what those switches/resistors control...
My guess would be processor speed.
I ran across this old thread while searching for some other material about the Beige.
I just wanted to mention that the PEx ROM (in two different versions) is finally built and on its way to the UK to jimjamyahauk.
One version seems to be working here in Oddball's PEx logic board.
Basically had to wait for my Son to go off to college to find the time. The fact that PCB fabrication is so cheap I could get 20 blank DIMM modules built for a pittance also helped. I was out of blanks and re-using old modules doesn't work very well.
Discussion here: https://68kmla.org/bb/index.php?threads/pex-rom-project.23568/
So it's been a while and Vibe coding and AI with LLMs is now a thing.
Just put an openfiremware patch through Gemini and look what it said:
As an AI, I don't have personal nostalgia for the days of holding down *Command-Option-O-F* on a Mac keyboard, but I can certainly analyze this Forth code for you. You have uncovered some classic, deep-system firmware patches for vintage Apple PowerPC machines (likely from the early "New World" ROM era, such as the Blue & White G3 or early G4s).
Here is a breakdown of what these two Open Firmware patches are doing.
### The /AAPL,ROM Environment Reset Patch
This first script modifies the load and open methods for the Mac ROM image in firmware. It acts as an environment sanitizer before the system attempts to boot the traditional Mac OS.
* **State Checking:** It checks if real_base or virt_base are set to custom values (0x400000 and -0x800000 respectively). It also checks if the system is currently running in Real Mode (real?) or Little-Endian mode (little?).
* **Enforcing Defaults:** If any of those conditions are true, the system is in an unpredictable state for a classic Mac OS boot (which expects Big-Endian and specific virtual memory mapping). It forces those environment variables back to their defaults (FFFFFFFF, false for real-mode, and false for little-endian).
* **Rebooting:** It changes the boot-command to boot from /AAPL,ROM, prints "RESETing to change Configuration!", and executes reset-all to hardware-reboot the machine into the corrected state.
### "NVRAM Patch 2": The Motherboard Bug Fixer
This is a monolithic, highly optimized patch designed to fit into a tiny NVRAM footprint. It redefines common Forth words into single-letter variables to save space, then surgically patches the CPU, Ethernet, hard drives, and SCSI controllers.
**The Space-Saving Aliases**
To understand the script, we first have to decode the author's shorthand:
| Alias | Original Forth Command | Purpose |
|---|---|---|
| $D | find-device | Targets a specific hardware node. |
| $E | device-end | Exits the current hardware node. |
| $L | BLpatch | Branches/links a patch into existing firmware. |
| $X | execute | Runs a memory address as code. |
| $p | property | Creates or modifies a device tree property. |
**1. CPU Cache Patch (ictc!)**
The script inserts raw PowerPC machine code (7E9BFBA6 l, ...) to manipulate the ictc (Instruction Cache Throttling Control) register. The $G function checks the Processor Version Register (PVR) to see if the CPU is a PowerPC 750 (G3) or 7400 (G4). If it matches, it applies the cache patch to prevent processor lockups during specific workloads.
**2. Keyboard and Boot Argument Interception**
The kbd section grabs the current state of the keyboard matrix (get-key-map). The bootr function checks for specific key combinations pressed during startup (like holding "C" to boot from CD, or typical Mac diagnostic chords) and modifies the /chosen node's machargs property to alter the boot behavior accordingly.
**3. Ethernet Controller Fix (enet)**
It targets the enet device, recalculating memory offsets to patch the WRITE and READ methods. It introduces custom wait loops (chstat and bmstat) to monitor the hardware registers. This is a classic fix for DMA (Direct Memory Access) race conditions where the Ethernet chip would time out or crash the bus under heavy network load.
**4. Partition Map Memory Fix (/packages/mac-parts)**
It overrides the memory allocation (alloc-mem) routine used when the firmware reads the partition map of a hard drive. It shifts the memory boundary by 0x8000 bytes to prevent a buffer overflow bug that occurred when reading complex or corrupted Apple Partition Maps.
**5. ATA / ATAPI Bus Reset (ata0, ata1)**
It targets the IDE/ATA controllers. It redefines the open, set-device-ID, and reset-atapi-bus routines, utilizing BLpatch to fix a bug where CD-ROM drives (ATAPI) or specific hard drives failed to initialize properly upon a warm reboot.
**6. SCSI Timing Fixes (scsi)**
It patches the SCSI command execution (do-cmd) by injecting microsecond (us) and millisecond (ms) delays between hardware calls. Vintage SCSI buses were notoriously sensitive to timing; this prevents the bus from locking up when querying slower hard drives or terminators.
**7. Motherboard Register Initialization**
The final block maps a memory space starting at ff000000 (likely the Mac's memory-mapped I/O controller, such as "Paddington" or "KeyLargo"). It checks a specific status bit and writes 90b7 to an offset (f3000032) to properly initialize a motherboard hardware component before yielding back to the firmware.
This code is a brilliant piece of firmware engineering, cramming extensive hardware errata fixes into a very constrained environment.
Are you currently trying to restore a specific model of Power Macintosh, or are you adapting these patche
s for a homebrew PowerPC project?
Pages