I am a little confused here. I installed a NewEgg.com ND-3500A on my secondary IDE controller as Master (no other devices on the secondary). I flashed the firmware to the Dangerous Brother Beta. I burned a TY02 disk at 8X with Nero and when I tested the disk it told me that the drive was CAV. The graph looks real sweet (see below).

I purchased a Mad Dog MegaSTOR MD-16XDVD9 and installed it in an ADS Pyro 1394 external enclosure. Like my internal NEC branded drive I also flashed this drive over the 1394 connection with the Dangerous Brothers Beta.

I tested the disk mentioned above and Nero told me that the drive was P-CAV. The graph shows a max read speed of 10X.

Why do these graphs look different and why is the drive in the enclosure being read as a P-CAV drive, rather than a CAV drive like my internal drive?

Is there any way that I can get my Mad Dog drive to read the disk in CAV rather than P-CAV?

Thanks in advance for educating me as to the reason(s) why one drive is CAV and the other is P-CAV and for any other insight that you give.

Bob Shem

It looks like the external drive transfer mode is 'Multi Word DMA' (about 10MByte per sec) rather than 'DMA 2' (33MByte per sec)

For a good explanation of CAV P-CAV and other modes, look here

I have sent an electronic message to ADS Tech asking for help with a link to this thread. Hopefully they will be able to educate me further and perhaps resolve this issue. In the meantime if anyone else has insight or a suggestion I am sure that everyone reading this thread who desires to assemble an external version of the ND-3500A would be grateful.

Thanks,

Bob Shem

I would not blame The Oxford Chipset for the Bad performance, since I have seen a Test on german c't Magazin performing very well. Writing miminum was 27MB/s, reading minimum 30MB/s. (A harddisk was used in the Test)
Maybe there is a problem with ATAPI Devices, I will check that with the NEC, since I bought the same chipset last week to hold my old NU DDW-081. (Untill now - no probs, but the NU isn't as fast as the NEC)

I would blame the crappy VIA chipset for the bad performance...

Just my 0,02€

This guy had the same problem (although not with an external enclosure). The reason was that his drive was running in multiword DMA mode (instead of Ultra DMA mode), like Dee explained earlier (-> IDE bottleneck, click here for the thread).

Your external enclosure simply does not enable the UDMA mode that provides the necessary bandwidth DVD reading (and writing) at the highest speeds needs (~22 MB/s for 16x reading/writing; UDMA2 limit is 33 MB/s, while MDMA limit is ~14 MB/s (~10x). This may be an incompatibility issue. I'd suggest that you replace the enclosure with another one if possible (unless there is a way to directly influence the DMA setting of the enclosure itself (unlikely), preferably one that other users in this forum recommend for the NEC 3500. External enclosures often cause problems with optical drives (they are primarily made for harddrives), it's important to purchase the 'right' one.

off topic
Hmm, I think "Multiword Mode" is a "half" of Ultra DMA mode. One "cycle" compared to two on UDMA.
So, the multiword mode (2) "equal" to UDMA-2 maxes out at ~16,7MB/s.

But this is all off topic...

I bought the ADS Pyro 1394 enclosure because I read on this forum that you need an Oxford 911 chipset to get 16X performance.

Hmm . . . I guess that there is more to this than simply placing an ND-3500A in a Pyro 1394 enclosure.

I hope to resolve this because it would be excellent to get full CAV performance out of my external Mad Dog setup. BUT, if I can't, this external setup still makes a very solid 8X burner. I burned one of my 3+gig video files to a TY02 8X DVD+R disk at 8X. It took around ten minutes from start to finish. From what I can tell with my Nero diagnostic tools the disk burned just perfectly. I can't really complain about the results but I do want to tweak my system for optimum performance.

Anybody else have any ideas???

Thanks,

Bob Shem

Just to clarify, you are not seeing P-CAV burns/reads, CDSpeed is just mis-identifying the mode. This drive does not do P-CAV. What you are seeing is serious buffer under-runs in the drive. You should not be trying to burn with this issue, stick to 8x until you sort it out.

There's really no way to tell whether the issue is the case or the controller, except to try the drive/case on a known good controller. My Nforce-2 board will burn and read 16x on firewire with no trouble. If it's not possible for you to try it on another system, the next best option would be to try a PCI controller card.

@Bob Shem

You could try to temporarily replace the NEC 3500 with a harddisk and see if the problem remains. If you get 'normal' transfer rates, you can rule out incompatibility issues between the firewire controller (of your board, or a PCI card) and the enclosure itself. And you'll know that your enclosure and optical drive simply don't work well together, and this incompatibility is the cause of your problem.

OXFORD 911 UpDate

Doing some research I have discovered that Oxford has a revised JAVA UpLoader dated around April 2004. One of the NEW options is as follows:

"Enable ATAPI UDMA on Master"

"Check this to enable an ATAPI device (CD-ROM, for example) to use UDMA data transfer mode on a master device"

Now - I have to obtain the NEW UpLoader (from Belkin?, from Oxford?, from ADS?) - Who knows !!!...

It appears that www.macally.com has the new updater and firmware for the Oxford chipset.

Have alook at there support section. I assume this can be used with any oxford based enclosure.

UB

I tried this but the updater can't 'see' the enclosure.

Hi unbreakable,
YES - I have already downloaded the JAVA UpLoader from "Macally". Their JAVA UpLoader is and older version (Dated 11/2002) than the documentation I downloaded from Oxford directly.

I'm sorry, my above statement might be incorrect. I had to use the Window's UpLoader from a different site since all the stuff from "Macally" that I downloaded was only for "Apple". I did notice all the binaries were the latest versons...

Bob,
You have to force flash the 911 chipset. Than means you must ground out pin 57 - power on the case - remove the short. I had to do this myself after turning on a wrong option. Please download the documentation for the UpLoader and read the details.

Try the new Uploader mentioned here

Direct Download link

You need StuffIt expander to unzip the file!

In the FW911Atapi Subdir I mentioned this Section in the txt-File:

...
Configuration information for OXFW911Atapi

[hardware_config]
MasterPIO 4
MasterDMA 2
MasterUDMA 6
SlavePIO 4
SlaveDMA 2
SlaveUDMA 6
MiscConfigByte2 80
DisableDREQ 1
MaxTransfer 9
....

I don't really know how the flasher works but I think this is the txt-File used in the win_uploader.ini under the section Last configuration Information file :for the flashprocess: config_911Atapi.txt

Could you post a link to the information about grounding out pin 57? I could not find the information.

Thanks,

Bob Shem

Try this document: Download

In the section Forced Update...

Thanks. I will check it out.

I downloaded the information and disassembled my ADS Pyro enclosure. I did not find a pin 57 to ground out. Are we talking about the same thing?

Hi Bob,
I know you were reading the Oxford Manual in detail on how to Force Load the firmware. The manual is talking about the Oxford Development BridgeBoard. And YES their is a pin57 jumper block. But the Manufacturer of your case and also my Belkin case manufactures their own bridge board without a pin57 jumper block. I don't have any jumper block on my BridgeBoard and more than likely you don't either.

What you have to do... (1)Go to the Oxford Site and look for the document that has a "picture" of the chip with pin numbers. (2)I took a very thin piece of copper wire and attached to the ground post. (3)Very carefully I placed the other end of the copper wre directly on pin57 on the Oxford 911 chip directly (making sure it did not touch pin56 or pin58). (4)Powered on the case and took the wire off pin57 quickly.

I was then able to force load the case...
You must be very carefully when doing this, you can destroy the chipset...
But since the Upoader doesn't even SEE you case you don't really have a option...