Topic: Customize X2 4980 (Read 981 times)

FLuKE11 · « **Reply #30 on:** January 16, 2004, 01:49:00 AM »

QUOTE (skorchir @ Jan 16 2004, 08:39 AM)

i will mess around a bit more but dunno if it will get much further then this.. i am not a very experienced c++ programmer i am just working on the little knowledge i know. I also never worked with win32 c++ programs before i have only done console apps hehe...

i might just take an alternate route and make some ppfs but that wouldnt really help much for changing colors unless they were pre-defined.

anyway il play some more tomorrow if i have time

looks good so far

ZaPhOd · « **Reply #31 on:** January 16, 2004, 05:48:00 AM »

I'm still using version 42.00, is that bad? J/K! Was there even a version 42.00? I'm new.

DBZRacer · « **Reply #32 on:** January 16, 2004, 12:07:00 PM »

Please excuse my lazyness... But will we be ever able to change the boot partition name/order with 4980 with or without the help of a new ver of xbtool?

so boot sequence would be something like mxmdash.xbe, then unleashx.xbe, then evoxdash.xbe.

I know that there were older vers of the x2 bios out there that xbtool couldn't change before but it's been such a long time and didn't know if that barriers been broken.

alg5 · « **Reply #33 on:** January 16, 2004, 12:45:00 PM »

QUOTE (rimmi2002 @ Jan 16 2004, 09:58 PM)

Is there any way to change fan speed for 4980?

of course, but it will be harder to find.
4980 seems to use different code for fan speed than 4979

heinrich · « **Reply #34 on:** January 16, 2004, 01:36:00 PM »

QUOTE (alg5 @ Jan 16 2004, 05:45 PM)

QUOTE (rimmi2002 @ Jan 16 2004, 09:58 PM)

Is there any way to change fan speed for 4980?

of course, but it will be harder to find.
4980 seems to use different code for fan speed than 4979

As far as I can tell, there is no code for fan speed (or LED color) in any released bios, that is a function that nghtshd's xbtool put in to make calls to the i2c controller, it's not simply changing existing values.

NghtShd · « **Reply #35 on:** January 16, 2004, 04:44:00 PM »

