Sidebar Sidebar
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

The Tiger Thread (Mac OS X 10.4)

Status
The first post of this thread is a WikiPost and can be edited by anyone with the appropiate permissions. Your edits will be public.
I recently acquired a iMac G4 800mhz (lamp design) and I love it :)

I installed a few console emulators but Emulator Enhancer is needed to have controller support. Have you come across an alternative solution, as I assume the serial number cannot be purchased anymore?

Also, is there a way to use a Xbox 360 or any other recent USB controller for console on that system?

Thanks!
 
Unfortunately to get full functionality including Joystick support you need the serial number, any thoughts or alternatives?
 
Emulator Enhancer 3.1 serial numbers are still available to purchase today. The latest release is fully compatible with current macOS and native on Apple Silicon.

Emulator Enhancer 1.x, 2.x, and 3.0 can no longer be licensed due to the closure of eSellerate. For avoidance of doubt, that means that even if you do have a serial number it won’t help you, as there is no way to enter it. There is no workaround for this that I’m aware of.

I’m not a regular here so please direct any follow ups to me via https://www.bannister.org/email/.
 
  • Like
Reactions: AphoticD
Not certain if this is the right place to ask, but how would I get Tiger to run on my Core Solo Mac mini? I can't seem to find a install disc for it anywhere online, and any Tiger disc I've tried won't work (even if it was for Intel, I assume due to model locking).
 
notabitail said:
Not certain if this is the right place to ask, but how would I get Tiger to run on my Core Solo Mac mini? I can't seem to find a install disc for it anywhere online, and any Tiger disc I've tried won't work (even if it was for Intel, I assume due to model locking).
Click to expand...
There is a Tiger image on the Garden you could try -> https://macintoshgarden.org/apps/mac-os-x-intel-microprocessor
Tiger Server also had a Universal release -> http://macintoshgarden.org/apps/mac-os-server-104

We also have a forum for your kind of Mac
forums.macrumors.com

Early Intel Macs

Core 2 Duo, Core Duo, Core Solo machines
forums.macrumors.com forums.macrumors.com
 
notabitail said:
Not certain if this is the right place to ask, but how would I get Tiger to run on my Core Solo Mac mini? I can't seem to find a install disc for it anywhere online, and any Tiger disc I've tried won't work (even if it was for Intel, I assume due to model locking).
Click to expand...

Is it too slow for 10.6? Or you need to test smth?
 
Apple seems to have removed many of the Tiger updates from the site. I can't even find new links to update this wiki. Luckily, there is a way to download these updates with Software update, and keep the files for archival use (who knew Software update had this feature!). I have for example, been unable to find AirPortExtremeUpdate2008002.pkg anywhere. My plan is to basically have all of the updates and the ACDT dmg for tiger 10.4.10 (basically a universal installer for any mac that can run intel tiger I found on archive.org) and at the very least put them up on the Garden to keep them alive.
 
Last edited:
  • Like
Reactions: Project Alice
alex_free said:
Apple seems to have removed many of the Tiger updates from the site. I can't even find new links to update this wiki. Luckily, there is a way to download these updates with Software update, and keep the files for archival use (who knew Software update had this feature!). I have for example, been unable to find AirPortExtremeUpdate2008002.pkg anywhere. My plan is to basically have all of the updates and the ACDT dmg for tiger 10.4.10 (basically a universal installer for any mac that can run intel tiger I found on archive.org) and at the very least put them up on the Garden to keep them alive.
Click to expand...

It is probably a good idea to do the same for 10.5 and 10.6 updates, to have all PowerPC systems covered. Who knows when someone in Apple gets another great idea to break something for random ppl.
 
  • Like
  • Love
Reactions: NikolaPPC, Project Alice and alex_free
barracuda156 said:
It is probably a good idea to do the same for 10.5 and 10.6 updates, to have all PowerPC systems covered. Who knows when someone in Apple gets another great idea to break something for random ppl.
Click to expand...
For sure. The best thing to do is install the lowest version you can (10.6.0, etc.) and then just run the Software Update utility (Using either download only or install and keep) as many times until there are no more updates. I just did this from 10.4.10 (my Macbook 2,1 needs 10.4.9 minimum), updated to 10.4.11 via combo update and then I had 9 packages (this is for Intel).
 
  • Like
