feudalnate

By default the only paths available to access are: D:\ (root directory of the currently running executable) T:\ (mapped path to the E:\TDATA\{TitleId} folder, TitleId is specified by the currently running executable) U:\ (mapped path to the E:\UDATA\{TitleId} folder, TitleId is specified by the currently running executable) Z:\ (mapped to the X/Y/Z cache partitions if the XINIT_MOUNT_UTILITY_DRIVE flag was specified when compiling the executable or XMountUtilityDrive() is called manually) W:\ (mapped path to the E:\TDATA\{AlternateTitleId} folder, only available if an alternate TitleId is specified and XMountAlternateTitle() is called manually) X:\ (mapped path to the E:\UDATA\{AlternateTitleId} folder, only available if an alternate TitleId is specified and XMountAlternateTitle() is called manually) Basically it gives you access to your running directory, cache, and the UDATA/TDATA folders specific to your set TitleId/AlternateTitleId's and that's it. If you want general access to the partitions you need to do as the dashboards do and mount the partitions or specific paths yourself Since everything on the Xbox runs in kernel mode, you can call any function the kernel exports as long as you have the function signature or ordinal even if it's not exposed by the XAPI. The way to mount the partitions and create a mapping between a partition and drive letter is to use the "symbolic link" functions exported by the kernel, which is how dashboards get access to these areas #include <xtl.h> #include <stdio.h> /* defines if needed: typedef char CHAR; typedef char* PCHAR; typedef char* PSTR; typedef int BOOL; typedef unsigned short USHORT; typedef long LONG; #define TRUE 1 #define FALSE 0 #define MAX_PATH 260 #define XBOXAPI #define NTAPI __stdcall #define NTSTATUS LONG if using CPP use: extern "C" { ... }; else use: extern { ... }; */ /* Kernel imports */ extern "C" { typedef struct _STRING { USHORT Length; // actual used character count in character buffer (literal string length) USHORT MaximumLength; // total size of character buffer PSTR Buffer; // pointer to character buffer } STRING, *PSTRING, ANSI_STRING, *PANSI_STRING; // create symlink between DOS device object and virtual drive letter XBOXAPI LONG NTAPI IoCreateSymbolicLink(PSTRING SymbolicLinkName, PSTRING DeviceName); // remove symlink, if exists XBOXAPI LONG NTAPI IoDeleteSymbolicLink(PSTRING SymbolicLinkName); }; /* DOS device objects defines */ // disc drive (mountable) PCHAR DVDROM = "\\Device\\CdRom0"; // raw hard drive I/O (not mountable, open a handle with NtOpenFile to access) PCHAR HARDDRIVE = "\\Device\\Harddisk0\\Partition0"; // standard FATX partitions (mountable) PCHAR E_Partition = "\\Device\\Harddisk0\\Partition1"; // title/user data partition PCHAR C_Partition = "\\Device\\Harddisk0\\Partition2"; // system data partition PCHAR X_Partition = "\\Device\\Harddisk0\\Partition3"; // cache partition PCHAR Y_Partition = "\\Device\\Harddisk0\\Partition4"; // ^ PCHAR Z_Partition = "\\Device\\Harddisk0\\Partition5"; // ^ /* NOTE: Extended partitions (homebrew) are not listed here, these partitions are mountable. To check if the LBA48 patch is present you must send a query to NtDeviceIoControlFile to retrieve LBA48 presence status and the extended partition table (see NKPatcher and/or XBPartitioner source code (found on xbins)) */ /* Mounting functions */ // // Creates a symbolic link between a device path and a virtual drive letter // // DevicePath: String containing the complete path to the driver device object // (and any tacked on sub-directory, for example passing "\\Device\\Harddisk0\\Partition1\\TDATA" would mount the TDATA as the root of the specified drive letter) // // DriveLetter: The requested drive letter to mount the passed path to (A-Z) // BOOL Mount(PCHAR DevicePath, CHAR DriveLetter) { // check null path if (!DevicePath) return FALSE; // continue only if valid drive letter if (DriveLetter >= 'A' || DriveLetter <= 'Z' || DriveLetter >= 'a' || DriveLetter <= 'z') { // allocate buffers PCHAR DevicePathBuffer = (PCHAR)malloc(MAX_PATH); PCHAR DriveLetterBuffer = (PCHAR)malloc(MAX_PATH); // check allocation success if (!DevicePathBuffer || !DriveLetterBuffer) return FALSE; // zero buffers memset(DevicePathBuffer, 0, MAX_PATH); memset(DriveLetterBuffer, 0, MAX_PATH); // pack and format the passed variables into buffers sprintf(DevicePathBuffer, "%s", DevicePath); sprintf(DriveLetterBuffer, "\\??\\%c:", DriveLetter); // DOS format // create winnt compatible string buffers ANSI_STRING DeviceName; DeviceName.Buffer = DevicePathBuffer; DeviceName.Length = strlen(DevicePathBuffer); DeviceName.MaximumLength = MAX_PATH; ANSI_STRING SymbolicLinkName; SymbolicLinkName.Buffer = DriveLetterBuffer; SymbolicLinkName.Length = strlen(DriveLetterBuffer); SymbolicLinkName.MaximumLength = MAX_PATH; // request symbolic link LONG Result = IoCreateSymbolicLink(&SymbolicLinkName, &DeviceName); // returns NTSTATUS (long) // free buffers free(DevicePathBuffer); free(DriveLetterBuffer); return (Result >= 0); // NT_SUCCESS check } return FALSE; } // // Deletes a symbolic link between a device path and a virtual drive letter // // DriveLetter: The requested drive letter to unmount // BOOL Unmount(CHAR DriveLetter) { // continue only if valid drive letter if (DriveLetter >= 'A' || DriveLetter <= 'Z' || DriveLetter >= 'a' || DriveLetter <= 'z') { // allocate buffer PCHAR DriveLetterBuffer = (PCHAR)malloc(MAX_PATH); // check allocation success if (!DriveLetterBuffer) return FALSE; // zero buffer memset(DriveLetterBuffer, 0, MAX_PATH); // pack and format buffer sprintf(DriveLetterBuffer, "\\??\\%c:", DriveLetter); // DOS format // create winnt compatible string buffers ANSI_STRING SymbolicLinkName; SymbolicLinkName.Buffer = DriveLetterBuffer; SymbolicLinkName.Length = strlen(DriveLetterBuffer); SymbolicLinkName.MaximumLength = MAX_PATH; // request remove symbolic link LONG Result = IoDeleteSymbolicLink(&SymbolicLinkName); // returns NTSTATUS (long) // free buffer free(DriveLetterBuffer); return (Result >= 0); // NT_SUCCESS check } return FALSE; } and to use this code to mount the title/user data partition (usually referred to as the the E: partition) for example: void Example() { // define the drive letter you want to mount to char DriveLetter = 'E'; // pass the device path and the drive letter you want to link together if (!Mount(E_Partition, DriveLetter)) { // failed to mount ... } // ... code to utilize the E:\ partition here // unmount when done Unmount(DriveLetter); } So if you want to access any other areas than the ones the XAPI provides to you, you will need to mount the partition or specific path yourself. I have a tool here where I was dealing with a bunch of partition and directory stuff if you need an example, the NXDK project has a bunch of kernel function definitions if you'd like to know more about that, and XBMC is fully open source and serves as a good resource for learning One thing I'll mention since I don't know your intent or what you're trying to access and it's something that stumped me for a bit, something I couldn't find a single mention of anywhere is that you cannot access the TDATA/UDATA folders of other titles - even if you mount the partition yourself. There's some kind of restriction in the file system functions that will not allow a title with a different TitleId to access the TitleId folders in TDATA/UDATA that belong to other titles. Any other directories on any partition is fully accessible except the TDATA/UDATA folders of other titles, it's a very bizarre restriction and my solution was to "spoof" the TitleId of my running executable on-the-fly to gain access to these folders - don't know if this is useful for what you're trying to do but I thought I would mention it // typedef unsigned int DWORD; // typedef void VOID; #define XBEBaseAddress 0x00010000 VOID SpoofAlternateTitleId(DWORD AlternateTitleId) { DWORD CertificateAddress = *(DWORD*)(XBEBaseAddress + 0x118); DWORD AlternateTitleIdsAddress = (CertificateAddress + 0x5C); *(DWORD*)AlternateTitleIdsAddress = AlternateTitleId; } Hope this helps

