I don't see why the parent was modded offtopic when the answer to his question is the topic.;)
MPlayer understands file formats, such as QuickTime, and plays video codecs such as MPEG2. It doesn't care what video codecs you put in which file formats like most commercial players. It will most definately play a QuickTime file with MPEG2 video.
Presumably you use a Mac. I don't, but I seem to recall seeing a credit in the MPlayer documentation for an OSX port...
"As I take it, his basic point seems to be that both Windows and Linux are based on OS concepts developed at least 30 years ago:
* "Data" and "Code" are separate and inviolable"
Microsoft has made significant progress has been made in the area of removing the seperation data and code under Windows. Outlook and your favorite email virus should be a good example of that!
Seriously, there's a reason code and data should be kept seperate: security.
And IBM, arguably the No. 1 player in the Linux market, promotes Linux to big users, but does not actually sell Linux: "It's weird. IBM says 'Hey British Aerospace! Buy Linux...from SuSE.'"
I guess when you are a monopolist, working with another company instead of trying to buy them or squeeze them out of the market is a bit weird...
My Tivo captures at 544x480, in best quality. Either you are wrong, or they increased the resolution in later software revisions. Mine has the latest, 2.5.1.
Slackware started out as a set of patches to make SLS a bit nicer. After SLS development stopped, Patrick released Slackware as a complete distribution.
BTW, there seems to be a lot of misconceptions about the state of slackware. Slackware has been a one-man company for years, and last I heard, it has always been profitable. For a while, it was a subsidiary of Walnut Creek CDROM, which was bought/merged with BSDI. BSDI pumped a bit more money into Slack, allowing Patrick to hire additional developers. When Windriver bought out BSDI's softare business, Slackware split off and became a seperate company again -- just Patrick.
The other developers, like David Cantrell, are still members of the Slackware development team who contribute in their spare time. They have to have day jobs doing other things to pay the rent now, so they aren't full-time slack developers. Development may slow down a little as a result, but it does not mean Slack is dead.
For those who haven't checked their favorite Slackware mirror lately, slackware-current is live again. Updates are coming slowly, but that is normal so soon after a major release.
Re:Games: XFree86 with DRI, or Linux FBDev?
on
XFree 4.1.0 Out
·
· Score: 1
"Kernel Drivers do not have to be under the GPL"
They do if you want them distributed with the kernel source tree.
Here's another idea. If DSL providers actually policed their network, and culled all the script kiddies, nukers, DVD-downloaders, DDoSsers etc., they could save themself one hell of a lot of money on bandwidth charges to their upstream provider.
Here's an easier way...why don't they just lower the amount of bandwidth everyone gets. Oh wait, then not as many people would want the service. Legalities aside, a fast connection that you can't download DVD's, MP3's, warez, porn, or whatever else you want is rather useless. And I suspect DVD downloading is actually the least popular of the above, and consumes the least bandwidth.
There are two types of people who use their connections. The occasional browsers, and the heavy users. The ISPs love the occasional browsers, as they don't use their connections to anywhere near capacity. Unless DSL or cable is cheap (it is in many areas now, but far from all), not many of these people are going to get it, because they don't really need it. The heavy users on the other hand, are going to be the first ones in line for cheap bandwidth. They are the ones the ISPs hate, because they actually _use_ the the services provided to them.:)
Script kiddies aren't that big of an issue here, they mainly cause problems for the receiver. A script kiddie on a modem attacking some user on x random DSL provider is more likely to consume their bandwidth, than one who is actually on their service attacking others. At least until they get attacked in return... I'm not saying they're not a problem, just that they are not a DSL-specific problem, and it's not really any worse there than it is anywhere else.
Right except for wet weather. I've never seen a race halted for wet weather.
However, a large number of the drivers on the street seem to freak out and drive like idiots (even more so than normal) whenever it rains. Racers don't have to worry about that.
Actually, the 68000-series CPUs on which the Amiga was based are mostly 32-bit. The original 68000 CPU was not fully 32-bit, but the 68020 and up were. Linux requires a 68020 or higher with an MMU.
Over all, I think I would have liked network or modem multiplayer support better than the two mouse method. It was too tempting to peek at that the other player was doing.
Too tempting? If you didn't pay attention to what the other person was doing, you were likely to find all of your lemmings falling down a new hole that was not originally part of the map.:)
"Yes, there are a lot of people who wouldn't be able to use an electric car because of the distances they drive, or other factors. That doesn't mean they aren't great solutions for those of us who can use them."
But if there were no government incentives to GM allowing them to sell the car for thousands of dollars less than it costs to build it, and you had to pay the full price of the car, would you still be willing to buy one?
Plus, they double as your floppy drive which is cool, saves space, and sounds better than a regular floppy drive (not quite as gratingly noisy with the seeks and transfers).
You obviously don't have the same model LS120 that my brother has. Not only is it about 1/4th the speed of a standard floppy drive when reading standard floppies, it's also about 3x louder.
It's perfectly fast and not particularly loud for reading SuperDisks though.
I've had from 1-3 computers running 24/7 at home at various times over the last 5 years.
A few years ago, I had just put a new (old) 8-bit soundblaster card into my 486. A few hours later, one of the capacitors on the card caught on fire. I would not have noticed if the case had been on. Whether it would have spread to other components, or just burned itself out I do not know.
I never did check the card to see if it works, but a friend of mine has an SB16 that he said caught on fire once, and still works.
"I still don't like the idea that they're keeping the instruction sets closed. It would seem like if someone out there wanted to port GCC to Crusoes native instructions, that would be good... But they just don't want to be percieved as being at all incompatible with Intel, i guees.
The reason has nothing to do with Intel compatibility, it has to do with the nature of VLIW. As someone else mentioned above, every new VLIW CPU from Transmeta will be different (the two CPUs they announced have different cores) and require totally different optimizing, possibly even having a different instruction set.
What Transmeta has done is remove the primary problem of VLIW...the fact that you need a very specific compiler for your CPU to extract performance out of it. By including the "compiler" in the CPU, it's done for you at run time, so you won't have to recompile your code every time you get a new CPU.
"The only solution might be to run all the code on the server. Yes, really. Imagine the client side just being a 2D graphical dumb terminal just drawing frames from the server. It can't be 3D because it would be hackable at the driver-level again."
I think you are right, that is what we will see eventually. But it won't be until the average person has cable, DSL, or some other high-bandwidth, low-latency connection to the net that it will be technically feasible.
But with the average player trapped behind a modem, the kind of tricks Carmack used are necessary for the game to be playable. ESR mentioned Carmack's reply in his article, but did not comment on it, and appeared to pass it off as unimportant because the design should have been "done right" in the first place. Obviously, ESR has never played Quake on a modem against players on low latency connections.:)
My other comment on the article was that there were no direct statement of ESR's point. From reading the comments here, it seems many people got entirely different meanings out of it. Pretty poorly written, IMHO.
As someone else mentioned, the solution is to turn off PCI Retry in your X server options. This is an article a friend of mine sent me about why it happens. The article is primarily directed at Windows drivers, but their drivers are just doing the same thing as PCI Retry under X.
--- (If you are not using a PC with a PCI VGA accelerator card, you need not read any further....)
WARNING: Long post ahead! updated 11/11/97
In the past this information has been suppressed, now it can be told...
A good number of VGA card manufacturers are squeezing out a few extra points on their winbench scores by locking up the PCI bus. This is fine for graphics and most systems on the PC (hard disks and such) don't even notice the problem.... Unfortunately this can hurt the audio system in a big way. Most audio cards use ISA/DMA to trickle samples over the bus one word at a time. Even PCI cards such as the AMIII can be hurt by this problem because they trickle the data over the bus in tiny PCI transfers. When another device illegally locks up the bus for more than 1/88200th of a second, there's a good chance you will lose audio samples resulting an a glitch in the recording or playback. How do you know if you're having this problem? Try opening up your favorite wave editing program, loading a wave file and hitting the play button. While the audio is playing, grab the top of the window (assuming it is not maximized) and repeatedly pick it up and drag it to another location on the desktop. On a soundblaster compatible card, the audio will glitch and pop while you drag the window. On a ZA2 card, there is a 50/50 chance the audio will swap L/R channels after such a glitch. On an adb card, not only can the right and left channels swap, but there is also a good chance the audio will be left in a glitchy mode that makes the audio repeatedly jump channels resulting in a high pitch scratchy noise.
At this point in the discussion, I would like to stress that this is NOT (I repeat NOT) the fault of the soundcard! This is not even the fault of the VGA card... it is in fact the fault of the VGA driver. If you do not experience any glitching or distortion then you can probably ignore the rest of this post! I've heard that the VGA drivers supplied by Microsoft (verses the drivers supplied by the VGA manufacturer) do not suffer from this problem.
I think Matrox was the first to play with this, but it doesn't really matter because most high performance VGA accelerator cards for the PCI bus are doing the same thing now. When a number of graphics acceleration operations need to be performed, these commands are sent from the VGA driver to the VGA card over the PCI bus. The VGA chipset has a built in queue that is capable of holding several accelerator commands. Normally the driver checks a status bit on the VGA card to tell if this queue is full or not. If the queue is full, the driver waits for the queue to have a free space before sending the next command. Matrox discovered (and everyone soon followed) that you could increase VGA performance by NOT CHECKING THIS STATUS BIT!!!!! What happens when you write blindly to a full queue of commands on the VGA card? The bus hangs... The bus master has started a PCI transaction, but the target (the VGA card) can't accept the data yet because it has no place to put it. As soon as the VGA card has room for the data, then the transaction can complete... but until that time the PCI bus is completely locked up. No PCI or ISA transactions can happen. This can take a long time (40 or more audio cycles) if the current VGA operation is a huge BITBLT on a 24bit screen... A 256 or 512 bit FIFO just ain't gonna cut it. The only acceptable solution to this problem is to put the queue check BACK into the VGA driver. I have been discussing this problem with some of the engineers at Matrox and Tseng labs and have some solutions for you! Tseng labs has released a new version of their ET6000 VGA driver that behaves nicer to the PCI bus.. this driver is now trickling down to the STB and Hercules products that use the ET6000 chip. For the Hercules Dynamite 128 card, there is a new driver on the Hercules BBS (not web page... don't ask me) called DV95112 (Version 1.12) Using this driver, you need to add a special switch in your system.ini file. Under the heading [Hercules] there is a line that reads "Optimization=0" you will need to set this to "Optimization=1"... ta da, problem fixed. It turns out that Matrox has ALWAYS had a hidden back door switch to enable this check in the VGA driver. If you are using the Matrox Millennium, you will need to add the following lines to your system.ini file:
[mga.drv] PCIChipset=1
This almost fixes the problem completely.... you will also need to disable the "Use PowerGDI acceleration" feature in the Advanced Matrox setup (Control Panel->Display Properties->MGA Settings->Advanced->Performance) ta da... problem fixed.
[update July 1997] I've heard from the good folks at S3 that _ALL_ S3 drivers for all of their VGA cards (downloaded from www.s3.com) can be fixed by adding a line in system.ini under the [display] section... After [display] add the line 'bus-throttle=1' so (for S3 drivers):
[display] busthrottle=1
[update September 1997] For owners of newer Matrox cards: Go to screen properties (right click in main window) Go to setting tab, Click on PowerDesk button Check 'Use Bus Mastering' (on) Uncheck 'Use Automatic PCI Bus retries' (off) On Pentium Pro machines, Uncheck 'Use Write-Combining' Click on OK
[updated November 1997] For owners of the #9 Imagine 128 series 2 It seems a new driver (version 4.102.36) is now available directly from the folks at #9 upon request..
Unfortunately there are other VGA maker who have not acknowledged this problem (not that Matrox or Tseng has formally done so either). And we as users, software manufacturers or hardware manufacturers need to get the word out that this is a VGA problem and not a DMA problem!!!!!! We need to drill it through the heads of the VGA card makers that they can't get away with this B.S. without at least having an OPTION to make the driver behave appropriately.
Have you ever been told to turn the VGA acceleration off??? or to reduce the size of your VGA screen??? or reduce the color depth???
THESE ARE NOT ACCEPTABLE SOLUTIONS!!!
Call your VGA manufacturer and tell them they need to fix the problem! (You will probably need to get beyond Joe Tech Support, because he probably doesn't know anything about this... please inform him!)
This message has been brought to you by Greg Hanssen (hanssen@zefiro.com) copyright 1996 Zefiro Acoustics.
PLEASE feel free to post this to any forum where the knowledge can be used.
Now you're getting into something considerably more complex than simple stuff like MP3 playing, GPS, and anything else you might normally use your computer for. Check out the diy_efi mailing list (Do It Yourself Electronic Fuel Injection)...you might be surprised how complicated things really are. http://efi332.eng.ohio-state.edu/diy_efi/
Slashdot Mirror
I don't see why the parent was modded offtopic when the answer to his question is the topic. ;)
MPlayer understands file formats, such as QuickTime, and plays video codecs such as MPEG2. It doesn't care what video codecs you put in which file formats like most commercial players. It will most definately play a QuickTime file with MPEG2 video.
Presumably you use a Mac. I don't, but I seem to recall seeing a credit in the MPlayer documentation for an OSX port...
Microsoft has made significant progress has been made in the area of removing the seperation data and code under Windows. Outlook and your favorite email virus should be a good example of that!
Seriously, there's a reason code and data should be kept seperate: security.
I guess when you are a monopolist, working with another company instead of trying to buy them or squeeze them out of the market is a bit weird...
"I can get 3-5 years out of a car"
You do know you are supposed to change the oil every 3-5000 miles, right? ;)
My Tivo captures at 544x480, in best quality. Either you are wrong, or they increased the resolution in later software revisions. Mine has the latest, 2.5.1.
Here's what mplayer has to say about it:
VIDEO: MPEG2 544x480 (aspect 2) 29.97 fps 7250.0 kbps (906.2 kbyte/s)
I've never tried extracting less than best quality, so I don't know if they use a lower resolution or not for those.
Slackware started out as a set of patches to make SLS a bit nicer. After SLS development stopped, Patrick released Slackware as a complete distribution.
BTW, there seems to be a lot of misconceptions about the state of slackware. Slackware has been a one-man company for years, and last I heard, it has always been profitable. For a while, it was a subsidiary of Walnut Creek CDROM, which was bought/merged with BSDI. BSDI pumped a bit more money into Slack, allowing Patrick to hire additional developers. When Windriver bought out BSDI's softare business, Slackware split off and became a seperate company again -- just Patrick.
The other developers, like David Cantrell, are still members of the Slackware development team who contribute in their spare time. They have to have day jobs doing other things to pay the rent now, so they aren't full-time slack developers. Development may slow down a little as a result, but it does not mean Slack is dead.
For those who haven't checked their favorite Slackware mirror lately, slackware-current is live again. Updates are coming slowly, but that is normal so soon after a major release.
"Kernel Drivers do not have to be under the GPL"
They do if you want them distributed with the kernel source tree.
OpenVerse Visual Chat: http://openverse.org
There are some SPEC benchmarks and commentary up on aceshardware.com.
Interesting that Intel appears to have finally released a CPU with good (great, even) fp performance. Too bad it sucks for integer...
OpenVerse Visual Chat: http://openverse.org
Here's an easier way...why don't they just lower the amount of bandwidth everyone gets. Oh wait, then not as many people would want the service. Legalities aside, a fast connection that you can't download DVD's, MP3's, warez, porn, or whatever else you want is rather useless. And I suspect DVD downloading is actually the least popular of the above, and consumes the least bandwidth.
There are two types of people who use their connections. The occasional browsers, and the heavy users. The ISPs love the occasional browsers, as they don't use their connections to anywhere near capacity. Unless DSL or cable is cheap (it is in many areas now, but far from all), not many of these people are going to get it, because they don't really need it. The heavy users on the other hand, are going to be the first ones in line for cheap bandwidth. They are the ones the ISPs hate, because they actually _use_ the the services provided to them. :)
Script kiddies aren't that big of an issue here, they mainly cause problems for the receiver. A script kiddie on a modem attacking some user on x random DSL provider is more likely to consume their bandwidth, than one who is actually on their service attacking others. At least until they get attacked in return... I'm not saying they're not a problem, just that they are not a DSL-specific problem, and it's not really any worse there than it is anywhere else.
OpenVerse Visual Chat: http://openverse.org
Right except for wet weather. I've never seen a race halted for wet weather.
However, a large number of the drivers on the street seem to freak out and drive like idiots (even more so than normal) whenever it rains. Racers don't have to worry about that.
OpenVerse Visual Chat: http://openverse.org
Actually, the 68000-series CPUs on which the Amiga was based are mostly 32-bit. The original 68000 CPU was not fully 32-bit, but the 68020 and up were. Linux requires a 68020 or higher with an MMU.
Otherwise you need something like ucLinux.
OpenVerse Visual Chat: http://openverse.org
Too tempting? If you didn't pay attention to what the other person was doing, you were likely to find all of your lemmings falling down a new hole that was not originally part of the map. :)
OpenVerse Visual Chat: http://openverse.org
I'm still annoyed that there's no serial port on Sony's recent laptops...
OpenVerse Visual Chat: http://openverse.org
But if there were no government incentives to GM allowing them to sell the car for thousands of dollars less than it costs to build it, and you had to pay the full price of the car, would you still be willing to buy one?
OpenVerse Visual Chat: http://openverse.org
You obviously don't have the same model LS120 that my brother has. Not only is it about 1/4th the speed of a standard floppy drive when reading standard floppies, it's also about 3x louder.
It's perfectly fast and not particularly loud for reading SuperDisks though.
OpenVerse Visual Chat: http://openverse.org
I've had from 1-3 computers running 24/7 at home
at various times over the last 5 years.
A few years ago, I had just put a new (old) 8-bit soundblaster card into my 486. A few hours later, one of the capacitors on the card caught on fire. I would not have noticed if the case had been on.
Whether it would have spread to other components, or just burned itself out I do not know.
I never did check the card to see if it works, but a friend of mine has an SB16 that he said caught on fire once, and still works.
OpenVerse Visual Chat: http://openverse.org
The reason has nothing to do with Intel compatibility, it has to do with the nature of VLIW. As someone else mentioned above, every new VLIW CPU from Transmeta will be different (the two CPUs they announced have different cores) and require totally different optimizing, possibly even having a different instruction set.
What Transmeta has done is remove the primary problem of VLIW...the fact that you need a very specific compiler for your CPU to extract performance out of it. By including the "compiler" in the CPU, it's done for you at run time, so you won't have to recompile your code every time you get a new CPU.
OpenVerse Visual Chat: http://openverse.org
I think you are right, that is what we will see eventually. But it won't be until the average person has cable, DSL, or some other high-bandwidth, low-latency connection to the net that it will be technically feasible.
But with the average player trapped behind a modem, the kind of tricks Carmack used are necessary for the game to be playable. ESR mentioned Carmack's reply in his article, but did not comment on it, and appeared to pass it off as unimportant because the design should have been "done right" in the first place. Obviously, ESR has never played Quake on a modem against players on low latency connections.
My other comment on the article was that there were no direct statement of ESR's point. From reading the comments here, it seems many people got entirely different meanings out of it. Pretty poorly written, IMHO.
Quake! http://lonestar.intcomm.net
Chat! http://openverse.org
As someone else mentioned, the solution is to turn off PCI Retry in your X server options. This is an article a friend of mine sent me about why it happens. The article is primarily directed at Windows drivers, but their drivers are just doing the same thing as PCI Retry under X.
---
(If you are not using a PC with a PCI VGA accelerator card,
you need not read any further....)
WARNING: Long post ahead! updated 11/11/97
In the past this information has been suppressed, now it can be told...
A good number of VGA card manufacturers are squeezing out a few extra
points on their winbench scores by locking up the PCI bus. This is fine
for graphics and most systems on the PC (hard disks and such) don't even
notice the problem.... Unfortunately this can hurt the audio system in
a big way.
Most audio cards use ISA/DMA to trickle samples over the bus one word
at a time. Even PCI cards such as the AMIII can be hurt by this problem
because they trickle the data over the bus in tiny PCI transfers. When
another device illegally locks up the bus for more than 1/88200th of a
second, there's a good chance you will lose audio samples resulting an a
glitch in the recording or playback.
How do you know if you're having this problem? Try opening up your
favorite wave editing program, loading a wave file and hitting the play
button. While the audio is playing, grab the top of the window (assuming
it is not maximized) and repeatedly pick it up and drag it to another
location on the desktop. On a soundblaster compatible card, the audio
will glitch and pop while you drag the window. On a ZA2 card, there is
a 50/50 chance the audio will swap L/R channels after such a glitch.
On an adb card, not only can the right and left channels swap, but there
is also a good chance the audio will be left in a glitchy mode that makes
the audio repeatedly jump channels resulting in a high pitch scratchy noise.
At this point in the discussion, I would like to stress that this is NOT
(I repeat NOT) the fault of the soundcard! This is not even the fault
of the VGA card... it is in fact the fault of the VGA driver. If you do
not experience any glitching or distortion then you can probably ignore
the rest of this post! I've heard that the VGA drivers supplied by
Microsoft (verses the drivers supplied by the VGA manufacturer) do not
suffer from this problem.
I think Matrox was the first to play with this, but it doesn't really
matter because most high performance VGA accelerator cards for the PCI
bus are doing the same thing now. When a number of graphics acceleration
operations need to be performed, these commands are sent from the VGA driver
to the VGA card over the PCI bus. The VGA chipset has a built in queue
that is capable of holding several accelerator commands. Normally the driver
checks a status bit on the VGA card to tell if this queue is full or not.
If the queue is full, the driver waits for the queue to have a free space
before sending the next command. Matrox discovered (and everyone soon
followed) that you could increase VGA performance by NOT CHECKING THIS
STATUS BIT!!!!! What happens when you write blindly to a full queue of
commands on the VGA card? The bus hangs... The bus master has started a
PCI transaction, but the target (the VGA card) can't accept the data yet
because it has no place to put it. As soon as the VGA card has room for the
data, then the transaction can complete... but until that time the PCI bus
is completely locked up. No PCI or ISA transactions can happen. This can
take a long time (40 or more audio cycles) if the current VGA operation is
a huge BITBLT on a 24bit screen... A 256 or 512 bit FIFO just ain't gonna
cut it.
The only acceptable solution to this problem is to put the queue check
BACK into the VGA driver. I have been discussing this problem with some
of the engineers at Matrox and Tseng labs and have some solutions for you!
Tseng labs has released a new version of their ET6000 VGA driver that
behaves nicer to the PCI bus.. this driver is now trickling down to the
STB and Hercules products that use the ET6000 chip. For the Hercules
Dynamite 128 card, there is a new driver on the Hercules BBS (not web
page... don't ask me) called DV95112 (Version 1.12) Using this driver,
you need to add a special switch in your system.ini file. Under the
heading [Hercules] there is a line that reads "Optimization=0" you will
need to set this to "Optimization=1"... ta da, problem fixed.
It turns out that Matrox has ALWAYS had a hidden back door switch to
enable this check in the VGA driver. If you are using the Matrox Millennium,
you will need to add the following lines to your system.ini file:
[mga.drv]
PCIChipset=1
This almost fixes the problem completely.... you will also need to disable
the "Use PowerGDI acceleration" feature in the Advanced Matrox setup
(Control Panel->Display Properties->MGA Settings->Advanced->Performance)
ta da... problem fixed.
[update July 1997] I've heard from the good folks at S3 that _ALL_ S3
drivers for all of their VGA cards (downloaded from www.s3.com) can be
fixed by adding a line in system.ini under the [display] section...
After [display] add the line 'bus-throttle=1' so (for S3 drivers):
[display]
busthrottle=1
[update September 1997] For owners of newer Matrox cards:
Go to screen properties (right click in main window)
Go to setting tab, Click on PowerDesk button
Check 'Use Bus Mastering' (on)
Uncheck 'Use Automatic PCI Bus retries' (off)
On Pentium Pro machines, Uncheck 'Use Write-Combining'
Click on OK
[updated November 1997] For owners of the #9 Imagine 128 series 2
It seems a new driver (version 4.102.36) is now available directly from
the folks at #9 upon request..
Unfortunately there are other VGA maker who have not
acknowledged this problem (not that Matrox or Tseng has formally done so
either). And we as users, software manufacturers or hardware
manufacturers need to get the word out that this is a VGA problem
and not a DMA problem!!!!!! We need to drill it through the heads of
the VGA card makers that they can't get away with this B.S. without at
least having an OPTION to make the driver behave appropriately.
Have you ever been told to turn the VGA acceleration off??? or to reduce
the size of your VGA screen??? or reduce the color depth???
THESE ARE NOT ACCEPTABLE SOLUTIONS!!!
Call your VGA manufacturer and tell them they need to fix the problem!
(You will probably need to get beyond Joe Tech Support, because he
probably doesn't know anything about this... please inform him!)
This message has been brought to you by Greg Hanssen (hanssen@zefiro.com)
copyright 1996 Zefiro Acoustics.
PLEASE feel free to post this to any forum where the knowledge can be used.
Now you're getting into something considerably more complex than simple stuff like MP3 playing, GPS, and anything else you might normally use your computer for. Check out the diy_efi mailing list (Do It Yourself Electronic Fuel Injection)...you might be surprised how complicated things really are. http://efi332.eng.ohio-state.edu/diy_efi/