Yes, he is being extremist here, but it's scary that he flaunts these kinds of fantasies. From reading his "armedndangerous" site, he comes across as a lunatic just looking and waiting for an excuse to get to shoot someone. When he goes fully crazy and starts gunning people down in the SCO offices, we'll have his blog to look back on and wonder "Why the hell didn't we see this coming?"
Putting the various other 64-bit processors aside (and remember, there have been > 32-bit processors since the 1970s), don't forget about the 64-bit MIPS processors. There's one in each and every PlayStation 2. Yes, there's only 32MB in a PS2, but the processor is still truly 64-bit. Integer registers are all 64-bits wide. Actually, they're 128-bits wide, but there's a limited number of operations that can be performed on 128-bit values
That rant pushes the edge of legal. One could definitely consider some of those words to be threats. I just hope they don't come to take him away. He's needed right now.
Remember, this is the Eric S. Raymond who--not too long ago--wrote a long, public rant about how it is his right to kill policemen. Sadly, ESR isn't just the usual UNIX/Linux contrarian, he's a sad lunatic who uses Linux and Open Source as ways to promote his personal agenda and feed his ego. In all seriousness, he's much more of an embarrassment than someone whose words we should be hanging on. We can stop making excuses for him.
Sorry, but MHz/GHz sell CPUs. That's not going to change anytime soon.
Ah, but that's not the case. MHz don't really sell CPUs, it's just that CPU speed has become meaningless and, as there's little point of differentiation between various makes of processor, going for the bigger number is as good as any other measure. But now that notebooks are outselling desktops, "battery life" carries a lot more weight.
We're in a bit of bind right now in that CPU development is tremendously stagnant. We develop processors that are good at running RISC-style assembly code, most commonly with an x86 ISA front-end. You don't see a lot of alternative architectures out there. (Transmeta's not having over the top success, but at least they're trying.) It's relatively easy to develop a 20MHz FPGA that outruns a 3GHz Pentium 4 for specialized applications, and that's the principle behind video card GPUs (which are typically clocked at a tenth the speed of modern processors). Quite possibly a CPU design that is focused on more specific needs is the way to go.
I think you could argue Deus Ex (from Ion Storm) as a low-budget hit. It saved the studio, and nobody expected it to do well. And it was pretty original - an FPS that's not really a shooter.
Except that Deux Ex cost MILLIONS of dollars to create. It is not low-budget by any means.
Moore's law is already ending. Intel's Prescott (i.e. Pentium 5) CPU dissipates 103 watts. That's beyond anything you can put in a laptop, and it's arguably beyond anything that should be in a workstation-class PC. But it also may not be that we're hitting CPU speed limits, just that we're hitting the limits of type types of processors that are being designed. Much of the reason the PowerPC line runs cooler than the x86 is because the instruction set and architecture are much cleaner. There's no dealing with calls to unaligned subroutines, no translation of CISC instructions to a series of RISC micro-ops, and so on. But there are the same fundamental issues: massive amounts of complexity dealing with out of order execution, register renaming, cache management, branch prediction, managing in-order writebacks of results, etc.
Historically, designing CPUs for higher-level purposes, other than simply designing them to execute traditional assembly language, has been deemed a failure. This is because generic hardware advanced so quickly that the custom processors were outdated as soon as they were finished. Witness Wirth's Lilith, which was soon outperformed by an off-the-shelf 32-bit CPU from National Semiconductor (remember them?). The Lisp machine is a higher profile example.
But now things are not so clear. Ericsson designed a processor to run their Erlang concurrent-functional programming language, a language they use to develop high-end, high-availability applications. The FPGA prototype was outperforming the highly-optimized emulator that had been using up to that point by a factor of 30. This was with the FPGA at a clock speed of ~20MHz, and the emulator running on an UltraSPARC at ~500MHz. And remember, this was with an FPGA prototype, one that didn't even include branch prediction. Power dissipation was on the order of a watt or two.
Quite likely, we're going to start seeing more of this approach. Figure out what it is that you actually want to *do*, then design for that. Don't design for an overly general case. For example, 90% of desktop CPU use could get by without floating point math, especially if there were some key fixed point instructions in the integer unit. But every Pentium 4 and Athlon not only includes 80-bit floating point units, but massive FP vector processing units as well. (Not to mention outmoded MMX instructions that are almost completely ignored.)
Umm, no matter what you do the heat goes into the room with you. Unless you have an exhaust that takes the heat right out of the room, there is usually hot air coming out of the power supply. With this case its radiating from the sides, but its still heat coming out of the case right into the room with you.
Exactly. And the point is that using heatpipes or other fancy cooling technologies does not get around this problem at all. The existence of such cooling technologies is not an excuse for constantly increasing the heat output of CPUS.
A chip that dissipates 103 watts is well over the line. Geez, and people used to laugh at the DEC Alpha in 1993. Sure, you can get that heat away from the CPU...and right into the room with you. This moronic race of trading an 8% clockspeed increase for a 15% increase in power consumption is the beginning of the end of modern CPU design...especially as the keyword for the 21st century is *mobile*. The last thing we want--a few years down the road--is every insurance saleman and secretary havinga Prescott on his or her desk, simply because there aren't easily available alternatives
Here's to whoever breaks the trend. Transmeta looked pretty dumb and slow a few years ago, but now the Efficeon looks to outdo the Pentium M by a large margin. But what we need now is a revolution, and not just another giant pseudo-RISC chip that trades a teensy bit more performance for over the top heat problems.
Yes, it pipes all that heat away from the CPU, and right into the room with you. Cooling solutions are not the answer for the upcoming 100+ watt monster CPUs. So far there isn't a good answer.
Amazing programming languages were developed in the 1960s, 70s, and 80s: Lisp, Smalltalk, various out-there functional languages. All of them have always been amazing languages to work with and offer much higher productivity than just using C for everything. But a 33MHz processor with an 8MHz bus, and more importantly little RAM, was stifling to say the least. You couldn't write more than toy programs in a functional language on consumer hardware. Now we have what amounts to supercomputers on our desks, and a full-blown Lisp system looks darned tiny next to an installation of gcc.
2. Inexpensive notebook computers.
This was a small market ten years ago, and now notebooks are outselling desktops--for roughly the same price.
3. Consumer-level graphics hardware. There was a long gap between the Atari 800 (1979), C64 (1982), and Amiga (1985) and good, reliable graphics-done-in-hardware for the PC (1996). Now, of course, consumer level 3D hardware is beyond what anyone ever expected. You can buy better 3D hardware for $200 than the folks doing graphics research in the 1980s ever had access to.
Outlook Express is the freebie email client and newsreader that comes with Windows. This is what's going away.
Outlook is the corporate email client that's used at tens of thousands of large businesses. This is NOT going away. All of the Outlook-targeted email worms are still going to work.
And am I correct in guessing that your already old or at least 40+?
Nope.
To me, you sound like one of those people who think that true AI is just around the corner...and have been thinking that since 1960 (long before I was born, BTW!). Heck, all we need is more computer power! But that turned out to be a red herring, it truly came down to us not having a clue about AI. And now, just because we know about DNA and a few other things, that doesn't mean we really have a clue about how things work. Start reading a biology or medical textbook and you hit unanswered questions--big, flamingly large unanswered questions--right away.
I'm not saying I disagree with you, just that that you're making a big leap that's without basis (like "We have gasoline engines! This means we're going to have flying cars and robots that do housework!").
All that research money IS starting to pay off, and we are getting closer and closer to completely understanding life. Its a completely new ball game now.
No, sorry, we are not. We're getting a grasp on DNA and how to tinker with it, but that does not translate, by any stretch of the imagination, into anything more than baby steps toward "completely understanding life." All you have to do is read medical research journals--especially brain research--to realize how little we know.
I wouldn't hold my breath for this. Modern science and medicine have done some amazing things, including organ transplants and effectively wiping out certain diseases. But so much, oh so much, is still at the alchemy stage. You ever know someone with cancer? The treatment is essentially to pump radioactive materials into the body and hope for the best. If it doesn't work, do it again--and again--until it either works or the patient dies of the cancer or the treatment (and the latter happens more often than anyone wants to admit). The progress in this area has been tremendously slow. Ditto for many other fatal diseases which are still, even after billions of dollars and 50+ years of research, uncureable. Now we're supposed to believe that "immortality" is just around the corner? Only in certain weird senses of the word.
One of the core tenets of UNIX was that you have small, simple tools and you glue them together. But now the popular programming languages under Linux are C++, Python, and Perl, none of which follow this philosophy. And to get to the point where Linux is a true alternative to Windows on the desktop, you have to put a massive X server on top of the kernel, and put a massive window manager and desktop environment on top of that. In the end, "Linux" is not a simple thing (and arguably even the kernel is not simple, but the API is), because you are looking at the combination of X+Qt+KDE, and that pretty much throws all philosophy out the Window. (Yes, I know you can use Blackbox or something else instead, but then don't go arguing that it's a suitable replacement for Windows.)
Have you ever read code from some of the original UNIX team, such as Kernhigan's Software Tools? Wow, can that man write clean and clear code. The original C compiler is similarly concise. But then look at the sources to just about any Open Source project and see that (1) there's a massive amount of code, and (2) it's mostly very ugly. Unfortunately, even though it's illogical, "open source" and "simplicity" aren't as intimately tied together as one would expect.
The author claims it is not free software. The FLTK site claims otherwise:
FLTK comes with complete free source code. FLTK is available under the terms of the GNU Library General Public License.
We have ammended the LGPL to explicitly allow static linking of FLTK (or any modified version of FLTK) to your software. The LGPL is not clear on this and we definately want to allow it.
All the Linux users (and *BSD for that matter) are walking around with a big smile on their lips days like this.
Sigh. The Windows exploit is essentially a buffer overrun. Microsoft knew about this and released a patch *before* this worm was even written. So it comes down to two things:
1. It's a common problem caused by people writing OS-level services in languages that are prone to these types of problems. Windows and Linux are in the same boat here. Many such exploits have been found in boths OSes, and more will be found in the future.
2. It doesn't matter how fast a patch is released if people don't download and install the patches. Again, both Windows and Linux are identical in this respect.
If Linux were on 90% of all desktop PCs, you'd see the same kinds of viruses and worms. It's not like there haven't been UNIX worms in the past; to think otherwise is fooling yourself. And if Linux were that popular, it would only be a matter of time until bogus "security updates" started making the rounds, so people log in as root to install them, and BANG.
...less interesting on the software side. You can already do development using MAME, various 8-bit computer emulators, and the Game Boy (and the GBA).
But the primary advantage of this system is to understand how the hardware works. That's something you rarely ever see. Even back in the 8-bit days, almost no one really understood machines like the Apple II and Atari 800 on a hardware level. For example, no one ever attempted to redesign Atari's ANTIC chip, because that info just wasn't available. This hasn't changed at all over the last 20 years. FPGAs are cheap and widespread, but not the info about designing graphics hardware.
Back to the software. If you're into game design, and you design and implement a game for MAME (say, on the Williams' 6808-based hardware), then that game is runnable on any PC or Mac right away. Not so with this new system.
Overall, LaMothe has always been very much into writing and teaching about game programming, but he's always completely avoided game design. He develops and writes about lackluster knockoffs of existing games, and offers little to advance the medium. In it's own way, for teaching purposes, that's a good thing. But the last thing we need is everyone to build this new system, then start writing versions of Tetris and Asteroids and old Commodore 64 games for it. If you want to move forward in design, you can do it for existing "hardware."
Before 1994, the idea of walking into a bookstore and seeing entire shelves of books on real-time graphics and game programming was almost unheard of. The very techniques and sciences driving the games that were already making billions of dollars for the Ataris and Nintendos of the world were still well-guarded secrets. That all changed, however, with the release of Tricks of the Game Programming Gurus by computer scientist Andre' LaMothe, and within only a few years, an entirely new genre of technical books had seemingly taken over the world.
Uh, I hate to mention it Andre, but this simply isn't true. There were dozens of books about graphics and game programming on 8-bit home computers. COMPUTE! had a whole line of them, for example. You could pick up at least two magazines for each make of computer that included source code listings for games written assembly language and making full use of the hardware. Heck, you could buy the hardware reference manual and even the full operating system source code from Atari. Even the source code to Atari DOS, with full commentary. was available in a $12 book. The source code to Chris Crawfords' award winning Eastern Front, widely considered one of the most advanced commercial games of its time, was also available for purchase. In a number of ways, things were more open and free back then.
similar to the Commodore 64, Atari 800, and Apple II
The Apple II just had a big, dumb frame buffer, plus a static character mode. The C64 and Atari 800 had raster interrupts, redefinable characters, sprites, hardware collision detection of sprites, etc. The Atari 800 was even further out there, with direct hardware support things that needed ugly graphic hacks on the C64 (like mixing graphics modes in arbitrary ways and multiplexing sprites).
Twelve years ago this was a valid question. Now you have:
1. Archived ROMs for almost every arcade and 8-bit home computer game ever produced, including rare and unreleased games.
2. Freely available emulators for running the majority of these. Many games suffer because they don't work well with a mouse and keyboard, but at least the games are preserved.
3. Commercial emulated versions of many old games, which aren't in the gray zone that most ROMs images are. The Namco Museum series is a good example. It even includes lesser known games like Toy Pop and Bosconian.
4. Rabid coin-op hobbyists producing new versions of marquees, control panel art, and so on, for classic arcade machines.
The saturn was bastardized at the last moment to support rudimentary 3D. It's 2D games are widely held to be the best of their kind, it's 3D games are not.
But that's not at all what made the Saturn so "difficult" to program. The 3D stuff was a breeze to work with. The difficulty was only in figuring out how to make good use of the DSP and the second CPU, which was not so easy. If you ignored them, then no trouble at all.
Nobody wanted to develop for it. No developers = no games which = no customers.
The dev kits were insanely expensive, and you had to write for a screwed-up dual CPU system. Not easy.
Essentially what you're describing is a PlayStation 2. Just because something is a bitch to develop for doe NOT give developers the option of not developing for it. That's like dropping a class because you think it's too difficult. Developers do what they get paid to do.
Slashdot Mirror
When to Shoot a Policeman, the last story on the page.
Yes, he is being extremist here, but it's scary that he flaunts these kinds of fantasies. From reading his "armedndangerous" site, he comes across as a lunatic just looking and waiting for an excuse to get to shoot someone. When he goes fully crazy and starts gunning people down in the SCO offices, we'll have his blog to look back on and wonder "Why the hell didn't we see this coming?"
Putting the various other 64-bit processors aside (and remember, there have been > 32-bit processors since the 1970s), don't forget about the 64-bit MIPS processors. There's one in each and every PlayStation 2. Yes, there's only 32MB in a PS2, but the processor is still truly 64-bit. Integer registers are all 64-bits wide. Actually, they're 128-bits wide, but there's a limited number of operations that can be performed on 128-bit values
That rant pushes the edge of legal. One could definitely consider some of those words to be threats. I just hope they don't come to take him away. He's needed right now.
Remember, this is the Eric S. Raymond who--not too long ago--wrote a long, public rant about how it is his right to kill policemen. Sadly, ESR isn't just the usual UNIX/Linux contrarian, he's a sad lunatic who uses Linux and Open Source as ways to promote his personal agenda and feed his ego. In all seriousness, he's much more of an embarrassment than someone whose words we should be hanging on. We can stop making excuses for him.
Sorry, but MHz/GHz sell CPUs. That's not going to change anytime soon.
Ah, but that's not the case. MHz don't really sell CPUs, it's just that CPU speed has become meaningless and, as there's little point of differentiation between various makes of processor, going for the bigger number is as good as any other measure. But now that notebooks are outselling desktops, "battery life" carries a lot more weight.
We're in a bit of bind right now in that CPU development is tremendously stagnant. We develop processors that are good at running RISC-style assembly code, most commonly with an x86 ISA front-end. You don't see a lot of alternative architectures out there. (Transmeta's not having over the top success, but at least they're trying.) It's relatively easy to develop a 20MHz FPGA that outruns a 3GHz Pentium 4 for specialized applications, and that's the principle behind video card GPUs (which are typically clocked at a tenth the speed of modern processors). Quite possibly a CPU design that is focused on more specific needs is the way to go.
I think you could argue Deus Ex (from Ion Storm) as a low-budget hit. It saved the studio, and nobody expected it to do well. And it was pretty original - an FPS that's not really a shooter.
Except that Deux Ex cost MILLIONS of dollars to create. It is not low-budget by any means.
Moore's law is already ending. Intel's Prescott (i.e. Pentium 5) CPU dissipates 103 watts. That's beyond anything you can put in a laptop, and it's arguably beyond anything that should be in a workstation-class PC. But it also may not be that we're hitting CPU speed limits, just that we're hitting the limits of type types of processors that are being designed. Much of the reason the PowerPC line runs cooler than the x86 is because the instruction set and architecture are much cleaner. There's no dealing with calls to unaligned subroutines, no translation of CISC instructions to a series of RISC micro-ops, and so on. But there are the same fundamental issues: massive amounts of complexity dealing with out of order execution, register renaming, cache management, branch prediction, managing in-order writebacks of results, etc.
Historically, designing CPUs for higher-level purposes, other than simply designing them to execute traditional assembly language, has been deemed a failure. This is because generic hardware advanced so quickly that the custom processors were outdated as soon as they were finished. Witness Wirth's Lilith, which was soon outperformed by an off-the-shelf 32-bit CPU from National Semiconductor (remember them?). The Lisp machine is a higher profile example.
But now things are not so clear. Ericsson designed a processor to run their Erlang concurrent-functional programming language, a language they use to develop high-end, high-availability applications. The FPGA prototype was outperforming the highly-optimized emulator that had been using up to that point by a factor of 30. This was with the FPGA at a clock speed of ~20MHz, and the emulator running on an UltraSPARC at ~500MHz. And remember, this was with an FPGA prototype, one that didn't even include branch prediction. Power dissipation was on the order of a watt or two.
Quite likely, we're going to start seeing more of this approach. Figure out what it is that you actually want to *do*, then design for that. Don't design for an overly general case. For example, 90% of desktop CPU use could get by without floating point math, especially if there were some key fixed point instructions in the integer unit. But every Pentium 4 and Athlon not only includes 80-bit floating point units, but massive FP vector processing units as well. (Not to mention outmoded MMX instructions that are almost completely ignored.)
Umm, no matter what you do the heat goes into the room with you. Unless you have an exhaust that takes the heat right out of the room, there is usually hot air coming out of the power supply. With this case its radiating from the sides, but its still heat coming out of the case right into the room with you.
Exactly. And the point is that using heatpipes or other fancy cooling technologies does not get around this problem at all. The existence of such cooling technologies is not an excuse for constantly increasing the heat output of CPUS.
A chip that dissipates 103 watts is well over the line. Geez, and people used to laugh at the DEC Alpha in 1993. Sure, you can get that heat away from the CPU...and right into the room with you. This moronic race of trading an 8% clockspeed increase for a 15% increase in power consumption is the beginning of the end of modern CPU design...especially as the keyword for the 21st century is *mobile*. The last thing we want--a few years down the road--is every insurance saleman and secretary havinga Prescott on his or her desk, simply because there aren't easily available alternatives
Here's to whoever breaks the trend. Transmeta looked pretty dumb and slow a few years ago, but now the Efficeon looks to outdo the Pentium M by a large margin. But what we need now is a revolution, and not just another giant pseudo-RISC chip that trades a teensy bit more performance for over the top heat problems.
Yes, it pipes all that heat away from the CPU, and right into the room with you. Cooling solutions are not the answer for the upcoming 100+ watt monster CPUs. So far there isn't a good answer.
1. Advanced programming languages..
Amazing programming languages were developed in the 1960s, 70s, and 80s: Lisp, Smalltalk, various out-there functional languages. All of them have always been amazing languages to work with and offer much higher productivity than just using C for everything. But a 33MHz processor with an 8MHz bus, and more importantly little RAM, was stifling to say the least. You couldn't write more than toy programs in a functional language on consumer hardware. Now we have what amounts to supercomputers on our desks, and a full-blown Lisp system looks darned tiny next to an installation of gcc.
2. Inexpensive notebook computers.
This was a small market ten years ago, and now notebooks are outselling desktops--for roughly the same price.
3. Consumer-level graphics hardware.
There was a long gap between the Atari 800 (1979), C64 (1982), and Amiga (1985) and good, reliable graphics-done-in-hardware for the PC (1996). Now, of course, consumer level 3D hardware is beyond what anyone ever expected. You can buy better 3D hardware for $200 than the folks doing graphics research in the 1980s ever had access to.
Lots of confusion here, I see.
Outlook Express is the freebie email client and newsreader that comes with Windows. This is what's going away.
Outlook is the corporate email client that's used at tens of thousands of large businesses. This is NOT going away. All of the Outlook-targeted email worms are still going to work.
I have had zero system crashes since I started using Windows 2000 over two years ago. So Microsoft would be responsible for exactly...zero of them.
And am I correct in guessing that your already old or at least 40+?
Nope.
To me, you sound like one of those people who think that true AI is just around the corner...and have been thinking that since 1960 (long before I was born, BTW!). Heck, all we need is more computer power! But that turned out to be a red herring, it truly came down to us not having a clue about AI. And now, just because we know about DNA and a few other things, that doesn't mean we really have a clue about how things work. Start reading a biology or medical textbook and you hit unanswered questions--big, flamingly large unanswered questions--right away.
I'm not saying I disagree with you, just that that you're making a big leap that's without basis (like "We have gasoline engines! This means we're going to have flying cars and robots that do housework!").
All that research money IS starting to pay off, and we are getting closer and closer to completely understanding life. Its a completely new ball game now.
No, sorry, we are not. We're getting a grasp on DNA and how to tinker with it, but that does not translate, by any stretch of the imagination, into anything more than baby steps toward "completely understanding life." All you have to do is read medical research journals--especially brain research--to realize how little we know.
I wouldn't hold my breath for this. Modern science and medicine have done some amazing things, including organ transplants and effectively wiping out certain diseases. But so much, oh so much, is still at the alchemy stage. You ever know someone with cancer? The treatment is essentially to pump radioactive materials into the body and hope for the best. If it doesn't work, do it again--and again--until it either works or the patient dies of the cancer or the treatment (and the latter happens more often than anyone wants to admit). The progress in this area has been tremendously slow. Ditto for many other fatal diseases which are still, even after billions of dollars and 50+ years of research, uncureable. Now we're supposed to believe that "immortality" is just around the corner? Only in certain weird senses of the word.
One of the core tenets of UNIX was that you have small, simple tools and you glue them together. But now the popular programming languages under Linux are C++, Python, and Perl, none of which follow this philosophy. And to get to the point where Linux is a true alternative to Windows on the desktop, you have to put a massive X server on top of the kernel, and put a massive window manager and desktop environment on top of that. In the end, "Linux" is not a simple thing (and arguably even the kernel is not simple, but the API is), because you are looking at the combination of X+Qt+KDE, and that pretty much throws all philosophy out the Window. (Yes, I know you can use Blackbox or something else instead, but then don't go arguing that it's a suitable replacement for Windows.)
Have you ever read code from some of the original UNIX team, such as Kernhigan's Software Tools? Wow, can that man write clean and clear code. The original C compiler is similarly concise. But then look at the sources to just about any Open Source project and see that (1) there's a massive amount of code, and (2) it's mostly very ugly. Unfortunately, even though it's illogical, "open source" and "simplicity" aren't as intimately tied together as one would expect.
The author claims it is not free software. The FLTK site claims otherwise:
FLTK comes with complete free source code. FLTK is available under the terms of the GNU Library General Public License.
We have ammended the LGPL to explicitly allow static linking of FLTK (or any modified version of FLTK) to your software. The LGPL is not clear on this and we definately want to allow it.
All the Linux users (and *BSD for that matter) are walking around with a big smile on their lips days like this.
Sigh. The Windows exploit is essentially a buffer overrun. Microsoft knew about this and released a patch *before* this worm was even written. So it comes down to two things:
1. It's a common problem caused by people writing OS-level services in languages that are prone to these types of problems. Windows and Linux are in the same boat here. Many such exploits have been found in boths OSes, and more will be found in the future.
2. It doesn't matter how fast a patch is released if people don't download and install the patches. Again, both Windows and Linux are identical in this respect.
If Linux were on 90% of all desktop PCs, you'd see the same kinds of viruses and worms. It's not like there haven't been UNIX worms in the past; to think otherwise is fooling yourself. And if Linux were that popular, it would only be a matter of time until bogus "security updates" started making the rounds, so people log in as root to install them, and BANG.
...less interesting on the software side. You can already do development using MAME, various 8-bit computer emulators, and the Game Boy (and the GBA).
But the primary advantage of this system is to understand how the hardware works. That's something you rarely ever see. Even back in the 8-bit days, almost no one really understood machines like the Apple II and Atari 800 on a hardware level. For example, no one ever attempted to redesign Atari's ANTIC chip, because that info just wasn't available. This hasn't changed at all over the last 20 years. FPGAs are cheap and widespread, but not the info about designing graphics hardware.
Back to the software. If you're into game design, and you design and implement a game for MAME (say, on the Williams' 6808-based hardware), then that game is runnable on any PC or Mac right away. Not so with this new system.
Overall, LaMothe has always been very much into writing and teaching about game programming, but he's always completely avoided game design. He develops and writes about lackluster knockoffs of existing games, and offers little to advance the medium. In it's own way, for teaching purposes, that's a good thing. But the last thing we need is everyone to build this new system, then start writing versions of Tetris and Asteroids and old Commodore 64 games for it. If you want to move forward in design, you can do it for existing "hardware."
The original Boulder Dash (Apple II had it in 1981
Nope. Boulder Dash was first released in 1983 for the Atari 800, then ported to other systems. So it wasn't available for the Apple II in 1981.
From the "About" page:
Before 1994, the idea of walking into a bookstore and seeing entire shelves of books on real-time graphics and game programming was almost unheard of. The very techniques and sciences driving the games that were already making billions of dollars for the Ataris and Nintendos of the world were still well-guarded secrets. That all changed, however, with the release of Tricks of the Game Programming Gurus by computer scientist Andre' LaMothe, and within only a few years, an entirely new genre of technical books had seemingly taken over the world.
Uh, I hate to mention it Andre, but this simply isn't true. There were dozens of books about graphics and game programming on 8-bit home computers. COMPUTE! had a whole line of them, for example. You could pick up at least two magazines for each make of computer that included source code listings for games written assembly language and making full use of the hardware. Heck, you could buy the hardware reference manual and even the full operating system source code from Atari. Even the source code to Atari DOS, with full commentary. was available in a $12 book. The source code to Chris Crawfords' award winning Eastern Front, widely considered one of the most advanced commercial games of its time, was also available for purchase. In a number of ways, things were more open and free back then.
similar to the Commodore 64, Atari 800, and Apple II
The Apple II just had a big, dumb frame buffer, plus a static character mode. The C64 and Atari 800 had raster interrupts, redefinable characters, sprites, hardware collision detection of sprites, etc. The Atari 800 was even further out there, with direct hardware support things that needed ugly graphic hacks on the C64 (like mixing graphics modes in arbitrary ways and multiplexing sprites).
Twelve years ago this was a valid question. Now you have:
1. Archived ROMs for almost every arcade and 8-bit home computer game ever produced, including rare and unreleased games.
2. Freely available emulators for running the majority of these. Many games suffer because they don't work well with a mouse and keyboard, but at least the games are preserved.
3. Commercial emulated versions of many old games, which aren't in the gray zone that most ROMs images are. The Namco Museum series is a good example. It even includes lesser known games like Toy Pop and Bosconian.
4. Rabid coin-op hobbyists producing new versions of marquees, control panel art, and so on, for classic arcade machines.
The saturn was bastardized at the last moment to support rudimentary 3D. It's 2D games are widely held to be the best of their kind, it's 3D games are not.
But that's not at all what made the Saturn so "difficult" to program. The 3D stuff was a breeze to work with. The difficulty was only in figuring out how to make good use of the DSP and the second CPU, which was not so easy. If you ignored them, then no trouble at all.
Nobody wanted to develop for it. No developers = no games which = no customers.
The dev kits were insanely expensive, and you had to write for a screwed-up dual CPU system. Not easy.
Essentially what you're describing is a PlayStation 2. Just because something is a bitch to develop for doe NOT give developers the option of not developing for it. That's like dropping a class because you think it's too difficult. Developers do what they get paid to do.