It was to explain (code-wise) why when you select 'flash from CD-ROM' it errors out, not a suggestion to use that method There can be any number of reasons why the chip won't write properly. Bad flash chip, something wrong with the CPLD or the code it's running, bad connection somewhere/fatigued solder joint, bad cable, bad switch, one of the pins/wires to the LPC port is bad, or even that FlashBIOS 3.0.3 doesn't support X2 chips because I was under the impression that FlashBIOS 2.6 was for X2 and FlashBIOS 3.X was for the X3 chips but I'm unsure

Flashing from DVD-ROM isn't going to work unless you have a disc inserted with known BIOS image names present on it and if part of the screen wasn't cut off you could see that the flash from HDD/HTTP is failing because the erase command is failing My guess is the chip thinks flash protect is enabled - could be caused by the switch being wired backwards (seen it before), bad connection on dip switch board, bad dip switch cable, or something faulty on the chip itself Try the flash protect in the opposite direction, boot into FlashBIOS, switch the bank switch to bank1, and then write an 256K image from HDD or over HTTP. If that doesn't work, you can try booting into FlashBIOS and then unplugging the dip switch board - although, I have no idea what the default behavior of that chip is when the board is unplugged. Good luck

Cromwell might boot without a valid EEPROM or could be edited to do so. It's likely some of the 4th generation modchips with built-in settings/recovery menus could boot into their respective menu as well Retail/debug kernels (including modded versions) will panic shortly into initialization without valid EEPROM data, no matter the console revision. 1.6/1.6B revisions won't make it past the bootloader without valid EEPROM data

