Jump to content


  • Content Count

  • Joined

  • Last visited

Recent Profile Visitors

251 profile views
  1. elliotnunn

    Backporting HFS+ to Mac OS 8.0 and earlier

    Yes, this will fail on 68k machines except the Quadra 900 (and possibly similar Quadras). I apologise for not making this clearer -- I documented it poorly, then forgot about it myself. The reason is that 8.1 introduces a required patch via the "gusd/gtbl/gpch" mechanism. I have narrowed down the resources required by crudely swapping them in from 8.1, but I have only done this on the Q900 emulated by Basilisk II. The purpose and function of the underlying patch are not yet clear. There seems to be some interest now, so I'll get back to work on it.
  2. elliotnunn

    Backporting HFS+ to Mac OS 8.0 and earlier

    Ship your Cube to me and I'll sort it out. You can use one of the whole bootable .dsk files from TestImages.tmp, and mount it using Disk Copy (I think -- perhaps the type/creator needs to be set). The .rdump files store resource fork data (in a format compatible with Apple's Rez utility), and the .idump files store the type/creator code (in the same format as the PkgInfo file inside a Mac OS X .app bundle). I settled on this scheme after struggling to preserve and manipulate this old-fashioned metadata on my macOS 10 machines.
  3. Hi all, I have had some success with adding HFS+ support to previously unsupported System versions. Briefly, Mac OS 7.6 and 8.0 on PowerPC work well, and I have managed to get 68k versions working with a rather inelegant hack. Here is a longer writeup: https://github.com/elliotnunn/HFSPlusBackport Hacking on the project yourself should be pretty easy. I am hoping that somebody with a bit of 68k-foo can help me dig deeper. I hope to add support for as many Mac OS versions as possible, and give users the option of installing an INIT or patching their System resources directly. Happy hacking, Elliot
  4. Anywhere that an interested hacker might browse the source? This is my second attempt at wrapping System 7 disk images around a source code tree. I would be very interested in targeting MACE or AMS as well as the current crop of hardware emulators. https://github.com/elliotnunn/BuildCubeE/
  5. elliotnunn

    PowerExpress/PowerMac 9700 Prototype

    Hi captainserial! This is the first time I’ve chanced upon an OldWorld Mac showing a NanoKernel v2 termination log. It sure looks out of place! Would you mind if I snagged a copy of the System file on this machine? I suspect it might be a bit of an oddball. Here’s my NK stuff: https://github.com/elliotnunn/powermac-rom Cheers, Elliot
  6. elliotnunn

    Picking apart the NewWorld ROM

    The Classic Environment abstracts OS 9 way away from the hardware, so no joy there. Nanopico (of the MacOS9Lives forum) and I have been putting our heads together and working out the NewWorld boot process. Getting the PCI bridge and interrupt controller working would be the first steps, and then writing basically a new Southbridge driver for all the IO to work. Apple's PCI driver architecture was actually quite nice, so this wouldn't be absolutely intolerable. I'm now working here: http://macos9lives.com/smforum/index.php/topic,2727.msg20226.html
  7. elliotnunn

    Picking apart the NewWorld ROM

    Cheers! Anyone have any experience hacking on 4 MB Power Mac ROMs?
  8. Hi folks, This post might meander a bit, because I'm sleepy, so I do apologise. I really wanted to post this now that I've had some success. I have written a Python script to take apart and put back together a Mac OS ROM file (a NewWorld Toolbox image -- tbxi). Just this evening I've gotten my iMac G4 to boot from one of its reassembled images. This is a first step towards getting OS 9 to run on some seriously different PowerPC hardware (G4 mini, or even G5). Much of my information has been taken from the SheepShaver source, and from the occasional stray Technote. Here it is: https://github.com/elliotnunn/cdg5 I note a few things: The "parcels-based" tbxis used by ~9.1 onwards seem to be an attempt to offload hardware-specific work from the 4 MB ROM image to the Trampoline bootloader. The real work of my script is the extraction of the parcels into an XML data structure. The Trampoline ELF executable, as well as copying and modifying the Open Firmware device tree, sets up interrupts for the Nanokernel. This implies that the Northbridge and Southbridge are largely initialised before the Mac OS and drivers take over. Little has been done to reverse-engineer 4 MB PCI Power Mac ROMs (with the notable exception of the work of the SheepShaver devs). This is a shame, because at least the "resources" in the ROM are easily unpacked. I intend to do more work here. Open Firmware imposes a hard 4 MB limit on tbxis, so their contents *must* be compressed. What a pain. The two executables after the parcels blob in the tbxi file have a fixed offset (per file at least) and must be present to boot. It would be very helpful to be able to move them and give the parcels blob some breathing space, but this is not urgent because you can just remove unnecessary driver parcels. Anyone interested in the workings of the Mac OS Nanokernel should check out PowerMacInfo from the Multiprocessing SDK, which you can find at this mirror of Apple's FTP site: http://staticky.com/ Credit is due to nanopico of MacOS9Lives for his work on this thread, which introduced me to the insides of a tbxi: http://macos9lives.com/smforum/index.php?topic=2727 Cheers, Elliot