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

Upgrading the ROM of a PM9600.

DarthNvader

Well-known member
So I have a PowerMac 9600 that has a ROM slot, presumably if Apple ever wanted to update the 4MB Boot ROM for these machines and the other Old World Mac's that had the ROM Slot they just needed a ROM Upgrade SIMM.

It looks like the Beige G3 ROM SIMM is Pin compatible, so maybe someone that has designed PCB's could design a ROM SIMM PCB?

Elliot Nunn has created a tool that will decode the 4MB ROM image into its' parts where we can make edits/upgrades and it will also rebuild those ROM images.

Something that could be useful for Old World machines is we could upgrade the NanoKernel, upgrade Open Firmware, or replace Open Firmware with OpenBIOS of SLOF. We could upgrade the ATA manager or add 'ndrv's.

In real world use we could add support for booting from PCI cards like Firewire and USB and we could also add some words to the dictionary to add support for nVidia cards like the PCI GeForce 6200 ( Core Image on Old World Macs ). We could also add the Multi-boot boot picker found in New World Macs.

Also we could add support for the firmware to be able to read HFS/HFS+ disks from Open Firmware.
 

Attachments

  • IMG_0318.jpeg
    IMG_0318.jpeg
    2 MB · Views: 8
  • IMG_0319.jpeg
    IMG_0319.jpeg
    2 MB · Views: 8
  • IMG_0320.jpeg
    IMG_0320.jpeg
    2 MB · Views: 6
  • IMG_0321.jpeg
    IMG_0321.jpeg
    2.1 MB · Views: 7

Cory5412

Daring Pioneer of the Future
Staff member
This is a neat idea, it could just be that the people who have designed PCBs just don't have time for this right now, and/or it's a little newer than their usual interest areas.