Week or so back I was doing some testing with various dashupdate.xbe files extracted from some early Xbox LIVE enabled games (Xbox LIVE enabled games were always shipped with a dashboard updater) and ended up finding quite a few different dashboard/online dashboard revisions that I haven't seen listed anywhere, which got me curious about how many dashboard revisions were actually pushed out (on disc, can't exactly know which were pushed over Xbox LIVE anymore) I was looking for a list of Xbox LIVE enabled games and was surprised that couldn't find one anywhere. There are plenty of lists for Xbox games but none seemed to note whether a game supported any Xbox LIVE functionality or not, so before I could look more into the dashboard updaters I had to make a list of games that actually contain them While it's not exactly the most useful list to have anymore, I still think it's something worth archiving and I'm posting this thread to see if others would be interested in helping Personal spreadsheet (my personal working doc, read-only to public) Public spreadsheet (public doc, anyone is free to add to it or edit it) References I've used building this list: Xbox.com (archived, for game XBL feature list) Wikipedia (for initial release dates) mobygames.com (for release dates and back covers with feature list) xboxaddict.com (for release dates and back covers with feature list) gamespy.com (for release dates, sometimes features list) gamescanner.org (archived, back covers with feature list) xbmcxbox blog (grabbed list of games that all contain an uninteresting dashboard revision) ebay.com (back covers with feature list, more useful than you might think) Whether people help or not is up to them but I'll continue to flush out the list. If you want to post the name of a game in this thread that you know has some kind of Xbox LIVE functionality and isn't already on this list then that's fine too

When this guy said "it's my softmod that is preventing the 576i capability" I immediately thought of this guy that wouldn't accept advice about XboxHDM and responded about as well as this guy does. I had to promptly check out of this "conversation". Good luck Dave, if you're brave enough to stick around for this one

Yes, your logic is truly flawless and there is absolutely no technical counter argument that anyone in existence could make. Good luck!

The Xbox doesn't support 50hz output over component. 480p@60hz, 720p@60hz, and 1080i@30hz are the only supported video modes over component. The Xbox will boot with the manufacturing set video mode and settings before switching to what's supported by the cable it detects and attempts to apply user set video settings. Standard AV, SCART/Advanced SCART, and RF were the only officially supplied and supported video cables for PAL region consoles - but you would know this if you learned to read, since this is clearly stated in the Xbox manual.

TjMax for the old Pentium III CPU's is around 85c officially. From what I've witnessed on the original Xbox, at around 82-83c the SMC will power off the console and blink the overheated LED error code. The other temperature reading is for ambient case temp. ("air" temp.), which seemingly has no purpose If your CPU temp. is sitting 10-15c below max while gaming then there's no real issue. Almost everything on the Xbox runs as a 3D application just like games, there's no true "idle" state to compare against If you're concerned with the temperature then you can turn up your fan speed and trade noise for heat reduction but I'm going to agree with Dave and say ~70c coming out of a game is okay

