Xell-Reloaded Build Compatible With All Consoles, Including Winchester

fixingthings · Monday at 2:56 AM

I managed to get Mupen64-360 running on an Xbox 360 with a Winchester motherboard. Here is an explanation generated by the AI that helped fix it, along with the download link for the corrected XeLL Reloaded and Mupen64-360 files.

This was basically a vibe-coding project with GPT Codex and Claude, and the result appears to be very well done. That said, it took a lot of time, money, and perseverance. I also had to rely heavily on logical reasoning to work out the method, decide what to test, interpret the results, and keep the investigation moving. The AI did much of the coding, but getting to a working result still required a lot of hands-on testing and problem-solving.

I also plan to work on fixing more emulators, so stay tuned.

The investigation and fixes were carried out with the help of GPT Codex and Claude. Both were used to analyze the source code, interpret logs, identify bugs, and develop corrections, while the results were tested directly on the Xbox 360 Winchester.

The problem was not caused by a single incompatibility. It involved the XeLL ELF loader, USB recovery in libxenon, and the disk-mounting code used by Mupen64-360.

In XeLL Reloaded, we first fixed a build-order problem in the alex-free fork. The stage2.elf32.gz target removed object files that were still needed for the Stage 1 link, so the build order had to be adjusted. We also restored the missing rules file required by the toolchain. The most important change was restoring elf.c and elf_run.S from before the ELF loader rewrite in May 2020, while keeping the rest of libxenon modern. With that combination, XeLL finally managed to hand execution over to the recompiled Mupen.

In libxenon, we fixed a null-pointer access in qh_end_transfer() that caused the red crash screen with dar=0x3c. We also found that USB recovery was resetting port 0 instead of the port where the device was actually connected. In our case, the flash drive was on port 4, so recovery could repeatedly reset the wrong port and leave the storage driver stuck in its retry loop. Both reset calls were changed to use the device's actual port. Another fix made ehci_reset_usb_port() return an error after handing a non-high-speed port over to OHCI, preventing the EHCI code from trying to initialize a port it no longer owned. EHCI_TUNE_CERR was also restored from 0 to 3, although that was not the main cause of the problem.

Mupen64-360 was then rebuilt against the corrected libxenon. This required locating, compiling, and installing ZLX-Library, libxemit, and ntfs-xenon. We also had to rebuild and reinstall ZLX after an incomplete library caused linker errors involving symbols such as ZLX::Font, ZLX::Browser, and ZLX::Console.

The ROM-loading freeze turned out to have a separate cause. The flash drive was formatted as FAT directly at sector 0, without an MBR, a layout commonly called superfloppy. ZLX was seeing the 0x55AA signature and interpreting the FAT boot sector as a partition table. That produced invalid LBAs, including 0x7265206B, which initially looked like a USB or SCSI problem. The return address helped trace the issue back to FindPartitions() in mount.cpp.

We corrected the partition detection so that it checks for FAT16 or FAT32 directly at sector 0 before attempting to interpret the sector as an MBR. If a valid FAT filesystem is found there, it is mounted as a partition starting at sector 0. After this correction, the flash drive mounted correctly and ROMs started loading.

There was still a problem when both the flash drive and external HDD were connected. The TinyEHCI driver detected both devices, but ZLX was only mounting one USB interface at a time. We added support for mounting both interfaces and adjusted the order so that the flash drive remains uda0 and the external HDD becomes udb0. This matters because Mupen looks for its installation in uda0:/mupen64-360/. When the HDD was mounted as uda0, Mupen could no longer find the expected files, which caused problems with the background and ROM loading. With the corrected order, the flash drive remains the main device, the HDD is available as additional storage, and a single connected USB device still mounts as uda0.

The final working build is based on Mupen64-360 0.992 beta. Version 0.993 beta2 was also investigated, but it lost video output on the Winchester. From what we observed, it does not appear to have many code differences compared with 0.992 beta, although we did not perform a complete comparison.

I haven't tested the emulator extensively yet, but so far everything appears to be working perfectly. I tested Castlevania and The Legend of Zelda: Ocarina of Time, and both ran successfully. XeLL loads the recompiled Mupen64-360, ROMs work from the flash drive, and the external HDD can remain connected as additional storage.

Thank you for reading!

I updated the download links in my post and added a version with aspect ratio settings in the menu.

