Search results

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

I'm able to launch the BSD boot loader (ofwboot.xcf) from the floppy but I get in dreaded OFW claim failure since I'm unable to override the real-base and load-base variables as required. I'd really like to know where the disk-based OFW is stashing nvram so I could mess with it or at least set...

Resuming after a vacation pause... I reverted my PM7100 to 24MB RAM (down from 136MB). After repairing the boot volume which was causing Copland to halt in the debugger, it then booted to Finder although it hangs there. I'm running the PowerPC debugger on my SE/30 with cable between modem...

So I went back and installed a clean System 7.5. I had to grab a copy of the original 61/71/8100 installation CD from Macintosh Garden because none of the trusty Legacy Iso install images wanted to recognize my PM7100. Copland installed again but the capslock snag key again failed to give me...

Thanks. Looking at release dates, 7.5.5 was Sept 96 whereas Copland D11E4 was June 96 .. so it may well matter.

Yes and no. On my first install, it booted back into 7.5 and I used System Picker to select the OS8 system folder. That seems to screw things and leads to the F/7FFFF SadMac. At this point I could see that the boot blocks weren't the special Copland intercepts that point to the Mac OS8 Loader...

And poking around the Copland D11E4 install kit, the previously attached ofw and nvram images are resources in the Mac OS Loader "app". And the modified boot blocks are another resource there.

This is all fascinating and covered nowhere on the web. In fact, if you now google about it, you'll be sent this this very thread! I'm attaching a design doc from the Copland DDK v.0.4 about the I/O structure including Boot Services. Copland is indeed running OpenFirmware, but disk-based...

I've tracked down the ram mis-configuration issue to a problem with BootX's PDM video re-mapping. BootX modifies the memory map passed to the kernel in a way that prevents correct discovery of simm banks. Without the nubus_simm bootarg, the kernel finds only 1MB off ram and panics. A patched...

I've recently been tinkering with some 68k assembly code in a program originally developed for MacOS7. I'm using CodeWarrior Pro 4 under MacOS9 in a Qemu emulation of a PPC machine running on my M4 MacBook Air. Qemu is Intel. So what I have is: 68k instructions emulated as PPC by the 68k...

Yes, 1 should be connected to 2.

I think it should possible to put a shorting link in the base of the terminal block between pins 9 and 10 and still be able to put the PSU in place. But I haven't ever tried this .. I have an extender cable (made by cutting down an ATX extender).

See https://github.com/speakers-k64/linux-2.4.27-pmac-nubus.git

Although the original source is nowhere to be found, I have discovered a nubus patch for Debian Sarge archived at debian-nubus.diff.gz and this applies OK to a 2.4.27 source archive from kernel.org at linux-2.4.27.tar.gz I've managed to configure and build a kernel from these sources that...