• Hello MLAers! We've re-enabled auto-approval for accounts. If you are still waiting on account approval, please check this thread for more information.

My Mad B&W G3 Setup!

The suggestion was to switch master and slave after getting the HD to boot. Switching the devices means the HD would not have the same boot path that allowed it to boot so then it probably won't boot.

Actually, I meant after getting the CD to boot and installing a viable OS on the HDD, now would be the right moment to switch master and slave over.
 
I tend to favour practical solutions and this is the first troubleshooting step I would try, but don’t let me stop you playing with Forth code if you’d rather understand what’s going on better @Snial :)
 
Actually, I meant after getting the CD to boot and installing a viable OS on the HDD, now would be the right moment to switch master and slave over.
Vive la Révolution!
I tend to favour practical solutions and this is the first troubleshooting step I would try, but don’t let me stop you playing with Forth code if you’d rather understand what’s going on better @Snial :)
It makes sense. I like Forth, which is why I keep pestering @joevt about it. I once developed FIGnition, a DIY computer based around it - it was somewhat Jupiter Ace-ish in the word set, but it never had a proper decompiler. I don't really get the Open-firmware architecture though: I agree Forth is good for hacking, but the implementation here seems astoundingly complicated for what is essentially a BIOS. Just thinking about the number of different boot ROM architectures Apple has gone through is an eye-opener!

  1. Early 68000/OS: Toolbox+Most of System-in-ROM + Patches on disk.
  2. Late 680x0/OS: Toolbox+System on Disk (except for the Classic I with System 6.0.x in ROM).
  3. Nubus PowerPC: Toolbox+Emulator in ROM, System on Disk.
  4. PCI Old World PowerPC: Open Firmware on ROM+Toolbox?, System on Disk.
  5. PCI New World PowerPC: Open firmware on ROM, Toolbox (now "Mac OS ROM") and System (or Mac OS X) on disk.
  6. 32-bit Intel Mac: EFI on ROM: Mac OS X on disk (no Toolbox).
  7. 64-bit Intel Mac: 64-bit EFI on ROM.
  8. Apple Silicon Mac: ... something else!
OK, well breakthrough! Swapping the Master and Slave around allowed me to boot from the HD. I could boot the HD using boot cd:,\\Mac%20OS%20ROM (thanks @joevt ) and I could see my Panther installation disc 1 on dir zip:,\\ . And everything appears to work, control panels behave as normal, which means I can set the dates to the only true and righteous format: dd/mm/yyyy ;-) .

As a bonus, VM is on (a whole 257MB based on the 160MB of actual RAM). Mac OS 9.1 seems to be taking 29MB.

BandWHdBootOk.jpg
I think I'll leave it here for tonight. The Sil3112 SATA card has also arrived! I read a post on The Other Site about how to flash the ROM so that it'll work on my Mac, which was last updated in August 2025 (though the link given is for a similar thread that ends in July 2025), so it might stand a chance of working!


BandWSataSil3112.jpg
I thought I didn't have any suitable connectors (they're not e-SATA), but I've just wondered if I could borrow one from my kinda-non-working iMac G5 :) .

@zefrenchtoon : OK I had a 30s scan of System Disk, gosh, looks interesting! Thanks!
 
Talking about the different boot architectures... not sure we can really separate the Toolbox/System/Patches that cleanly? After all, the Mac OS ROM file on disk contains the entirety of the 680x0 Toolbox + patches in low memory doesn't it? The early 6800 stuck most of the system in ROM combined with the toolbox, and later 68k ROMs just kept all that and over time patched out more and more of the system components to the file on disk, leaving the core sitting there unused. I'm pretty sure by the time PPC rolled around, the capability to modify and build the original core of the ROM was long lost, so they just bundled the whole pre-compiled thing in, with patches where necessary.

I could be wrong there though; you and @joevt definitely know a lot more than I do in this area.

Anyway... all that to say, on the one hand there were relatively few times when Apple made a clean-break new architecture -- but on the other hand, they were continually patching out what went in ROM and what was loaded from elsewhere.

