tiertop

Good ideas. I removed the cap from the circuit and intensity didn't change. I was wondering if it was possibly failing and becoming a short. I will grab a toothbrush and clean up the connector. I'm not sure why I didn't think of that. I have a new cap and SPDIF port on the way. The SPDIF port was very worn out from decades of use anyway. I don't have any high intensity LEDs around to experiment with unfortunately. I do have an old PC SPDIF bracket but didn't really feel like desoldering it as that port won't fit well with the XBox adapter anyway (I have it for an old nForce MCP-D motherboard ).

Thanks for the tips. I will look over it again. It is of course possible the cabling has hidden damage too. But all the visible wiring looks ok. The optical port is rather worn out though. It had a broken solder joint and the little door barely closes. I wonder if an electrical arc from a broken solder joint could damage it. The port connection also has a lot of play in it. I dug around Digikey and found a replacement emitter assembly that looks remarkably similar to the original, and also bought a replacement cap. We'll see what happens!

This is causing some memories to surface. After playing with these prebuilt releases from around the web, and finding IGR non-working, I looked around more and found the github with python patcher: https://github.com/gaasedelen/titan I patched an original m8 Plus myself and the patch itself is what disables IGR. I don't think you can load the final patched builts into EVTool.

I didn't have any INI in use. I think I tried EVTool on it. Actually I think I even tried taking the original m8 Plus and patching it myself and the patch caused IGR to be disabled.

These 128MB EVOX ROM modifications. I think they are based on m8 plus? I tried a few of the UDMA builds for non-HDMI systems on my v1.0 and IGR wasn't functional. I also found some talk elsewhere about IGR not working with it.

If I remember right IGR does not work with these.

I think they are available on Etsy. I bought one there about a year ago. It works well. I've been using it with an 8bitdo wireless adapter and primarily a XBO or PS4 pad. There is a quirk in that the 8bitdo won't pair with the controllers on power up unless I press its connect button.

A few more photos. It is so incredibly basic inside. I had to repair the green component output years ago because the horrible molding caused a wire to eventually break. They charged $50 for this! I don't know if I think a wire is broken. Moving the cable around while it's operating doesn't affect anything. Analog audio and component video are working fine. A cap replacement is easy to find but I'm not sure how to shop for an emitter.

My HD AV Pack is no longer outputting a working optical audio signal. The receiver acts as if nothing is connected. The AV box is producing the red light but it is noticeably dimmer when compared to my TV's optical output. I tried two optical cables and two XBoxes. Inside the HD AV pack, the optical audio section is on a mini PCB and has a tantalum cap, as shown in the photo. Could this cap be going bad and causing the LED to dim?

The XBox will always be a monster block of console regardless of whether it has a HDD or SSD inside. I just looked up the UDMA6 thing and see that the Cerbios guys did release a new BIOS that supports it. I was setting my Xbox up before they released that BIOS. I will have to experiment with the new BIOS.

I have one of the Startech adapters and some cheapos too. With my XBox only a regular hard drive is stable at UDMA4/5. I went looking over the Cerbios official Discord and I saw some chatter about stability problems with UDMA4/5. I think the XBox is on the ragged edge of the IDE specs if you set it to UDMA4/5 and that a SSD or SSHD push it too hard. Hard drives do vary in speed, but it's rather meaningless in the modern SSD world. I used to obsess over picking fast hard drives decades ago lol. For example, access time measures how long it typically takes a hard drive to find data on its platters. Usually like 12-18 ms. No data is transferring while the drive is locating it. If the file you're accessing is fragmented, this time gets multiplied to read all of the file. If you're accessing a zillion tiny files and they aren't near each other on the platters, it might take that 12-18ms to find each one. A SSD's access time is more like 0.01 ms. 1000x faster. A SSHD drive will also have fast access time if data is stored in the flash portion. And also for comparison, a DVD drive usually has a read access time > 100 ms.

Yeah I was playing around with the UDMA5 BIOSs earlier this year while also setting up Emustation. I have a few SSDs, SSHDs and hard drives around so tried different configs. The SSD is definitely fastest at scanning games and moving around the dashboard. SSHD is pretty good too. The hard drive a bit slower than those and noisier. For regular Xbox games I can't tell much difference between any modern drive. Unfortunately the SSD and SSHDs cause the XBox to freeze at random if at UDMA 4/5 for some reason so that's why I have it at stock UDMA2. The thing with SSDs is they rock at reading small files randomly whereas a hard drive chokes. So when you run a game scan with Emustation for example the SSD just blasts those files across nearly instantly whereas with a hard drive the speed drops way down because you wait on the read head moving around the platters.