Reactions: G4fanboy and Project Alice
A quick update on MacPorts and 10.4:

Upstream began pro-actively breaking ports for Tiger (it is not supported anymore), so expect things not to work. (Not that 10.4 had a great support before, but now even existing fixes are being removed.)

While I will keep a more favorable policy in PPCPorts in regard of 10.4, I don’t have time to keep rebasing patches or testing stuff (spending time on that would automatically mean that I have less time for newer macOS versions on PowerPC, which is not what I want).
So if anyone is interested to have up-to-date ports on Tiger, consider making some minimal contributions: fixing patches which do not apply is a good start. If there will be no practical interest in this over next 5 months, I will stop putting efforts to keep 10.4 somewhat working either.
 
  • Like
Reactions: alex_free
barracuda156 said:
A quick update on MacPorts and 10.4:

Upstream began pro-actively breaking ports for Tiger (it is not supported anymore), so expect things not to work. (Not that 10.4 had a great support before, but now even existing fixes are being removed.)

While I will keep a more favorable policy in PPCPorts in regard of 10.4, I don’t have time to keep rebasing patches or testing stuff (spending time on that would automatically mean that I have less time for newer macOS versions on PowerPC, which is not what I want).
So if anyone is interested to have up-to-date ports on Tiger, consider making some minimal contributions: fixing patches which do not apply is a good start. If there will be no practical interest in this over next 5 months, I will stop putting efforts to keep 10.4 somewhat working either.
Click to expand...
I’m ngl, I would like to contribute but I have no idea where I would even begin to like help in this instance? Applying patches manually that already exist and fixing ports n stuff seems a little alien to me.

I would need to probably maintain my own repo of binaries. I remember someone had a Leopard Ports binary repo and that worked alright for a bit.

What kind of knowledge do I need to have to start helping?
 
jktwice said:
I’m ngl, I would like to contribute but I have no idea where I would even begin to like help in this instance? Applying patches manually that already exist and fixing ports n stuff seems a little alien to me.
Click to expand...

For example, today’s update of `ninja` dropped patches needed for Tiger: https://github.com/macports/macports-ports/commit/b94e7da39a0112d4085b41702a37d34512d12310
I have kept the patches, but at least one does not apply, therefore it will not build until the patch is rebased: https://github.com/macos-powerpc/powerpc-ports/commit/0198a345a5809382365b3d4c0f32008ef8c0bcb8

MacPorts / PPCPorts base needs this patch to support 10.4: https://github.com/macos-powerpc/macports-base/commit/cd4ebcade22c8f86264be07adcb6f8085aceadfc
I am not gonna rebase it anymore (done that twice).

There are a few other ports like fastfetch, for example, that have Tiger-specific patches and are updated more or less frequently (so chances are high patches won’t apply after one update or another).

jktwice said:
I would need to probably maintain my own repo of binaries. I remember someone had a Leopard Ports binary repo and that worked alright for a bit.
Click to expand...

Just make sure not to start mixing ports installed via completely different package managers. (Installing in parallel is perfectly fine, as long as it is not done in system prefix.)

jktwice said:
What kind of knowledge do I need to have to start helping?
Click to expand...

Basic knowledge of MacPorts build system and git. Rebasing patches is largely (though not always) a mechanical work.
 
barracuda156 said:
A quick update on MacPorts and 10.4:

Upstream began pro-actively breaking ports for Tiger (it is not supported anymore), so expect things not to work. (Not that 10.4 had a great support before, but now even existing fixes are being removed.)

While I will keep a more favorable policy in PPCPorts in regard of 10.4, I don’t have time to keep rebasing patches or testing stuff (spending time on that would automatically mean that I have less time for newer macOS versions on PowerPC, which is not what I want).
So if anyone is interested to have up-to-date ports on Tiger, consider making some minimal contributions: fixing patches which do not apply is a good start. If there will be no practical interest in this over next 5 months, I will stop putting efforts to keep 10.4 somewhat working either.
Click to expand...
I think it is perfectly acceptable to move to a model that is essentially “here is a ports tree, all of this works on tiger but nothing from upstream will be worked on without user contributions”. Is this essentially where we are? I am horrendously out of the loop on tiger macports, I know they stopped supporting tiger and the last installer was many versions ago from their official website.

