Keeping Macs running Mac OS X

Travis Butler wrote:
> This is going to depend on technical details that I haven't seen released
> yet; however, from what I've seen so far and what I've seen of Apple, this
> is NOT a shift of the Mac to commodity PC hardware designs. My impression is
> that this is going to be like the 68K to PPC transition: Apple system
> architecture design that happens to use an Intel chip instead of a PPC chip,
> just as the first PPC Macs were an evolution of 68K Mac designs and not
> based on the POWER workstations that had used the precursor PPC chips.

It's worth noting that since that initial transition, Apple has moved
more and more to using commodity PC hardware designs. Shortly after that
transition they moved to PCI. Somewhere in there they switched to IDE
and then later to SATA. They've dropped ADB and switched to USB. These
days, there are a few custom ASICs and ROMS on Apple systems that are
unique to Macs. However, these ASICs are very similar in function to
motherboard chipsets that are put out in the PC market. Their primary
advantage was some of the bandwidth they were able to achieve with the
PowerPC's rather nice I/O interface. This advantage will be gone and
Apple is going to find themselves competing with x86 chipset makers who
have far more experience and knowledge of the Intel architecture
(including Intel themselves). Particularly given that the market value
of these ASICs is perhaps $50, it's going to be hard to justify
continuing with custom ASICs.

> (Anyone else remember CHRP, the Common Hardware Reference Platform? The idea
> was that with the switch to PowerPC, Apple would also switch over to a
> hardware platform co-developed with IBM that would use more
> industry-standard components, and would thus be cheaper and faster. After
> some initial interest, nothing actually came of it; I suspect the issue
> we're talking about here was one of the primary reasons, though getting
> Classic MacOS ported over to run on a different hardware foundation was
> another potential difficulty.)

I believe the killer for CHRP was the failure of Workplace OS and the
Apple's decision to kill the clone market. With only one OS and one
hardware maker in the PC space, developing CHRP designs was a pretty
pointless excercise.

--Chris

> The Mac has always been defined by firmware in ASICs as well as by the
> OS and the CPU -- AFAIK this is still true.

The trick that is different is that OS X is layered on top of Darwin,
which today *right now* can run just fine on x86 systems without custom
Apple's ASICs. That wasn't true of OS Classic or the current Mac OS on
PowerPC.

--Chris

On 6/7/05 10:34, "Frd75" <tigeraroo1925netscape.net> wrote:

> This is the worst news I have heard since we invaded Iraq. I was about to
> upgrade to a new power Mac G5--now I'm not so sure I'd hate to be stuck with a
> machine that doesn't like my version of photo shop and portfolio. And what
> about security???

Huh? At what point did this change security? Did Apple say they were running
an OSX theme on Windows at the keynote? I don't recall someone tasing me
during the keynote, and having been shocked across a room by a B-52 ECM
transmitter, I'm VERY familiar with that.

How do you get current hardware not working with current software?

Did steve flash evil subliminal images or play the brown noise on the stream
that we didn't get in the keynote?

This is just panic, and exactly as useful.

--
John C. Welch Writer/Analyst
Bynkii.com Mac and other opinions
jwelchbynkii.com

At 5:10 PM -0700 2005/06/07, Nik wrote:

