Although there may be many ways to destroy your drive, I don't want to add another one and the sourcecode will stay closed source
I just updated the Linux and the DOS32 packages.
The Linux version is now statically linked which made the file grow pretty big. The DOS32 version now contains the missing DOS extender as well as the ASPI.SYS that's needed and two small commandline tools to add and delete device drivers without the need to change config.sys. Just have a look at the included readme.txt

I placed the "UniFlasher" utility in the folder "C:\uniflasher". Then when at the C:\uniflasher> prompt I typed the following:-

necflash -scan



Which told me the {Device Letter} part of Uniflashers general f/w dump command:-

necflash -dump {Filename}.BIN {Device Letter}

From my screen capture above that was obviously D: hense the correct dump command for me was:-

necflash -dump Backup.BIN D:

Finally tried it....Great utility Liggy..thanks!

Mac version is now also updated to the latest version 0.92

hi there.
i cant seem to get my 3500 drive to flash to the 3500_217.bin firmware via commandline prompt.
i have my drive (in an external enclosure) connected to a laptop via usb2,could this be the problem?
it says something about a problem sending firmware to drive with a load of guff beforehand.
if i was to connect it via firewire would iu stand a better chance of it working?
i also tried the windows flash utility but that wouldn't work either.
any ideas?
paul

Hello, Liggy!

First of all thank you very much for your great work!!!

I can't use DOS32 or Windows version, because flashing in windows always hangs up and never finish with any type of flashers I tried to use for both my NEC DVD-RW drive and Sony DVD-ROM, so I always flash the drive in pure DOS where it works just fine. I don't know what's wrong with my computer, but I saw other posts having the same problems with computers like mine. I have Tyan Tiger MPX 4M (Dual-AMD) motherboard. Have Windows XP Pro with SP1 installed and don't use AMD drivers for IDE. I had problems flashing in Windows with my prevoius NEC 2500 drive and have the same problems with NEC 3500. Also I have problems with Sony DDU-1612 (LiteOn 166) DVD-ROM drive. Nec connected to the secondary master and Sony to secondary slave integrated AMD IDE controller.

So I'm also very interested in DOS version. To update my NEC 3500 to Herrie's 2.17 (MadDog) FW, I used TDB DOS flasher and had to change 1 byte in FW to make it accepted by TDB NEC flasher. Those last 4 bytes was K350 and TDB flasher wanted K310.

Thanks again!

Maxim.

P.S. The above was related to original (not updated) DOS32 0.92 version. Will try the latest updated version next time new FW will be available.

In order to find out what went wrong, please give me the output when using "necflash -scan -v" and that of "necflash -flash -v {Binfile} {Device}"
It usually should work with both Firewire and USB.

Do you get a valid device listed, when using -scan? If so, what output do you get if you start the program when flashing with "-v" option? Maybe some SPTI or ASPI routines have trouble with multiprocessor systems. In this case there may be a difference between using "X:" and "x.y.z" as devicename.

My flasher accepts K310 AND K350 and even the DOS32 version should work fine now. I tested at least extracting the current firmware back to disc. You just need to load the included aspi driver before.

quick update.
i have now swapped the usb cable from the enclosure to a firewire cable and using the windows flasher it now goes half way and then just seems to hang???
it used to only go 2 notches and then error.
also tried the dos flash and still no luck.
will now try what you mention liggy.
paul

I keep getting error accessing firmware file errors. Though I know that I typing the firmware file name correctly.

bit lost here.
in the dos screen i put the following:

c:\uniflash>NECFlash -scan -v

this listed all my drives including the nec and then proceeded to tell me this:
device:L
vendor:nec
model:dvd_rw nd-3500AG
firmware:2.16

i then proceeded to try flashing using the following command:
c:/uniflash>NECFlash -flash 3500_217.bin L:

i got the ususal disclaimer and selected y

nothing happened for like 3 mins then i get an error saying:

// sptxSay.DeviceControl: x4D3 (1235) the request was aborted
// sptsSay x 0 0 0 E (ioctl status length senselength)

hope this helps.
still trying to work out how to do msdos screen captures.
gotta learn somewhere.
paul

I worked my prob out! I had the .bin in the wrong directory For others I did a dump then search for that bin then copied the update bin into that folder and it run like a dream great app LIGGY

This command including -v would have been interesting, but I have an idea what might have happened.
The flasher uses 32k blocks to send a firmware to the drive. I guess there may be something that prevents you from sending those blocks and they need to be smaller. This output is sent by the SCSI routines I am using, not by my program, so I need to find out what command it tries to send that causes the problems. I can then try to create a special version that uses smaller packets, but I don't know 100% if this will work, since 32k blocks is what the original flasher from NEC uses.

