Looking for a copy of my Revenge tool

Dear Lazyweb,

If anyone happens to have a copy of the Revenge (Radeon Reverse-Engineering Tool) Git repository, tarball, or code in any format, please comment on this post.

I know one released tarball was named "revenge-1.0.1.tar.gz", but it is unfortunately lost due to the home directories being lost on people.freedesktop.org. I believe there were newer versions, too.

I am reasonably (~90%) sure that I have the Git repository stored on one of my computers, unfortunately the computer in question is currently half the world away, and not online.

Perhaps this post will serve as a reminder to backup your code in more than one location (excluding your workstation.) Yeah, my bad. :-(

Underwater ultrasonic data modulation?

I'm currently looking for a bit of a combination hardware and software project to fill the boredom, so I've been thinking about underwater ROV's. Traditionally these use a surface tether for command communication (presumably with some basic protocol) and a feed from the camera and sensors.

I'm wondering what kind of distance I could get with modulated ultrasonic transducers?

I am quite sure how to design a suitable protocol; in fact I can reuse a lot of the bit-message code used in Quake 3 (there are lots of gems in there.) That provides me with compact messages, and with Huffman compression and an optimized table (based on either simulated or real-world packet capture) the compression ratio becomes pretty good. I think it would even be possible to send the surface a low-resolution/low-FPS video feed, while recording the high-resolution real-time feed to a solid-state drive.

The challenging part would be modulating the data; I have no idea how to choose a carrier frequency and modulation scheme for low-frequency (longer range, less ambient noise) ultrasonic transducers.

Furthermore, assuming the ROV and surface use the same frequency, the link would be half-duplex. This should be fine in theory as the protocol could be designed around this, but ultrasonic is still sound, so picking up an echo is a definite possibility (less so in open water.) I don't see this being too much of a problem (famous last words) because the protocol would be designed to be inherently unreliable: packet sequence number checking, CRC check, sanity check on values.

Far more concerning would be the potential to output too much power and thus be damaging to divers ears underwater. I guess that would just be a matter of capping the output power at the maximum exposure limit for the length of the dive, minus an N percent safety margin.

At least those Full Face Mask underwater communication systems seem to work very well for voice, and do not have any exposure limits that I know about. Quick Google search shows one rated for "50 to 500 meters depending on Sea Conditions and noise levels." Of course, this is voice which is much higher bandwidth than a simple command stream and perhaps 640x480 compressed 1 FPS video.

Anyone out there know about modulation schemes? There's a little on Google, but not too much; possibly I don't know what I'm looking for, though.

Just a random brain-dump idea I've been thinking over; at least writing this post breaks the boredom somewhat and might even motivate me to work on code for the sinking ship that is Nokia. Last I checked the stock was down ~20% and dropping since Stephen Elop's announcement. Ah, back to my general state of pessimistic realism.

!@#$ing drunkards outside...

Yet another early morning reminder of how much I dislike New Zealand and it's people...

I think if I should ever manage to return to living in Finland I'm going to buy our team many rounds of beer. See you guys sometime in the next few decades. :(

To the airport...

Just FYI for anyone who is interested in the N900 ioquake3 work (there seems to be some interest lately.) I'm taking a short vacation where I'll be completely offline for about 6 days. See you when I'm back.

Quake 3 qgl API

I'm sure having the qgl API made sense at some point in time (GL 1.x) however now it's just a pain for doing any kind of porting. The qgl API is a set of function pointers which are initialized by the renderer to point to the real gl API functions (or logging wrappers.) e.g. glClear() becomes qglClear()

I think the original reason for this was logging GL calls (a valid reason, at the time) and handling extensions. IMHO logging could be implemented easier using a GL tracing library (there are a few; Google) and GREMEDY_string_marker for renderer specific messages (begin of function foobar(), etc.)

Actually this is what Robert is doing for XreaL-ET branch, however it's not on the mainline branch yet. I think I'll cherry pick these changes over before doing more work on GLES2 for XreaL. Otherwise the qgl API is going to turn GLES2 support into a massive ifdef mess...

I am quite interested to see what kind of performance SGX can get out of a real VBO optimized renderer.

Me, travel, and fail

It seems I'm rather prone to running into some kind of fail during my travels. Previously the Icelandic Volcanic ash Cloud, and now a rather strong earthquake has hit Christchurch several days before my flight there.