Recent content by speakers

Tried to fix it but quotes remain mucked up. The web editor isn't helpful :confused: >hwint3 is 211C0 but the A2 was 17135E0. Right.

That indeed checks out. That R5 value gets to the expected spot! The PPC step I needed was 100000000 and more! Thanks. I'll try that next time. Yup. I don't know. I'll see if I can determine. Branch dot. A trivial spin. Machine code 48 00 00 00. Yes. DingusPPC floppy doesn't work...

It's been a while since I last repoted but I've made some progress. I've changed the thread title to reflect what I've been up to: So I first tried to get an instruction trace for booting into DBOF. I captured stdout to a file but the spew was so vast that my M4 MBA ground to a standstill -...

Yes, finger trouble. [I do also have a pm7600.] I see now that the code in machinepdm.cpp only has pm6100 properties defineed Yes. A FAT floppy is readable on my pm7100 under DBOF.

Ah, thanks. This wasn't clear from the docs and was too lazy to chase it down in the code :confused: That works. The pm7100 machine setting boots but only 8MB of RAM shows up. I'd like to be able to emulate my PM7600's discontiguous RAM layout I'm currently running the original 6100/7100 ROM...

I also chopped off the preamble and fed the PEF fto Ghidra. Your Mac Nosy listing is much more useful than Ghidra's! But it appears that this entire PEF is the Tertiary Loader responsible for loading Copland. This loader runs as an OFW client after DBOF has been loaded. The 'nkld' resource...

I'm blocked in my attempts to get DBOF to boot a BSD kernel, so I back-tracked to answer the 136MB booting question: DBOF does boot and reach the CLI with 'auto-boot?' flals. Copland proceeds to the "Microkernel initialization starting..." message but gets no further. I can connect the remote...

It failed to launch Copland with 136MB. I don't know if it got into DBOF because that was before I discovered how to override auto-boot? I'll need to re-install the larger SIMMs and that's awkward on the PM7100 since memory is under the drive chassis which requires the machine to be dismantled...

Neither changing l@ to c@ nor using the new method makes a difference. Same error exactly. :(

Yep, D11E4. And I do see translations. And dump-vt is now working for me! I've mucked further with the memory config which may be the issue (again). DBOF didn't boot when I had 8+32+32+32+32; it booted with 8+0+0+8+8 but dump-vt failed; now with 8+8+8+0+0 dump-vt is good.

It does work for OF 2.4 on my G3 (I mispoke) but on DBOF 2.0, I get translatiions, no word as you surmise. ... Using the above, I get this error when running dump-vt: 0 > dump-vt DEFAULT CATCH!, code=FFFFFFF3 at %SRR0: FF80BC14 %SRR1: 00000030 ok On-board 8MB RAM is 0x0-0x800000 with...

Thanks greatly for these code snippets which (except for dump-vt) work well on my 7100 and Beige G3. The main issue with the 7100 appears to be its discontiguous RAM. Banks are separated by awkward holes that results in OFW claim failures loading the BSD Booter, ofwboot.xcf. There's also...

Yep. In my case, a similar problem showed up after recapping and persisted after replacement of UE13. Removal of caps C10..C13 again, more cleaning with IPA and application of additional solder mask did the trick though. There's a collection of RC timer circuits sensitve to lingering cap juice...

I've now confirmed that the nvrm resource of Mac OS Loader can be edited to change the initial value of 'real-base' and 'load-base' variables etc. And it is indeed necessary to update the checksum word (16-bit word offset 2) of the resource. I use DeRez on OSX to decompile the resource fork of...

Thanks for this effort. It does seem to show that the Loader constructs nvram in memory from using a number of its resources. This is consistent with what I see in ResEdit for the Loader: This is taken from the install kit. I can edit 'auto-boot?' to false, re-install and have it take effect...