Cannot read TYG01 DVD-Rs in my DVD-ROM

I burned an iso on a TYG01 4x DVD-R with my BTC 1004 (firmware 0043) and it burned successfully and I am able to read it in the burner, as well as my friend’s (same burner). However, my liteon ltd163 dvd-rom (firmware GH5S) cannot recognize the disc when put in. The light on the drive just blinks and blinks until it gives up and stops. When I doubled click the drive, it tells me to insert a disc, other times it tells me the disc may be corrupted or using some format not recognizeable. Does the problem lie on the dvd-rom side or the burning side? Has anyone had success with these disc using firmware 0043? Would upgrading to 0047 fix this issue?

what burning software are you using? it´s maybe a bug in your software, try to upgrade to the latest version. i had such a problem with nero 6.0.0.9, after the update to 6.0.0.28 the media was working well.

you can also try a FW update to 0047, if you are not happy (what i don´t think) you can flash it back.

greeitings

herbei

I am using nero 5.5.10.35. Maybe I will give nero 6.x a try.

I also tried upgrading the firmware to 0047 but it completely killed my burner earlier today. I used the dos mtkflash and a 0047 bin firmware. It flashed fine and when I rebooted my computer, it no longer detected the drive and the drive would not even eject anymore (it’s like there’s no power) and the lights do not even blink or anything. Tried flashing back to 0043 and same thing. So I had to take it back and exchange it for a new drive :slight_smile: Now back up and running and I doubt I will upgrade it to 0047 this time :confused:

Originally posted by sPiKeS
I also tried upgrading the firmware to 0047 but it completely killed my burner earlier today. I used the dos mtkflash and a 0047 bin firmware. It flashed fine and when I rebooted my computer, it no longer detected the drive and the drive would not even eject anymore (it’s like there’s no power) and the lights do not even blink or anything. Tried flashing back to 0043 and same thing. So I had to take it back and exchange it for a new drive :slight_smile: Now back up and running and I doubt I will upgrade it to 0047 this time

Welcome to the club! This happened to me also.

When using MTKFLASH, I bet you attempted to flash the entire firmware at once but forgot to set the /M switch, without any parameters. Because if you don’t, you’ll end up with data in one bank only. The reason is that MTKFLASH will erase the entire chip before writing to each bank.

Small wonder this killed your drive. The MTKFLASH helppage is not really clear on this; at least it had me guessing.

If this will resolve your issue with flashing, let’s know; if it won’t, let’s know also.

Regards, Martin A

Changed due to: Stupidity (fingers faster than brain)

i flashed with the windows version without problems, my drive is set as secondary master and in bios DMA mode is Auto.

Originally posted by Centurio
[B]Welcome to the club! This happened to me also.

When using MTKFLASH, I bet you attempted to flash the entire firmware at once but forgot to set the /M switch, without any parameters. Because if you don’t, you’ll end up with data in one bank only. The reason is that MTKFLASH will erase the entire chip before writing to each bank.

Small wonder this killed your drive. The MTKFLASH helppage is not really clear on this; at least it had me guessing.

If this will resolve your issue with flashing, let’s know; if it won’t, let’s know also.

Regards, Martin A

Changed due to: Stupidity (fingers faster than brain) [/B]

When I tried to upgrade to 0047, using the command line mtkflash 4 W /B 0047.bin, it started erasing each memory bank (0-14 I believe) one at a time and upgrading each one respectively. However, when I tried flashing back to 0043 using the same comamnd line but with different filename, it only erased the chip once and updated the info. So what does the /M parameter do? And will that for sure correct the flashing problem that I previously had? Thanks for the help.

Originally posted by sPiKeS
When I tried to upgrade to 0047, using the command line mtkflash 4 W /B 0047.bin, it started erasing each memory bank (0-14 I believe) one at a time and upgrading each one respectively. However, when I tried flashing back to 0043 using the same comamnd line but with different filename, it only erased the chip once and updated the info. So what does the /M parameter do? And will that for sure correct the flashing problem that I previously had? Thanks for the help.