Audio: Fixed resampler issues, improved audio queue/cache handling, and implemented a packet-based audio queue with a persistent resampler and DMA aligned to 2048-byte blocks.
Stability: Fixed texture copying issues and a recompiler heap bug.
Performance: Added a small CRC optimization and an ABI3/ENVMIXER3 optimization. Also eliminated redundant USB polling, improving VI/s by 22.3% (49.08 → 60.03) and the measured frame rate by 26.3% (18.62 → 23.52 FPS). This allows the emulator to reach full speed in the tested scenario, with substantially fewer long frame-time spikes.
Display: Added an aspect ratio option.
Additional changes: Increased the audio queue headroom from 16 KiB to 32 KiB.

NOTE: ~~You no longer need to download multiple files or replace anything. The latest version is available here as a single zip file.~~
I was informed that the files I made available do not comply with the GPLv2 license. I'll correct this and make the files available again soon. If anyone needs them urgently, please contact me.

Vetus_Mundi · Monday at 8:22 AM

Awesome! I will try this out later. Thank you very much!

Could you maybe make it where it doesn't stretch the screen? It's fine for games with widescreen options as well as hacks. Perhaps an option?

fixingthings · Monday at 2:51 PM

Afeohtan said:
Awesome! I will try this out later. Thank you very much!

Could maybe make it where it doesn't stretch the screen? It's fine for widescreen games and hacks. Perhaps an option?

Done! I've updated the download links in my post and added a version with aspect ratio settings in the menu.

Update: I'm still working on the fixes. The aspect ratio adjustment isn't quite right yet. Once I've finished fixing it, I'll come back and edit this post to let you know. The updated download will be available in my previous comment.

Vetus_Mundi · Monday at 3:45 PM

Awesome, thank you again. Do you have any plans to possibly update the core in the future?

If you do update and use not64 as a base, I should let you know that after the last 2019 version of not64, certain SM64 hacks on longer work, so if you decide to port any of them I would recommend that specific version, though sadly it would lack fixes for games in later versions.

Is there a way to remap buttons? I would like to map N64 B button to Xbox 360 X button. As far as I can tell there isn't a way to remap. Would you mind adding an option? I apologize if I am asking too much and if so, please let me know.

One thing I like better about this port of Mupen64 over the Wii and GC ports is the dynamic recompiler. I will explain:
There is a tool to inject N64 ar/gameshark codes into N64 roms. I use a walk through walls code for OOT 1.2.

It is temporarily activated by holding the A button. To get this code to work as intended some emulators/ports require the interpreter core to recompile the newly changed code. It can work on the dynamic recompiler on wii64 and not64 but the A button needs to be held most of the time until in-game. Unfortunately though it will stay active unless a save state is created and the game is reloaded without the A button being held or by switching to the interpreter core.

fixingthings · 2026-09-08T02:41:06+0100

Vetus_Mundi said:
Awesome, thank you again. Do you have any plans to possibly update the core in the future?

If you do update and use not64 as a base, I should let you know that after the last 2019 version of not64, certain SM64 hacks on longer work, so if you decide to port any of them I would recommend that specific version, though sadly it would lack fixes for games in later versions.

Is there a way to remap buttons? I would like to map N64 B button to Xbox 360 X button. As far as I can tell there isn't a way to remap. Would you mind adding an option? I apologize if I am asking too much and if so, please let me know.

One thing I like better about this port of Mupen64 over the Wii and GC ports is the dynamic recompiler. I will explain:
There is a tool to inject N64 ar/gameshark codes into N64 roms. Some years ago I made a walk through walls code for OOT 1.2. I am not the first though.

Anyway, it is temporally activated by holding the A button. To get this code to work as intended some emulators/ports require the interpreter core to recompile the newly changed code. It can work on the dynamic recompiler on wii64 and not64 but the A button needs to be held most of the time until in-game. Unfortunate though it will stay active unless a save state is created and the game is reloaded without the A button being held or by switching to the interpreter core.

I don't have any plans for that at the moment. I've updated the download link (wait for the admins to approve it) with some new audio, stability, and performance patches. I plan to keep improving the emulator and will probably try to bring dulldc to XeLL on Winchester as well. Tomorrow, I'll try to add a button-mapping option. Stay tuned.

Vetus_Mundi · 2026-09-08T02:50:55+0100

fixingthings said:
I don't have any plans for that at the moment. I've updated the download link (wait for the admins to approve it) with some new audio, stability, and performance patches. I plan to keep improving the emulator and will probably try to bring dulldc to XeLL on Winchester as well. Tomorrow, I'll try to add a button-mapping option. Stay tuned.

Great! Thank you again!

Speaking of nulldc, are you planning on adding the updates from the recent Wii port?

(Edit: Now I see the post and the attachment.

)

Edit 2: I noticed the dialog text on Ocarina of Time is now a bit blurrier. Was the framebuffer textures option enabled?

fixingthings · 2026-09-08T23:59:01+0100

