Slashdot Mirror
More ApeXtreme Info
Hack Jandy writes "AnandTech has some pretty interesting follow up information to last week's sneak peek and discussion concerning VIA's attempt to penetrate the console market. By the looks of it, the S3 DeltaChrome GPU is horribly incapable of making VIA/Apex a formidable gaming console." More on vaporware at CES: Bob Gortician points to this "interesting, if terse, piece on the Phantom game console's debut..."
Let me explain. Many great games are being ported to Linux, and blockbusters are being announced on a practically weekly basis. With a GNU/Debian Linux based gaming system, all the required infrastructure for grabbing game updates and patches would be in place with apt-get. Of course, most consoles aren't going to be equipped with a keyboard, but it is easy to imagine something like dselect being extended with an SVGAlib written wrapper that would allow an inexperienced games console user to 'type' in using an onscreen keyboard commands like 'apt-get update nethack', or 'apt-get install xbill'. Of course access charges to such a service would be completely free. This could be the thing that really blows Microsoft and Xbox Live! out of the water.
What I want to know is...has anyone tried a Linux-based games console before? Just take some commodity hardware, package Linux, and let the community do the rest? If not, it's high time. I think it would be a massive success. If only VA Linux was still in the Linux hardware game, they could potentially manufacture these boxes and provide support too.
In regards to PC games, you're somewhat correct, as usage of assembly is pretty much limited to discrete pieces that need extreme performance. These pieces are easier to re-write than the entire application. However, console games are a different beast. As consoles age and developers become more familiar with the hardware (and at the same time are required to squeeze more and more out of the hardware, because a third or fourth generation title is expected to be more impressive than a first generation title), developers develop their own libraries for the console using low-level languages. This is especially common on Sony platforms, because 1) the PS1 was alive for so long, the initial development libraries were completely inadequate near its end of life, and 2) Sony totally dropped the ball with the PS2, not even providing a higher-level set of libraries*. Now, a lot of these are portable across platforms with a recompile, because the developers will write the backends for multiple consoles while the library's interface remains the same. These games are not portable simply by putting the disc in a different console, however.
So, how does the PS2 achieve backwards compatibility with PS1 games? Sleight of hand. The PS2 includes a PSOne-on-a-chip (the development of which made it possible to release the cheap, compact PSOne redesign of the PS1). It shares memory and hardware devices with the PS2 hardware, but when you pop in a PS1 game the Emotion Engine and so forth are not working at all. It's all being done via the PSOne-on-a-chip.
* Sony saw that 5 years after the PS1 launch no developers were using the Sony-provided tools (well, outside of hobbyist-level startup shops that didn't have the time or money to develop their own libraries or buy a good set from established parties like EA). If no developers are going to use the tools, why should they spend time and money on developing those tools for the PS2? Of course, they didn't look back and see that the PS1 would not have been as popular in its early life if it had not been easy to write for initially. This forced companies to spend millions of dollars and months of work to gear up for PS2 development, and is why there were very few good early launch titles for PS2. The PS2 was almost totally carried by its PS1 compatibility in the first 6-12 months of its life.