Speaking of which: have you tried OFPong yet?
 
Talking about the different boot architectures... not sure we can really separate the Toolbox/System/Patches that cleanly?
It's a bit fuzzy I admit!
After all, the Mac OS ROM file on disk contains the entirety of the 680x0 Toolbox + patches in low memory doesn't it? The early 6800 stuck most of the system in ROM combined with the toolbox, and later 68k ROMs just kept all that and over time patched out more and more of the system components to the file on disk, leaving the core sitting there unused.
Up until about System 5 pretty much all of it was Toolbox stuff in ROM. The Finder of course was always on disk, because it was the launch application (you can replace it with your own). System patched stuff, but also control panels and printer drivers were on disk, which makes sense because they could vary.
I'm pretty sure by the time PPC rolled around, the capability to modify and build the original core of the ROM was long lost,
From what I know (about 1% of what @joevt knows), the ROM was maintained. Much of the core code was rewritten over time for improved speed and functionalities. E.g.:
  • Mac Plus added SCSI and SCSI booting; HFS. There were some QuickDraw speed improvements. It also added a more sophisticated memory test. (1986).
  • Mac SE added ADB and PDS expansion, but kept pretty much the same memory test. (1987).
  • Mac II added 8-bit Color Quickdraw and NuBus. I think it also needed some support for the MMU. Memory expansion got more complex yet again.
  • Mac IIx needed some changes for the 68030 and memory expansion beyond 8MB.
  • Later versions added 24-bit Color Quickdraw and modified memory management.
  • Time manager got a whole lot cleverer.
  • The ROM was revamped to be 32bit clean.
  • A universal ROM was developed that could handle all current 68K Macs.
There's a lot of work done to reverse engineer the PPC ROM. The emulator is surprisingly compact (but it takes up a significant chunk of RAM). Color Quickdraw; memory management and a number of other PPC improvements were rewritten for speed.

PCI Macs added PCI support and appeared just 16 months after the first PowerMacs (August 1995). This is where Open Firmware first appeared.

As I recall, the main reason the ROM was moved to disk, ironically, was because of the opposite reason: the ROM needed updating too often, even during the lifetime of a single model and was getting too large. By placing the Toolbox on disk, Apple could cut the cost of machines and update the 'firmware' of a Mac over time. I remember hearing about it before the first iMac came out.
so they just bundled the whole pre-compiled thing in, with patches where necessary.
So, I figure the source code for the ROM wasn't lost.

I could be wrong there though; you and @joevt definitely know a lot more than I do in this area.
I could be wrong too.
Anyway... all that to say, on the one hand there were relatively few times when Apple made a clean-break new architecture -- but on the other hand, they were continually patching out what went in ROM and what was loaded from elsewhere.
Agreed! OTOTOH Apple has done a clean break 4 more times than PCs have (unless you count the AMD64).
Speaking of which: have you tried OFPong yet?
No! Sounds like fun! I wonder if there's OFTetris then?
 
I recommend the @dosdude1 patcher, see here.
I've been looking up Molex to SATA power connectors and so far it seems like they're literally a sure-fire method for a toasty B&W G3 .


Great. So, how am I supposed to power an internal SATA drive on my B&W G3 given that the PCI card only has data connectors? They do say more expensive ones are better. Would these be OK?



They're more expensive certainly and presuming they're from Farnell, not junk. Though if I'm buying one I should also buy another data cable so I can return my other one back to my iMac G5 (which indeed had a suitable connector).

What would you use?

-cheers from Julz
 
He has another video on how to select ones that are less likely to fail:
Isn't "here's how bad adapters are made" and "here's how to select good Molex to SATA adapters" the same thing?

Anyway, I watched the video and it looks pretty good. I've been scanning adapters at CPC Farnell.

1761338486667.png
So, this is a bad one. This one is a crimped Molex to 2x SATA power, which is a 'good' one.

1761338552686.png
There's some Molex+Data to mini SATA which look like they're molded on the SATA end, so although he didn't cover these, I figure that's bad and I'll avoid it.

