Opened A Xbox To Find A Hitachi-lg Dvdrom, **MERGED TOPICS** Options

[menelik]

i was on vacation or a few weeks and came back to see that tiros and wenid are really good friends again
at this moment i dont see a good reason to waste more time into this mod as the most important functions work. sure, some got really interested into this and try to get this work with programs like the xecuter os etc., but it isnt worth to flame each other. just my quick opinion.

[mrkaylor]

Here is what my output says when I try to install the firmware. I have two drives one is brand new and one has all the connections soldered. The output is the same.

I was trying to do this from WinXP Pro. Does it need to be done from dos? Both drives had a manufactures date of January 2005 on them and the current ROM Version is 0L23.

You can see from the output below that I tryed both with and without the /r switch.

C:\Hitachi\8050L_FW_Flasher_FIXED>SF8163 8050L.dld 3 /f /c /p /o

Drive Firmware Update Utility Rev. 3.21c
© 2001,2002 Hitachi-LG Data Storage, Inc.

Download file information:
File Name :8050L.dld
Vendor ID :HL-DL-ST
Product ID :DVD-ROM GDR8163B
Firmware Revision :0L23

No CD/DVD drive.(2)

C:\Hitachi\8050L_~1>SF8163 8050L.dld 3 /f /c /p /o /r

Drive Firmware Update Utility Rev. 3.21c
© 2001,2002 Hitachi-LG Data Storage, Inc.


<><><><><> Recovery Mode <><><><><>
Download file information:
File Name :8050L.dld
Vendor ID :HL-DL-ST
Product ID :DVD-ROM GDR8163B
Firmware Revision :0L23


Updating drive firmware now!
Drive responds with an error.
Please check the drive and re-start again.

C:\Hitachi\8050L_~1>

[maximilian0017]

Your problem with the servo was explained!

Ok, if i understand correctly you are reffering to the VOH of the ready signal?, or is there another reason to do this modification?

I haven't been able to find any documentation on that an22023 chip, do you have any idea what these two traces are used for in the origional drive?(cdr support?!?)

After this mod it still isn't exactly the same....

[sness54]

mrkaylor, try again with LG8163 drive configured as secondary master.

[wenid]

@bourke: Thanks for your support. I think.

@Jinxter: Nice idea. Unfortunately the old and new Samsung drives are not actually that similar. They do both use MediaTek chipsets, but the 605B uses the MT1329E controller chip (same as in the SD616T/F), while the 605F uses a newer controller chip (can't remember the number and I don't have one handy to look at -- I think it's the same one as in the SD616Q and some of the SD816's). They also use different laser pickups. Now I'm by no means an expert on this stuff, but I suspect these differences are enough that the 605F firmware won't work in a 605B, and vice versa.