For the older revisions of 2BL there are similar tables of values that are stored and read directly from the BIOS image, sent to the NB/GPU to do calibration and is immediately followed by the memory test. I don't think you're far off on your guess, it's just the strange thing is that the table was moved into the EEPROM instead when older revision BIOS images have a specific table for Samsung memory and another for Micron memory then just does a check beforehand to see what type of memory the system has and uses the appropriate one but in the case of 1.6 and 1.6B models they shoved the table into the EEPROM instead It's like they didn't know if they could get different memory chips in advance when releasing 1.6 revisions? It would have been trivial for them to just update the table in the BIOS and recompile it or just have multiple tables stored for different types of memory like the earlier revisions. Not sure, maybe they manufactured all the 1.6 boards at the same time with the standard 1.6 BIOS pre-flashed to the ROM in Xyclops chip and then just used whatever memory they had on hand then updated the hardware section of the EEPROM accordingly? I stated in my write up that perhaps it had something to do with the model of GPU they used and that might be true too, it's difficult to say. The 1.6 revision boards have always seemed a bit hacky and probably why it has various issues with even retail software I can confidently say that those values in the hardware section of the EEPROM are for memory but I have no idea how those values work when they're passed to the GPU BIOS

For those that are interested I have written some documentation on the EEPROM. There's still a bit of research to do but for the most part it's complete and as far I can tell, is the most robust documentation on the subject. Let me know if you spot any mistakes/misinformation or something I missed https://github.com/feudalnate/Original-Xbox-Data-Structures/blob/master/EEPROM/README.md I would have edited this into my original post but this usergroup doesn't have edit permissions

For the last year or two I've been working on reversing some of the data structures that have been left unresearched or incomplete by the old scene, not to such a hardcore degree as I would honestly like but off and on when I have the time. This spans from what most people have seen me put out like the Xbox LIVE account stuff but I also have an interest in FATX16/32 structuring, the various configuration/datastore sectors at the beginning of the Xbox hard drive, the 1BL/FBL/2BL/BIOS image structures and data packing, XBE header/certificate data, security, and structuring, and the EEPROM data and structuring - the fundamental data types that make up the Xbox Today I completed the EEPROM data structure - well I say "completed" but there are still some things like flags, bitpacking, and a single unlabeled 16bit value to truly finish up all the info on the data handling side of things - however, structurally I have mapped out all the EEPROM data including the notorious hardware section as well as reversing the XConfigChecksum into something much more legible, portable, and simply more correct than what's been sitting on the XboxLinux/XboxDev wiki's for the last decade and a half I didn't really feel posting something like this on Reddit would be the way to go, the constant Twitter-feed like nature of threads just buries information and I have always preferred forums for their organization - and besides, forums are where I started in modding and forums are what I ran/helped run for many years of my modding life Anyway to my point, if you're interested in the structure and/or (partial for now) handling of EEPROM data then I've posted all the info on my GitHub project. This information can be used to parse, edit, or build an EEPROM image from scratch for any revision of the Xbox (including 1.6 and 1.6b models). I'll likely make a tool for people to create/edit EEPROM images at some point but I've got a couple Xbox projects I've been working on for a while and would like to finish at least one of those before starting another and I'll stuff all this structuring information into a table on the project page soon or maybe edit the XboxDev wiki so it's easier for non-programming people to view and understand at a glance Thanks for reading (also, posting this in the general forum wasn't my first choice but this doesn't really fit into the topic of homebrew - it's more so R&D) This paragraph has nothing to do with the subject of my post but I just wanted to say something personal here. I post this kind of information and put out these various tools and answer these questions that most people don't have an answer to for the sole purpose of bettering or further educating and simply just passing on information I know to the few left in original Xbox scene and even though I might come off as such it's never really been an ego or "clout" thing for me with the original Xbox, I've owned an original Xbox since 2001 and it's purely a passion thing. All I'm really after with this hobby of research and modding of the Xbox is to leave the scene with correct information or at least as correct as I'm able to comprehend and express to others, which I'm sure the old members of the early scene tried to do as well. The reason the original Xbox still lives on is because of sites like this and the handful of people that still hold onto their interest of the original Xbox or their passion of tinkering. Some of you may know my username and others may not, I've seen people mention me as this sort of Xbox "guru" or "expert" and I don't know if I come across as such but I can say, there are many things I don't know, many things I feel I'll never know, and a lot of times I feel like I barely know anything but I know objectively this isn't entirely true because there's a lot I know about the Xbox (and Xbox 360 for that matter) and yet it doesn't stop me from feeling dumb much of the time. Everything I know about computers, the Xbox/Xbox 360, data, structuring, programming, etc. is all self-taught and if you want to learn the type of stuff I know then you absolutely can teach yourself these things and it doesn't necessarily need to be on the software side of things, if you want to know hardware then you can teach yourself that as well - push yourself to learn, you are your best teacher. If you're part of the Xbox scene, whether you're a complete noob or have been around forever, whether we've had good/bad interactions in the past or maybe in the future, know that I appreciate you regardless of your knowledge or "status" and know that I hold no negative feelings towards anyone left in this scene and I probably never will. Not entirely sure why I just wrote this rant but hopefully no one minds, I'm just glad I'm not alone in this hobby of playing around with a 20 year old outdated machine