Then there's this one which is curious:
1761338655487.png1761338676590.png
Here it's a Molex female to SATA power pins. Now, there's no cables going into the connector so the cable insulation won't melt; the separation between pins looks pretty robust; the connection pins themselves look sturdy. OTOH, it's just a single molded unit. Finding it hard to figure out how it'll melt plastic and short.

What do people think?
 
Isn't "here's how bad adapters are made" and "here's how to select good Molex to SATA adapters" the same thing?

Anyway, I watched the video and it looks pretty good. I've been scanning adapters at CPC Farnell.

View attachment 91914
So, this is a bad one. This one is a crimped Molex to 2x SATA power, which is a 'good' one.

View attachment 91915
There's some Molex+Data to mini SATA which look like they're molded on the SATA end, so although he didn't cover these, I figure that's bad and I'll avoid it.

Then there's this one which is curious:
View attachment 91916View attachment 91917
Here it's a Molex female to SATA power pins. Now, there's no cables going into the connector so the cable insulation won't melt; the separation between pins looks pretty robust; the connection pins themselves look sturdy. OTOH, it's just a single molded unit. Finding it hard to figure out how it'll melt plastic and short.

What do people think?

Oh wow, I didn’t know this was a thing - I’ve used these kind of adapters before and currently have one in my Beige G3 DT. Either the risk is overstated or Ive just been lucky.
 
This is wild: I couldn't boot from HD if it was slave, but I can boot from CD if it's slave! ( boot zip:,\\BootX) So, now I'm trying to install Mac OS X Panther on the second partition! I might have an issue when it reboots for the second disk, but we'll see.

OK, it's booted back into Mac OS X! It installed Mac OS 10.3.0! Now upgrading to 10.3.9! That worked!

Woohoo! A triumph!

In other news I've ordered some 'safe' (or safer) Molex to SATA and a SATA data cable! And also, some IPA 99%! All from Farnell!

This B&W G3 project is such fun!
 
Pending the arrival of the SATA cables I installed Steinberg Cubasis VST 2.0 for Mac on the B&W 350. It's a Classic application I used with my tangerine iBook/300 or maybe my iceBook/600.

At the time I had a Roland SC-D70 Sound Canvas. Essentially it's a bit like two MT-32s stuck together, with more sounds; a proper GM sound set and, importantly, a USB interface, MIDI in/out And Audio In/Out. So, I could hook up my Ensoniq Halo (or other MIDI keyboard); do normal MIDI sequencing from Cubasis and then record the audio out from the synths to audio channels in Cubasis: Noice!