I think I should improve some error messages in the next version

firstly,many thanks for your help and patience.
i have just retried the flash command with the -v included as follows:
NECFlash -flash -v 3500_217.bin L:

and it returned the following message immediately:
identified drive: 3x00

detected drive from firmware: K310
program terminated with returncode 23

hope this helps.
sorry to be a pain.
paul

It looks like you are still using an old version of the patcher, you should update to v0.92.
But I think this error meant that either the firmware file could not be opened or it's not a proper NEC firmware.

I'll take some Aspirin

oops.
my bad.didn't realise i had the wrong patcher.
tried it again with the v0.92 version and all seemed to be going to plan.
it produced loadsa messages of sending firmware to drive
then sending checksum to drive
then erasing flash block 2
then just a cursor underneath and drive light still flashing but nothing else seems to be going on?
does that mean it's done?
helllllpppppppppp.

ooops,summit else has come up.
similar to before bout device control etc
and then erasing flash block 3
just so i have an idea in case i need to do it again
how long should it actually take from start to finish?
this is so much harder than i remember when i flashed my pioneer drive.

Hmmm. It should usually work the following way:
"Erasing flash block 2" up to "Erasing flash block 18" and then "Writing flash block 2" up to 19. I don't abort the program in this situation since this process must complete if you don't want to have an unusable firmware.
But something seems to prevent your drive from accepting the commands used for erasing . Unfortunately I have no idea what this could be.
It should not take more than about half a minute to complete the flash procedure. Something seems to be very wrong here.

oh dear
well,it still seems to work ok with the 2.16 firmware so i guess i'll just have to stick with it.
worrying thing is i've seen a success story of someone doing it via firewire and drive in enclosure.
oh well.
appreciate you trying to help me.
just my luck.
guess i'll keep a look out for an updated firmware and try again then.
strang thing is it wont even do it using the windows gui flash method,it gets half way and then just hangs.
do you think i might of buggered the drive up?
dont think i have mind.
thanks anyway.
paul
just a thought,do you think i might get a success story if i put the drive into a desktop pc and flash it from there?

This could help, but I cannot guarantee that it will...

could it be anything to do with the drive being set to master in the enclosure?
should it be set to slave due to it being connected via firewire to a laptop?
paul

No. The drive in my USB2 enclosure is set to master and you should keep it like that. Every IDE channel (there's an IDE2Firewire bridge in your enclosure) needs a master device to work properly. I'd stick with Liggy's solution and flash the drive when mounted in a PC.

Allthough I'm a firm believer in using real-dos flashing tools for stability reasons, some remarks in this thread made me spend an afternoon to create a windows shell for the windows version of necflash.exe.

The result, WINFlash.exe, should be seen as a preview release of this shell program. Given the beta phase of both programs at this time I would recommend 'playing' with this shell program, but take great caution with the FLASH option!

From the ReadMe file:

WINFlash is a simple MS Windows shell for the NEC firmware
flasher (UniFlash) by Liggy and Herrie. This program does
nothing more than spawning the windows version of NECFlash.exe
as a childprocess. Results from NECFlash.exe are placed in a small
output window that will inform you about the success / failure
of the operation.
The only requirement for this program to run, is to have the
WINDOWS version of NECFlash.exe in the same directory as
WINFlash.exe.

Please be aware of the following:

- Since both programs are still in a beta phase, thing can go
wrong. Most operations are harmless, but the FLASH option
can be dangerous!
- Whenever NECFlash.exe is doing its work, all buttons are
disabled and the blue disk at the upper left corner is
spinning. ALSWAYS wait for the buttons to become active
again and the disk stops spinning. Trying to close/kill
WINFlash when NECFlash.exe is running will cause this
process to be killed also!! This may lead to all kind of
failure.
- This program has been developed and tested on Windows XP
using a NEC ND-2510A burner. Other operating systems or
burners may cause strange behaviour.
- WINFlash relies on the current (0.92) release of NECFlash
in regards to the command line options and certain output.
Future versions of NECFlash may cause WINFlash to behave
unexpectedly.

!! THE AUTHORS OF BOTH PROGRAMS TAKE NO RESPONSIBILITY FOR
ANY PROBLEMS THESE PROGRAMS MAY CAUSE !!

download:
http://www.norocketscience.com/download/WINFlash.zip

Paul

@r-man
Thanks!
I did try it and It works great!

Yes, that works fine ! Thanks !!!