When you tried XBOXSCENE and TEAMASSEMBLY did you pad to 32 bytes? Unlocking with the master password will only temporarily disable security on the drive, if the user password is set (and it is on the Xbox) then only the user password can disable the security state and have it persist through a power cycle. If you are able to unlock the drive with the master password you will need to copy everything off the drive and then send a secure erase command - this will wipe the drive and disable security Try these master passwords //XBOXSCENE 58424F585343454E450000000000000000000000000000000000000000000000 //XBOX-SCENE 58424F582D5343454E4500000000000000000000000000000000000000000000 //TEAMASSEMBLY 5445414D415353454D424C590000000000000000000000000000000000000000 Most UDE2/UXE softmod installers will set one of these as the master password. Here is documentation on ATA/APAPI security states and commands

EvoX M8/M8+ is the most common BIOS used for modchips, TSOP, and softmods (PBL) iND 5003/5004 is somewhat common, usually used by people that don't want to use M8/M8+ or people that need it for it's 128MB memory support or ability to have an external config file X2 is seldomly used aside from people that want to use it with an X2 chip or people that need it for it's 128MB memory support or ability to have an external config file M7 and below is usually used by people that have an old chip/TSOP that they don't know how to update or care to update X3 is used by people that have an X3 chip because of it's embedded configuration/recovery program Debug BIOS' are generally used only by programmers, curious people, or someone using an XDK When you ask for "BIOS revision" what are you referring to? If you mean a retail image then there's only 2 revisions of the bootloader(s) (1.0, 1.1-1.6) - there are variables and offsets that are changed between 1.1-1.6 models but they are more or less exactly the same and not enough is changed to be classified as their own BIOS revision - else if you're talking kernels then there are many Size of a retail BIOS image is always 256KB and the one existing debug BIOS is 512KB. 1.0 consoles have the BIOS duplicated 4 times to fill a 1MB area I suppose the 1.1 MCPX is more common since it was used in more revisions of the motherboard (1.1 and onward use the 1.1 MCPX), the 1.0 revision motherboard is the only revision that uses the 1.0 MCPX southbridge chip. This is more of a production quantity and sales question, not really a question anyone in the Xbox scene can answer Some of the questions you ask have answers with a lot of variables to them, I don't believe anyone left in this scene could answer them all concretely. If you're researching the Xbox BIOS then XboxDevWiki is a good place to start, it offers information and references but there are many unknowns still to be researched

I'm surprised no one has mentioned recovery via modchip. Replace your current modchip with one that has an intermediate interface between startup and when a BIOS loaded, one that supports EEPROM access - a modchip such as the OpenXenium, Xenium, SmartXX, Xecuter 3, etc. can recover the EEPROM. You will need to write a 1.6 EEPROM image, if your hard drive isn't locked then the EEPROM image doesn't necessarily need to be your own but it needs to come from a 1.6 board (untested, would recommend writing the original EEPROM for the board if you have it) You can grab an OpenXenium off eBay for $25 For future reference: 1.0 EEPROM images only work on a 1.0 board 1.1-1.4(1.5?) EEPROM images only work on 1.1-1.4(1.5?) boards 1.6(b) EEPROM images only work on 1.6(b) boards 1.0-1.4(1.5?) EEPROM images can be edited to work between these models but 1.6(b) EEPROM images contain a required hardware configuration data section and must be written to 1.6(b) boards only (perhaps other model EEPROM images could be edited to add this section but it's unclear if this hardware section is board specific or not) Your mistake was writing an entire EEPROM image from another console instead of simply updating the XboxHDKey for locking