Vetus_Mundi said:
Great! Thank you again!

Speaking of nulldc, are you planning on adding the updates from the recent Wii port?

(Edit: Now I see the post and the attachment.)

Edit 2: I noticed the dialog text on Ocarina of Time is now a bit blurrier. Was the framebuffer textures option enabled?

I’m going to replace the version in the original post with an earlier version from before my new fixes, as they apparently caused some issues. Please wait for the new download to be available in the original post. Unfortunately, I haven’t been able to remap the buttons yet.

Vetus_Mundi · 2026-09-09T00:09:16+0100

fixingthings said:
I’m going to replace the version in the original post with an earlier version from before my new fixes, as they apparently caused some issues. Please wait for the new download to be available in the original post. Unfortunately, I haven’t been able to remap the buttons yet.

I have all three versions that you posted. I will probably go back to the second build until the update.

I am not sure if the blurrier textures is an issue as in an emulation issue or not. To be honest I should not have asked about the framebuffer textures being enabled because the subscreen pause in OOT would render mostly correct it it were enabled. I know they aren't enabled. My apologies.

Anyway thank you again.

fixingthings · 2026-09-09T00:35:40+0100

Vetus_Mundi said:
I have all three versions that you posted. I will probably go back to the second build until the update.

I am not sure if the blurrier textures is an issue as in an emulation issue or not. To be honest I should not have asked about the framebuffer textures being enabled because the subscreen pause in OOT would render mostly correct it it were enabled. I know they aren't enabled. My apologies.

Anyway thank you again.

I think I managed to get the button remapper working. This time, I’ll try posting updates separately from the original post so I don’t end up replacing stable versions with problematic ones. Let me know if it works on your end. Also, check whether the text is still blurry (I didn’t quite understand your last comment about that). I’ve been playing OOT too, and I haven’t really noticed that issue.

Also, I think you noticed that the 4:3 aspect ratio isn’t quite perfect in OOT, at least on my end. I haven’t managed to fix it yet. For now, I’m trying to manage my coding AI tokens more efficiently. Looking forward to your feedback.

Audio: Fixed resampler issues, improved audio queue/cache handling, and implemented a packet-based audio queue with a persistent resampler and DMA aligned to 2048-byte blocks.
Stability: Fixed texture copying issues and a recompiler heap bug.
Performance: Added a small CRC optimization and an ABI3/ENVMIXER3 optimization.
Additional changes: Added controller remapping and increased the audio queue headroom from 16 KiB to 32 KiB.

NOTE: This is an older version. The latest version is now available in my original post.

Vetus_Mundi · 2026-09-09T00:55:23+0100

Using the FB textures option on older versions of wii64 and probably not64 made games look blurrier but that was resolved in later versions of not64 at least.

To me the text (dialog text) looks blurry on the third version. I do not have a capture card so I can't capture clean screenshots of it.

Update:
The control mapping works good and it saves. I forgot to check the text clarity though. I will after I have tried the older version again.

Update 2: Please ignore what I posted about input lag. This version seems the same or about the same as the other versions and I think the older versions too from years ago. Also, the text looks cleaner to me on this build.

Speaking of the 4:3 option, it may not be perfect, but it's much better than the image being stretched all the way across the screen.

Thank you again. I really appreciate the options I requested being implemented. Will this version work on other motherboards?

fixingthings · 2026-09-09T01:49:36+0100

Vetus_Mundi said:
Using the FB textures option on older versions of wii64 and probably not64 made games look blurrier but that was resolved in later versions of not64 at least.

To me the text (dialog text) looks blurry on the third version. I do not have a capture card so I can't capture clean screenshots of it.

Update:
The control mapping works good and it saves. I forgot to check the text clarity though. I will after I have tried the older version again.

Update 2: Please ignore what I posted about input lag. This version seems the same or about the same as the other versions and I think the older versions too from years ago. Also, the text looks cleaner to me on this build.

Speaking of the 4:3 option, it may not be perfect, but it's much better than the image being stretched all the way across the screen.

Thank you again. I really appreciate the options I requested being implemented. Will this version work on other motherboards?

Unfortunately, I don't have another Xbox 360 with a motherboard other than Winchester to test it on, but I bet it would work on other motherboard revisions.

Edit: Please keep the feedback coming, as it's helping me fix issues I hadn't noticed. Thanks for your attention!

Edit2: I'm doing my best to optimize the emulator, considering that, if I'm not mistaken, it's been 13 years since the last Mupen version. I think today's AI coding tools have a good chance of improving the emulator's performance, so I'll keep trying. My main focus right now is improving smoothness in OOT.

Vetus_Mundi · 2026-09-09T01:58:59+0100

