As I said, I've been out of the loop awhile so thanks for the update. I still think, however, that general number-crunching is probably a better description of what was being done back then rather the very specialized parallel processing that GPUs are used for nowadays. But think of the GUI they could have had with 2 machines -- one for the content and one for the presentation.
I've been away from the scene from awhile but can someone tell me which phone is capable of performing 160 million Floating Point Operations per second? At 6 clock cycles per Floating Point Instruction (which I really doubt), that would be running at a clock rate of 1GHz. I recall that even NOP (No Operation) instructions take a clock or two to execute which is why they used to be (still are?) used in some timing loops. Even with pipelining that advances every clock cycle, I find it hard to believe that 355.0/113.0 done out to 6 or 10 digits of (equivalent) precision can be done 160 Million times per second. I can see a phone micro maybe handling 160MIPS (Instructions Per Second), but not floating point.
It also promotes better music because when the consumer has better choice, they will choose better music.
I got out of the retail record business over 25 years ago because the industry was rapidly losing its customers to consumers. They weren't choosing better music; they were choosing cheaper music. Saving 50 cents on Saturday Night Fever was more important than their store actually having a wide selection of interesting sounds. Eventually, it wasn't worth it to stock the better; only the popular.
I blame the Decline of Western Civilization on the Rise of the Consumer. YMMV.
That may have been true of the later versions (CoCo 2 / CoCo 3) but the very first one was incredibly minimal. Remember, this was in 1980-81 and I don't think that the IBM PC was even out yet (at least while I was writing the game) so the bar hadn't even begun to be raised.
re: Java vs asm -- my point was more that the features of the game were far beyond most of what had been done (2-D paddles, gravity, multi-player, etc.) in that early era.
While not wanting to take away too much from this, in the early 80s, Radio Shack released a version of Breakout (the ball and bricks game) that had nine modes including 2-player versions in both cooperative and competitive modes. You could put English on the ball (square) because of the 2-D paddle motion (not just 1-D). In some modes (bricks at top of screen), gravity also affected the trajectories.
For the Color Computer ("CoCo") -- 1K of RAM (included the screen memory) and 4K of ROM for the program. Don't remember if there was anything like a BIOS but I believe not. No OS, no virtual machines, or any of the fun things available nowadays.
I spent many long nights squeezing my code into that tight shoe -- and along the way fell in love with the Motorola 6809 as probably the best designed microprocessor ever made. (I haven't seen anything since then to change my opinion on that.)
The more things change, the more they stay the same....
I just received email (5/15/06 9:18am CDT) from Palm Products Newsletter announcing "The new Treo 700p smartphonecoming soon on the Sprint and Verizon Wireless networks." Basic ad email with some pictures.
So it was actually a 15-bit counter. And that was necessary because we all know that a negative number of changes was likely to happen so it had to be implemented with a SIGNED counter rather than an unsigned counter. (Would doubling the number of changes allowed by using an unsigned counter have eliminated... errrrr, postponed.... the problem to another day?)
Oh yeah --- everything had to be written in position independent code (PIC) -- couldn't use any of the 'bsolute addressin' stuff. In development, I'm not even sure that the RAM-emulating-ROM was at the same place in the address space so 'bsolutely only used relative addressing. Since the short jumps were not as capable as long jumps, you moved subroutines around to best position the size of the jumps (or calls) -- often could save a few bytes just by reordering portions of the code.
Working on the Tandy Color Computer was similar. I programmed Super BustOut for the initial release of the machine. 4K Rom, 1K Ram (1/2 of which was the screen.) You had to squeeze every byte out of the 6809's instruction set (one of the greatest processor designs ever!) But we ended up with a great game... like Breakout but with * 2D paddle motion * horizontal or vertical brick orientation * gravity in some modes * "English" on the paddle/ball interactions * single or dual player in competitive or cooperative simultaneous play * sound effects (CPU generated) * etc. etc.
Just before release, with 9 free bytes left, a bug was found. The initial fix would break the ROM barrier by 13 bytes. Yet another pass through the code doing the 4th or 5th optimization -- finally got it in and ended up with 11 free bytes.
Amazing what is possible in ASM but, boy, it was many 20 hour days!
So I understand those 'smallest executable' contests, but how much functionality does the executable really have? Or how much of the Word document is really information?
The developers say they can't wait 20 years for a 1000 fold increase. But if Moore's Law holds, there are about 13 18-month periods in 20 years so they could get a 8,192 fold increase in that period. (Or a 1,024 fold increase in about 15 years).
We know have 800MHz machines -- about 20 years ago the standard was the 4.77Mz 8088 -- that's a 167 fold increase.
But the architectures are so different now -- any idea what the real performance (not just clock rates) increase is?
You can always throw more hardware at a bubble-sort to speed it up -- but a better algorithm makes more sense. Discussing distributed computing, etc. sounds like looking for better algorithms, not just more cycles.
With similar logic, I can prove that the chances of you sitting in a particular place are extremely vanishingly small.
Consider all the possible locations in the universe -- let's assume some rough size so there are only 10000000^10000000 possible locations.
And a similar collection of atoms that constitute you -- again, let's say that you are one of a possible 1000000^1000000 configurations. (Let's not even get into how this particular clump of atoms got together).
NOW --- the chances, i.e. the probability, of this particular state of affairs existing is astronomically small. Yet you exist where you exist.
Both the probability is real and your existence is real.
But the chances that based upon the state of affairs at a prior time (4,000yrs, 12 billion years, whatever), that this one state of current affairs would exist is infinitesimal. But some state of affairs has to exist.
The problem is in defining the 'outcomes' to be the goal -- there is a 100% chance of some state of affairs to exist, we just don't know which state it might be. It may have been just as useful that we developed with three eyes -- evolution is not a progression toward a goal (a particular outcome) but a series of changes and we examine the series at a particular point in time.
Seti@Home takes about 65 hours per data packet on my machine -- of course with Win98 there are almost daily requested or insisted upon shutdowns. The designers obviously anticipated power-offs (intended or not) and dealt with it. I think the apps that require such runtimes should be designed to deal with such exigencies.
Has to be... It isn't even an original virus! It's just a variation of one that has been affecting systems for months. Obviously, the Taliban cannot support up-to-date technology and has to rely upon recycling viruses with some kind of script kiddie toolkit. Yet another reason to clamp down on the distribution of hacker toolz!
What I see is "unlawful to manufacture, import, offer to the public, provide or otherwise traffic in any interactive digital device that does not include and utilize certified security technologies that adhere to the security system standards.". Which is basically saying that "if you want to have something that you can view multimedia on, it has to have built in digital copyright controls on it".
It is a big jump to assume that interactive digital device means multimedia (in the now-current sense of music and video).
About 15 years ago, I moved from the application developement world (spreadsheets, etc.) to the new world of "interactive advertising" -- using floppies (originally 360k disks targetted to CGA quality screens) to provide information and eye-candy.
The computer itself was considered the interactive digital device. The technology has advanced tremendously but I believe you could still argue that the interactive nature of the programs (display of information is at least partially controlled by the interaction of the viewer and the computer) still applies.
By this reading (don't you hate it when history comes into play:-), all computers now existing would not longer be able to be sold on the used market because none of them have the appropriate controls.
Maybe this proposed regulation is supposed to "only" apply to videos and music -- if so, the wording needs to be drastically altered. (Even with such alterations I think this whole kind of thing is a bad and stupid idea.)
I wouldn't think of trying to read a book on my laptop. My Handspring, however, is a different story...
Last summer, out in the woods with the new popup camper, it was very enjoyable to reread Huckleberry Finn (which I do every few years) whenever I could grab a few minutes. I carry it anyway (work, spreadsheets, phone #s, etc.) so I might as well load up a book or three for those spare moments.
I purchased and read all the installments of Stephen King's The Plant (first time I've ever read anything by him). I'm looking forward to the conclusion of the work (if he ever decides that the 6-figure _profit_ he made from the early portions justifies writing some more).
Some implementations of ZModem supported LZW compression (but not all because of the LZW patent issues) -- according to the book The Working Programmer's Guide to Serial Protocols by Tim Kientzle. Copr 1995. The question would be if "standard ZModem" specified this option earlier than 1991...
And Kermit and Blast also did some kind of compression. Kermit development began in 1981 and it seems like RLE (run-length encoding) was there from the very early stages. I just looked at a book about modems -- 3rd ed from 1992 (which means it was published between the patent filing and the patent grant) -- and [XYZ]Modem, Kermit and Blast are all mentioned as protocols with some kind of compression built in. (File compression programs were mentioned separately).
And I seem to recall that the posting of news back in the '80s was at least smart about 'partial updating' and I think (but am not positive) that uucp probably did some kind of compression because it was so obvious a thing to do...
>> Using that reasoning, it's probably also a function of who's paying for it and whether it's a want or a need.
But what does that do to all the cantatas and other works that J.S. Bach wrote as a paid church musician who was filling the need for new music every week?
Our culture no longer has the same need and very few paid church composers... Is Bach now an artist while he was (only) a craftsman in his own time?
Glad to know that my BFA makes me a script kiddie although I have been supporting myself and others (sometimes a whole company) for over 20 years know. Those Fortune 100 companies must feel really bad that this non-CS person can do more things in more computer languages than their IT department. And they pay for it! And hundreds of thousands of people in the real world (not just the computer world) have used the programs. The best programmers I've ever met -- and there have been some damn good ones -- didn't have CS degrees. But we actually read Knuth, Wirth, Ritchie, et al, and try to learn from them. And most of the best are also musicians, artists, writers, not just programmers.
Slashdot Mirror
As I said, I've been out of the loop awhile so thanks for the update. I still think, however, that general number-crunching is probably a better description of what was being done back then rather the very specialized parallel processing that GPUs are used for nowadays. But think of the GUI they could have had with 2 machines -- one for the content and one for the presentation.
I've been away from the scene from awhile but can someone tell me which phone is capable of performing 160 million Floating Point Operations per second? At 6 clock cycles per Floating Point Instruction (which I really doubt), that would be running at a clock rate of 1GHz. I recall that even NOP (No Operation) instructions take a clock or two to execute which is why they used to be (still are?) used in some timing loops. Even with pipelining that advances every clock cycle, I find it hard to believe that 355.0/113.0 done out to 6 or 10 digits of (equivalent) precision can be done 160 Million times per second. I can see a phone micro maybe handling 160MIPS (Instructions Per Second), but not floating point.
I got out of the retail record business over 25 years ago because the industry was rapidly losing its customers to consumers. They weren't choosing better music; they were choosing cheaper music. Saving 50 cents on Saturday Night Fever was more important than their store actually having a wide selection of interesting sounds. Eventually, it wasn't worth it to stock the better; only the popular.
I blame the Decline of Western Civilization on the Rise of the Consumer. YMMV.
The title of this article is redundant.
That may have been true of the later versions (CoCo 2 / CoCo 3) but the very first one was incredibly minimal. Remember, this was in 1980-81 and I don't think that the IBM PC was even out yet (at least while I was writing the game) so the bar hadn't even begun to be raised.
re: Java vs asm -- my point was more that the features of the game were far beyond most of what had been done (2-D paddles, gravity, multi-player, etc.) in that early era.
While not wanting to take away too much from this, in the early 80s, Radio Shack released a version of Breakout (the ball and bricks game) that had nine modes including 2-player versions in both cooperative and competitive modes. You could put English on the ball (square) because of the 2-D paddle motion (not just 1-D). In some modes (bricks at top of screen), gravity also affected the trajectories.
For the Color Computer ("CoCo") -- 1K of RAM (included the screen memory) and 4K of ROM for the program. Don't remember if there was anything like a BIOS but I believe not. No OS, no virtual machines, or any of the fun things available nowadays.
I spent many long nights squeezing my code into that tight shoe -- and along the way fell in love with the Motorola 6809 as probably the best designed microprocessor ever made. (I haven't seen anything since then to change my opinion on that.)
The more things change, the more they stay the same ....
I just received email (5/15/06 9:18am CDT) from Palm Products Newsletter announcing "The new Treo 700p smartphonecoming soon on the Sprint and Verizon Wireless networks." Basic ad email with some pictures.
So it was actually a 15-bit counter. And that was necessary because we all know that a negative number of changes was likely to happen so it had to be implemented with a SIGNED counter rather than an unsigned counter. (Would doubling the number of changes allowed by using an unsigned counter have eliminated ... errrrr, postponed .... the problem to another day?)
Oh yeah --- everything had to be written in position independent code (PIC) -- couldn't use any of the 'bsolute addressin' stuff. In development, I'm not even sure that the RAM-emulating-ROM was at the same place in the address space so 'bsolutely only used relative addressing. Since the short jumps were not as capable as long jumps, you moved subroutines around to best position the size of the jumps (or calls) -- often could save a few bytes just by reordering portions of the code.
* 2D paddle motion
* horizontal or vertical brick orientation
* gravity in some modes
* "English" on the paddle/ball interactions
* single or dual player in competitive or cooperative simultaneous play
* sound effects (CPU generated)
* etc. etc.
Just before release, with 9 free bytes left, a bug was found. The initial fix would break the ROM barrier by 13 bytes. Yet another pass through the code doing the 4th or 5th optimization -- finally got it in and ended up with 11 free bytes.
Amazing what is possible in ASM but, boy, it was many 20 hour days!
So I understand those 'smallest executable' contests, but how much functionality does the executable really have? Or how much of the Word document is really information?
Can't register at passport.com with Opera 6.04 either (at least when it identifies itself as Opera rather than IE).
The developers say they can't wait 20 years for a 1000 fold increase. But if Moore's Law holds, there are about 13 18-month periods in 20 years so they could get a 8,192 fold increase in that period. (Or a 1,024 fold increase in about 15 years).
We know have 800MHz machines -- about 20 years ago the standard was the 4.77Mz 8088 -- that's a 167 fold increase.
But the architectures are so different now -- any idea what the real performance (not just clock rates) increase is?
You can always throw more hardware at a bubble-sort to speed it up -- but a better algorithm makes more sense. Discussing distributed computing, etc. sounds like looking for better algorithms, not just more cycles.
Consider all the possible locations in the universe -- let's assume some rough size so there are only 10000000^10000000 possible locations.
And a similar collection of atoms that constitute you -- again, let's say that you are one of a possible 1000000^1000000 configurations. (Let's not even get into how this particular clump of atoms got together).
NOW --- the chances, i.e. the probability, of this particular state of affairs existing is astronomically small. Yet you exist where you exist.
Both the probability is real and your existence is real.
But the chances that based upon the state of affairs at a prior time (4,000yrs, 12 billion years, whatever), that this one state of current affairs would exist is infinitesimal. But some state of affairs has to exist.
The problem is in defining the 'outcomes' to be the goal -- there is a 100% chance of some state of affairs to exist, we just don't know which state it might be. It may have been just as useful that we developed with three eyes -- evolution is not a progression toward a goal (a particular outcome) but a series of changes and we examine the series at a particular point in time.
Seti@Home takes about 65 hours per data packet on my machine -- of course with Win98 there are almost daily requested or insisted upon shutdowns. The designers obviously anticipated power-offs (intended or not) and dealt with it. I think the apps that require such runtimes should be designed to deal with such exigencies.
And just what is your reason for hiding your on-line banking password?
And what problem does this allow you to ignore?
Has to be ... It isn't even an original virus! It's just a variation of one that has been affecting systems for months. Obviously, the Taliban cannot support up-to-date technology and has to rely upon recycling viruses with some kind of script kiddie toolkit. Yet another reason to clamp down on the distribution of hacker toolz!
About 15 years ago, I moved from the application developement world (spreadsheets, etc.) to the new world of "interactive advertising" -- using floppies (originally 360k disks targetted to CGA quality screens) to provide information and eye-candy. The computer itself was considered the interactive digital device. The technology has advanced tremendously but I believe you could still argue that the interactive nature of the programs (display of information is at least partially controlled by the interaction of the viewer and the computer) still applies.
By this reading (don't you hate it when history comes into play :-), all computers now existing would not longer be able to be sold on the used market because none of them have the appropriate controls.
Maybe this proposed regulation is supposed to "only" apply to videos and music -- if so, the wording needs to be drastically altered. (Even with such alterations I think this whole kind of thing is a bad and stupid idea.)
Last summer, out in the woods with the new popup camper, it was very enjoyable to reread Huckleberry Finn (which I do every few years) whenever I could grab a few minutes. I carry it anyway (work, spreadsheets, phone #s, etc.) so I might as well load up a book or three for those spare moments.
I purchased and read all the installments of Stephen King's The Plant (first time I've ever read anything by him). I'm looking forward to the conclusion of the work (if he ever decides that the 6-figure _profit_ he made from the early portions justifies writing some more).
Specialized readers? NO! Useful and/or entertaining documents? SURE!
I carry around the Constitution, Bill of Rights, Declaration of Independence, FIFA Soccer Rules, Unleashing the Ideavirus!, and others ...
Having the exact quote at your fingertips is sometimes quite handy ...
A friend of mine had a sign up in his cubicle that read, "Whenever you are in a demo situation, say nothing more predictive than 'Watch this.'"
Does anybody know the patent number?
Some implementations of ZModem supported LZW compression (but not all because of the LZW patent issues) -- according to the book The Working Programmer's Guide to Serial Protocols by Tim Kientzle. Copr 1995. The question would be if "standard ZModem" specified this option earlier than 1991 ...
And Kermit and Blast also did some kind of compression. Kermit development began in 1981 and it seems like RLE (run-length encoding) was there from the very early stages. I just looked at a book about modems -- 3rd ed from 1992 (which means it was published between the patent filing and the patent grant) -- and [XYZ]Modem, Kermit and Blast are all mentioned as protocols with some kind of compression built in. (File compression programs were mentioned separately). And I seem to recall that the posting of news back in the '80s was at least smart about 'partial updating' and I think (but am not positive) that uucp probably did some kind of compression because it was so obvious a thing to do ...
But what does that do to all the cantatas and other works that J.S. Bach wrote as a paid church musician who was filling the need for new music every week? Our culture no longer has the same need and very few paid church composers ... Is Bach now an artist while he was (only) a craftsman in his own time?
Glad to know that my BFA makes me a script kiddie although I have been supporting myself and others (sometimes a whole company) for over 20 years know. Those Fortune 100 companies must feel really bad that this non-CS person can do more things in more computer languages than their IT department. And they pay for it! And hundreds of thousands of people in the real world (not just the computer world) have used the programs. The best programmers I've ever met -- and there have been some damn good ones -- didn't have CS degrees. But we actually read Knuth, Wirth, Ritchie, et al, and try to learn from them. And most of the best are also musicians, artists, writers, not just programmers.