Xbox 1.0 Black Screen (Aladdin XBlast v0.55)

[Mike Davis]

Xbox 1.0 boots up with a black screen and blinking green LED only once USB daughterboard is connected. If daughterboard isn't present, XBlast OS loads up just fine. The same chip works in a 1.1 Xbox.

[psyko_chewbacca NA]

Can the issue be reproduced with v0.50? With the daughterboard in place, what is the boot behavior when a single controller is already connected and when no controller is connected?

EDIT: test daughterboard scenarios described above with v0.55.

[Mike Davis]

I've tested the following scenarios on v0.55 all with the same results; it boots up with hdd/dvd activity, a black screen, and flashing green LED. Disconnecting/connecting the composite AV cable yields either a flashing green/orange or green LED. The DVD eject/inject works as well, so the software obviously isn't hung. I should also mention that this box has 128MB of RAM installed. I can read/write the entire address space without issue so I doubt this is a contributing factor.

• with daughterboard, usb cables disconnected
• with daughterboard, usb cables connected, no controller
• with daughterboard, usb cables connected, single controller

v0.50 actually works fine with the daughterboard connected. Sorry for not thinking to try that earlier. That should at least narrow it down a bit for you.

I'm assuming SPI debugging isn't possible with the Aladdin chips? Are any of yours still available for purchase?

[psyko_chewbacca NA]

SPI debugging is indeed impossible on the Aladdin XBlast mod.

My hypothesis on the issue at hand is that booting XBlast OS from a Aladdin mochip rather than a real XBlast Lite mess up a bit USB init on 1.0. As XBlast OS v0.55 specifically relies on having a fully loaded USB stack before completely booting, something must go wrong with the combination of a 1.0 Xbox, a Aladdin XBlast and XBlast OS v0.55. I just hope this issue isn't related to a certain board variant of a 1.0 daughterboard, if multiple board revisions exists.

I will try to reproduce the issue with a 1.0 and a Aladdin XBlast myself.

When you say the DVD inject/eject still works. Do you mean by pressing the Eject button on front panel or by blindly navigating XBlast OS' menus to that specific section? Eject button presses are not handled by the CPU, the input is directly fed to the PIC (SMC controller) and an action is immediately taken by it. The CPU is informed of a status change via an IRQ.

If the soft isn't truly hung up, you should be able to blindly select and boot a BIOS bank.

Speaking of this, a good test would be to set up the Aladdin XBlast with v0.55 to quickboot a user bank when powering the Xbox via the power button and see if the bank is indeed loaded. Quickboot works by launching XBlast OS as usual but branch out quite rapidly during the init of XBlast OS (before Video, IDE and other init routines) and launch the desired BIOS bank. You could prealably set up quickboot to boot a properly flashed 512KB BIOS bank from another Xbox than the problematic 1.0. Once it is confirmed quickboot is properly set, put that Aladdin XBlast into the 1.0 in question and see if quick boot works. This could help me narrow down the bit of code that hangs execution on that 1.0 Xbox.

EDIT: I still have a few units for sale. Hit me up on AssemblerGames although I would prefer to resolve this issue on the Aladdin XBlast beforehand. Maybe your 1.0 Xbox is unique in a way you're the only one to experience this kind of issue and possibly a XBlast Lite won't solve that(although unlikely).

[Mike Davis]

When I mentioned DVD inject/eject working, that was only via pressing the button on the front. Quickboot does not work after testing with an XBlast 0.55 image that works fine on a 1.4 Xbox. Hammering A during startup to try to select a bank doesn't do anything either, so perhaps the software is hung after all.

The daughterboard part number is "X00253-001 Rev A" for your reference.

I've got a few other fresh 1.0's lying around here I can try to repro on as well if needed.

[psyko_chewbacca NA]

I just tried my Aladdin XBlast v0.55 in two 1.0 Xbox, both have the same Daughterboard revision mentionned in the comment above. I even tried a spare daugtherboard (same rev) in both units. All configurations boot successfully into XBlast OS. I cannot reproduce the issue on my end.

I would very much like you to determine wether the daugtherboard or the 1.0 motherboard is the troublesome component. You mentionned you have a spare 1.0. First try to boot your Aladdin XBlast (on v0.55) on that spare 1.0 without swapping parts. If it works, try swapping daughterboards and test again on both units.

To keep track of which Xbox is which, The 1.0 motherboard along with its matching daughterboard could be referred as "Motherboard A" and "Daughterboard A". Any other combination of 1.0 mother and daughter boards verified working with Aladdin XBlast on v0.55 would be the "B" counterpart.

Thanks.

[Mike Davis]

I'll get some tests set up with a few 1.0 boxes and couple different Aladdin chips and let you know the results hopefully within a day or two.

[Mike Davis]

Early tests point to it possibly being related to the RAM upgrade. I'm going to test against another fresh box and then upgrade its RAM and test it again. I suspect afterwards it will exhibit the same issue with a daughterboard and 0.55

http://imgur.com/a/ELFdy

[Mike Davis]

Well, I upgraded the RAM in box C and denoted it as F in the new tests image below.

http://imgur.com/a/peFUN

It still works with both 0.50 and 0.55 much to my surprise. For some reason I can't reproduce the 0.55 issues on any 1.0 box other than A. I even tried swapping out box A's inferior PSU with Box C's Delta, thinking it might be some weird timing issue caused by power draw, but that didn't help. Box A can't boot 0.55 with any USB daughterboard plugged in, it's the strangest thing. Box A otherwise appears to be healthy and fully functional.

Hardware-wise, the only real difference between box A and C is the TSOP. The RAM chips used were sourced from the same batch via utsource and are the F type which should be superior to M in every way. I'm assuming EEPROM contents aren't touched at this stage in the boot process, or would a dump of those help as well?

Any other ideas? Since this doesn't appear to be a widespread issue, I'm not sure how much interest you have in looking further into it, and it's no skin off my back as I have plenty of other options here. However, if you'd like, I'd be happy to ship you box A in exchange for a couple xblast lites or something...