Hacked GS0H firmware... *experimental!*

vbimport

#1

So I decided to poke deeply around the firmware. There is a LOT of information about each media code that is stored in the firmware. Not just speed limits. It’s speculated that these extra tables (I found 8 of them for the +R codes alone; haven’t tried parsing the tables for the other 3 media types) contain write strategy information and who knows what else about each media code. In all, for the +R codes, each media code has, between all 8 tables, 197 bytes of information stored about it! I compared the RICOHJPNR01 entries for GS0F and GS0H, and I found that 19 bytes have been changed all together in 5 different tables. Because GS0F has had a much happier time burning RICOHJPNR01 media at 8x, I decided to try something: I patched the GS0H firmware by importing GS0F’s RICOHJPNR01 data.

*) This is my attempt ever at patching something as complicated as this. I’m not entirely sure what I was doing.
*) This is definitely to be considered experimental!
*) It seems that my error rates were a bit lower with the GS0F data imported in. But then again, this might just be caused by random factors (and unless I get other data points from other people, I’m going to say that this is the result of random variation).
*) This did not resolve the slowdown problem!
*) There is one caveat: because I had stuff running that I didn’t want to stop, I didn’t reboot after loading the FW. Since I modified only the data area of the FW, I don’t think that a restart would be necessary. But I can’t be sure. I will retest as soon as I get a chance to restart.

If you want to test it out to see if it produces different results than the official GS0H on your drive, you can download it here:

*Edit: Decided that I should probably remove this link, as the experiment failed.


#2

Just curious, is there a compelling reason not to use GS0F? I mean, what makes GS0H worth all the effort?


#3

I’m most likely going to revert to GS0F myself after I’m done playing… :slight_smile:

I guess the only reason is that it seems that GS0H seems to have resolved some of the -R problems present in GS0F. Since I don’t really use -R anyway, I’ll probably go back to GS0F. But… eh… I was having fun. :wink:


#4

But… eh… I was having fun

No need to explain that. :wink: Don’t have a x51S myself and I just was wondering. LiteOn sometimes releases F/W that doesn’t seem to do anything new.


#5
[B]But... eh... I was having fun.[/B]

Heads up… and please go on with your experimenting. :smiley:

You never know what you might run over one day…

…maybe a 8X -R hack for the *51 & *11S series. :cool:


#6

Originally posted by pinto2
…maybe a 8X -R hack for the *51 & *11S series. :cool:

shakes head There are people on this forum with much more experience and skill than me who have tried and failed. :sad: But then again, why bother with 8x -R when 8x +R works so well? :wink:


#7

I wonder how easy it would be to increase the read speed of ±R/W. We know it can read faster with USxx and UYS1. I wonder what limits the maximum read speed? Is there a table for the read speeds that sets the start speed for the CAV.

I have seen Pioneer 107 patched firmware that increases the DVD-Video read speed from 5x to 12x. :smiley:

@code65536
Who knows when Liteon will solve this, if ever. If we can find a solution now, all the better. :slight_smile:

Also, how did you locate the tables. I understand how the ±R/W speed setting works but how does each media entry reference to these tables?


#8

I think that removing read lock will require disassembly of the FW. I’ve programmed in assembly only a few times, on a Sparc processor (not on any of these burner chipsets), and I’ve never disassembled anything before (okay, I’ve tried once to disassemble the LiteOn firmware using a 8051 disassembler, but haven’t had any success yet). So I’ll leave something like this to the people in the community who have had more disassembly experience.

Address 0xC0000 to 0xCFFFF contains all of the +R/W data.

Address 0xD0000 to 0xDFFFF contains all of the -R/W stuff.

In the +R/W section, there’s a header, there’s a list of media codes and their speedcodes, and immediately after that are 4 tables with +R data, after that are a few tables with +RW data, and after that, there’s stuff that I can’t decipher, plus a few more +R and +RW tables.

FYI, there are a total of 89 +R/W codes (this includes the blank & junk codes, which you don’t see because they’re filtered by my program). Of these, the first 62 are +R (there’s a blank code at the beginning), the next 27 are +RW. The first table +R table, for example, is 496 bytes long (62 x 8).


#9

i’m still using GS0A firmware and w/ my Ricoh’s and my new computer setup, i’ve been gettin’ great results knock on wood so many people are eager to try new firmwares when the first come out, expecting the best. i’ve found that the saying, “it it ain’t broke, don’t fix it” works best. i’m happy, i’ve seen people unhappy w/ the newer firmwares. granted if you’re getting newer and newer dvd +/- r’s to burn, you’ll need it, but if you’re not, just don’t change for the sake of change. my 2 cents. i hope this firmware works out for everyone tho, hardwork is in this.


#10

@code65536
I get it…thanks. :slight_smile:

