xboxdev/serial-usb-adapter

Original Xbox Serial to USB Adapter

XboxDev

XboxDev is the place for all original Xbox projects to come together.

XboxDev is an effort to provide tools and documentation for the original Microsoft Xbox and Xbox-based SEGA Chihiro. We not only care about technical details about those platforms, but also how to develop homebrew and emulate them.

We are not interested in documenting the Xbox 360, Xbox One or any other console at this point.

You can create an issue to contact XboxDev maintainers.

Ecosystem

We currently provide the following services:

• Discord for communication
• XboxDevWiki to document research
• GitHub organization to host tools and files

Want to help? Contact us!

Please come chat with us:

• XboxDev on Discord

and for closely related projects:

• XQEMU: #xqemu on Freenode IRC (Webchat)
• Cxbx-Reloaded: Discord

You'll also get the details for XboxDevWiki account creation on any of these channels.

Coding style

The usual rule is: follow the existing code / commit style of whatever you are working on. If the previous commits use prefix style: use prefix style. If the surrounding code respects 80 column limit: respect it. If the surrounding code uses an unusual C style: mimic it.

Disclaimer

XboxDev is not affiliated with, endorsed by, or sponsored by Microsoft Corporation, Nvidia Corporation, licensed Xbox developers, publishers, manufacturers or any of their affiliates or subsidiaries. All product and company names are trademarks™ or registered® trademarks of their respective holders. Use of them does not imply any affiliation with or endorsement by them.

Reverse engineering of the original software and hardware is done to achieve interoperability with other computing platforms. In the process, excerpts of the reverse engineered source code will be shown for educational purposes.

No copyright infringement is intended at any stage during creation of XboxDev software, hardware or documentation.

serial-usb-adapter's Issues

Serial USB adapter becomes erratic when ribbon cable exceeds 10 inches

As the ribbon cable exceeds ~10 inches, the Serial USB adapter begins to behave erratically. This manifests in several different ways including:

• Xbox may outright FRAG when the serial adapter is attached
• WinDbg can hang, presumably waiting retrying a request for data while the SMSC keeps outputting invalid/garbage data
  • the TX (green) LED can be seen going nuts as retry attempts are made by the xbox to send the requested data
• The Xbox will not respond to any break's sent by WinDbg, so a debug session never connects.
  • RX (blue) LED blinks, but presumably the signals sent from the SMSC chip down the ribbon to the Xbox are getting corrupted / mangled by the time they reach the mobo
• Past ~11 inches ribbon length I have never been able to successfully established a debug session

It seems like there's a signal integrity issue and was hoping someone who is an EE might be able to help diagnose what could be going wrong here.

I'm pretty confident that by the time the signals reach our SMSC chip after running along the ribbon, they're too muddy for it to decode correctly.

Some additional thoughts:

• DVT4's have longer than 10 inch ribbons running to their serial boards
• I tried cutting SDA/SCL out of the ribbon close to the LPC side see if that might help reduce 'noise' on the ribbon
  • The ribbons in DVT4's also cut these two lines, which is why I decided to try it but it didn't help
• Is there anything that we missed about the design of the native DVT4 serial board that should be ported over to this?
• Are there going to be any issues with the fact that the FTDI side of our Serial USB circuit is powered by USB while the SMSC side is powered by the Xbox LPC? Is this best practice, or something that could also get refined in a new revision?
• This issue manifests at least on all REV A and REV C boards that I have on hand (and presumably REV B too)
• C4 is removed on all these boards. Anytime I have C4 on one of the boards, The Xbox outright FRAGs

I chatted briefly with a non-Xbox EE friend who had the following to say:

[LPC] is slow and edge rates are all that should matter here.

You can try adding 5-10 ohm resistors in series to the signal lines. it's counterintuitive, but basically it slows the rise time of the signals which removes a lot of the high frequency components.

Basically: old school stuff had slower rise times, less high freq. components (sharper edge: more hi freq, see: fourier). higher frequencies couple better between lines (crosstalk) and will give you more issues with reflection and other transmission line effects.
So even if you have a newer chip with "slow" signals, it's driving the fuck out of those edges, so stick some resistors in series to slow him down, it helps sometimes 🙂

another note: you can interleave grounds to help

Would be more than happy to hear any other thoughts from HW / EE / CSE people

Pre-Assembled Unit Interest

I've made 20 of these adapters (includes all cables and pin-header for the Xbox LPC) and will be selling them to active XboxDev contributors for $15 USD plus shipping. Non-contributor pricing is $30 USD plus shipping. This will be a bit different however in that those who benefit the most from it will be given priority over others at my discretion so I'd like to get an idea of who's interested first as once they're gone I likely won't be making another batch.

Note, as described in the README, you'll need either a debug/devkit or a retail v1.0-1.2 motherboard with the capability of soldering a pin-header onto it in order to use this.

Please let me know via here or Discord if you're interested and whether or not you're located in the EU so I have an idea of how many to ship in bulk there for further distribution.

TODO's

So I don't forget...

1. Re-generate PCB screenshots and gerbers; no need to update the hardware revision as there were just minor silkscreen changes for interchangeable parts.

2. Fix screenshot tooltip copypaste mistakes.

3. Clarify that iND kernels don't fully initialize KD (still need to test if plain serial output works however). If not using a debug/devkit, the following hacked kernels have been tested successfully with KD and windbg:

   • X2 4979 BFM - use on any board
   • X2 4981 (256 KB) - use on 1.2+ boards
   • X2 4983 BFM - use on any board
   • X2 5035 (512 KB) - use on 1.0-1.1 boards