I don't know if there's a good way to store "proposed projects" like this, at least without the wiki (and, a "proposed projects" or "ideas for the taking" thread wouldn't do bad there once we get it back, someone would just need to curate it a bit).

If the software had a visual task board built in I'd suggest that but it feels a bit too much like prioritizing and assigning work for a hobby space.
 

trag

Well-known member
It looks like the Beige G3 ROM SIMM is Pin compatible, so maybe someone that has designed PCB's could design a ROM SIMM PCB?

@Cory5412 @cheesestraws @mdeverhart

Already done back around 2002, see top board in images. Sorry I missed this when it was current. I didn't have much time for forums last year.

Do not exchange ROMs between the Beige G3 and the X500/X600 series. The Beige G3 module is wired for 3.3V and all the others are wired for 5V, although, it probably shouldn't do any harm, unless you put a Beige ROM in a 5V machine.

If you read through this really long thread, you'll see that we built modules for the ANS as well. It uses the same module:

https://68kmla.org/bb/index.php?threads/pex-rom-project.23568/

Around page 7 there's an excursion into discussing building a programmable ROM module and programming tool. Just discussion. After I got these ROMs made and delivered, I got busy again.

Ah, images on new modules from JLCPCB at this post: https://68kmla.org/bb/index.php?threads/pex-rom-project.23568/post-417205

The NuBus PowerMacs, X500/X600 series, PM7200, PM7300, Beige G3, ANS (Apple Network Server) and the never released 9700 (pEX) all use the same ROM module.

I have the pinout here: http://sphinxgroup.org/Apple_pinouts/Firmware_Module_Pinout.txt and that file was in the 68Kmla wiki.

If you track down the NuBus PowerMac Apple Hardware Developer Note, you'll find that there is a pinout for the Cache module in the NuBus PowerMacs. Apple used the same slot connector for the cache and the ROM in the NuBus PowerMacs, and one can install the cache or ROM in either slot. So the Cache pinout in the Hardware Developer Note is actually a slightly more accurate pinout than my hard-won documentation....

Fronts

ROM_Modules_front.jpg
Backs

ROM_Modules_back.jpg
 

trag

Well-known member
Hey DarthNvader, so the ROM slot it's empty by default on the 9600?

Except some very early 9600s, the ROM chips are soldered to the logic board and the ROM DIMM socket is empty.

However, the ROM DIMM socket and DIMM module are designed such that installing a ROM DIMM module in the socket will disable the on-board (motherboard) ROM chips.

One of the pins in the ROM DIMM socket is wired to the soldered-down ROM chips' CE_ pin. The ROM DIMM module connects that pin to 5V and when 5V hits the CE_ pins on the ROM chips, they are disabled, because that changes "Chip Enable" to "Inactive".
 

joevt

Well-known member
In real world use we could add support for booting from PCI cards like Firewire and USB and we could also add some words to the dictionary to add support for nVidia cards like the PCI GeForce 6200 ( Core Image on Old World Macs ). We could also add the Multi-boot boot picker found in New World Macs.

Also we could add support for the firmware to be able to read HFS/HFS+ disks from Open Firmware.
There's now ROMs for the 6200 and newer Nvidia cards (6600, 7800, etc.) up to 512 MB VRAM for Old World Macs (and they should continue to work for New World Macs).

For FireWire and USB and HFS+ and Multi-boot, my idea would be to port patches and packages to Old World Open Firmware from a New World Mac such as a Quad G5. Initially, the firmware would be loaded from a supported SCSI or IDE disks's partition.
Multi-boot notes: #225
USB notes: #76
The last New World Macs have support for GPT booting: #51 so that's where I would get the disk-label and mac-parts package from. They have HFS+ and FAT support for partitions or whole disk. #58

fcode images for PCI cards (either by vendor/device ID or pci class code) can be added so that you don't need to flash PCI cards which helps with PC PCI cards that are difficult to flash, or don't have enough room for an Open Firmware image, or don't have a ROM at all).
 

Phipli

Well-known member
For FireWire and USB and HFS+ and Multi-boot, my idea would be to port patches and packages to Old World Open Firmware from a New World Mac such as a Quad G5. Initially, the firmware would be loaded from a supported SCSI or IDE disks's partition.
How would you best recommend loading from disk? With the need for a PC formatted disk it can be tricky in machines with a single disk - is a second disk mandatory?
 

joevt

Well-known member
How would you best recommend loading from disk? With the need for a PC formatted disk it can be tricky in machines with a single disk - is a second disk mandatory?
Instead of reading from a file system (since Old World Open Firmware can't read files from HFS or FAT partitions and floppies are slow and tiny), I would have the nvramrc script read blocks from a partition of a supported disk (IDE or SCSI) that works before probe-all has been called.

The partition can be created in Mac OS X. It will be really small (a few megabytes). It would have a special type that is not automatically mounted by the OS. Since the partition will be on an internal disk and won't move or change size, the nvramrc script can just read from fixed block numbers of a specific disk. The partition won't contain a file system. It will just contain a binary blob like how Open Firmware is arranged in ROM.

As a simple test, I would try reading the partition table of the disk. There's some code at #222 to list the partitions of a disk. I have yet to try that from an nvramrc script.

The nvramrc script would look like this:
Code:
install-console \ so that we can output messages from our new code before nvramrc finishes
\ do some patches required for reading blocks from a disk (if any)
\ setup buffers - maybe use alloc-mem
\ open the disk using find-device and open-dev
\ read blocks from disk to buffers using read-blocks
\ execute the code in the buffers which will do the following:
\ - make additional patches (including making probe-device do byte-load-file for unknown PCI devices)
\ - add our fcode images to the @startvec >fcfiles chain so that byte-load-file can find them.
\ - replace or add packages (disk-label, mac-parts, multi-boot, etc.)
probe-all \ pci devices
\ probe USB and FireWire for HID and mass storage devices.
\ do multi-boot if option key is being held down.
banner

For creating the code, I would have to update my fcode tokenizer to handle Apple Open Firmware local variables and some features that exist in New World Macs. The code could be text instead of fcode, but it would be much larger in size.
 

DBJ314

Member
How would you best recommend loading from disk? With the need for a PC formatted disk it can be tricky in machines with a single disk - is a second disk mandatory?
If you put a Driver Descriptor Map at the start of the GPT-formatted disk right where the boot block would be, the ROM will use it to try and load a 68k driver. The ROM will do so even if it doesn't understand the rest of the disk. That driver can then set NVRAM and reboot to make OF load code from the right place on disk. This will let it work even on systems without a PRAM battery.

If you do an incredible amount of magic, it doesn't even compromise the boot block's ability to be used as an x86 boot block. https://mjg59.dreamwidth.org/11285.html
 
Top