Ok.

This is what I found out about MTKFLASH the hard way: When flashing the chip in the 1004 you’ll need MTKFLASH 1.69 or higher, the latest version being 1.80.1. While 1.80.1 defaults to .bin files, every version below this one defaults to .hex. So, if you’re using 1.80 and lower and you want to flash a .bin file, you’ll have to set the /B switch to tell the program to expect a binary. Conversely, you’d have to set the /H switch if you’re using 1.80.1 and want to flash a hex file. This merely for completeness’ sake.

However: if you’re using 1.80.1, you should take care NOT to set the /B switch by accident because this version defaults to binary anyway. Using the switch together with a binary file, i. e. when it’s not required, may negatively affect the flashing process. I found this in one of the forums at The Firmware Page http://forum.rpc1.org/portal.php. Search for mtkflash; this should let you strike oil.

The /M switch: When writing a full-length binary file (size: 1048576 bytes) to the chip in the 1004IM, the /M switch without any additional parameters instructs MTKFLASH to erase the EPROM and then to write chunks of 65636 bytes to each of the EPROM’s memory banks (banks 0 to 15) one after the other. Unless I’ve forgotten something, MTKFLASH 1.80 must be called up as follows:

MTKFLASH <IDE port> W /B /M <filename.extension> (and don’t you ever forget the spaces!)

Accordingly, MTKFLASH 1.80.1 would be called up MTKFLASH <IDE port> W /M <filename.extension>. The result will be that all 16 banks are ripe with data. Voilà , flashing process successful!

If you forget to set the /M switch, however, MTKFLASH will proceed as follows:

a) It will erase the EPROM and write data to bank 0. So far, so good. But then:

b) It will then erase the EPROM again (including bank 0 which it just wrote) and write data to bank 1.

c) Then it will erase the EPROM again (including bank 1 which it just wrote) and write data to bank 2.

And so on ad nauseam. At the end, you’ll be left with data in one bank only, namely, in bank 15 which was written to last. This will, understandably, also leave you with a dead drive because banks 0 through 14 are filled with FFh. It almost drove me nuts before I understood the mechanism.

There’s another way to do it. You can split the full-length binary into 16 files of 65636 bytes each and allocate, to the chunk files, hex-indexed (indeed!) filenames which follow the convention expected by MTKFLASH. There is a trap here which it’s very easy to fall into. Not any form of indexing the chunk files will do. Everything except hex-indexing the 16 files will make you fail. Only if you name them foo0.bin, foo1.bin, foo2.bin and so on through foof.bin and call up MTKFLASH 1.80 by invoking:

MTKFLASH <IDE port> W /B /M16 <foo.bin> (for MTKFLASH 1.80.1 use the command line MTKFLASH <IDE port> W /M16 <foo.bin>)

you’ll get the desired result. “foo”, of course, stands for any 7-digit combination of alphanumeric characters. Remember that the parameter supplied with the /M switch must be in decimal notation while the indices of the chunk files must be in hex.

I hope I’m not giving away any secrets. Actually, this is what Marco does in the DOS firmware packages he sends out on request, except that he will use hex files, not binaries. But unless you’re very sure of what you’re doing, fingers off!

Anything else will kill your drive, as you were unfortunate enough to find out. (Oh, I guess writing a batch file and fiddling around with the /M switch would probably let you write to individual banks also, but why invent the wheel again?)

Regards, Martin A

Thanks for all that info Centurio. Guess I screwed up on the command-line while flashing. So even if the drive was dead, I could have still flashed it and brought it back to life right?

Originally posted by sPiKeS
So even if the drive was dead, I could have still flashed it and brought it back to life right?

Right. Refer to Marco’s post in this thread here; his was the last one.

