It seems to me that one of the main advantages of spread spectrum is that by distributing a signal across a wider range of frequencies, better use of that frequency range occurs and so multiple transmitters/receivers can share the same bit of spectrum. And yet some products which claim to be spread spectrum seem to take spread spectrum to mean they can just transmit at high power across a larger frequency range.
I have a phone and an 802.11 network card which constantly conflict with one another. And yet both claim to be 2.4 GHz spread spectrum... I had also tried (and returned) one of those remote TV boxes and that also interfered with the phone.
For me, it is extremely easy to record shows with the TiVo. Does WinTV-PVR have that functionality? Don't I have do devote a PC to the job at least while I record? Isn't a PC + tuner card more expensive than a TiVo? I don't own a PC by the way... my home machine is a laptop provided by my employer.
Am I the only one here who thinks that what Metallica is doing is right? Am I the only one who completely agrees with Lars' point of view? I'm sure there are others also, but they seem far and few between.
I am not an artist, I am not an author, nor am I a movie director. But I do write code, like maybe 99% of the other of the readers of this site, and I do consider the results of my work to be artistic, creative intellectual property that I have the right to control: I have the right to say who does what with my work, I have the right to say my software should be open source, I have the right to say you can only make copies of it under such-and-such circumstances, I have the right to sell my software or give it away.
How different are we from Lars? He considers his music to be the intellectual property of his band, and likewise he has the right to say who can make copies of it, who can distribute it, and in what manner.
I don't know Lars personally, but from reading his responses to the interview questions, it comes across, to me at least, that he is very intelligent and worthy of everybody's respect, despite what his headbanger appearance might seem to suggest: he makes all the right points; his underlying arguments are clear and simple, though maybe somewhat hidden in the long-windedness of conversation; and he has the guts to stand up and fight for what for what he believes in, even if that leaves him a lone hero fighting what seems to be an impossible battle.
So here is what I don't get about the latest and greatest from ATI: what about latency?
The review states that each of two Rage chips draws every other frame. If you only have one chip working on a given frame, the time to draw a single frame stays the same even though there are two chips. So the latency is twice what it should be given the frame rate! The end result might be visually equivalent to the competition, but for games where rendering latency actually matters -- Quake 3 on a LAN, say -- I expect the results will be disappointing.
It seems to me at least that this scheme is an attempt to push benchmark numbers up without offering a "real" solution to the problem. Sadly, latency is not measured by any benchmarks I know of. But perhaps I am wrong about how the chips work, or perhaps I am wrong about latency being a gameplay issue. Maybe someone from ATI will clear all this up?
Reverse engineering is just like science. You pose hypotheses about the system you are reverse engineering, then you find ways to test those hypotheses.
Like Raphael, I have been involved in reverse engineering a number of fun systems -- Quake network protocols, Quake map formats, OpenGL programs, LEGO Mindstorms. All of these systems required the same general strategy but different tools and background knowledge.
My experience has been that the hardest step of reverse engineering a system is getting started. You typically find yourself needing some tool to analyze a system that you just don't have.
For the Quake network protocol, that tool was a UDP proxy that dumped data in a format I could understand. For OpenGL programs, getting a tracing infrastructure set up was required before meaningful analysis of how programs use OpenGL could proceed.
For LEGO Mindstorms, the hardest part would have been figuring out the baud and bit encoding of a serial stream, since I didn't have easy access to an oscilloscope at the time, and I do not like trial and error when something unrelated -- like my serial port setup -- could go wrong; however, somebody had figured out the serial encoding already, and the starting hump ended up being obtaining a serial line data analyzer. (I ended up using a SGI Indy as a serial proxy.) Later Mindstorms reverse engineering required a disassembler/assembler/compiler tool suite.
Quake map files were easy; the tools were a hexdump program, a program to factor numbers to find strides, an HP calculator, and some programs to convert number formats.
The second part of reverse engineering something is finding useful ways to sort through the data that gets collected or generated. A lot of times I found that this boiled down to writing a program to analyze and print out the data, which I could then look over and study.
For example, the Quake 2 network protocol included some compressed information whose presence or absence was indicated by a bit vector; to figure out which bits mapped to which data, I used a program that tabularized and printed out the data in a really wide format; I then looked for patterns in the compressed data across many, many packets. By lining up columns of numbers that were clearly the same data, it was possible to infer which bits mapped to that data. Kind of like playing a really long game of Mastermind where somebody else gets to choose most of the guesses.
For Quake map files, after figuring out the basic layout of the records in the file (which hasn't changed much from version to version), the important part was figuring out the meaning of all the data. Early on, a useful tool was one that started at a given offset and printed out the range of numbers located at a particular stride from the starting point; this helped associate records of different types to one another. Later, and by far the most useful tool for analyzing Quake map files, was a level renderer used to verify the meaning of the map data. Related tools verified not only the meaning of certain data structures, but also high-level aspects of the algorithms that used these data structures, e.g. collision detection.
A single-stepping, single-buffered OpenGL trace player helps enormously when trying to figure out what algorithms an OpenGL program uses.
In any event, along with these common aspects of reverse engineering (getting started, developing the right tools), the general strategy of posing hypotheses and testing them holds throughout. Once you think you have figured out something new, you need to come up with a way of testing and verifying (or rejecting) the new idea. Unverified knowledge is just a guess, it's not really valid until you have confirmed it with at least one test; the more independent tests the better, as this leads to more confidence in both the new and the established knowledge. Hacking is of the essence here; the faster you can test an idea, the faster you can move on to testing new ones. Not only that, but the results of testing one new idea often opens up more questions and leads to further progress, at least early on.
This is just like science. The only difference is that when you are reverse engineering something, presumably the underlying mechanisms are already known by others -- the original engineers.
Since the original poster was interested in graphics, I will add that for OpenGL programs, I use a "DLL proxy" replacement for SGI's OpenGL Stream Codec based on ideas from a program called gltrace. The proxy dumps a trace of OpenGL/GLX/WGL calls that can later be replayed, single-stepped, run through a simulator, etc.
Slashdot Mirror
It seems to me that one of the main advantages of spread spectrum is that by distributing a signal across a wider range of frequencies, better use of that frequency range occurs and so multiple transmitters/receivers can share the same bit of spectrum. And yet some products which claim to be spread spectrum seem to take spread spectrum to mean they can just transmit at high power across a larger frequency range.
I have a phone and an 802.11 network card which constantly conflict with one another. And yet both claim to be 2.4 GHz spread spectrum... I had also tried (and returned) one of those remote TV boxes and that also interfered with the phone.
What's up with that?
-Kekoa
For me, it is extremely easy to record shows with the TiVo. Does WinTV-PVR have that functionality? Don't I have do devote a PC to the job at least while I record? Isn't a PC + tuner card more expensive than a TiVo? I don't own a PC by the way... my home machine is a laptop provided by my employer.
-Kekoa
The paper on the Lightning-2 hardware that drives the monitor is here.
See also WireGL and its associated paper, which was used to run Quake3 on the IBM display.
Am I the only one here who thinks that what Metallica is doing is right? Am I the only one who completely agrees with Lars' point of view? I'm sure there are others also, but they seem far and few between.
I am not an artist, I am not an author, nor am I a movie director. But I do write code, like maybe 99% of the other of the readers of this site, and I do consider the results of my work to be artistic, creative intellectual property that I have the right to control: I have the right to say who does what with my work, I have the right to say my software should be open source, I have the right to say you can only make copies of it under such-and-such circumstances, I have the right to sell my software or give it away.
How different are we from Lars? He considers his music to be the intellectual property of his band, and likewise he has the right to say who can make copies of it, who can distribute it, and in what manner.
I don't know Lars personally, but from reading his responses to the interview questions, it comes across, to me at least, that he is very intelligent and worthy of everybody's respect, despite what his headbanger appearance might seem to suggest: he makes all the right points; his underlying arguments are clear and simple, though maybe somewhat hidden in the long-windedness of conversation; and he has the guts to stand up and fight for what for what he believes in, even if that leaves him a lone hero fighting what seems to be an impossible battle.
So here is what I don't get about the latest and greatest from ATI: what about latency?
The review states that each of two Rage chips draws every other frame. If you only have one chip working on a given frame, the time to draw a single frame stays the same even though there are two chips. So the latency is twice what it should be given the frame rate! The end result might be visually equivalent to the competition, but for games where rendering latency actually matters -- Quake 3 on a LAN, say -- I expect the results will be disappointing.
It seems to me at least that this scheme is an attempt to push benchmark numbers up without offering a "real" solution to the problem. Sadly, latency is not measured by any benchmarks I know of. But perhaps I am wrong about how the chips work, or perhaps I am wrong about latency being a gameplay issue. Maybe someone from ATI will clear all this up?
-Kekoa
Reverse engineering is just like science. You pose hypotheses about the system you are reverse engineering, then you find ways to test those hypotheses.
Like Raphael, I have been involved in reverse engineering a number of fun systems -- Quake network protocols, Quake map formats, OpenGL programs, LEGO Mindstorms. All of these systems required the same general strategy but different tools and background knowledge.
My experience has been that the hardest step of reverse engineering a system is getting started. You typically find yourself needing some tool to analyze a system that you just don't have.
For the Quake network protocol, that tool was a UDP proxy that dumped data in a format I could understand. For OpenGL programs, getting a tracing infrastructure set up was required before meaningful analysis of how programs use OpenGL could proceed.
For LEGO Mindstorms, the hardest part would have been figuring out the baud and bit encoding of a serial stream, since I didn't have easy access to an oscilloscope at the time, and I do not like trial and error when something unrelated -- like my serial port setup -- could go wrong; however, somebody had figured out the serial encoding already, and the starting hump ended up being obtaining a serial line data analyzer. (I ended up using a SGI Indy as a serial proxy.) Later Mindstorms reverse engineering required a disassembler/assembler/compiler tool suite.
Quake map files were easy; the tools were a hexdump program, a program to factor numbers to find strides, an HP calculator, and some programs to convert number formats.
The second part of reverse engineering something is finding useful ways to sort through the data that gets collected or generated. A lot of times I found that this boiled down to writing a program to analyze and print out the data, which I could then look over and study.
For example, the Quake 2 network protocol included some compressed information whose presence or absence was indicated by a bit vector; to figure out which bits mapped to which data, I used a program that tabularized and printed out the data in a really wide format; I then looked for patterns in the compressed data across many, many packets. By lining up columns of numbers that were clearly the same data, it was possible to infer which bits mapped to that data. Kind of like playing a really long game of Mastermind where somebody else gets to choose most of the guesses.
For Quake map files, after figuring out the basic layout of the records in the file (which hasn't changed much from version to version), the important part was figuring out the meaning of all the data. Early on, a useful tool was one that started at a given offset and printed out the range of numbers located at a particular stride from the starting point; this helped associate records of different types to one another. Later, and by far the most useful tool for analyzing Quake map files, was a level renderer used to verify the meaning of the map data. Related tools verified not only the meaning of certain data structures, but also high-level aspects of the algorithms that used these data structures, e.g. collision detection.
A single-stepping, single-buffered OpenGL trace player helps enormously when trying to figure out what algorithms an OpenGL program uses.
In any event, along with these common aspects of reverse engineering (getting started, developing the right tools), the general strategy of posing hypotheses and testing them holds throughout. Once you think you have figured out something new, you need to come up with a way of testing and verifying (or rejecting) the new idea. Unverified knowledge is just a guess, it's not really valid until you have confirmed it with at least one test; the more independent tests the better, as this leads to more confidence in both the new and the established knowledge. Hacking is of the essence here; the faster you can test an idea, the faster you can move on to testing new ones. Not only that, but the results of testing one new idea often opens up more questions and leads to further progress, at least early on.
This is just like science. The only difference is that when you are reverse engineering something, presumably the underlying mechanisms are already known by others -- the original engineers.
Since the original poster was interested in graphics, I will add that for OpenGL programs, I use a "DLL proxy" replacement for SGI's OpenGL Stream Codec based on ideas from a program called gltrace. The proxy dumps a trace of OpenGL/GLX/WGL calls that can later be replayed, single-stepped, run through a simulator, etc.
-Kekoa
"Click on OK to terminate, click on CANCEL to debug."