Please confirm: I have been trying to find out what MPU the Liteon writers use. Is the Liteon’s MPU an 8051 or 8051XA. I have a very strong understanding of assembler code and this processor.


#11

Originally posted by kaotic504
i’m still using GS0A firmware and w/ my Ricoh’s and my new computer setup, i’ve been gettin’ great results knock on wood so many people are eager to try new firmwares when the first come out, expecting the best. i’ve found that the saying, “it it ain’t broke, don’t fix it” works best. i’m happy, i’ve seen people unhappy w/ the newer firmwares. granted if you’re getting newer and newer dvd +/- r’s to burn, you’ll need it, but if you’re not, just don’t change for the sake of change. my 2 cents. i hope this firmware works out for everyone tho, hardwork is in this.

Party Pooper. :sad:


#12

I played around with this when the 812S first came out. I modified the write strategy for TYG01 so it was the same as TYG02. Did a burn and the results were O.K. The problem is not modifying the tables, it is in finding the ideal strategy for each media. This adds up to lots of wasted discs searching for it. In the long run it is not worth the effort, mostly because LiteOn has not made a real effort to get these drives working to their potential. If we had a drive that lived up to it’s capabilities then I for one would put more effort into enhancing it. Increasing the read speed may not be that difficult, but again why do that when the drive is not the greatest reader in the first place. Dissasembly of the firmware does not mean we can solve all of the problems. Trust me it’s been done, things have been tried, but in all honesty we don’t have much to work with here, considering all of the bugs already present in the drives. 8X -R is not difficult, the firmware identifies the media, looks up the speed rating, and sets up to burn at that speed. The problem is the X11 and x51 drives are 4X -R limited in the fimware. That can be changed but then there is no write strategy present for 8X -R media. Patching in the media tables from the 812 firmware is not the answer even if the 4X limitation is removed as there are many jumps into this region of the firmware that would have to be adjusted. Keep in mind this is not a couple of hundred lines of code. It is in the thousands. Lots to look at and without complete knowledge an impossible task. I’m not posting this to discourage further progress on this, just pointing out the realities. Keep up the good work, you may yet solve all of the issues. I’m looking forward to the Dual Layer firmware. I will be interested in seeing if I can get it to work on the 812…


#13

I forgot to mention that the slowing down of the burn on the outer edge of the disc is a Sony thing. They seem to think it is better to drop back to 4X to complete the burn. Same trick is used in the DRU-530. It may be helpful for cheap media. I don’t agree with this strategy. It increases the total burn time which is in conflict with the purpose of an 8X burner…


#14

Originally posted by worker
I forgot to mention that the slowing down of the burn on the outer edge of the disc is a Sony thing. They seem to think it is better to drop back to 4X to complete the burn. Same trick is used in the DRU-530. It may be helpful for cheap media. I don’t agree with this strategy. It increases the total burn time which is in conflict with the purpose of an 8X burner…

Would patching around this be easy? I ask because according to C0deKing, he doesn’t get the slowdown when burning w/ 8x-certified media. If this slowdown appears only for 4x-certified media, then the burner must have some way to determine if it’s 8x or 4x-cert., and then there might be an easy way to patch around that?


#15

code65536

Mate, I love your enthusiasm. I wish more people had what you have.

But…

-R 8x on the 811S just isnt this simple. Let alone -R 8x on an 851S@812S.

If you pull apart a firmware and disASM it to its very core components, you begin to realise the nightmare we would have to deal with…

i.e - not as simple as copying and pasting “structs” of write descriptors of controller functions - its a case of writing NEW ones. Now, I dont speak for everybody on this forum - and I know there are some truly skilled individuals, but…on the outset, in order to do this properly…you need to be, or have the skills of an opto-engineer.

I wish you the best in your quest however. With your determination, if you are willing to learn…you could figure these things out.

Oh - and a clue…

8052 will help you


#16

Oh, I’m not nearly that ambitious to try 8x -R. :slight_smile: I’m just wondering if there’s a quick-and-dirty way to deal with the slowdown at the end of 8x +R burns introduced in the new FW since the new FW has nice things (like good -R) but it also introduced this minor nusiance.

Thanks for the tip about the 8052. I might poke around just for the fun of it, but as I said, I’m inexperienced in this, and if experienced people like you haven’t succeeded, I doubt that I’d be crazy enough to try. :wink:


#17

Hi, I’m new and I’m italian, so , sorry if I make mistake with my English…

Ok…

I think this is not the right 3D for my questions, but I see that there are the best user (Zebra, Code65536 IMHO) to explain my dubt…
I’ve a 811s and i notice that a firends that have the 1S81 modded to 811 have best performance with the same support. So I think to compare the EEprom contents to find the difference and to understands how the laser’s “calibrations” function.
You think is possible “recalibrate” the laser for improve the performance?

Have you understand me?
Bye!