fixingthings said:
Unfortunately, I don't have another Xbox 360 with a motherboard other than Winchester to test it on, but I bet it would work on other motherboard revisions.

Edit: Please keep the feedback coming, as it's helping me fix issues I hadn't noticed. Thanks for your attention!

Edit2: I'm doing my best to optimize the emulator, considering that, if I'm not mistaken, it's been 13 years since the last Mupen version. I think today's AI coding tools have a good chance of improving the emulator's performance, so I'll keep trying. My main focus right now is improving smoothness in OOT.

I would like to thank you as well.

I do have another Xbox 360 console. It is a Falcon (v3). I don't use it much anymore as I have semi-retired it and mainly use my Winchester as it's newer, quieter and runs cooler than the Falcon.

I might test these builds out later on my Falcon but at the moment I don't feel like hooking it up. However if another person wants to test them out I think that would be great.

If xell had hardware accelerated video it would dramatically improve the performance. If I am correct the OpenXDK for Xbox 360 also lacks hardware accelerated video.

I noticed the ppsspp port is using the native default.xex format while mupen64 and nulldc use xell.
It's a shame they weren't updated to run in the standard format. This would have allowed them to run on all motherboard without issue.

fixingthings · 2026-09-09T09:10:38+0100

Vetus_Mundi said:
I would like to thank you as well.

I do have another Xbox 360 console. It is a Falcon (v3). I don't use it much anymore as I have semi-retired it and mainly use my Winchester as it's newer, quieter and runs cooler than the Falcon.

I might test these builds out later on my Falcon but at the moment I don't feel like hooking it up. However if another person wants to test them out I think that would be great.

If xell had hardware accelerated video it would dramatically improve the performance. If I am correct the OpenXDK for Xbox 360 also lacks hardware accelerated video.

I noticed the ppsspp port is using the native default.xex format while mupen64 and nulldc use xell.
It's a shame they weren't updated to run in the standard format. This would have allowed them to run on all motherboard without issue.

I've drastically improved the emulator's performance. Ocarina of Time runs extremely well now, and I still have more optimizations planned! Check out the patch notes in my original post, the download has been updated with the latest version.

As for your suggestions, apparently the issue isn't related to hardware-accelerated graphics, at least according to the AI.

Vetus_Mundi · 2026-09-09T17:33:18+0100

I have only tested a little but, the slowdowns in Kokiri forest are non-existent. Excellent work!

My experience may not be as optimal as it could because I am using a rom that has been modified not only with custom (mostly old Latin with a few changed words to English equivalents) text but also has ar/gs codes using the N64 gameshark code injector which also requires the expansion pack.

In saying all that, the emulator does not recognize the rom because of checksum changes so it won't apply settings from the database file when running the game.

NilGames · 2026-09-09T17:44:35+0100

Todas as roms que tento abrir dão erro, alguma coisa estou fazendo errado!

Post automatically merged: Today at 5:45 PM

Todas as roms que tento abrir dão erro, algo não esta correto.

fixingthings · 2026-09-09T18:30:33+0100

I was informed that the files I made available do not comply with the GPLv2 license. I'll correct this and make the files available again soon. If anyone needs them urgently, please contact me.

Post automatically merged: 29 minutes ago

Vetus_Mundi said:
I have only tested a little but, the slowdowns in Kokiri forest are non-existent. Excellent work!

My experience may not be as optimal as it could because I am using a rom that has been modified not only with custom (mostly old Latin with a few changed words to English equivalents) text but also has ar/gs codes using the N64 gameshark code injector which also requires the expansion pack.

In saying all that, the emulator does not recognize the rom because of checksum changes so it won't apply settings from the database file when running the game.

I’m not sure I understood exactly. Is there any problem with the modifications I made? If so, please let me know so I can try to fix it.

Post automatically merged: 26 minutes ago

NilGames said:
Todas as roms que tento abrir dão erro, alguma coisa estou fazendo errado!

Post automatically merged: Today at 5:45 PM

Todas as roms que tento abrir dão erro, algo não esta correto.

Qual versão da placa mãe é o seu Xbox 360? Você usou exatamente os mesmos arquivos que estão no ZIP do post inicial, tanto o XeLL Reloaded quanto o mupen64? Você colocou os arquivos em um pendrive?

Xell-Reloaded Build Compatible With All Consoles, Including Winchester

Member

amo vetus mundi

Member

amo vetus mundi

Member

amo vetus mundi

Member

amo vetus mundi

Member

amo vetus mundi

Member

amo vetus mundi

Member

amo vetus mundi

New Member

Member

Similar threads

Popular threads in this forum