skorchir, those 3 files are binary files containing machine code. XBtool adds 32k to the end of the kernel and adjusts the kernel's PE header to account for that (and to make the init section executable) and sticks those patches in the expanded area. The DiscardInit patch handles making sure that the code added to the end of the kernel doesn't get dumped along with the rest of the init section (it hooks into the kernel's DiscardINITSection function). The other two patch files contain a function to set the fan speed and LED color and a replacement for the dash loading function. The code in those patches gets called by hooking into other kernel functions.

Things are further complicated by the fact that the patch code gets moved after the kernel is through with the init section (thats where the DiscardInit patch--devised by oz_paulb--comes in). As you can see, it's kind of a convoluted mess.

You could probably use SantMat's led setting method without resorting to expanding the kernel. You might even be able to patch it up so it changes the fan speed instead. It's been a while since I used SantMat's method and I don't recall exactly what the code it patched looks like (it hooked in around the AV cable check), so I'm not sure if you can do that, but I'm thinking just change the SMBus commands from LED mode/sequence to fan mode/speed.

Heykrop · « **Reply #36 on:** January 16, 2004, 08:16:00 PM »

QUOTE (NghtShd @ Jan 17 2004, 01:44 AM)

skorchir, those 3 files are binary files containing machine code. XBtool adds 32k to the end of the kernel and adjusts the kernel's PE header to account for that (and to make the init section executable) and sticks those patches in the expanded area. The DiscardInit patch handles making sure that the code added to the end of the kernel doesn't get dumped along with the rest of the init section (it hooks into the kernel's DiscardINITSection function). The other two patch files contain a function to set the fan speed and LED color and a replacement for the dash loading function. The code in those patches gets called by hooking into other kernel functions.

Things are further complicated by the fact that the patch code gets moved after the kernel is through with the init section (thats where the DiscardInit patch--devised by oz_paulb--comes in). As you can see, it's kind of a convoluted mess.

You could probably use SantMat's led setting method without resorting to expanding the kernel. You might even be able to patch it up so it changes the fan speed instead. It's been a while since I used SantMat's method and I don't recall exactly what the code it patched looks like (it hooked in around the AV cable check), so I'm not sure if you can do that, but I'm thinking just change the SMBus commands from LED mode/sequence to fan mode/speed.

NghtShd If you do not intend to further develop XBTOOL then do you plan on releasing the source for the last version? 1.0.12 Personally I find it interesting that Team Executer announces XBTOOL like functionality in the X3 chip's OS and there is suddenly no further development for XBTOOL. Are they using your source? Sorry if I sound like I'm on the offensive. Nothing against you. I for one am greatly appreciative of all you have done. I've also fully hexed my 4980 and the only thing I wish I could add is the LED color. I use the alternate color to remind my self that I'm running with the mod on.

Anyway. It would be great to see another release but If not then let me be the first to post

R.I.P. XBTOOL 01-19-03 to 01-05-04

heinrich · « **Reply #37 on:** January 16, 2004, 08:40:00 PM »

QUOTE (NghtShd @ Jan 16 2004, 09:56 PM)

QUOTE

With NghtShd making threats of not updating XBtool

Just for the record, I wouldn't characterize it as a threat. It sounds like I'm trying to extort something out of someone.

Although 4981 may be nearly identical to 4980, I'll wait till that's out and then look into doing a patcher for it (just to be on the safe side).

I'll also try to get my latest source code out, along with the assembley language patch file sources.

After that, I'm looking for something new and different, though I'd also be glad to assist if someone wanted to do an Xbox hosted version of XBtool (my feeble DirectX skills prevent me from doing it a user interface, though I've always thought it would be cool).

As for the last part, I was actually looking into this today. I don't think it would be too difficult to get running on the xbox, I worked on this a little today with kl0wn, we have a simple UI with some extremely primitive options already, I'll post a few screenshots if anyone is interested in seeing what we've got started.
I agree that the 'x3 live config' does sound like its pretty much a port of xbtool to the xbox, it would be extremely nice to have something for the 'rest of us'.

heinrich · « **Reply #38 on:** January 16, 2004, 09:32:00 PM »

NghtShd · « **Reply #39 on:** January 17, 2004, 07:19:00 AM »

Ok, I had some free time, so now I have partial 4980 support implemented, but someone on IRC is saying the live disable feature doesn't work or doesn't work on some games. If this is the case then is there much point in supporting this kernel? If you can't trust the live disable it isn't really much good.

Heykrop · « **Reply #40 on:** January 17, 2004, 08:35:00 AM »

QUOTE (NghtShd @ Jan 17 2004, 04:19 PM)

Ok, I had some free time, so now I have partial 4980 support implemented, but someone on IRC is saying the live disable feature doesn't work or doesn't work on some games. If this is the case then is there much point in supporting this kernel? If you can't trust the live disable it isn't really much good.

Team Executer said in the initial release that they had not tested all of the available LIVE! titles and were looking for others to test what had not been done. If it is only 1 or 2 titles out of the majority that are having a problem then that is sufficient for me to continue to use 4980.

Were the guys on IRC being specific and trustworthy individuals or

A. Complete N(oYo)Bs that dont know the difference between a pinheader and a pogo pin install?

B. Plants by M$ that are just trying to throw a wrench in the works?

There was a person spouting off on this forum not too long ago that 4980 was a waste of time because he had dozens of EEPROMS that he could use if he were banned. Maybe that person could put a few EEPROMS where his mouth is and test it out. Or possibly share a couple for testing purposes.

dzv · « **Reply #41 on:** January 17, 2004, 08:09:00 PM »

QUOTE

If the game asks you if you wish to update your dashboard YOU MUST SELECT NO. THIS WILL BAN YOU FROM LIVE. The bios currently does not block access to the server - it is being worked on. You will only be asked for an update if you do not have the latest version of the Xbox Live 2.0 Dashboard (currently 5659.03). It is a good idea to update to the latest dash by using the original game and with your mod disabled. Thanks to forum member and 4980 tester Leftyfb for actually testing this and getting banned less than 24 hours later (on a spare box he had of course hehe).

Unfortunately, I'd say this still leaves users quite open to getting banned. In fact, it might even make users more inclined to getting banned. I think that most users using 4980 have been given the impression that it is completely Live-Safe, and will become more complacent, therefore increasing the chances of them allowing something like a dashboard update to occur.

Until this hole is plugged, I wonder if it's even a good idea for people to use 4980.

At least when people are using 4979 or M7, they KNOW they will be banned if they make a mistake, and therefore they are (usually) very careful about getting banned.

Author Topic: Customize X2 4980 (Read 981 times)