Print

[Chicken Scratch Boy]

hangs with logitech wirelesss controller

hangs  on the bios screen with the xbox logo with MS below it

oh yeah, boots fine with the controller unplugged

[jonathan2007]

yeah i think getting rid of the corruption would be awesome but maybe not realistic. idk. anyway i think u should still call it 1.5 cuz it does support svideo and 2+ usb devices and those are a lot bigger additions than the things u took out. who would want jpeg's anyways cuz they just make the load time go up.

[Chicken Scratch Boy]

) because you can have the xbe file point to nk patcher!

good idea with the stopusb and stuff

[jonathan2007]

 

[Chicken Scratch Boy]

i think that the next cool thing (other then stopusb) would be to make it hold the xbox logo on screen or maybe play iwth it , if you think thats possible

for me it boots to a black screen

i wait

and it goes to my dash

[Chicken Scratch Boy]

i'd assume it was impossible to do anything to it, but to leave it up i though may have been but i guess not

[Dan Wysocki]

[jonathan2007]

[Tomilius]

QUOTE (Dan Wysocki @ Jun 28 2004, 09:39 PM)

still hitting error 21 everytime i replce it...

Unless you specified XBEFile and there was an error, then the error 21 can't possibly be the fault of PBL (oh, or the BIOS PBL loads loads an XBE that doesn't exist). Do you get any output at all? You should see something if it has anything to do with PBL at all. Otherwise, like jon said, you probably need to re-sign it to whatever exploit you're using. It was signed with habibi like UDE uses.

[ldots]

I never really cared that much about S-video support (I dont have the cable) but wanted to make PBL load as fast as possible. So just now I tried to strip 1.4.1 down and I guess I have a version pretty much identical to yours now Tomilius. I really cut away everything except :
- DriveRemap
- GetConfig
- loadbios

So I completely skipped all the Hermes stuff, the USB stuff, the BootVga call, the DoSplash and the Dash. Meaning no jpeg's needed in the installation and no output to the screen at all. Also skipped the parsing of the Timeout and hardcoded this to zero.

Now it's only 108kb

I too get the 1-2 second screen corruption, and without using the VGA engine of free-xdk I dont see how it should be possible to get around this. You cannot use fb_clear unless BootVga is called, I think! Using BootVga I get no corruption but s-video users would get the same fuzzy screen for 2 secs. as with the usual 1.4.1.
Actually its quite clear from the source of BootVgaInitialization that s-video is not yet enabled in free-xdk for neither the Conexant or Focus chip. The CRTC register lines are not done yet. So it might be a bit misleading when you say you get s-video support by disabling BootVgaInitialization You dont get corruption, but thats really because you dont attempt to initialize VGA comletely.
Hopefully free-xdk will be updated soon to inlude the nessecary lines, or maybe openxdk can be a help. Did you look at that ?

An interresting thing is the code in the ParseConfig routine.

CODE

for(i = 0; i < 4; i++) {              VideoStandard = I2CTransmitByteGetReturn(0x54, 0x58 + i);      }

I dont see this being used anywhere in the remaining routines. Looks like the videostandard is being set writing to address 0x54. The bytes that are set are certainly not NTSC or PAL but some rubbish. The reason why I find this interresting is that if you remove this code PBL doesn't work anymore. Knowing more about how PBL works now I have a feeling this is what trickers the kernel to go into debug mode (or what we should call it) which might be needed for enabling the new bios. Remember that PBL enables the bios that is being loaded in memory by doing a QuickReboot.

Well, I will look a bit more at the code. More tests awaits

[Tomilius]

QUOTE

CODE      for(i = 0; i < 4; i++) {             VideoStandard = I2CTransmitByteGetReturn(0x54, 0x58 + i);     }

Good find! I wonder if by moving that you can gain compatibility for s-video or not by editing the boot.cfg like originally planned...

I'll try it later maybe.

[Dan Wysocki]

QUOTE (Tomilius @ Jun 28 2004, 10:21 PM)

Unless you specified XBEFile and there was an error, then the error 21 can't possibly be the fault of PBL (oh, or the BIOS PBL loads loads an XBE that doesn't exist). Do you get any output at all? You should see something if it has anything to do with PBL at all. Otherwise, like jon said, you probably need to re-sign it to whatever exploit you're using. It was signed with habibi like UDE uses.

Im running UDE with PBL, so signing isnt the problem, when I run my normal pbl (not the one you fixed) it boots up like a dream, i get tHc in my face straight away. The only strange thing that i notice is that with you pbl on my hdd, when i boot up the screen rolls (even during the flubber animation) then error 21 rolls for a while, then settles...
Im sure what you have done to PBL has helped a great amount of people, at a guess i would say my xbox doesnt like your pbl  well, thats my technical thought of the day anyway....

[ldots]

QUOTE (Tomilius @ Jun 28 2004, 10:43 PM)

Good find! I wonder if by moving that you can gain compatibility for s-video or not by editing the boot.cfg like originally planned... I'll try it later maybe.

Dont think this is related to s-video support. Tried moving this bit to the very end of the config parser.
I'm pretty sure we have to hope for an update of xboxvgalib. Composite and scart is defined for both NTSC, PAL, Conexant and Focus. Only svid missing
Someone most have done this bit at one point though. I would think 1.3.5i was compiled using the free-xdk library also  

[Chicken Scratch Boy]

dont forget about componet (or what ever you call HD these days)

ed: i was talking to ldots, not implying that it needs to be fixed, since i think it works anyway

[ldots]

So let me be sure I understand you post. You made one xbe that has two options :
1) NoVideo false : BootVgaInitializationKernelNG is called and you have no screen corruption
2) NoVideo true : BootVgaInitializationKernelNG is not called but you still have screen corruption.

I'm not sure I completely agree with you on the VideoStandard code. It's doesn't directly have something to do with S-video. The entire setup of the S-video mode is handled by BootVgaInitializationKernelNG which is why you get rid of the fuzzy image if you disable this. The only thing moving the VideoStandard code to boot.c did was to enable you to run the ConfigParser before you run BootVga and thereby know whether to run BootVgaInitializationKernelNG or not (depending on the NoVideo flag). Is that not correct?

What I meant in my previous post was that to get true s-video support we need these CRTC registers for s-video, and I'm sure someone has them.