From elliotnunn at fastmail.com Mon Aug 5 10:13:41 2019 From: elliotnunn at fastmail.com (Elliot Nunn) Date: Mon, 5 Aug 2019 10:13:41 +0800 Subject: [CDG5] Just joined the mailing list In-Reply-To: <840079247.9449210.1551766616052@mail.yahoo.com> References: <840079247.9449210.1551766616052.ref@mail.yahoo.com> <840079247.9449210.1551766616052@mail.yahoo.com> Message-ID: <087A452D-C588-4832-A832-97C6D543C5CE@fastmail.com> Jubadub, Sorry this took aaaaaages! I have finally rationalised the non-MPW-dependent parts of my Mac ROM hacking system. Gone are the powermac-rom and mac-rom repos. Instead we have `tbxi`, a Python script that breaks down and rebuilds Mac ROMs down to the level of 68k ROM resources. All the patches necessary to get the mini running can be made by one script in the linked `tbxi-patches` repo, which you can tweak to your heart?s content. https://pypi.org/project/tbxi And if you want to patch the core of the 68k ROM (not needed for the mini) then this repository makes it pretty easy to patch and build the SuperMario sources. It depends only on python3, some PyPI packages, and a copy of Mini vMac. https://github.com/elliotnunn/supermario The NanoKernel repository still does not contain any buildable v2 NanoKernel, and also depends on ksherlock's mpw environment. But the powermac-rom NKv2 sources are still available if you want to figure out more NK hacks. Let me know how you go, Elliot > On 5 Mar 2019, at 2:16 pm, donots donots wrote: > > Greetings to everyone. I'm Jubadub, a passionate developer & OS 9 user with close to no knowledge on Classic Mac coding or even overall low-level programming, although I'm here precisely to change that. > > My current goal is to set up a good environment for compiling the Mac mini G4's newworld Mac OS ROM from Elliot's Github source. Afterwards, I'd like to try tinkering with it. > > On the side, I have been reading this delicious-tasting guide on PowerPC Assembly...: http://afturgurluk.org/mirrors/macintosh/www.lightsoft.co.uk_Fantasm/Beginners/begin1.html > > I'll try asking questions only if they are somehow constructive to everyone, or if I can't figure out something even after a week of banging my head against a wall. Hopefully only the former will take place. :) > > Nice to join y'all! > _______________________________________________ > cdg5 mailing list > cdg5 at ucc.asn.au > https://lists.ucc.gu.uwa.edu.au/mailman/listinfo/cdg5 -------------- next part -------------- An HTML attachment was scrubbed... URL: https://lists.ucc.gu.uwa.edu.au/pipermail/cdg5/attachments/20190805/08741955/attachment.htm From elliotnunn at fastmail.com Sat Aug 17 09:24:10 2019 From: elliotnunn at fastmail.com (Elliot Nunn) Date: Sat, 17 Aug 2019 09:24:10 +0800 Subject: [CDG5] 68k ROM patching Message-ID: Hi all, I have made a first attempt at programmatically stitching different 68k MainCode images together. This code is likely a dead end, but I thought I'd share some insights in the readme in case anyone tries a similar project. https://github.com/elliotnunn/swap68 Elliot From danielbj314 at verizon.net Mon Aug 19 09:32:07 2019 From: danielbj314 at verizon.net (Daniel B-J) Date: Sun, 18 Aug 2019 21:32:07 -0400 Subject: [CDG5] 68k ROM patching In-Reply-To: References: Message-ID: Does the focus on GoNative there mean you are investigating GoNative? Did you discover anything interesting about it? > On Aug 16, 2019, at 9:24 PM, Elliot Nunn wrote: > > Hi all, > > I have made a first attempt at programmatically stitching different 68k MainCode > images together. This code is likely a dead end, but I thought I'd share some > insights in the readme in case anyone tries a similar project. > > https://github.com/elliotnunn/swap68 > > Elliot > > _______________________________________________ > cdg5 mailing list > cdg5 at ucc.asn.au > https://lists.ucc.gu.uwa.edu.au/mailman/listinfo/cdg5 From elliotnunn at fastmail.com Mon Aug 19 09:37:02 2019 From: elliotnunn at fastmail.com (Elliot Nunn) Date: Mon, 19 Aug 2019 09:37:02 +0800 Subject: [CDG5] 68k ROM patching In-Reply-To: References: Message-ID: No and no. It?s just a large blob of code with a single entry point. > On 19 Aug 2019, at 9:32 am, Daniel B-J wrote: > > Does the focus on GoNative there mean you are investigating GoNative? > > Did you discover anything interesting about it? >> On Aug 16, 2019, at 9:24 PM, Elliot Nunn wrote: >> >> Hi all, >> >> I have made a first attempt at programmatically stitching different 68k MainCode >> images together. This code is likely a dead end, but I thought I'd share some >> insights in the readme in case anyone tries a similar project. >> >> https://github.com/elliotnunn/swap68 >> >> Elliot >> >> _______________________________________________ >> cdg5 mailing list >> cdg5 at ucc.asn.au >> https://lists.ucc.gu.uwa.edu.au/mailman/listinfo/cdg5 > > _______________________________________________ > cdg5 mailing list > cdg5 at ucc.asn.au > https://lists.ucc.gu.uwa.edu.au/mailman/listinfo/cdg5 From elliotnunn at fastmail.com Tue Aug 20 14:32:45 2019 From: elliotnunn at fastmail.com (Elliot Nunn) Date: Tue, 20 Aug 2019 14:32:45 +0800 Subject: [CDG5] Booting 9 from driver-less disks Message-ID: Hi all, The classic Mac OS requires non-floppy disks to have a driver partition to be bootable. The ROM ATA/SCSI/FW/USB Manager has a special code path to load a DRVR from this partition, and then the DRVR takes over. (After boot is completed, DRVRs can come from other sources.) This was fine when Macintosh formatting utilities routinely wrote out this driver partition. But many 9-compatible Macs either shipped with, or have ended up with, driver-less HFS boot disks. Open Firmware can read the NewWorld ROM from these disks, but the ROM then leaves the machine with an OldWorld-style blinking-question-mark-on-floppy-disk. (For reasons that I don't understand yet, the ROM sometimes relents after 25 seconds of blinking, and uses its own DRVR.) For Mac OS 8/9 to boot, the disk then needs to be reinitialised by Drive Setup or similar. This is inconvenient for tinkerers, and a show-stopper on machines with limited I/O options. By the time this problem is encountered, the NewWorld ROM is already safely loaded into RAM. Now, with our ability to patch the NewWorld ROM, we have an opportunity to produce a workaround. I have looked into this, and I think I am close to a solution. These are some of my findings about the ROM boot process, which I don't think are documented elsewhere. They focus on the ATA Manager, but the Monster Disk Driver Technote suggests that SCSI will work the same way. The .ATALoad DRVR in ROM (ID -20175) uses accRun time to scan for new ATA drives, and load their ATA drivers. It can be signalled to do this by the 10.x ROM function at offset 0x5D940, and possibly by another mechanism as more disks come online. The 0x5D940 function is called in every search iteration of the ROM function FindStartupDevice. The ATA Manager has a horrible and poorly documented calling convention, but using IDA I have gotten a decent idea of the ATA Manager calls that .ATALoad makes. ATA Manager calls are used to load the driver from disk, then the driver has a special entry point at offset 8 to determine whether a given partition is bootable. At this point, I think, the driver calls the ATA Manager to "open" itself and get a slot in the unit table. So one option is to patch ATALoad to "see" a driver partition where there is none. It would be difficult to automate such a patch to work with different versions, because the relevant function is compiled from C, so register allocations might change frequently. At the moment I am not near a real Mac, but in Qemu, I have noticed that the 68k ROM glue to the StartLib function GetStartupDevice returns an error when the driver partition is missing. This suggests that the native StartLib parcel PEF is unable to interpret the "bootpath" property of the "chosen" node without the help of the DRVR. I think the most elegant solution would still be to fake the presence of a driver partition. Cheers, Elliot From danielbj314 at verizon.net Tue Aug 20 20:44:51 2019 From: danielbj314 at verizon.net (Daniel B-J) Date: Tue, 20 Aug 2019 08:44:51 -0400 Subject: [CDG5] Booting 9 from driver-less disks In-Reply-To: References: Message-ID: SCSI Interface Modules have the ability to override the driver on disk for a device. SIMs seem to be the only type of Interface Module with that capability. AIMs and FWIMs can't do it. So SCSI Manager (4.3) supports fallback drivers by design and you are reversing ATA's mechanism for it. Apple restricted info on Firewire booting, so I have no idea how it works at all. It would be interesting to make a tbxi that loads and provides drivers for a RAMDisk. That would work on everything. > On Aug 20, 2019, at 2:32 AM, Elliot Nunn wrote: > > Hi all, > > The classic Mac OS requires non-floppy disks to have a driver partition to be > bootable. The ROM ATA/SCSI/FW/USB Manager has a special code path to load a DRVR > from this partition, and then the DRVR takes over. (After boot is completed, > DRVRs can come from other sources.) > > This was fine when Macintosh formatting utilities routinely wrote out this > driver partition. But many 9-compatible Macs either shipped with, or have ended > up with, driver-less HFS boot disks. Open Firmware can read the NewWorld ROM > from these disks, but the ROM then leaves the machine with an OldWorld-style > blinking-question-mark-on-floppy-disk. (For reasons that I don't understand yet, > the ROM sometimes relents after 25 seconds of blinking, and uses its own DRVR.) > > For Mac OS 8/9 to boot, the disk then needs to be reinitialised by Drive Setup > or similar. This is inconvenient for tinkerers, and a show-stopper on machines > with limited I/O options. > > By the time this problem is encountered, the NewWorld ROM is already safely > loaded into RAM. Now, with our ability to patch the NewWorld ROM, we have an > opportunity to produce a workaround. > > I have looked into this, and I think I am close to a solution. These are some of > my findings about the ROM boot process, which I don't think are documented > elsewhere. They focus on the ATA Manager, but the Monster Disk Driver Technote > suggests that SCSI will work the same way. > > The .ATALoad DRVR in ROM (ID -20175) uses accRun time to scan for new ATA > drives, and load their ATA drivers. It can be signalled to do this by the 10.x > ROM function at offset 0x5D940, and possibly by another mechanism as more disks > come online. The 0x5D940 function is called in every search iteration of the ROM > function FindStartupDevice. The ATA Manager has a horrible and poorly documented > calling convention, but using IDA I have gotten a decent idea of the ATA Manager > calls that .ATALoad makes. ATA Manager calls are used to load the driver from > disk, then the driver has a special entry point at offset 8 to determine whether > a given partition is bootable. At this point, I think, the driver calls the ATA > Manager to "open" itself and get a slot in the unit table. > > So one option is to patch ATALoad to "see" a driver partition where there is > none. It would be difficult to automate such a patch to work with different > versions, because the relevant function is compiled from C, so register > allocations might change frequently. > > At the moment I am not near a real Mac, but in Qemu, I have noticed that the 68k > ROM glue to the StartLib function GetStartupDevice returns an error when the > driver partition is missing. This suggests that the native StartLib parcel PEF > is unable to interpret the "bootpath" property of the "chosen" node without the > help of the DRVR. I think the most elegant solution would still be to fake the > presence of a driver partition. > > Cheers, > > Elliot > > _______________________________________________ > cdg5 mailing list > cdg5 at ucc.asn.au > https://lists.ucc.gu.uwa.edu.au/mailman/listinfo/cdg5 From elliotnunn at fastmail.com Tue Aug 20 20:57:16 2019 From: elliotnunn at fastmail.com (Elliot Nunn) Date: Tue, 20 Aug 2019 20:57:16 +0800 Subject: [CDG5] NanoKernel log In-Reply-To: <6C5493DC-45C5-447F-9A57-4DCB1D40EE02@yahoo.com> References: <48A390A9-A84C-47D4-8509-3747EDC68A72@fastmail.com> <7B8481B7-3152-440A-A573-03F84A8D9468@yahoo.com> <2E05D359-2B9E-44AD-BEDB-D0E1799F43A2@fastmail.com> <6C5493DC-45C5-447F-9A57-4DCB1D40EE02@yahoo.com> Message-ID: Thanks! I get the most useful results with: -prom-env aapl,debug=1000000 -serial stdio Of note: - the case of aapl,debug seems to be important - the 1000000 flag means "Enable the Nanokernel debugger? - the interactive NK debugger appears on the console :D (I?ve only ever accessed it by hacking the NK to work with a userspace app) > On 20 Aug 2019, at 7:52 pm, Jd Lyons wrote: > > -prom-env "aapl,debug=3013FFF" > >> On Aug 20, 2019, at 7:20 AM, Elliot Nunn wrote: >> >> Hmm ? not seeing anything from the NanoKernel. >> >>> On 20 Aug 2019, at 7:18 pm, Jd Lyons wrote: >>> >>> -prom-env ?aapl,debug=130fff? -nographic >> > From elliotnunn at fastmail.com Sat Aug 24 09:19:28 2019 From: elliotnunn at fastmail.com (Elliot Nunn) Date: Sat, 24 Aug 2019 09:19:28 +0800 Subject: [CDG5] Booting 9 from driver-less disks In-Reply-To: References: Message-ID: <138618A8-494C-4F49-9849-9E2416CFB7C6@fastmail.com> Got it! ?kind of This commit adds an ATALoad patch to the tbxi-patches library: https://github.com/elliotnunn/tbxi-patches/commit/9351898 ATALoad reliably falls back on the ROM ATADisk driver when no driver partition is present. In QEMU, this enables a successful boot. Not so on my Mac mini. On that machine, the ROM driver does not recognise the bootable partition as being bootable, and we get stuck at the question mark. > On 20 Aug 2019, at 2:32 pm, Elliot Nunn wrote: > > Hi all, > > The classic Mac OS requires non-floppy disks to have a driver partition to be > bootable. The ROM ATA/SCSI/FW/USB Manager has a special code path to load a DRVR > from this partition, and then the DRVR takes over. (After boot is completed, > DRVRs can come from other sources.) > > This was fine when Macintosh formatting utilities routinely wrote out this > driver partition. But many 9-compatible Macs either shipped with, or have ended > up with, driver-less HFS boot disks. Open Firmware can read the NewWorld ROM > from these disks, but the ROM then leaves the machine with an OldWorld-style > blinking-question-mark-on-floppy-disk. (For reasons that I don't understand yet, > the ROM sometimes relents after 25 seconds of blinking, and uses its own DRVR.) > > For Mac OS 8/9 to boot, the disk then needs to be reinitialised by Drive Setup > or similar. This is inconvenient for tinkerers, and a show-stopper on machines > with limited I/O options. > > By the time this problem is encountered, the NewWorld ROM is already safely > loaded into RAM. Now, with our ability to patch the NewWorld ROM, we have an > opportunity to produce a workaround. > > I have looked into this, and I think I am close to a solution. These are some of > my findings about the ROM boot process, which I don't think are documented > elsewhere. They focus on the ATA Manager, but the Monster Disk Driver Technote > suggests that SCSI will work the same way. > > The .ATALoad DRVR in ROM (ID -20175) uses accRun time to scan for new ATA > drives, and load their ATA drivers. It can be signalled to do this by the 10.x > ROM function at offset 0x5D940, and possibly by another mechanism as more disks > come online. The 0x5D940 function is called in every search iteration of the ROM > function FindStartupDevice. The ATA Manager has a horrible and poorly documented > calling convention, but using IDA I have gotten a decent idea of the ATA Manager > calls that .ATALoad makes. ATA Manager calls are used to load the driver from > disk, then the driver has a special entry point at offset 8 to determine whether > a given partition is bootable. At this point, I think, the driver calls the ATA > Manager to "open" itself and get a slot in the unit table. > > So one option is to patch ATALoad to "see" a driver partition where there is > none. It would be difficult to automate such a patch to work with different > versions, because the relevant function is compiled from C, so register > allocations might change frequently. > > At the moment I am not near a real Mac, but in Qemu, I have noticed that the 68k > ROM glue to the StartLib function GetStartupDevice returns an error when the > driver partition is missing. This suggests that the native StartLib parcel PEF > is unable to interpret the "bootpath" property of the "chosen" node without the > help of the DRVR. I think the most elegant solution would still be to fake the > presence of a driver partition. > > Cheers, > > Elliot > > _______________________________________________ > cdg5 mailing list > cdg5 at ucc.asn.au > https://lists.ucc.gu.uwa.edu.au/mailman/listinfo/cdg5 From danielbj314 at verizon.net Sat Aug 24 09:26:03 2019 From: danielbj314 at verizon.net (Daniel B-J) Date: Fri, 23 Aug 2019 21:26:03 -0400 Subject: [CDG5] Booting 9 from driver-less disks In-Reply-To: <138618A8-494C-4F49-9849-9E2416CFB7C6@fastmail.com> References: <138618A8-494C-4F49-9849-9E2416CFB7C6@fastmail.com> Message-ID: Are you doing the mini test on a CD? CD drives are ATAPI. > On Aug 23, 2019, at 9:19 PM, Elliot Nunn wrote: > > Got it! ?kind of > > This commit adds an ATALoad patch to the tbxi-patches library: > > https://github.com/elliotnunn/tbxi-patches/commit/9351898 > > ATALoad reliably falls back on the ROM ATADisk driver when no driver partition > is present. In QEMU, this enables a successful boot. Not so on my Mac mini. On > that machine, the ROM driver does not recognise the bootable partition as being > bootable, and we get stuck at the question mark. > >> On 20 Aug 2019, at 2:32 pm, Elliot Nunn wrote: >> >> Hi all, >> >> The classic Mac OS requires non-floppy disks to have a driver partition to be >> bootable. The ROM ATA/SCSI/FW/USB Manager has a special code path to load a DRVR >> from this partition, and then the DRVR takes over. (After boot is completed, >> DRVRs can come from other sources.) >> >> This was fine when Macintosh formatting utilities routinely wrote out this >> driver partition. But many 9-compatible Macs either shipped with, or have ended >> up with, driver-less HFS boot disks. Open Firmware can read the NewWorld ROM >> from these disks, but the ROM then leaves the machine with an OldWorld-style >> blinking-question-mark-on-floppy-disk. (For reasons that I don't understand yet, >> the ROM sometimes relents after 25 seconds of blinking, and uses its own DRVR.) >> >> For Mac OS 8/9 to boot, the disk then needs to be reinitialised by Drive Setup >> or similar. This is inconvenient for tinkerers, and a show-stopper on machines >> with limited I/O options. >> >> By the time this problem is encountered, the NewWorld ROM is already safely >> loaded into RAM. Now, with our ability to patch the NewWorld ROM, we have an >> opportunity to produce a workaround. >> >> I have looked into this, and I think I am close to a solution. These are some of >> my findings about the ROM boot process, which I don't think are documented >> elsewhere. They focus on the ATA Manager, but the Monster Disk Driver Technote >> suggests that SCSI will work the same way. >> >> The .ATALoad DRVR in ROM (ID -20175) uses accRun time to scan for new ATA >> drives, and load their ATA drivers. It can be signalled to do this by the 10.x >> ROM function at offset 0x5D940, and possibly by another mechanism as more disks >> come online. The 0x5D940 function is called in every search iteration of the ROM >> function FindStartupDevice. The ATA Manager has a horrible and poorly documented >> calling convention, but using IDA I have gotten a decent idea of the ATA Manager >> calls that .ATALoad makes. ATA Manager calls are used to load the driver from >> disk, then the driver has a special entry point at offset 8 to determine whether >> a given partition is bootable. At this point, I think, the driver calls the ATA >> Manager to "open" itself and get a slot in the unit table. >> >> So one option is to patch ATALoad to "see" a driver partition where there is >> none. It would be difficult to automate such a patch to work with different >> versions, because the relevant function is compiled from C, so register >> allocations might change frequently. >> >> At the moment I am not near a real Mac, but in Qemu, I have noticed that the 68k >> ROM glue to the StartLib function GetStartupDevice returns an error when the >> driver partition is missing. This suggests that the native StartLib parcel PEF >> is unable to interpret the "bootpath" property of the "chosen" node without the >> help of the DRVR. I think the most elegant solution would still be to fake the >> presence of a driver partition. >> >> Cheers, >> >> Elliot >> >> _______________________________________________ >> cdg5 mailing list >> cdg5 at ucc.asn.au >> https://lists.ucc.gu.uwa.edu.au/mailman/listinfo/cdg5 > > _______________________________________________ > cdg5 mailing list > cdg5 at ucc.asn.au > https://lists.ucc.gu.uwa.edu.au/mailman/listinfo/cdg5 From elliotnunn at fastmail.com Sat Aug 24 09:51:11 2019 From: elliotnunn at fastmail.com (Elliot Nunn) Date: Sat, 24 Aug 2019 09:51:11 +0800 Subject: [CDG5] Booting 9 from driver-less disks In-Reply-To: References: <138618A8-494C-4F49-9849-9E2416CFB7C6@fastmail.com> Message-ID: <31C0235E-3CAD-4C2D-B06F-5D53B3E815C7@fastmail.com> No, the internal drive. > On 24 Aug 2019, at 9:26 am, Daniel B-J wrote: > > Are you doing the mini test on a CD? > > CD drives are ATAPI. >> On Aug 23, 2019, at 9:19 PM, Elliot Nunn wrote: >> >> Got it! ?kind of >> >> This commit adds an ATALoad patch to the tbxi-patches library: >> >> https://github.com/elliotnunn/tbxi-patches/commit/9351898 >> >> ATALoad reliably falls back on the ROM ATADisk driver when no driver partition >> is present. In QEMU, this enables a successful boot. Not so on my Mac mini. On >> that machine, the ROM driver does not recognise the bootable partition as being >> bootable, and we get stuck at the question mark. >> >>> On 20 Aug 2019, at 2:32 pm, Elliot Nunn wrote: >>> >>> Hi all, >>> >>> The classic Mac OS requires non-floppy disks to have a driver partition to be >>> bootable. The ROM ATA/SCSI/FW/USB Manager has a special code path to load a DRVR >>> from this partition, and then the DRVR takes over. (After boot is completed, >>> DRVRs can come from other sources.) >>> >>> This was fine when Macintosh formatting utilities routinely wrote out this >>> driver partition. But many 9-compatible Macs either shipped with, or have ended >>> up with, driver-less HFS boot disks. Open Firmware can read the NewWorld ROM >>> from these disks, but the ROM then leaves the machine with an OldWorld-style >>> blinking-question-mark-on-floppy-disk. (For reasons that I don't understand yet, >>> the ROM sometimes relents after 25 seconds of blinking, and uses its own DRVR.) >>> >>> For Mac OS 8/9 to boot, the disk then needs to be reinitialised by Drive Setup >>> or similar. This is inconvenient for tinkerers, and a show-stopper on machines >>> with limited I/O options. >>> >>> By the time this problem is encountered, the NewWorld ROM is already safely >>> loaded into RAM. Now, with our ability to patch the NewWorld ROM, we have an >>> opportunity to produce a workaround. >>> >>> I have looked into this, and I think I am close to a solution. These are some of >>> my findings about the ROM boot process, which I don't think are documented >>> elsewhere. They focus on the ATA Manager, but the Monster Disk Driver Technote >>> suggests that SCSI will work the same way. >>> >>> The .ATALoad DRVR in ROM (ID -20175) uses accRun time to scan for new ATA >>> drives, and load their ATA drivers. It can be signalled to do this by the 10.x >>> ROM function at offset 0x5D940, and possibly by another mechanism as more disks >>> come online. The 0x5D940 function is called in every search iteration of the ROM >>> function FindStartupDevice. The ATA Manager has a horrible and poorly documented >>> calling convention, but using IDA I have gotten a decent idea of the ATA Manager >>> calls that .ATALoad makes. ATA Manager calls are used to load the driver from >>> disk, then the driver has a special entry point at offset 8 to determine whether >>> a given partition is bootable. At this point, I think, the driver calls the ATA >>> Manager to "open" itself and get a slot in the unit table. >>> >>> So one option is to patch ATALoad to "see" a driver partition where there is >>> none. It would be difficult to automate such a patch to work with different >>> versions, because the relevant function is compiled from C, so register >>> allocations might change frequently. >>> >>> At the moment I am not near a real Mac, but in Qemu, I have noticed that the 68k >>> ROM glue to the StartLib function GetStartupDevice returns an error when the >>> driver partition is missing. This suggests that the native StartLib parcel PEF >>> is unable to interpret the "bootpath" property of the "chosen" node without the >>> help of the DRVR. I think the most elegant solution would still be to fake the >>> presence of a driver partition. >>> >>> Cheers, >>> >>> Elliot >>> >>> _______________________________________________ >>> cdg5 mailing list >>> cdg5 at ucc.asn.au >>> https://lists.ucc.gu.uwa.edu.au/mailman/listinfo/cdg5 >> >> _______________________________________________ >> cdg5 mailing list >> cdg5 at ucc.asn.au >> https://lists.ucc.gu.uwa.edu.au/mailman/listinfo/cdg5 > > _______________________________________________ > cdg5 mailing list > cdg5 at ucc.asn.au > https://lists.ucc.gu.uwa.edu.au/mailman/listinfo/cdg5 From elliotnunn at fastmail.com Sun Aug 25 22:32:18 2019 From: elliotnunn at fastmail.com (Elliot Nunn) Date: Sun, 25 Aug 2019 22:32:18 +0800 Subject: [CDG5] Booting 9 from driver-less disks In-Reply-To: <138618A8-494C-4F49-9849-9E2416CFB7C6@fastmail.com> References: <138618A8-494C-4F49-9849-9E2416CFB7C6@fastmail.com> Message-ID: <8FD6168E-993F-42D3-9D40-B9AEDBF3D125@fastmail.com> Got it, for real! https://github.com/elliotnunn/tbxi-patches/commit/a8c1a4d The commit message describes some of the hurdles. > On 24 Aug 2019, at 9:19 am, Elliot Nunn wrote: > > Got it! ?kind of > > This commit adds an ATALoad patch to the tbxi-patches library: > > https://github.com/elliotnunn/tbxi-patches/commit/9351898 > > ATALoad reliably falls back on the ROM ATADisk driver when no driver partition > is present. In QEMU, this enables a successful boot. Not so on my Mac mini. On > that machine, the ROM driver does not recognise the bootable partition as being > bootable, and we get stuck at the question mark. > >> On 20 Aug 2019, at 2:32 pm, Elliot Nunn wrote: >> >> Hi all, >> >> The classic Mac OS requires non-floppy disks to have a driver partition to be >> bootable. The ROM ATA/SCSI/FW/USB Manager has a special code path to load a DRVR >> from this partition, and then the DRVR takes over. (After boot is completed, >> DRVRs can come from other sources.) >> >> This was fine when Macintosh formatting utilities routinely wrote out this >> driver partition. But many 9-compatible Macs either shipped with, or have ended >> up with, driver-less HFS boot disks. Open Firmware can read the NewWorld ROM >> from these disks, but the ROM then leaves the machine with an OldWorld-style >> blinking-question-mark-on-floppy-disk. (For reasons that I don't understand yet, >> the ROM sometimes relents after 25 seconds of blinking, and uses its own DRVR.) >> >> For Mac OS 8/9 to boot, the disk then needs to be reinitialised by Drive Setup >> or similar. This is inconvenient for tinkerers, and a show-stopper on machines >> with limited I/O options. >> >> By the time this problem is encountered, the NewWorld ROM is already safely >> loaded into RAM. Now, with our ability to patch the NewWorld ROM, we have an >> opportunity to produce a workaround. >> >> I have looked into this, and I think I am close to a solution. These are some of >> my findings about the ROM boot process, which I don't think are documented >> elsewhere. They focus on the ATA Manager, but the Monster Disk Driver Technote >> suggests that SCSI will work the same way. >> >> The .ATALoad DRVR in ROM (ID -20175) uses accRun time to scan for new ATA >> drives, and load their ATA drivers. It can be signalled to do this by the 10.x >> ROM function at offset 0x5D940, and possibly by another mechanism as more disks >> come online. The 0x5D940 function is called in every search iteration of the ROM >> function FindStartupDevice. The ATA Manager has a horrible and poorly documented >> calling convention, but using IDA I have gotten a decent idea of the ATA Manager >> calls that .ATALoad makes. ATA Manager calls are used to load the driver from >> disk, then the driver has a special entry point at offset 8 to determine whether >> a given partition is bootable. At this point, I think, the driver calls the ATA >> Manager to "open" itself and get a slot in the unit table. >> >> So one option is to patch ATALoad to "see" a driver partition where there is >> none. It would be difficult to automate such a patch to work with different >> versions, because the relevant function is compiled from C, so register >> allocations might change frequently. >> >> At the moment I am not near a real Mac, but in Qemu, I have noticed that the 68k >> ROM glue to the StartLib function GetStartupDevice returns an error when the >> driver partition is missing. This suggests that the native StartLib parcel PEF >> is unable to interpret the "bootpath" property of the "chosen" node without the >> help of the DRVR. I think the most elegant solution would still be to fake the >> presence of a driver partition. >> >> Cheers, >> >> Elliot >> >> _______________________________________________ >> cdg5 mailing list >> cdg5 at ucc.asn.au >> https://lists.ucc.gu.uwa.edu.au/mailman/listinfo/cdg5 > > _______________________________________________ > cdg5 mailing list > cdg5 at ucc.asn.au > https://lists.ucc.gu.uwa.edu.au/mailman/listinfo/cdg5 -------------- next part -------------- An HTML attachment was scrubbed... URL: https://lists.ucc.gu.uwa.edu.au/pipermail/cdg5/attachments/20190825/dde3c243/attachment.htm