Bowlsnapper

Heh, it's on XBlast aladdins (swapped 1MB flash chip and reflashed CPLD). Open Xeniums have their own OS called XeniumOS. It has basically all the features of XBLast, minus the 128MB test tool. There may a be a few minor differences otherwise, but the main purpose is tat you can FTP, do basic HDD operations and, most importantly, flash a bios to the main banks with it.

Right... Those don't count. lol. Those things are cursed and are a pain. Case in point. I meant a chip that has at least Xblast on it, like an XBlast aladdin (which is modified with multiple banks and has XBlastOS on it) or an OpenXenium with XeniumOS on it (or even PrometheOS)

Interesting. I had this happen once with a OpenXenium in Xenium Tools. I tried again and swapped without issue. If this is repeatedly happening... Maybe just get a modchip with an OS present.

I think what is happening (and @KaosEngineer mentioned this) is that since you are still booting a softmod setup, you are booting with a "Shadow" C partition. Even though you are hardmodded, I think your chip's bios is still booting the exploited/shortcut xboxdash.xbe (because no other dash files are present on E, so it defaults to the stock dashboard) on your REAL C partition. The softmod runs the exploit and boots your modded dash with a fake C partition. You are creating the directory on what is not ACTUALLY your C partition and that is why you are not seeing it when XBlast looks to your REAL C partition. What bios is currently on your modchip? if you are able to boot a disc, I would use the FTP feature, and backup anything you need on that HDD, then format it and install a modded dash (such as XBMC or UnleashX) as well as "set up C" which you should see as part of the main installer options. You will then boot from the E partition. However, to run the TSOP flash, you need to boot with the mod disabled and boot the official MS bios and dash. After that, you can either use the savegame exploit or the endgame exploit to TSOP flash Cerbios to your onboard TSOP flash. Remember, if you're not booting from your TSOP, you will not have access to it in XBlast. Make sure that after your HDD is set up with an installer (including C), you are able to disable the SmartXX chip and boot your stock TSOP MS Bios with your new, un-softmodded MS dash files on C. I cannot find instructions on how to boot with the mod disabled, so you may have to pull the chip off the pin header when you want to boot from your TSOP and run the TSOP flashing exploit(s). Edit: Looks like you resolved this on reddit. Glad you sorted it out. For anybody wondering, this was solved using option 6 on the aforementioned Cerbios Disc "Option 6: Flash Cerbios (Softmod Users)" after choosing the option to boot with BFM. I recommend using netflash to ensure that you can easily flash the newest version of Cerbios.

Now that is weird. Okay. So run an installation disc with the 60GB, use a common dash and try playing the games in a typical structure: F:/Games/(Whatever Game Folder)/. Use NOTHING from the problem setup. Unless you have done that here. In which case... I'm at a loss.

I'm probably gonna borrow from a few tutorials, one of them being the MVG video. I will use the kernel debugger, since I have Cerbios installed on the TSOP and the LPC is free to attach the ribbon to. I will detail it here as much as possible. I will use a USB-C breakout and internalize the serial debugger, with USB-C out at the rear of the console. There is a case modification STL I have that will enable this. The 128MB RAM upgrade is something you will want to do one chip at a time, carefully and methodically. That way if you have a FRAG, you will know it's the chip you just worked on, probably a bridge or lifted pin. Do NOT get solder into the vias around it. This has ALWAYS killed my motherboards and I do NOT know why. You can run XBlast at every chip installation. If XBlast does not boot from your chip and you FRAG, inspect your work. This happened a couple times on this board and there was a bridge on one and a lifted pin on another. Stay tuned!

I figured, "Why not"? Maybe I can learn to code at least a little. I have a spare Halo Edition. Need to build the serial debugger after I finish with the software side of this. https://github.com/XboxDev/serial-usb-adapter

It's worth a shot. I forgot to focus on the fact that this is only with a few actual games. Back to the HDD thing, what happens if you mirror your dash configuration on the other HDD and load a problem game in folder format?

However, XBlast will have a hard time being used because it has to boot with the intended flash area fully exposed. This would have to be a one time TSOP flash. There will only ever be one chance to do it.... Unless a programmer is involved. Or, perhaps XBLAST will see the TSOP and detect it properly regardless of how much is exposed and the proper switch configuration can be engaged after XBlast has booted from its 256K bank.

