In case anyone cares: 16x dvd+R writing is acheieved (on a decently fast PC) on UDMA2. In other words: ATA133 is nice, but not required. Of course, the faster your PC and bus and the less OS overhead your PC has, the more you can do whilst it is burning. Note that speed tests easily achieve 16x, but actually getting that speed when burning data really really wants your HDD to be on a different IDE controller. Without that, you want to be burning in win98 or DOS and preferably using optimised drivers. Decent software (nero) will do this. Crappy software (anything sonic or veritas ever made, the stuff built into XP) won't. But you still get to 14x or so - and with UDMA4 you get to 16x. So it's all good.
The hardware is capable of DVD-minus-R burning at least to 8x, possibly to 16x. We're working on it. If BENQs firmware does not support minus burning, then wait a bit because 8x minus will be out in a few months on that platform.
BenQ? do not firmware lock their drives. So you can reflash when newer firmware comes out. Firmware locking is supported though, so it's not our fault RIAA?. (And really - DRM doubters - it's a legal requirement that a drive not be able to do certain things, and you have to be able to lock it down. Our chip can do boot-up signature checking. This isn't enabled currently though...)
It's not my fault the media isn't out yet :) It's coming, we are promised.
Note that I haven't seen this exact drive, so I cannot confirm the exact capabilities of their firmware. It's based off of our reference code, but we KNOW that they (BenQ?) have made changes.
Our data quality is indsustry standard, because we define the spec ;) But seriously - it's very very good.
It is possible, sometimes, to make our drive lose the plot slightly by causing an error in the middle of a long write. This is because our drive says 'ready' on the bus before it actually is. Which it has to do, because the host PC puts a 100ms delay on sending the next block of data. So if your PC gets reallly fast then you can trip it up. It should recover, but be aware that going too fast can actually make the drive slow down. Optimising for the usual case is a pain sometimes.
I don't think this version of the firmware contains the read-ahead caching - just the write-behind cache. So contiguous reads/writes are lvoely fast, but anything else is slow. I'm guessing by when it came out. Our current code (and so maybe this release) contains read-ahead caching (so a read from lba 0 then lba10 is accelerated) but not read-behind or random-read caching. (So a read from lba0 then lba0 again is slow.) Do this caching at the OS level, dummies! You've got wayyy more RAM! (Yeah yeah, we're working on it - six months minimum though, we have to work around some nasty chip level bugs)
For those that don't know, LBA is logical block address - it's basically a sane addressing scheme for ATA devices (sane as in 'it starts at zero and then goes up' - you don't wanna know about the alternatives) Logical because it includes any automatic remapping and such - it just numbers potentially-user-readable blocks. (So all the 'start of disc' garbage is hidden from you)
Oh - this drive supports CD-MRW (MountRainier?) but no-one uses that. DVD+MRW is in the works. All this is is 'bad sector remapping' though, nothing groundshaking. Again, it'll be a firmware upgrade is vendors decide to offer that.