Surprisingly, this method works although it goes against everything I ever learned about computers. When attempting to recover from a bad flash I used it myself, although it turned out later that MTKFLASH could write to my drive even though it hadn’t shown up in the BIOS list of drives. Go figure. YMMV.

Regards, Martin A

Hi Martin,

Merrry christmas to you - and to the rest of you guys in the BTC forum.

As you might recall, You and I discussed this “how to flash correctly in DOS” some time ago. I asked Marco for his oppinion on this matter, but unfortunately he had no “safe” commandlines for backing up/restoring the firmware. I guess he gets the DOS upgrades from BTC headquarters. Fair enough.

I am a bit puzzled in regards to your emphasize on the /M switch. Personally I use the following commandlines myself (MTKFlash v1.80):

For backing up a firmware
MTKFLASH 3 R /C /B /M myfile.bin

For restoring
MTKFLASH 3 W /C /B myfile.bin

As you can see I do not use the /M switch when restoring - only when backing up. And the drive has not died on me yet - thank God:bow: Do you have any explanation for this?

Cheers,
Peter

Originally posted by pdu
As you might recall, You and I discussed this “how to flash correctly in DOS” some time ago. I asked Marco for his oppinion on this matter, but unfortunately he had no “safe” commandlines for backing up/restoring the firmware. I guess he gets the DOS upgrades from BTC headquarters. Fair enough.

I am a bit puzzled in regards to your emphasize on the /M switch. Personally I use the following commandlines myself (MTKFlash v1.80):

For backing up a firmware
MTKFLASH 3 R /C /B /M myfile.bin

For restoring
MTKFLASH 3 W /C /B myfile.bin

As you can see I do not use the /M switch when restoring - only when backing up. And the drive has not died on me yet - thank God:bow: Do you have any explanation for this?

Hi Peter,

of course I do remember; Alzheimer hasn’t struck me dumb yet…

As for the /M switch - no, I can’t give you an explanation. What I found was that using MTKFLASH 1.80 under DOS with mtkflash 4 w /b foo.bin left me with data in the bank 15 of the MXIC(MX29LV008B)(+3.3V)chip only, effectively killing my drive.

During later (futile) attempts at flashing the drive back to live, I logged MTKFLASH’s console output to a file. Here is an extract of one of the logs, edited for readability:

Erasing…00% Chip Erased
Erasing…100%
Updating…00% [and so on, up to 100%]
Bank0 Ok!

Erasing…00% Chip Erased
Erasing…100%
Updating…00% [and so on, up to 100%]
Bank1 Ok!

[… same for banks 2 through 13 …]

Erasing…00% Chip Erased
Erasing…100%
Updating…00% [and so on, up to 100%]
Bank14 Ok!

Erasing…00% Chip Erased
Erasing…100%
Updating…00% [and so on, up to 100%]
Finished!(A79D)

>>> Please REBOOT your PC !

Bad flash, although at first glance the log would appear to tell you otherwise.

Note that, other than you, I had NOT set the /C switch (“Check FLASH & Unlock WINBOND(W29C040)”, according to the MTKFLASH help page), however. The reason I didn’t was that I didn’t have an inkling of what this switch would do, so it was a big no-no for me. It could be that not invoking /c in my command line was ultimately responsible for my mishaps. But this is just guesswork.

Splitting the firmware file into 16 chunks and flashing the banks separately from a batch file didn’t work either. No matter how I sequenced the banks, I always found data only in the last bank I had MTKFLASH write to.

What finally worked for me was the command line mtkflash 4 w /m dual43.bin (without specifying /b as MTKFLASH 1.80.1 defaults to binary). If you have a look at MTKFLASH’s help page, you can see in the examples given by Joseph Lin that /M may be set without a parameter, not only when reading from but also when writing to the flash chip.

I still don’t know what /C will do for you, BTW.

Merry Christmas to you and to all others out there!

Regards, Martin A