I think this is all people really want:
1) A GUI installer to install macports on tiger.
2) Any ports that are available to said tiger user actually build. They don’t need to be the latest version, just actually build and work.
3) Any ports that are impossible on tiger (I.e. requires rust, 10.4 SDK can’t supply API, etc) are removed. So like sudo port -N install rust doesn’t work (no port with name rust was found) but sudo port -N install openssl could install a non-current version of OpenSSL (pulling these examples out of thin air).

If this was done, there is actually a serious benefit. With a mostly “frozen” port tree, binaries for tiger PPC especially can actually be obtainable since we don’t have a constant moving target. Same for intel tiger. It’s a lot of compilation time, but if things remain relatively static it is infinitely more obtainable.

Even 4 years ago when I was developing PPCMC7, I was bundling software that was newer at the time of the update release then what people on Linux had with package managers. But slowly, either due to no longer being C99 compatible or upstream requiring newer Mac APIs it became apparent that this wasn’t really possible anymore. For example PPCMC7.2.7 uses openssl from 2023… and that’s ok because TLS 1.3 is from 2018. It supports everything I need it to do right now, I just throw up to date certificates at it. Same thing with FFmpeg/FFplay, SDL 2.0.3, and python 3.10. Not everything has to constantly be up to date for people to find it useful. You do the best job that you can with things and just try to provide something useful in the end.

I think the last time I used macports on tiger was about 4 years ago to compile sm64 for tiger ppc. That would of been impossible without macports. That doesn’t need the newest of the new versions of things either but keeping that possible to build is important to me for example.
 
@jktwice And then have a number of important ports installed – and update them once they are updated (assuming you do not use a local replacements). This is how you can ensure at least the basic stuff is actually working. This is critical for a) toolchain and build systems (cmake, meson and alike) and b) ports which are dependencies for a lot of other ports (say, glib2 or ffmpeg). If some end-user port breaks, that becomes a problem only when there is at least 1 user of that port. If something like cmake or glib2 is broken, hundreds of ports cannot build anymore. If ld64 or gcc is broken, installation is unusable.
 
alex_free said:
I think it is perfectly acceptable to move to a model that is essentially “here is a ports tree, all of this works on tiger but nothing from upstream will be worked on without user contributions”. Is this essentially where we are? I am horrendously out of the loop on tiger macports, I know they stopped supporting tiger and the last installer was many versions ago from their official website.

I think this is all people really want:
1) A GUI installer to install macports on tiger.
2) Any ports that are available to said tiger user actually build. They don’t need to be the latest version, just actually build and work.
3) Any ports that are impossible on tiger (I.e. requires rust, 10.4 SDK can’t supply API, etc) are removed. So like sudo port -N install rust doesn’t work (no port with name rust was found) but sudo port -N install openssl could install a non-current version of OpenSSL (pulling these examples out of thin air).

If this was done, there is actually a serious benefit. With a mostly “frozen” port tree, binaries for tiger PPC especially can actually be obtainable since we don’t have a constant moving target. Same for intel tiger. It’s a lot of compilation time, but if things remain relatively static it is infinitely more obtainable.

Even 4 years ago when I was developing PPCMC7, I was bundling software that was newer at the time of the update release then what people on Linux had with package managers. But slowly, either due to no longer being C99 compatible or upstream requiring newer Mac APIs it became apparent that this wasn’t really possible anymore. For example PPCMC7.2.7 uses openssl from 2023… and that’s ok because TLS 1.3 is from 2018. It supports everything I need it to do right now, I just throw up to date certificates at it. Same thing with FFmpeg/FFplay, SDL 2.0.3, and python 3.10. Not everything has to constantly be up to date for people to find it useful. You do the best job that you can with things and just try to provide something useful in the end.

I think the last time I used macports on tiger was about 4 years ago to compile sm64 for tiger ppc. That would of been impossible without macports. That doesn’t need the newest of the new versions of things either but keeping that possible to build is important to me for example.
Click to expand...

@alex_free Having a “frozen” ports tree for 10.4 is a workable approach. (That won’t be done in my tree, but you can always pick w/e needed from there.)
However, I don’t think we have any snapshot that is guaranteed – or even expected – to coherently work on 10.4. Pretty much nothing was tested on 10.4 for years. The only thing which is known to have worked is gcc14 and its dependencies at the moment when the PR by @glebm was merged. That may be a sensible starting point, if someone decides to start a dedicated fork.

