Funny you should mention that - a Japanese company called Optware just recently announced a product based on volume holography in a disc format. One terabyte per disc, initially write-once, with rewritable discs to follow. Look under "VRD Technologies" here.
From the press release:
The company will start sample shipping of the disc and the replay device in the third quarter of this year.
I always wondered what happened to this technology. Looks like it might finally arrive:-)
True, DVD+RW discs are not entitled to bear the DVD logo (though the drives may well be), as the logo is controlled by the DVD Forum.
However, nothing I could find on the DVD Forum site mentioned that the word "DVD" could not be used to describe non-Forum-approved products. There's no trademarks applied to the word "DVD", AFAIK. In any case, it's merely a legal distinction, not a functional one. It certainly hasn't stopped all the various manufacturers of DVD+RW products from calling them DVDs, even though those companies are members of the DVD Forum as well.
Given that DVD+RW discs work like DVDs, store video & data like DVDs, and are at least as compatible with DVD-Video players & DVD-ROM drives as DVD-RW discs (and far more so than DVD-RAM discs), I think people are entitled to call them DVDs. If it quacks like a duck, etc.
However, Forum-approved DVD-R discs remain the most compatible current writable format (at least until DVD+R is available), due to the different reflectivity of both RW formats. DVD-RAM discs cannot be read by anything except a DVD-RAM drive, so I don't think it counts, regardless of whether it has a DVD logo or not.
Re:You figure they'd be more original
on
iMac LCD Impostors
·
· Score: 2
does anyone else have integrated FireWire on most/all of their systems? No!
Who cares? I can get a generic two-port FireWire card (or USB 2.0, or whatever) for $13 from Pricewatch, for my ugly but oh-so-expandable box. Hell, FireWire ports get thrown in as bonuses on video & sound cards these days.
That's why I won't be buying an iMac (or Profile) anytime soon.
My company's the developer of that app of mine. And a Linux-64 port would leave our customers with the same problem they have with Itaniums - no way to run their other Win32 apps.
WinXP runs on the Itanium, too - it's just the 64-bit version. Any x86-64 compile would certainly be WinXP, but it could just as easily be the IA32 version.
Can anyone confirm if Win64 is definitely being released for the Hammer?
The PR is vague enough to be interpreted as "running a 64-bit version of Linux as well as [plain old 32 bit] Microsoft Windows". I've asked AMD flat out, and they will not commit to saying yes, Win64 will be coming to the Hammer party. MS certainly haven't mentioned it, AFAIK.
As a film/video FX developer, we'd love the massive memory space & 64 bit registers that Hammer brings. But as a [currently] Windows-only app, Linux-64 isn't helpful (except possibly for a few customers' render farms).
Our code is 64-bit clean, we have a working Itanium port, but we haven't sold a copy yet. We have customers who need multigigabytes of RAM & the speed of an Athlon to process it all, yet don't have the spare kilobux to justify dedicating a dual Itanium to a single app (it's all but useless for 32 bit apps at Winzip level & up).
So... rumours, anyone? Hard facts? Tidbits, gossip, insider info?
Actually, the nVidia extension is the string-based one; the ATI extension uses commands. And I wouldn't call either approach a "kludge" - they're both quite usable, & in fact so similar it's almost possible to automatically translate between them.
I thought the ATI command method looked cleaner, but Carmack says it was "massively more painful", and prefers nVidia's string-based approach.
It's true that nVidia did want a licence (protecting their IP, yadda yadda) which may have slowed adoption, but come to think of it, there isn't even ONE NV_* extension supported by ATI anyway, even the useful ones like NV_texture_rectangle (and yes, the ATI hardware does support it, they just refuse to expose it under Windows until it becomes "officially" supported), so I kinda doubt it really slowed down anything except ARB adoption (which is happening now in OpenGL 2.0, the way it should be).
I've read so many comments on the high quality of nVidia's OpenGL drivers over the years - from people I tend to believe, like John Carmack & Brian Hook. Things like "it just works", "best in the industry", "better than any other [consumer?] vendor's", etc.
What exactly leads you to say otherwise? Presumably personal experience, rather than just a desire to trash nVidia, but compared to what? Given that 3D game luminaries have repeatedly stated they prefer nVidia's OpenGL drivers to those from ATI or (shudder) Matrox, that really only leaves the few remaining "professional space" vendors (sgi, 3DLabs), and I can't imagine they're universally perfect either.
Perhaps your perspective needs widening? Or perhaps you're running into the same bug over & over and have not bothered to notify nVidia about it? (or perhaps they just think it too isolated a case to get a high priority)
Vertex processing can (and often do) do lighting and coordinate transformations, but it does far more than that. It can be used for anisotropic lighting schemes, matrix blending/skinning, keyframe interpolation, surface deformation, various procedural lighting & texturing approaches, even pseudo-motion-blur & complete particle systems. Take a look at this pdf for some of the many uses found so far.
Fragment processing is more for new ways of combining textures, fancy bump/reflection mapping, or creating procedural textures from scratch. You can do relatively complex mathematical operations (think "massively parallel SIMD") - even cool stuff like using textures as multidimensional lookup tables for further texturing. More than just "better access to texture memory".
The pack/unpack processors are actually pixel pack/unpack processors, and AFAIK unrelated to vertices. They're used for encoding/decoding the myriad of possible formats of image data from the host (e.g. textures). OpenGL currently copes with a large number of possibilities (RGBA, BGRA, 32 bit, 48 bit, floating point data, different numbers of channels, etc), but a programmable processor will simplify all this, and also allow for more exotic encoding schemes like the various 2D and 3D texture compression formats around. One of the stated goals of OpenGL 2.0 is to reduce the huge number of vendor-specific extensions. A lot of those extensions deal with accessing textures.
All this will be done in software (although fragment processing is notoriously slow to do in software), but hardware already exists that does programmable vertex & fragment processing. It wouldn't surprise me if programmable pack/unpack hardware also existed on modern GPUs, and was just waiting for an API to expose it.
Here's a question: How does the DVD playback dongle do its region checking? Is it based on the country ID in the Xbox itself, or is it stored in the dongle's software? Would this USB region checking prevent it from working at all?
I'm just wondering what would happen if you took a Japanese DVD playback dongle & plugged it into a US Xbox (or vice versa) - would it playback US DVDs, Japanese DVDs, or not work at all?
I'm particularly concerned about regions as I'm a Canadian resident & Xbox owner who's planning to move back to Australia sometime (and I'd kinda like to keep my Xbox)...
...2 days worth of music. Now when are you going to listen to the complete 8 days worth of music...?
Hell, you're right! What did I buy all these hundreds of CDs for? Wait right there - I'm going to throw most of them in the bin right now! I never have more than an hour or two at a time to listen to music, so one or two CDs should be all I need...
Pros:
- 20 GB drive
- USB2 (i.e. Firewire speeds, but still backwards compatible with ubiquitous USB1 when you need it)
- Records:-)
- 10 hour life
- Usable as portable harddrive; you can put non-MP3 files on there and get them off again (unlike iPod)
- Cheaper: US$369
Cons:
- 350g
Summary:
It ain't as small & sexy as an iPod, but it's undoubtably more useful. ALL your music on tap (OK, a lot of it at least), a portable drive that plugs anywhere and is usably fast, and it records too:-)
Not exactly. All you see is a 130 MB partition with some DVD-Video files (an Xbox logo/trailer & a message in multiple languages to the effect of "This is an Xbox disc. Go put it in your Xbox instead.")
But it's a standard DVD-9 disc. The rest is in a custom filesystem. Doubtless you could read the datablocks directly, but you'd have to write a filesystem driver, or an extracter of some kind.
Your standard DVD-R discs are single layer only. Xbox games (and most movies) are DVD-9, dual layer discs. No consumer-level drive will write dual layer discs.
Xbox games MUST be dual layer; the Xbox boots off the second layer. You might be able to squeeze a movie onto a single layer disc (though not the extras - there wouldn't be room), but even then you'd have to decrypt it with DeCSS or similar first.
DVD-Rs are made to the DVD-General standard, which has an unwritable key data track, precisely so you can't just bit-copy CSS-scrambled content to them. DVD-Authoring discs allow this, but they're unusable by consumer DVD-Rs (and the drives are a LOT more expensive).
Weaker? No. It has less memory bandwidth, true, but it has a faster clockrate than most GF3 cards, and it has a second vertex pipeline. nVidia have also said it is tweaked in other ways.
Finally, it shares its memory with the CPU. It reads its geometry data directly from main memory, rather than transferring it over an AGP bus. This gives it multiple GB/s to read non-static vertex data, and allows the CPU to assist in preparing it. Its performance with dynamic geometry will destroy any add-on card. And developers can & will take full advantage of the architecture's strengths, unlike any PC developer, who has to cater for dozens of configurations.
No, that definitely won't work, for the reasons below (and probably others):
- All Xbox games are made on dual layer (DVD-9) discs, and the OS & game are booted from the second layer. As no DVD writer (under at least $5k anyway) will write dual layer discs, coping the games is not an option (unless the firmware is modified to bypass this restriction).
- All Xbox executables are encrypted & signed using public-key encryption (don't know what strength). This would have to be broken, or the key(s) obtained before any executables could be patched or even executed.
- A filesystem driver/emulator might have to be written (it's a modified form of FAT32).
- There's still the matter of the unified memory architecture. Some games will require this, in order to directly modify textures or polygon data, or simply to get the data throughput required. At best, a regular-PC-based emulator will run such a game quite slowly; at worst it wouldn't run at all.
- There is already an Xbox hardware "emulator", made available by MS to lower-tier developers. However, this is more a set of instructions about what PC hardware to use (i.e. GF3, DX8) to make something that approximates final Xbox hardware. It will certainly not run final Xbox games.
Alternatively, an emulator could be made to work at the hardware level (intercepting register calls etc from the monolithic DX/driver dll), running all system software unmodified - which would restrict it to GeForce3/4 hardware at least, possibly on an nForce chipset (which has the same sound hardware) - or raise the CPU requirements considerably to emulate these.
Slashdot Mirror
I'm sure you're aware the first season of the Simpsons is now available on DVD, with the second season due in May.
What's more, I recently bought the first seasons of Futurama and Family Guy, in London - Region 2 only.
Why were they released in Region 2 first, when they're far more known & popular in Region 1? Who knows. Still looking for The Young Ones though.
From the press release:
I always wondered what happened to this technology. Looks like it might finally arrive :-)
However, nothing I could find on the DVD Forum site mentioned that the word "DVD" could not be used to describe non-Forum-approved products. There's no trademarks applied to the word "DVD", AFAIK. In any case, it's merely a legal distinction, not a functional one. It certainly hasn't stopped all the various manufacturers of DVD+RW products from calling them DVDs, even though those companies are members of the DVD Forum as well.
Given that DVD+RW discs work like DVDs, store video & data like DVDs, and are at least as compatible with DVD-Video players & DVD-ROM drives as DVD-RW discs (and far more so than DVD-RAM discs), I think people are entitled to call them DVDs. If it quacks like a duck, etc.
However, Forum-approved DVD-R discs remain the most compatible current writable format (at least until DVD+R is available), due to the different reflectivity of both RW formats. DVD-RAM discs cannot be read by anything except a DVD-RAM drive, so I don't think it counts, regardless of whether it has a DVD logo or not.
Who cares? I can get a generic two-port FireWire card (or USB 2.0, or whatever) for $13 from Pricewatch, for my ugly but oh-so-expandable box. Hell, FireWire ports get thrown in as bonuses on video & sound cards these days.
That's why I won't be buying an iMac (or Profile) anytime soon.
My company's the developer of that app of mine. And a Linux-64 port would leave our customers with the same problem they have with Itaniums - no way to run their other Win32 apps.
Interesting. Doesn't really show Win64 support, but at least they've heard of AMD ;-)
Of course, if a monopoly verdict doesn't encourage MS's readiness to announce support of non-Intel platforms, I don't know what will...
Thanks anyway :-)
The PR is vague enough to be interpreted as "running a 64-bit version of Linux as well as [plain old 32 bit] Microsoft Windows". I've asked AMD flat out, and they will not commit to saying yes, Win64 will be coming to the Hammer party. MS certainly haven't mentioned it, AFAIK.
As a film/video FX developer, we'd love the massive memory space & 64 bit registers that Hammer brings. But as a [currently] Windows-only app, Linux-64 isn't helpful (except possibly for a few customers' render farms).
Our code is 64-bit clean, we have a working Itanium port, but we haven't sold a copy yet. We have customers who need multigigabytes of RAM & the speed of an Athlon to process it all, yet don't have the spare kilobux to justify dedicating a dual Itanium to a single app (it's all but useless for 32 bit apps at Winzip level & up).
So... rumours, anyone? Hard facts? Tidbits, gossip, insider info?
I suppose Mr Peddie meant an "exlusive" on his own "first look" at the white paper :-)
I thought the ATI command method looked cleaner, but Carmack says it was "massively more painful", and prefers nVidia's string-based approach.
It's true that nVidia did want a licence (protecting their IP, yadda yadda) which may have slowed adoption, but come to think of it, there isn't even ONE NV_* extension supported by ATI anyway, even the useful ones like NV_texture_rectangle (and yes, the ATI hardware does support it, they just refuse to expose it under Windows until it becomes "officially" supported), so I kinda doubt it really slowed down anything except ARB adoption (which is happening now in OpenGL 2.0, the way it should be).
What exactly leads you to say otherwise? Presumably personal experience, rather than just a desire to trash nVidia, but compared to what? Given that 3D game luminaries have repeatedly stated they prefer nVidia's OpenGL drivers to those from ATI or (shudder) Matrox, that really only leaves the few remaining "professional space" vendors (sgi, 3DLabs), and I can't imagine they're universally perfect either.
Perhaps your perspective needs widening? Or perhaps you're running into the same bug over & over and have not bothered to notify nVidia about it? (or perhaps they just think it too isolated a case to get a high priority)
All this will be done in software (although fragment processing is notoriously slow to do in software), but hardware already exists that does programmable vertex & fragment processing. It wouldn't surprise me if programmable pack/unpack hardware also existed on modern GPUs, and was just waiting for an API to expose it.
I'm just wondering what would happen if you took a Japanese DVD playback dongle & plugged it into a US Xbox (or vice versa) - would it playback US DVDs, Japanese DVDs, or not work at all?
I'm particularly concerned about regions as I'm a Canadian resident & Xbox owner who's planning to move back to Australia sometime (and I'd kinda like to keep my Xbox)...
Pinouts for the Xbox video port. There's no provision for any signal inputs.
Not to mention the 133 MHz FSB, seen on all PIIIs these days.
Congrats, you're the first person to get it :-)
Hell, you're right! What did I buy all these hundreds of CDs for? Wait right there - I'm going to throw most of them in the bin right now! I never have more than an hour or two at a time to listen to music, so one or two CDs should be all I need...
Pros: :-)
- 20 GB drive
- USB2 (i.e. Firewire speeds, but still backwards compatible with ubiquitous USB1 when you need it)
- Records
- 10 hour life
- Usable as portable harddrive; you can put non-MP3 files on there and get them off again (unlike iPod)
- Cheaper: US$369
Cons:
- 350g
Summary: :-)
It ain't as small & sexy as an iPod, but it's undoubtably more useful. ALL your music on tap (OK, a lot of it at least), a portable drive that plugs anywhere and is usably fast, and it records too
Not exactly. All you see is a 130 MB partition with some DVD-Video files (an Xbox logo/trailer & a message in multiple languages to the effect of "This is an Xbox disc. Go put it in your Xbox instead.")
But it's a standard DVD-9 disc. The rest is in a custom filesystem. Doubtless you could read the datablocks directly, but you'd have to write a filesystem driver, or an extracter of some kind.
Xbox games MUST be dual layer; the Xbox boots off the second layer. You might be able to squeeze a movie onto a single layer disc (though not the extras - there wouldn't be room), but even then you'd have to decrypt it with DeCSS or similar first.
DVD-Rs are made to the DVD-General standard, which has an unwritable key data track, precisely so you can't just bit-copy CSS-scrambled content to them. DVD-Authoring discs allow this, but they're unusable by consumer DVD-Rs (and the drives are a LOT more expensive).
Finally, it shares its memory with the CPU. It reads its geometry data directly from main memory, rather than transferring it over an AGP bus. This gives it multiple GB/s to read non-static vertex data, and allows the CPU to assist in preparing it. Its performance with dynamic geometry will destroy any add-on card. And developers can & will take full advantage of the architecture's strengths, unlike any PC developer, who has to cater for dozens of configurations.
You don't know anything about all this, do you?
- All Xbox games are made on dual layer (DVD-9) discs, and the OS & game are booted from the second layer. As no DVD writer (under at least $5k anyway) will write dual layer discs, coping the games is not an option (unless the firmware is modified to bypass this restriction).
- All Xbox executables are encrypted & signed using public-key encryption (don't know what strength). This would have to be broken, or the key(s) obtained before any executables could be patched or even executed.
- A filesystem driver/emulator might have to be written (it's a modified form of FAT32).
- There's still the matter of the unified memory architecture. Some games will require this, in order to directly modify textures or polygon data, or simply to get the data throughput required. At best, a regular-PC-based emulator will run such a game quite slowly; at worst it wouldn't run at all.
- There is already an Xbox hardware "emulator", made available by MS to lower-tier developers. However, this is more a set of instructions about what PC hardware to use (i.e. GF3, DX8) to make something that approximates final Xbox hardware. It will certainly not run final Xbox games.
Alternatively, an emulator could be made to work at the hardware level (intercepting register calls etc from the monolithic DX/driver dll), running all system software unmodified - which would restrict it to GeForce3/4 hardware at least, possibly on an nForce chipset (which has the same sound hardware) - or raise the CPU requirements considerably to emulate these.