A/UX note: /mac/lib/Patches—why are there two files?

[cheesestraws]

I spent the last couple of evenings tracking this down so I thought I'd leave a note here in case anyone else needs to know for whatever bizarre reason. This may, of course, be common knowledge and I was just looking with the wrong keywords. If so, it's been a learning experience.

A certain amount of the code to allow Mac software to run under A/UX is in the files in /mac/lib/Patches. These files are, technically, ROM patches, but following the usual Apple tradition, "Patch" grows to contain quite a lot of software. So it goes. And they're not patches in the sense of modifying the ROM data: they're libraries that contain reimplementations of various ROM routines.

Under A/UX 3.x, there are two patch files, and I didn't know why.

​

Turns out, the patch loaded depends on the ROM. Specifically, the two bytes after the dot in the name correspond to the two bytes at offset 8 of the ROM, which are a ROM version consisting of apparently the machine number and some kind of machine class?

​

The IIcx ROM has 0178 in this location, which means that the first patch file will be loaded. The Quadra 650 ROM has 067C, which means the second will be.

I found this out by digging into /mac/bin/startmac24: initial forays into /mac/bin/startmac were unsuccessful.

Much of these startmac binaries are, unsurprisingly, black magic. But usefully, debugging symbols were left in, including a suspicious looking routine called getPatches. getPatches uses good old sprintf to generate the path to the patch file:

​

A2 at this point points to the middle of a big struct for which we have, irritatingly, no field names. But a quick look for other points where offset $7C is written to takes us into a function called getROMImage. getROMImage does some shared memory shenanigans I do not properly understand to convince the kernel to hand over a copy of the ROM. But at the bottom, we find this:

​

A0 at this point seems to point to the base of the ROM copy that the kernel has handed over.

There also seems to be an undocumented TBPATCHES environment variable that you can use to override (?) this process, if I'm reading this correctly. Braver souls than I will need to descend down that road...

Trying to work out why on earth they did it like this rather than just having a compatibility environment that didn't depend on the ROM in the machine. The amount of mucking about here, surely that wouldn't have been much more work? Dunno.

 

[MrFahrenheit]

Would this be one of the reasons that A/UX only supports specific machines, because it depends upon the ROMs within only specific machines ?

 

[Phipli]

Whats it like in older versions of AUX - did they write it initially in a way that had one patch file... but was incompatible with later machines. When planning fails... bodge like your life depends on it. Or juat bodge from the start and hope nobody notices.

 

[cheesestraws]

Would this be one of the reasons that A/UX only supports specific machines, because it depends upon the ROMs within only specific machines ?

Yes, though it's less restrictive than it may look. The 475, for example, if the ROM image I have here is any guide, has an 067C ROM so it probably would work with the A/UX Mac environment if the rest of the system could be made to run. I suspect the lack of hardware drivers in the kernel is a more restrictive issue, but I'll have to leave that question open to someone who understands old UNIX drivers better than me.

When planning fails... bodge like your life depends on it

Software engineering, and possibly other engineering, is a lot of "seemed like a good idea at the time". I'm just slightly surprised because this wasn't how I thought this was done. Being wrong is good for the soul.

 

[Phipli]

Software engineering, and possibly other engineering, is a lot of "seemed like a good idea at the time". I'm just slightly surprised because this wasn't how I thought this was done. Being wrong is good for the soul.

The road to hell is else if'd with good intentions?

 

[cheesestraws]

The road to hell is else if'd with good intentions?

All of our lives, this is all of our lives.

 

[Corgi]

I suspect the lack of hardware drivers in the kernel is a more restrictive issue, but I'll have to leave that question open to someone who understands old UNIX drivers better than me.

I'm still learning the ins and outs of 68K Macs, but I do know more than any decent person should about old Unix drivers.

The main flaw I can see is if the SCSI controller differs. A/UX, being a SysV / BSD derivative, would not support what is now called a kernel extension (kext) like Darwin or kernel module like FreeBSD / Linux. All drivers must be compiled into the kernel. You can bodge some stuff into the kernel at runtime, but you have to be able to load it from somewhere. Hence, without a working disk driver, you have no hope.

 

[Phipli]

Daft thing, but the System Enablers on the mac side might be a good starting point for clues regarding what's different on machines that could but don't run AUX? They're teaching old systems about new machines.

 

[cheesestraws]

You can bodge some stuff into the kernel at runtime, but you have to be able to load it from somewhere.

Here you are actually in a slightly better position than in some, because A/UX uses a hacked System 7 as a bootloader. So so long as its hacked MacOS can read the disc, you can inject things into the boot sequence.

For the 475, anecdotally, it is graphics support that is mostly missing. I emphasise anecdotally because I've never tried it, nor has anyone I've directly spoken to, but I've heard it from multiple people that seem somewhat reliable.

All drivers must be compiled into the kernel

There is source code for example drivers out there, I'm just not competent (or have the time) to do anything useful with them. Not graphics drivers, though, I think. And yeah, I think the approach here would have to be to get the drivers linked into the kernel on a supported machine, then transport the whole installation, or something. Though again, I'm speciulating here.

 

[cheesestraws]

Daft thing, but the System Enablers on the mac side might be a good starting point for clues regarding what's different on machines that could but don't run AUX? They're teaching old systems about new machines.

Could be! Beyond my competence, but plausible on the face of it.

 

[Phipli]

Could be! Beyond my competence, but plausible on the face of it.

The clock chipping site owner used to provide a modified system enabler for the 650 with the GUID set to the unreleased computers... the email listed is dead, but it means someone understood them enough to do the basic change of what id machines they recognise. I haven't been able to find the same information on the internet and it wasn't obvious in the enabler when I had a cursory look.

 

[MrFahrenheit]

If someone could write a driver for the LC3 and LC475 that would be amazing. Imagine the amount of hardware possibilities that could open up.

 

[cheesestraws]

If you add "-o debug" to the startmac command line (in /mac/bin/mac32 for all users, or in ~/.mac32 for individual users), you'll get a dump of which patch file is in use in the log (in /tmp).

You can also use the -P option to load custom patches. This particular nugget brought to you by the radical practice of 'reading the manual pages', which perhaps I should have done before I started.

If someone could write a driver for the LC3 and LC475 that would be amazing.

Ir'd be great. Rather above my competence level at the moment, alas. One day I may get good enough to attack this, but I wouldn't hold your breath...

 

[yuhong]

Would this be one of the reasons that A/UX only supports specific machines, because it depends upon the ROMs within only specific machines ?

0178 is the original Mac II ROM. 067C is the ROM used in the Mac IIci and later. There is also 077D (SuperMario), but A/UX never supported Macs that used this one.