So, I'm thinking that one of the possible applications for the B&W is to do the same. It's really interesting to note that although the G3/350 is a New World Mac that can run Panther pretty decently, when I kept checking out all the Mac OS X applications I had: iLife '05, iWork '06, GarageBand, iMovie 3 the specs are all way beyond what the G3 is supposed to deliver. That's a good correction for my perception of that transitional era of Mac, because I had imagined that it would be fine for doing some early movie editing or DAW. It's not really geared up for that (though I might use iMovie 3 with it just to see if it's possible. That version is at least non-destructive as an editor).

But Cubasis VST 2.0 will be fine. Now, onto the interesting bit. Early Macs of course had built-in serial ports which could use an external clock to generate an accurate MIDI baud rate. But New World Macs would use USB-Serial adapters.

Now I could buy an old 2x2 MIDI Man USB serial adapter (or an SC-D70 or SC-88 or something similar), but I also wondered if it's possible to use an actual USB serial port adapter?

Specifically I could buy an Arduino Micro and upload this USB-Serial Adapter firmware written in C. You don't need to use the Arduino Sketch language, you can just compile the 'C' and use avrdude to upload it. The real cool thing would be if I could get an old enough version of AVR gcc to run on my B&W G3 along with avrdude so the whole thing could be done that way! Embedded development on an old G3 is one of my goals too.

The critical line is this:

UBRR1 = SERIAL_2X_UBBRVAL(CDCInterfaceInfo->State.LineEncoding.BaudRateBPS);

Because, SERIAL_2X_UBBRVAL is just a macro that converts an absolute baud rate into the divider register value:

#define SERIAL_2X_UBBRVAL(Baud) ((((F_CPU / 8) + (Baud / 2)) / (Baud)) - 1)

Which means that CDCInterfaceInfo->State.LineEncoding.BaudRateBPS is an absolute baud rate, which means that it can be 31250; which means that it could be treated as an actual MIDI interface (I'd strap an adapted MIDI shield to the Arduino Micro).

This gives me most of the requirements: a 5V MCU which can do USB to MIDI; suitable firmware; a means of compiling it; suitable hardware and a MIDI-oriented application. The only thing I'm missing at this point is a suitable Mac OS 9 USB serial driver that can be seen as a MIDI port to Cubasis.

And that's the question, is such a thing possible? Could early USB Mac sequencers simply treat a USB serial port as a MIDI interface? It's quite an interesting challenge to write that in and of itself.

But note, and this is probably the most comical thing. Look how complex this whole chain of development is compared with developing a MIDI interface in 1983! All you needed then would be, for example, a hardware serial port or a parallel port (such as a VIA) hooked up to an astoundingly simple ACIA 6850.

1761473854962.png

The ACIA only had 4 baud rates and a single buffer byte, but driving it from a 1MHz clock nicely leads to 31250 as one of the baud rates. It's almost as if Sequential Circuits, Roland and Yamaha were familiar with that specific chip (otherwise they could have just chosen 38400 baud) ;-) !
 
Another option is Mac OS X has USB class compliant MIDI drivers. So if you do end up running Panther, you can just have the Arduino implement a USB MIDI.
 
Get a B&W G3 compatible modem port to serial port adapter (g3 stealth serial port or griffin port or circuittalk)
https://68kmla.org/bb/index.php?thr...-circuittalk-localtalk-for-powermac-g4.40182/
Then you can do MIDI like older beige Macs - externally clocked.
Another option is Mac OS X has USB class compliant MIDI drivers. So if you do end up running Panther, you can just have the Arduino implement a USB MIDI.
So many choices! I might go for a USB MidiSport 2x2 to begin with, alongside a micro arduino to experiment with as that seems a fairly cheap route.

I’m pretty sure I used to use Apple’s USBprobe with my tangerine iBook/300, which I think I had because I imagined I’d be writing at least one Classic driver (Mac OS X was just on the horizon). But I only remember having CodeWarrior Gold 10 (or 11) as my dev environment. Did Apple supply a Classic development environment in the day, alongside Interface Builder, the precursor to X Code?
 
I’m pretty sure I used to use Apple’s USBprobe with my tangerine iBook/300, which I think I had because I imagined I’d be writing at least one Classic driver (Mac OS X was just on the horizon). But I only remember having CodeWarrior Gold 10 (or 11) as my dev environment. Did Apple supply a Classic development environment in the day, alongside Interface Builder, the precursor to X Code?
Classic development from Apple consisted of MPW and ResEdit.
Source code version control was done using MPW Projector.

MPW contained C, Pascal, Assembly headers and UNIX-like commands. The commands included compilers and linkers, disassemblers, etc.

Rez, DeRez, GetFileInfo, SetFile still exist in modern macOS.

Many UNIX commands had MPW analogs. For example sed -> StreamEdit

Many commands operated on the UI of MPW.
All menus were customizable with MPW scripts.
Commands existed to affect selections, window content, window position, etc.
The selection of a window could act as a file.

MPW used special characters in commands that you type with the Option key.
• ∂ §

https://en.wikipedia.org/wiki/Macintosh_Programmer's_Workshop
 
Here's a question for you MPW experts: did someone ever implement tab completion for MPW? That was something that was always a pain point for me once I started doing dev work on VAX, IRIX and other unixes in the 90s -- csh had nice tab completion, and every time I went back to MPW, I'd try to tab complete and then have to undo and manually type, or manually set up command key shortcuts.
 
Back
Top