Obviously, if you keep the whole tree of your own, nothing will be broken randomly due to updates (and yeah, you can have pre-built stuff easily). The problem with this approach is that you will have to maintain 40 thousand ports, single-handedly LOL
I mean, sure enough, only a small fraction of those are of interest, but a small fraction of 40 thousand is still a lot. Or if that is not done, nothing gets updated.

In any case it is probably sensible to have overlay ports for the toolchain and fundamental build systems. There is no pressing need to have the latest cmake at any given point of time, but having cmake broken is a catastrophe LOL
 
  • Like
Reactions: alex_free
barracuda156 said:
@alex_free Having a “frozen” ports tree for 10.4 is a workable approach. (That won’t be done in my tree, but you can always pick w/e needed from there.)
However, I don’t think we have any snapshot that is guaranteed – or even expected – to coherently work on 10.4. Pretty much nothing was tested on 10.4 for years. The only thing which is known to have worked is gcc14 and its dependencies at the moment when the PR by @glebm was merged. That may be a sensible starting point, if someone decides to start a dedicated fork.

Obviously, if you keep the whole tree of your own, nothing will be broken randomly due to updates (and yeah, you can have pre-built stuff easily). The problem with this approach is that you will have to maintain 40 thousand ports, single-handedly LOL
I mean, sure enough, only a small fraction of those are of interest, but a small fraction of 40 thousand is still a lot. Or if that is not done, nothing gets updated.

In any case it is probably sensible to have overlay ports for the toolchain and fundamental build systems. There is no pressing need to have the latest cmake at any given point of time, but having cmake broken is a catastrophe LOL
Click to expand...
The idea with a “frozen” tree would be to prompt any users for feedback. “Hey this port doesn’t work”, opens an issue and after a look if an older version can’t be used to “fix” the issue then it gets removed from the theoretical frozen ports tree completely. Basically it just keeps getting better, all the time. But it never sets out to be perfect in the beginning. And I’m sure while testing stuff out I’ll be able to figure out what should just be removed and is incompatible as well before anyone hits that problem. But we all know how long compile times can be on especially ppc, and if something doesn’t work it could just be a waste after hours of attempts.

And I mean for sure some stuff was definitely at least tested by me before🤣, maybe the most insane thing that worked on PowerPC tiger back in 2021 was the mingw-w64 compiler. I could cross compile native windows x86_64 executables with like iirc a very recent gcc from PowerPC Mac OS X, and it is actually what made the super Mario 64 ex port possible to be built natively (don’t ask how that makes sense, something about having to create an x86_64 assembly object to allow the python script to extract certain data from said binary during build time for again, a native PowerPC Mac osx build of super Mario 64). It was the easiest way back then in my head to get it actually working…

Your gcc14 starting point does sound great. Thanks for all the feedback. I’m going to regroup in my head and figure out the best thing to do here when I get time.
 
  • Like
Reactions: barracuda156
alex_free said:
But we all know how long compile times can be on especially ppc, and if something doesn’t work it could just be a waste after hours of attempts.
Click to expand...

A rough estimate is presence in PPCPorts. If something is there, then a) if it is not ahead of MacPorts version, then probably it needed a fix for ppc, b) it build on 10.6 ppc, so should be fixable for Tiger, in most cases.
 
  • Like
Reactions: alex_free
I have a Powerbook G4 successfully serving binaries with Macports to another 2005 Powerbook G4 over a local network with lighttpd 1.4.79.
It should be accessible to you all here: powerbookg4e.pagekite.me
If you can't get the binary archives to work, let me know and I will try to fix it. This is my first server. Please test but be nice to it.
Pubkey is attached, I had to add a .txt extension so it would upload. You will need to remove that and save as .pem file.
Relevant part of https://trac.macports.org/wiki/howto/ShareArchives2
Add the following to /opt/local/etc/macports/archive_sites.conf

name bonjour
urls http://powerbookg4e.pagekite.me/

A line indicating the location of the public key must also be added to /opt/local/etc/macports/pubkeys.conf. Something like:

/opt/local/share/macports/local-pubkey.pem
 

Attachments

  • local-pubkey.pem.txt
    451 bytes · Views: 7
Last edited:
  • Love
  • Like
Reactions: galgot and jktwice
You must log in or register to reply here.
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.
Top Bottom
Back