@mrkaylor: Yes, you are supposed to run SF8163.EXE in DOS (although it may work under Windoze -- I haven't tried that myself). The original HP distribution of this stuff comes as a package that creates a boot disc for you.

Now then. Who am I forgetting? Oh yes.
Since you insist on going on and on about it I suppose I'd better post at least a brief explanation of what I think was wrong with your theory, but I expect this will just lead to more nonsense.

Trace the original yellow xbox drive wire signals directly to the CPU I/O pin where they are connected. Maybe they are directly connected to switch, but keep following circuit to the control CPU.

And what if there had been other circuitry effecting the signal along the way? Any of these signals could easily have been inverted on one drive and not the other or been "calculated" from multiple signals at the controller. It is only pure luck that they weren't.

The polarity has to be right at that point or control CPU will be confused.

Obviously the polarity has to be right, or at least the right polarity for the controller. That polarity need not match the polarity, or even the timing, expected by the Xbox, PC, or even other parts of the drive's own circuitry (if there was an inverter or whatever between the controller and this other circuitry). It need not even have been a simple, single signal at the controller.
Like I said, it's only luck that things worked out well for us. You were lucky, not "right".

[maximilian0017]

I was trying to do this from WinXP Pro.  Does it need to be done from dos? 

I think so, the dos utility doesn't ask for permission to write to the drive like the windows flasher would, so winXP would most probably disturb the process.

[bourke]

For anyone trying to discern the differences between the original 8050 firmware and the regular 8163B firmware perhaps you could look for these numbers:


=========================================
Speed.......kbytes/sec......hex..............bytes/sec...........hex
=========================================
4X............5400?............1518............5529600............546000
4X............5500?............157C............5632000............55F000
=========================================

I.e. I am assuming that somewhere in the firmware lies the hard coded drive speed limit (at 4X) - though I am not sure whether 4X is 5400kb/sec or 5500kb/sec?

Search for the hex values I think?


If you find one of those four hex values then try replacing it with the respective value here:

=========================================
Speed.......kbytes/sec......hex..............bytes/sec...........hex
=========================================
4X............21600............5460............22118400..........1518000
=========================================


cheers,
Bourkie

This post has been edited by bourke: Apr 27 2005, 02:40 AM

[Stitch_626]

HI,

Yeah I understand that, but I'm not talking about a comparrison of the firmware on a Samsung a PC 616 and an Xbox 605 ... instead I'm refering to the possible differences in the firmware of the original Xbox Samsung drive that was manunfactured up to about April 04, and the newer Hitachi/Samsung drives from August 04 ... the newer Hitachi/Samsungs despite looking indentical mechanically even down to the lense do not read CDRs, I was hypothesising that this was down to a slightly altered firmware and therefore a direct comparisson of the firmware from the old Smasung drive (that does read CDR) and the newer firmware (that doesn't read CDR) may lead to a better understanding of what has been altered in the 8050 compared to the 8163b to make it stop reading CDR, i.e. a clearly denoted differnet block of code. That way we'd have a block of code in a kind of before and after comparrible state (if you see what I mean - this block allows CDR reading this newer block dosen't).

As I say just a thought but I'll have a go extracting the firmware from a newer Samsung and then flash the new Samsung DVD drive with an older firmware to see if this will enable CDR reading as a test of this hypothesis.

Cheers
Jinxter

Sorry to shoot your hypothesis 605b & 605f f/w are very different. My comment still stands. They are written in "C" so the code created by the complier as a result it is difficult to id the important code differences.

[Stitch_626]

Ok, if i understand correctly you are reffering to the VOH of the ready signal?, or is there another reason to do this modification?

I haven't been able to find any documentation on that an22023 chip, do you have any idea what these two traces are used for in the origional drive?(cdr support?!?)

After this mod it still isn't exactly the same....

I just did a circuit trace with the xbox lg drive gdr8163b for the pc. This is one of the important hardware differences that were found.

[bourke]

4X............21600............5460............22118400..........1518000

Sorry that should have read '16X' not '4X':

16X............21600............5460............22118400..........1518000

[bourke]

Nero is telling me that 4X = 5500kb/sec, whilst Alcohol 120% is telling me 4X = 5520kb/sec, and another site had 5400!

What is the real number?

[menelik]

as the bios is encrypted i dont think that you can just use a hex editor to make to drive go 16x

[RMV]

1X = 1353 Kilobytes per second (KB/s)
4X = 4 x 1353 = 5412 KB/s (1524 in HEX)
16X = 21648 KB/s ( 5490 in HEX)

[Tiros]

Now then. Who am I forgetting? Oh yes.
Since you insist on going on and on about it I suppose I'd better post at least a brief explanation of what I think was wrong with your theory, but I expect this will just lead to more nonsense.

And what if there had been other circuitry effecting the signal along the way? Any of these signals could easily have been inverted on one drive and not the other or been "calculated" from multiple signals at the controller. It is only pure luck that they weren't.

Obviously the polarity has to be right, or at least the right polarity for the controller. That polarity need not match the polarity, or even the timing, expected by the Xbox, PC, or even other parts of the drive's own circuitry (if there was an inverter or whatever between the controller and this other circuitry). It need not even have been a simple, single signal at the controller.
Like I said, it's only luck that things worked out well for us. You were lucky, not "right".

Wrong again, Guido.
It could NOT have been "easily inverted from one drive and not the other"
By virtue of the fact that the the xfirmware runs at all in unmodified drive, the internal polarities, signals, timing MUST match or the controller would be confused.
It DID have to be "a simple single pin on the controller" since it was on the original xdrive. and after the flash, thats what you have.
That's what I said in my post. I never waivered from this position. It was not a guess. I was right.
You were both "Unlucky" and WRONG!

The xbox Tray signals are SYNTHESIZED by the CPU firmware, that's why using the non-xbox points was never a good idea. That's also why the timing for the xbox is also guaranteed. Yes there are "signals along the way" specifically the RF/Servo 49 and 50. It was trivial to mod the board to look exactly like xdrive, guaranteeing the xfirmware will work. This is the method I pursued and I suceeded. You attempted to go this way, failed, pursued alternates and failed again.

If you would have explained your problems with my theory earlier, instead of throwing a temper tantrum, I could have corrected you then, and you could have avoided all the time you wasted on the OpAmp.

Luck had nothing to do with the no chip hack. It was luck that I came along and derailed your OpAmp method.


Speaking of luck,
There is no way you guys are gonna patch this firmware using just a hex editor. You need to use a disassembler for the target CPU. The fact that it is written in C has nothing to do with encryption, or if the program can be disassemled. I don't know how this "encryption" rumor got started anyway. Its just straight machine code. Posting hex strings that equate to drive speeds is not helpful. Just like the hardware problem, it is not going to be hacked using "shoot from the hip" technology. It has to be done right. It has to be disassembled. I am fluent in assembler for several different microcontrollers. Is there anyone else here who is prepared to attack this problem without Hexedit?

This post has been edited by Tiros: Apr 27 2005, 06:21 PM

[maximilian0017]

Is there anyone else here who is prepared to attack this problem without Hexedit?

The chance of getting any improvement with only the help of Hexedit is close to nothing, it's a great program but not for this.

And i think you are right on the encryption bit too(at least when they didn't use a mask in the processor), just look at the two firmwares and it's obvious that they are almost the same.

At this time i'm researching something that may prove to be a problem later but i need to dissasemble the firmware first too.

Tiros, did you have any success in dissasembeling the firmware?, at this time i haven't found a program and/or plugin to dissasemble the bin file.

I'm a beginner at this but i want to try with the time i have, and many hands make light work.

This post has been edited by maximilian0017: Apr 27 2005, 06:43 PM