Sure. It is still faster than a UDMA5 hard drive in the Xbox because it can saturate the bus whereas a hard drive bogs way down with small random file access. It is most noticeable when scanning games with Emustation for example.

The Jmicron adapters can work fine. That one appears to be of decent quality. Sometimes the XBox has trouble detecting the drive connected with cheap builds of them though. It can cause a startup delay or may not work at all. Marvell controllers tend to work better. The Xbox runs UDMA 2 (33MB/s) unless you flash a BIOS with UDMA 4 (66) or 5 (100MB/s) support like Cerbios or a M8 Plus Titan mod. This makes the XBox even more picky about drive and adapter. I settled on a SSD at UDMA 2 with standard M8 Plus after lots of experimentation.

Well have fun with it! It's a very customizable console with lots of interesting homebrew to try.

Are you copying a zillion little files to it (as some games have)? Copying lots of little files takes a long time mostly because of the delay of the FTP client and server negotiating each transfer. It takes longer than the actual file transfer. This is a reason to switch to playing games in XISO files. Copying the big ISO files avoids the slowness with copying those games that have thousands of tiny files. Also, if you are using some form of XBMC, well it has a rather slow FTP server. UnleashX is a lot faster.

Sorry I meant EvoX M8+ Titan edition doesn't have IGR. CerBIOS does of course. Yeah I have the CerBIOS.ini on C and with default settings aside from the dashboard to load. I found the XboxScene Discord with Cerbios sub forums and read through some UDMA5 discussion on there. They had some similar problems and mostly recommend just not using UDMA5. I think using a regular hard drive is the surest way to success. Less bus traffic with a slower HDD probably helps keep things stable.

I did some more testing with my 128MB Xbox 1.0 and its freezes at UDMA5 with Cerbios. I have a spare SSD so I thought I might try that. It freezes in the same way as the SSHDs. I can't finish a single lap in Burnout 1 before it locks up. I also tried one of my generic Chinese SATA adapters (I think these use a Jmicron chip instead of Marvell) and one of them did seem to work ok at UDMA5 but it too eventually froze in Burnout 1. Then I had the idea to try Evox M8+ Titan UDMA5 and to my surprise it did not freeze. I played Burnout for awhile without trouble. The question though is it really at UDMA5? I don't know of a way to verify that. And since these BIOSs lack IGR they are rather unappealing anyway. In general though the SSD, even at UDMA2, is quite nice. The silence is great, but it also has some noticeable benefits for dashboard performance. Scanning games with XBMC-Emustation is faster for example. I'm sure that's the SSD near-zero seek time in action.

Looks great! That will be an amazing addition to the library.

Yeah, clicking is often a sign of some kind of failure. You could try deleting the game and FTPing it over again and see if that fixes the problem. It might just be a weak sector on the disk and rewriting it might fix that or cause the drive to remap it with a spare. With a change in temp possibly fixing it, I think of perhaps a failing solder connection somewhere. Heating a broken solder joint can make the the connection good again and when cold it becomes intermittent.

XISO. I think it might be a problem specific to these Seagate notebook style SSHDs.

Has anyone else used these BIOSs with a SSHD? I have a couple, pulled from notebooks. A first gen Seagate Momentus XT 500GB and a later 500GB Seagate ST500LM000 that is apparently Seagate's 3rd gen SSHD. They are really snappy hard drives and also quiet. But they seem to be prone to freezing with Cerbios UDMA 4 or 5. I had Burnout lock up within a few minutes and Goldeneye Rogue Agent in maybe 30 mins. Running with M8+ is trouble free.

fading/glowing blue. Mine is green because I have the custom carbon color in the menu set to 107C10. Here are my modifications if anyone would like to play around. darker carbon.zip

Carbon is almost there, but with an OLED TV in a dark room, any white text or backgrounds sear the retinas. It would be nice to have a theme that keeps things even darker. I went into the XML files and managed to customize Carbon (and it's connection with Simple) to make it mostly black and it looks great. I love how a transparent black carousel looks with the fading/glowing green background effect. I can't figure out where the white selected text of the settings submenus or the acknowledgments page is configured though.

Yeah that's surely what's happening. I should look at the boot log sometime. That might be interesting. I wish I could think up some other way to bench a sequential read/write.