In applications that constantly wait for user interaction such as dtp software and wordprocessors, that is what's happening...
Actually, CPUs have dedicated instructions to handle idle processes to tell the memory controller that they don't need data.
Do you know what the "idle" process in a modern kernel does?
Hardware Abstraction Layer (HAL) - remember? OS4 has one.
The HAL relies heavily on a BIOS and lots of kernel-mode drivers. The Gamecube doesn't have them, remember?
Why can't you just admit it's the games that use OS system libraries that are the compatible ones.
In the same way that ancient 3D games were hard-coded for the Glide library? How many of them work without an emulator or wrapper, like GlideOS?
Look I don't study Linux.
Which, of course, makes you an expert on gc-Linux, and thus the "proof" that Gamecube is really a PC.
I also don't believe it's a stripped down version just because Linux itself in not big. It's when you want to run Apache, PHP, MySQL and a whole bunch of other stuff one one machine that memory requirements go up. 40MB is more than enought to run a gui and browser and a word processor...Linux is a memory whore like Windows.
The Linux kernel can be forced to use 4MB of memory if required. I hope you're aware that the reason why OSes use so much memory is because of performance optimizers like filesystem caching. The size of the kernel itself has nothing to do with features or compatibility. Some kernels can be written in 35K of flat memory, but that doesn't mean they do much.
Compare an OS for a cell phone to BSD UNIX. Notice any differences?
So I don't know why you want to keep asking me questions about hardware I have no interest in. You just seem bent to prove me wrong on any ridiculous point.
Because you are an idiot who is spreading false information. Your marketting points may still be valid no matter what other people say, but at some point you'll have to conceed that nobody is agreeing with you on the technical front.
and that's great, it's obviously not a problem for them and they have experience doing it already.
You still lied.
Are you on drugs?
Aspirin. I need it for threads like this.
Actually, that's a lie. I enjoy it. :-)
The implimentation is not my issue but Hyperion's. I'm saying "Hey, wouldn't it be great if OS4 was ported to the Gamecube." Why can't you understand that?
Yes, it would be. But it can't, unless they reprogram OS4 to retrograde it into OS3 again.
If you wanted OS3 on Gamecube, I wouldn't complain. That's definately possible.
Yes and I paid for a gamecube and love it.
Why don't you give gc-Linux a spin, then?
Then look at the source code.
If OS4's graphics.library just called the cube's API then it should still work fine on Revolution just like I've mentioned before with A500->A1200 os compliant software.
Ah, yes, it's all so simple on paper, isn't it?
Also, let's go back to the HAL here. Hyperion has stated before that they designed the OS so that rewriting the HAL for another hardware platform (like a Pegasus) is all that would be required for getting it to run on something other than the A1.
So long as it follows PC standards. Throw a proprietary bus into the works and your HAL has to be rewritten from scratch for each platform.
You're also under the false pretense that all hardware abstraction is done with the HAL.
So you really don't need to argue with me about technical details.
Why? Isn't that the primary fault with your idea?
Right, so you could never throw Amiga graphics over live video...mmmm k.
Sure you can. You just need extra hardware to do it. :-)
Gee wizz, the Gamecube has support for bongoes, too!
And if you knew anything about the GC, you would know it has 2 completely different and separate memory banks.
The memory is clocked at different speeds but is mapped continously. They work like "chip" and "fast" RAM on the Amiga, except the speed differential is caused by the memory clocking, not which chip can access it.
Quite advanced, but technically, this is still a unified memory architecture.
Yes, by luck, some non-OS compliant games ran fine, most didn't.
When talking about hardware compatibility, luck has nothing to do with it. :-)
So what you are saying is that OS4 which is targetted at the G3FX chip would have to be completely re-written to run on a G4 equipped A1?
Effectively, yes, because the total hardware is different, not just the CPU, and even if the system architecture is the same, the two cores are not binary compatible, which is why you'd have to recompile all your apps, too.
Recompiling apps for each hardware platform isn't a viable option. Linux people deal with it, but that's another of the million reason why Linux can't gain any desktop market share.
Ofcourse not. Just like 68000 assembly can be run on a 68060 (yes I know some instructions are missing). Now if you wanted a graphics library to take advantage of the Altivec instruction in the G4 or Gamecube Gekko, then you could rewrite that library to do so.
What about stuff other than Altivec? Altivec is a set of accelerators, not mandatory instructions, so it's easy to write libraries for that, just like you can for MMX.
Writing libraries to deal with different registers and alignments... er, that's not so easy. You end up having to use an emulator or virtual machine (a euphemism for "really fast emulator").
Remember, all I'm asking for is a licensed port of OS4 to a cheaper (and in some ways more modern) hardware platform.
It's modern only by gaming standards. It's a purpose-built machine.
Revolution could be different architecutally, but it's still purpose built for gaming. So is XBox 360 and PS3, but those are off-topic, of course.
Gekko is a PPC just like a 1997 Pontiac Firebird is like a 1998 Firebird.
Well... well... a 1949 Volkswagen Beetle and a 2006 Honda Accord both used the same gas and oil! So there!
Hey, do you think you can branch this topic some more, and maybe bump it a few more times every day by posting more than one response consecutively?