>Shouldn't be too long until VMWare, WINE or even VirtualPC allows for
>Windows to run as a speedy virtual machine on your Mac.
>
>One question I have is about hardware. If Macs are running on
>Intel-standard chips, does that change the landscape for what video
>cards and other expansion cards Macs can use? There's still the issue
>of drivers, but assuming support for a dual-boot into Windows, Macs
>could be pretty solid gaming machines. Just not under MacOS. (Is that
>the sound of Aspyr going bankrupt? That's not good...)

        Nah, we can hope it takes them 1/3 the time to do a port,
since it's mostly (video) APIs that have to be ported, and OpenGL
games get **much** easier. So they lose some of the business, because
the original developers (say anyone who already targets Win+Lin) now
start adding +Mac as Tier 1 platforms. They should do okay. I wonder
what Howard <http://www.greendragon.com/> thinks.

>And what about development in general? It seems to me that this change
>won't make things particularly easier for developers to create cross
>platform applications. The basic APIs in MacOS X are wholly unchanged,
>so they still need to put something together in XCode or some other
>friendly environment. Presumably creating cross-platform compilers will
>be easier, but even still, I don't see this changing the development
>landscape too drastically. Am I wrong?

        Sure. They can use a single optimizing compiler, such as
XCode, gcc, or (probably) icc -- Intel's CC to generate optimized x86
code for both platforms.

        Windows shops can pay a (small?) premium, and get Mac
dev/test boxes without buying, supporting, and testing 2 of
everything, so more Mac developers come over from Windows only.

        VMware will probably emulate Macs, or perhaps VMware (Mac
hardware edition) will run on Apple systems and host Windows systems,
since that doesn't violate Apple's model.

        If Apple charges a 25% premium for a box that does
Mac/Windows/Linux, vs. a box that only does Windows/Linux, this is
attractive for many people.

        I'm entertained by the idea of users making direct buying
decisions: PowerBook vs. Vaio, or Dell's "Lexus" product line vs. a
Jonathan Ive special. Should be interesting -- here's hoping it all
works out well for users and Apple.

http://www.fool.com/Server/foolprint.aspx?file=/news/mft/2005/mft05060316.htm


                                                Chris
--
Chris Pepper: <http://www.reppep.com/~pepper/>
Rockefeller University: <http://www.rockefeller.edu/>

At 17:10 -0700 UTC, on 2005/06/07, Nik wrote:

[...]

> And in the end, as a user, do I really CARE what chip is under the
> hood? Heck no. I just want the fastest one for the cheapest price.

Well, as long as it doesn't mean a lot more heat, noise and shorter battery
life, yes.


--
Sander Tekelenburg, <http://www.euronet.nl/~tekelenb/>

On 6/7/05 at 5:10 PM, herouthspamcop.net (Herouth Maoz) wrote:
> So, that's one major change. No Open Firmware, no device tree, no boot
> device selection in Open Firmware. Why? Open Firmware has ben used on
> Sun computers and I don't think it's specifically tied to the PPC.

I wouldn't attach much importance to this. Open Firmware itself is a
relatively recent addition to the Mac platform; IIRC it first appeared
incomplete in the beige G3/Wallstreet generation and reached full form
in the first iMacs. That means it wasn't present for 2/3 of the
platform's history, including at least two+ generations of 'mainline'
PowerMac designs (the NuBus PPCs and the 'processor slot' PCI models;
I'm not sure how you'd count all the various other PPC board designs
like the 6400, Tanzania, and especially the bastard designs like the
PowerMac/Performa 5300). Apple's system designs were more unique then,
not less; removing Open Firmware could just as easily mean a change back
to a more proprietary bootstrap system. Right now, we just don't know
enough to be sure.

> Second, about Darwin, the version currently available for 386 works
> on generic PCs. So you have the operating system kernel working well
> with the commodity PC architecture.
>
> So now, are the modules built on top of Darwin hardware-aware or not?
> If they use operating system services for everything, then the entire
> shebang can be ran on a PC. If not, for example if Quartz talks
> directly to the graphics cards installed in the machine, then it may
> be that the bus protocol won't allow Quartz to speak to them or won't
> list them properly for Quartz to call them.

That's why I said I'm not sure if Darwin changes the equation. On the
one hand, it does run on commodity PC hardware. OTOH, from what I
understand, Darwin is a very bare-bones system and includes very little
of what we think of as 'the Mac experience' - no Carbon, no Cocoa, no
Quartz, no Quicktime, even leaving out Classic which is apparently going
to go away.* So while Darwin runs, it runs as basically Just Another
Unix System, and as you say I don't know how much those additional
modules depend on hardware. I would bet that Quartz, at least, talks to
the hardware at a fairly low level; it'd have to, to pull off the
various acceleration tricks it does.

The other low-level hardware issue I'm not sure about is the issue of
device addressing. The last time I seriously had to mess with things
like IRQs was back in the APS days, over a decade ago, and I've
forgotten most of what I knew back then, but I remember them being a
!$#$ pain in the neck to try and troubleshoot. Things seem to have
improved greatly since Microsoft started pushing their Plug-and-Play
standard, but even today I've had major trouble getting shipping
software to recognize the label printers and electronic scale we have
hooked up to our shipping machine; and looking at the Real Technical
Info device dialogs in WinXP, it looks like IRQs and COM ports are still
there, but kludged around. Can anyone with more low-level PC tech info
confirm whether this is a Windows legacy issue or a PC hardware platform
legacy issue? If it's a hardware issue, that's one more thing I could
see as a significant hurdle.

(*Classic's something I am going to miss; I don't do a whole lot with
Classic these days, but I still have a few old favorite games (some
dating back to 1984!) that I'd really hate to lose. Anyone know if
someone ever did an updated trading game with the same 'feel' as Tycoon,
to name one example?)


Travis Butler
tbutlermac.com

...Cats are the proof of a higher purpose to the universe.

--On June 8, 2005 12:00:23 AM -0700 Travis Butler <tbutlerbirch.net> wrote:

> The other low-level hardware issue I'm not sure about is the issue of
> device addressing. The last time I seriously had to mess with things
> like IRQs was back in the APS days, over a decade ago, and I've
> forgotten most of what I knew back then, but I remember them being a
> !$#$ pain in the neck to try and troubleshoot. Things seem to have
> improved greatly since Microsoft started pushing their Plug-and-Play
> standard, but even today I've had major trouble getting shipping
> software to recognize the label printers and electronic scale we have
> hooked up to our shipping machine; and looking at the Real Technical
> Info device dialogs in WinXP, it looks like IRQs and COM ports are still
> there, but kludged around. Can anyone with more low-level PC tech info
> confirm whether this is a Windows legacy issue or a PC hardware platform
> legacy issue? If it's a hardware issue, that's one more thing I could
> see as a significant hurdle.

I'm sure Apple will still be shipping legacy free hardware -- so no serial
(COM) ports, no parallel ports, no PS/2 moouse/keyboard ports. These old
legacy ports are where the majority of IRQ problems arise.

USB, Firewire, and Bluetooth have their own device interrupt systems that
don't have these issues. PCI generally works around the problem -- but Macs
had this issue too with PCI (one of the reasons you didn't see 6 PCI slot
Macs until AGP came out). I believe PCI-X pretty much fixes all around.

I haven't seen an IRQ problem on a Windows box in a long, long time. Maybe
with a really cheap add-in network card or with a serial port issue.

Kevin

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 8.6.2005, space aliens observed tbutler saying:
>(*Classic's something I am going to miss; I don't do a whole lot with
>Classic these days, but I still have a few old favorite games (some
>dating back to 1984!) that I'd really hate to lose. Anyone know if
>someone ever did an updated trading game with the same 'feel' as
>Tycoon, to name one example?)

Actually, there will probably soon be a well-sized market for Mac
emulators running on the Intel version of Mac OS X. I wouldn't worry too
much about those games if I were you, I'm sure there will be a way to
run them on a MacIntel.

Actually, you can run System 6 on your Mac OS X system using an emulator
today:
<http://emulation.victoly.com/macintosh/>

lucas

- --
"Wine makes a man more pleased with himself; I do not say that it makes him more pleasing to others."
  -- Samuel Johnson

-----BEGIN PGP SIGNATURE-----
Version: PGP SDK 3.2.2

iQA/AwUBQqb12s0zN2kKTjB0EQJtPACgiimupZLABfadwb3JtHqRfOO0dVoAoKMr
sSO9QbFRIs0rRYPCrGo7QX6k
=iFMr
-----END PGP SIGNATURE-----

On 08 Jun 2005, at 01:00 , Chris Pepper wrote:
> Nah, we can hope it takes them 1/3 the time to do a port,
> since it's mostly (video) APIs that have to be ported, and OpenGL
> games get **much** easier. So they lose some of the business, because
> the original developers (say anyone who already targets Win+Lin) now
> start adding +Mac as Tier 1 platforms.

Why would they?

"You have a PC, just boot Windows if you want to play SimCity 5 or
Battlefield 1944."

I don't see any motivation for game vendors to continue porting,
especially not if a VMWare or WINE solution exists that runs at 'near-
enough' speeds. Which it will.

On Jun 8, 2005, at 1:00 AM, Sander Tekelenburg wrote:

> At 17:10 -0700 UTC, on 2005/06/07, Nik wrote:
>> And in the end, as a user, do I really CARE what chip is under the
>> hood? Heck no. I just want the fastest one for the cheapest price.
>
> Well, as long as it doesn't mean a lot more heat, noise and shorter
> battery
> life, yes.

I'm not talking about the G5, here. ;)

Really, the only place where that matters is the portable market. The
Pentium M in my buddy's Thinkpad gets 7.5 hours of battery life with
the extra-chunky battery. That's about four times what I typically get
with my 12" PowerBook.

Yes, performance isn't at desktop-P4 standards, but it gets the job
done quite well, and is fast, quiet, and gets great battery life.

--Nik

At 12:00 AM -0700 6/8/05, Chris Pepper wrote:
> VMware will probably emulate Macs, or perhaps VMware (Mac
>hardware edition) will run on Apple systems and host Windows systems,
>since that doesn't violate Apple's model.

Or host multiple OS X environments (TIger & Leopard?) on the same machine.

--
Larry Rosenstein
lrosensteincatsincharge.com

On 8/6/2005 7:00 PM, "Travis Butler" <tbutlerbirch.net> spake thus:

> That means it wasn't present for 2/3 of the
> platform's history, including at least two+ generations of 'mainline'
> PowerMac designs (the NuBus PPCs and the 'processor slot' PCI models;

I can't confirm this at the moment (being at work), but I'm pretty sure that
my Power Computing PowerWave 604 (second generation clone, Tanzania
motherboard?) had an incomplete Open Firmware implementation, whereas the G3
that I had at work at the time was pretty much complete. Not that it really
matters, of course :)

--
Nigel Stanger, Dunedin, NEW ZEALAND.
http://public.xdi.org/=nigel.stanger

Xlr8yourmac.com has some detailed information from folks working on the
new MacIntel development systems. Sounds like they're off to a good
start, and performance is waaaaaaaay better than it was under PPC for
recompiled applications. (Most of the iLife applications have been
converted as have all of the standard OS X apps.)

The relevant articles are on the front page (today) but they may be
farther back if you get this message later. Just check the archives.

<http://www.xlr8yourmac.com>

Looks like Rosetta emulates a G3 (thus totally avoiding Altivec and 64
bit weirdness -- makes sense), and the dev systems contain BIOS rather
than open firmware. The machines boot Windows XP without difficulty.
Performance in Rosetta sounds better than I could believe, thanks to
the fast Pentiums in there.

I have to give kudos to Apple for making it easy on developers to get
an early start. This was not the case with the 68K -> PPC transition,
and really hasn't been the case for the OS X transition what with all
the changing APIs from Rhapsody on through 10.2. Clearly Apple's
showing a bit more care on this one, and with good reason.

Now it's up to the developers to make this painless on all us users.

I'm also very excited to see whether or not we can get full binary
compatibility on FOSS programs under BSD/Darwin.

--Nik

On 6/8/05 at 7:12 AM, kevinvanhaaren.net (Kevin van Haaren) wrote:

> --On June 8, 2005 12:00:23 AM -0700 Travis Butler <tbutlerbirch.net>
> wrote:
>
> > looking at the Real Technical Info device dialogs in WinXP, it
> > looks like IRQs and COM ports are still there, but kludged around.
> > Can anyone with more low-level PC tech info confirm whether this is
> > a Windows legacy issue or a PC hardware platform legacy issue? If
> > it's a hardware issue, that's one more thing I could see as a
> > significant hurdle.
>
> I'm sure Apple will still be shipping legacy free hardware -- so no
> serial (COM) ports, no parallel ports, no PS/2 moouse/keyboard ports.
> These old legacy ports are where the majority of IRQ problems arise.
>
> USB, Firewire, and Bluetooth have their own device interrupt systems
> that don't have these issues. PCI generally works around the problem
> -- but Macs had this issue too with PCI (one of the reasons you
> didn't see 6 PCI slot Macs until AGP came out). I believe PCI-X
> pretty much fixes all around.
>
> I haven't seen an IRQ problem on a Windows box in a long, long time.
> Maybe with a really cheap add-in network card or with a serial port
> issue.

<nod> I understand this is a legacy issue, but it doesn't really answer
my question. What I was trying to get at was that 10-12 years ago, the
Mac platform and Wintel platform addressed hardware in very different
ways - autoconfiguring NuBus cards vs. manually-jumpered IRQ settings,
as one example.

The current Wintel platform now has autoconfiguring hardware, to a large
degree; but if you look at the technical addressing details, Windows XP
still talks about things like IRQs and LPT ports. (The Resources tab for
a device in Device Manager still lists 'I/O Range', 'Memory Range', and
'IRQ' settings that look pretty much like what I remember from Windows
95, for example.)

What I want to know is whether this legacy is only on the
software/Windows level, or are things like IRQs still part of the
hardware architecture? If they're part of the hardware architecture,
then it seems like the Mac platform and Wintel platform still have
significant differences in device addressing on the hardware level, and
that could be a reason why Apple would go with its own motherboard
design or a 'clean-sheet' Intel-based design instead of a standard
commodity PC motherboard.

On 6/9/05 at 4:59 AM, nstangerinfoscience.otago.ac.nz (Nigel Stanger)
wrote:
> On 8/6/2005 7:00 PM, "Travis Butler" <tbutlerbirch.net> spake thus:
>
> > That means it wasn't present for 2/3 of the platform's history,
> > including at least two+ generations of 'mainline' PowerMac designs
> > (the NuBus PPCs and the 'processor slot' PCI models;
>
> I can't confirm this at the moment (being at work), but I'm pretty
> sure that my Power Computing PowerWave 604 (second generation clone,
> Tanzania motherboard?) had an incomplete Open Firmware
> implementation, whereas the G3 that I had at work at the time was
> pretty much complete. Not that it really matters, of course :)

I'm almost certain it wasn't Tanzania; the only companies I can think of
off the top of my head who used Tanzania were Motorola, APS, and Apple
themselves with the PowerMac 4400.

All of the later PowerComputing clones I'm familiar with used variations
on the 7500/8500/9500 PCI/processor slot architecture, same as the
Daystar and the higher-end Umax models. Hmm, actually, IIRC the low-end
PCC and Umax models used a similar architecture that wasn't Tanzania but
wasn't the processor slot design either; something based off a 603
design like the 6400, IIRC?

Travis Butler
tbutlermac.com

Travis Butler wrote:
> The current Wintel platform now has autoconfiguring hardware, to a large
> degree; but if you look at the technical addressing details, Windows XP
> still talks about things like IRQs and LPT ports. (The Resources tab for
> a device in Device Manager still lists 'I/O Range', 'Memory Range', and
> 'IRQ' settings that look pretty much like what I remember from Windows
> 95, for example.)

The basic notion of using IO ports and interrupts hasn't changed in
computing in general. You'll find the same things in the underpinnings
of OS X as well, they just aren't exposed to the same degree. To a large
extent this is because OS X hasn't had to deal with thousands of 3rd
party hardware drivers.

Ever since the move to PCI and 32-bit, PC's haven't had much concern
about I/O Ranges (there was a lingering problem with PCMCIA, but that
has finally gone away too). APIC took care of the PC's antiquated
interrupt hierarchy. The only time these issues are a concern right now
is during the boot up process, which for compatibility reasons still
starts off in standard mode before they load the kernel and switch to
enhanced mode. Even this has been addressed with Intel's EFI standard,
but EFI has yet to really take over the PC space. I'm willing to hazard
a bet though that the first Intel Mac's do use EFI.

> What I want to know is whether this legacy is only on the
> software/Windows level, or are things like IRQs still part of the
> hardware architecture?

IRQ's are part of Mac's as well. The difference was that Apple was able
to move away from the slow, ancient and generally pathetic interrupt
controllers found in PC's a long time ago, because they had control of
the hardware and the software. You never had to worry about IRQ
conflicts because of the plug-n-play support, and you never ran out of
interrupts, because whenever Apple needed more interrupts they just
added some to their interrupt controller. Intel moved away from this
legacy controller architecture as well with APIC (although APIC
controllers can emulate the pair of 8259 controllers that have been part
of PC's since the IBM AT).

> If they're part of the hardware architecture,
> then it seems like the Mac platform and Wintel platform still have
> significant differences in device addressing on the hardware level, and
> that could be a reason why Apple would go with its own motherboard
> design or a 'clean-sheet' Intel-based design instead of a standard
> commodity PC motherboard.

I think you are partly right. Apple may very go for Intel-based designs
that do away completely with legacy interfaces. They might boot up
directly in enhanced mode, be based on EFI, APIC, etc. without any
support for backwards compatibility. Intel has wanted to do this for a
while, and actually did do it with their Itanium systems (which they
hoped would provide leverage for moving the industry forward... if it
sounds like IBM with the PS/2 it's for a reason ;-), and I can't see why
Apple won't do this as well.

--Chris

Has anyone else noticed that 10.5, the first version to support Intel chips will be called "leopard"?

...as in "changes it's spots" perhaps?

On 14/6/2005 4:47 AM, "Christopher Smith" <xxman.org> spake thus:

> IRQ's are part of Mac's as well.

Yes, I remember booting up my old Mac under Linux several years back and
seeing the IRQ messages scroll by.

--
Nigel Stanger, Dunedin, NEW ZEALAND.
http://public.xdi.org/=nigel.stanger

I wonder if Rosetta can be disabled without affecting the operating system itself.

During the 68k to PPC transition, the Mac OS itself continued to have 68k code that was incrementally (but never fully) removed. Of course Microsoft blamed Office sluggishness on the emulated 68k code buried in the Mac OS. Remember Speed Doubler? :)

Real Mac Users go with Universal Binaries! (this is said in jest). Therefore it would be interesting if Rosetta itself could be an optional install, or if the operating system relies on it in some way.

If the Marklar project anteceded QuickTransit for X86, then hopefully it is not the latter.

--On Monday, June 13, 2005 9:47 AM -0700 Brad <brad.saillardimmi.gov.au>
wrote:

> Has anyone else noticed that 10.5, the first version to support Intel
> chips will be called "leopard"?
>
> ...as in "changes it's spots" perhaps?

Hopefully not as in "spotty performance." :-)

Cheers
  -- perry
---------------------------------------------------------------------------
Perry The Cynic perrycynic.org
To a blind optimist, an optimistic realist must seem like an Accursed Cynic.
---------------------------------------------------------------------------