Yeah, try the other HDD. At this point, it looks like just trying to run ANYTHING from it would be a sufficient test as new files do not seem to wanna run on the current HDD.

AHHH. That's why the time was resetting... It's not a fire hazard, man! Better safe than sorry though, as long as you don't mind unplugging and plugging it back in. I'm glad you were able to set the time through internet and get the issue fully resolved.

Out of curiosity, what is the issue you're experiencing?

Are you cutting power from the mains? I was under the impression that that was the only way to lose time without the clock cap as it's supposed to power the clock circuit if mains power gets interrupted. Maybe it was just never set following the last power interruption. Has it been keeping the time at every boot now? I would get a Nichicon capacitor and put it in there, as those are pretty decent caps and may be more resistant to the same issues that those older cheap-ass caps fell victim to. Or if you want to avoid that, try connecting the console to the internet. Cerbios allows for syncing of the clock through internet, assuming UnleashX supports it also. I know that XBMC does, so I would be surprised if unleash didn't.

It's a part of this package here. https://bitbuilt.net/forums/index.php?threads/xbox-dvd-remote-scan.5917/

Since there is obviously more to converting/porting executables across platforms than what I assume to be the "header", then what was the point of this function? I don't understand it's real life, practical purpose... You need a coding environment to do this properly. At least in the case of XBE to EXE, the purpose in emulation was to get it to run almost natively, although I don't know how involved CXBX was/is as a container. I don't think these executables run standalone... So why was there a "conversion" function if these executables had to be run in an emulator? I am very confused. And in the case of EXE to XBE... I just have no damn idea what that is for. If it's a way to avoid using the XDK, you'd have a hell of a hard time debugging and developing efficiently.

I just discovered ship of Harkinian. I'm about to try out the OOT PC port. I REALLY wish I could program so I could port it over...

I would love to finally replace a temp sensor, too. Well damn!

This happens when you swap the chip before you reach the point where you flash. Make sure that the last XBE has loaded before swapping chips and then hit the button combo or "Write" function to flash. Don't swap the chip and THEN load whatever executable is meant to flash. The bios is called upon every time an executable is launched. You will crash if a blank chip is mounted and you try to launch a piece of software, flashing software included.

For the hell of it, could you try ripping the game from an ISO (Mulleter) and running it on a different HDD? Clean files. Same dash setup. Nothing from the current drive. If it works, THEN copy the game files from the old/main HDD for a problem game and run that file set on teh new HDD, sourced from the old.../main. You know what I mean. lol. Wanna see if it's corruption. That's my idea, anyway.

Sceptre... at least it wasn't expensive. However, I am interested to see why these sets would have an issue with this signal...

Okay, if it is at a cold boot EVER (like the console is cold and things can't be hot yet), then yes, the temp sensor probably needs to be replaced. That is my assessment, but maybe Kaos can add his input as well. It's worth a shot if wanna try. Do you have any confidence to try to replace the sensor yourself, or are you not a very soldery guy?

The fix for a failure of this component is to desolder it and solder in a new one. Cleaning the contacts is not going to fix the component. The bios is not responsible and it is handled at a lower level than bios software. Although, @KaosEngineer is most experienced with all that Edit @fox That could be! @lightwish Is the issue ever at boot from a cold start or is it in the middle of operation?

Kay, so OpenXenium. Download from this link and flash Cerbios 2.3.2. I don't know what HDD is in your console, so just flash UDMA 2 for now, which is the file that does not have any UDMA 4,5 or 6 naming. We'll figure out the HDD part later, but this will at least diagnose the issue. Be sure to leave evox in the boot menu in case you have an issue with Cerbios for any reason and you can switch back. It should theoretically work fine, though. There is ElpisHD available to configure the HD+. This console mods link tells you how and how to boot it as default. https://consolemods.org/wiki/Xbox:XeniumOS Here is the manual: https://www.mediafire.com/file/8pp4o8b0m3yzrcp/Xenium-OS_V2.0_User_Guide.pdf/file

Okay. You running an OpenXenium, or do you not know? I assume an installation service did this for you, correct?

This is the newest version of the installer and is the one I would use. I would select "DHCP and no BFM" at the beginning as long as you are running Cerbios already.