BetaArchive Logo
Navigation Home Screenshots Image Uploader Server Info FTP Servers Wiki Forum RSS Feed Rules Please Donate
UP: 0d, 15h, 49m | CPU: 31% | MEM: 3938MB of 9757MB used
{The community for beta collectors}

Post new topic Reply to topic  [ 11 posts ] 
Author Message
 PostPost subject: Xbox OS [Original/360/XBone]        Posted: Sun Sep 30, 2018 1:28 am 
Reply with quote
Donator
Offline

Joined
Sat Sep 09, 2006 6:43 am

Posts
741

Favourite OS
Win10/Debian Linux
Let's talk Xbox!

Disclaimer: I will not provide links to sources, as per forum rules. You can do your own googling.

The Original Xbox Console's Operating System, herein called xboxkrnl, was based on Windows 2000 code. It was designed around a heavily customized Windows Embedded line of Operating Systems.
Internally, the OS consists of the bare-minimum boot code to transfer from x86 POST up through switching to protected mode and 32-bit kernel mode. The entire kernel exists within the first 1MB of system RAM once it's fully booted.
Note: There are security systems in place that have been both defeated and bypassed due to failure to read Intel documentation on Microsoft's part. Those are not things that I will talk about in this post, as they are secondary to the main idea behind this thread.

The underlying Kernel was designed specifically for the Xbox. There has been lots of speculation as to whether or not the OS was completely written from scratch, or if it was simply a modified form of the NT kernel. During my own research, I compared the source tree directories and files stored within to the Windows Research Kernel, and found that, for the most part, NT and XboxNT are very close cousins. A large amount of core services were ripped from the NT source and given a home within the Xbox OS. That isn't to say that those services weren't modified for a low-memory environment, though.

The OS was designed from roughly 1999 through 2001, with Alpha SDK kits going out early on in 2000. These kits were basic PC's with a specific target hardware feature-set. The earliest of the SDK's, which seem to have never appeared up for auction, were AMD-based systems. Due to Intel offering a lower price (a deal) for processors, subsequent SDK machines came with Pentium III's. nVidia provided the graphics chipset for all the machines. Even after AMD was dropped for processors, their AMD-760 chipset was kept around for the final hardware design. The Alpha II SDK, however, utilized an Intel 440BX chipset, with a standard Intel Desktop motherboard.

These Alpha SDK's utilized a Windows98 DOS7.1-based loader to get up and running. The earliest form of the Xbox OS was chain-loaded via DOS. From 16-bit land to 32-bit land, Xbox was just any other NT. Included on the recovery disk for the Alpha II (Build 3146), are DOS files, as well as an xboxldr, XboxKRNL, and various support files for the Xbox dashboard, as well as a debugger.

One of the biggest differences between NT and XboxNT is the lack of a Windows directory, separate driver files, and/or any external resources for the running kernel. Everything that is necessary to run the kernel, drive devices, etc., is stored within a single kernel executable. This was by design, as their target ROM size was 256kb. They did use compression (Specifically LZX) to make use of the lack of ROM space more efficient, which allowed the compiled kernel to exceed the small constraints of 256kb. As part of the security system, they moved the real 16-bit bootloader into the nVidia MCPX chipset, put a dummy, highly-compressible fake bootloader in the ROM, which would get overwritten at boot time in memory, and added a 32-bit bootloader to the top of the ROM to bootstrap the 32-bit kernel. This allowed for a very quick startup, as nothing was needed to be stored on optical or magnetic media for the system to boot into XboxNT.

*XboxNT is what I call the OS. I haven't seen it known as such in official documentation, but it IS a possibility that it was known as such within Microsoft

The kernel revolves around an embedded x86 target with DirectX capabilities. It may have been the most successful NT product/project prior to Windows XP. Under the hood, DirectX 8.0 was targeted, fully utilizing all the hardware functionality provided within the Geforce3 embedded chipset. nVidia also provided an early preview to the nForce Soundforce audio processing unit within the chipset. (Of which, is only now being researched heavily due to emulation efforts; It has a dedicated Texas Instruments DSP, with lots of intricate features that not even nVidia or Microsoft ended up utilizing).

The original name for the project was the "DirectXBox". The entire reason for its existence was to utilize DirectX for a dedicated gaming machine

Inside the kernel, several drivers and services are cut down so that the system does not need external resources to run - no Registry, for instance. This is what makes it one of the most efficient NT-based OS's ever. It only does the bare minimum to give a sane execution environment. Several services that would normally be provided by Windows, like directX runtimes, aren't present. The compiled games contain the majority of the code for DLL's, which allowed an older Xbox to continue doing new tricks. This design was not replicated for the later consoles, however. Perhaps it was due to a worry of security - allowing a user to modify a game's executable with their own libraries would provide an easy path to exploiting the system.
This also allowed newer games to utilize the hardware on a lower-level than the normal NT ecosystem would allow.

Interestingly, however, video drivers are provided in the kernel, stuck at whatever version nVidia was up to at the point in time that the kernel was compiled. As far as I can tell, nVidia was already done with providing support for the Geforce3-based chipset by the time the Xbox launched - late 2001. Even though they continued to release Detonator drivers for desktop-versions of the chipset, the stable-state that the Xbox provided shows just how little changed within the DirectX 8 era.

The Xbox only has 64MB of RAM to use. This includes just 16MB sectioned off for graphics memory, 1MB for the kernel, and the remaining 47MB for game code to execute in. This does not take into account the Swap space on the hard drive, which consisted of 3 partitions of roughly 700MB. Several games were written to fit within that 47MB space, while others -- typically the ones that really shined above the rest -- used the swap partitions as a cache for storing large files from the game discs temporarily.

The original Xbox could not have benefited much from DirectX 9, as the hardware feature level was stuck in version 8.0. That didn't stop developers from trying to exploit low-level hardware features to utilize DirectX 9-era/style shaders. Most of the later titles pushed the hardware to the limit. Halo 2 was one of these titles, that, even when released, didn't play well on the hardware due to the constraints of 64MB of RAM. Developers of Halo 2 have said that the game really only ever ran perfectly on DevKit Xbox's, which had 128MB of RAM, allowing for an additional 64MB of space for game code. There was no additional allowance for texture memory, however.

As the Xbox aged, the final Xbox Development Kits came with newer libraries, of which could be linked with a game, to provide newer experiences on the old hardware. This allowed the old hardware and underlying Kernel to become host to new code.

With the Xbox 360, came a complete departure of sorts. NT on PowerPC had been done before, during the NT4 era. Apparently that development had not ended internally, as tooling up for the Next Xbox was done quickly, and Apple PowerMac G5's became the basis for Xbox development, now powered by DirectX 9.0 features, using an AMD R500-based chipset. The Xbox360 OS is something that I haven't spent much time researching, but it does appear to be based on NT5 from a cursory glance. Given the timeline of OS development, it is likely based on NT5.2 (2003) code, and, like the original Xbox Kernel, is designed to run within a small footprint - 16MB this time around. However, given the security systems in place, a kernel backup is always present, as is the entire dashboard, so that size quickly diminishes to 12MB of usable flash storage. Later Xbox 360 consoles came with 256MB flash ROMs to store the entire dashboard in ROM, and provide storage for an entire Kernel + Dashboard backup in flash.

The Durango was a complete departure yet again. This time, Microsoft chose to base the Xbox kernel off of Windows 8's kernel. For the earliest Durango SDK, they simply took an interim version of Windows 8.0/8.1, stripped out the Win32 Subsystem, and placed in the Xbox Subsystem, based on DirectX11. The Xbox Subsystem at this point in time, was a culmination of the Xbox 360 OS Services, DirectX, and drivers for all the hardware in the system. The underlying OS is anything but stripped down - at least the devkits appear to be completely off-the-shelf components. Granted, they added security layers upon security layers in the actual final product. The original Durango vision was a PC-based machine with several layers of virtual machines to run the kernel and system services off of.

During Windows 8.1 to Windows 10, the Windows RunTime sub-system was under rework and re-development. Alongside WindowsRT, the Xbox SubSystem was developed as another flavor of RT. The Xbox One runs a Windows 8.1 through 10 base kernel, followed by several encrypted hyper-v containers for every program in user-space. This allows for the hardware to change over time, yet provides a stable target for developers of games and apps to develop for. As of writing, Windows 10 RS5 is set to launch any day now, and as per buildfeed.net, the Xbox One is also receiving RS5 any day now.

Microsoft has shifted Xbox OS development to a SubSystem of the NT OS. It's been quite a ride, from having to develop for a hardware target, to now having to develop for a software target. The underlying hardware means less today than it did 17 years ago when the project got going. Virtualization has helped push the boundaries of the entire gaming ecosystem.

_________________
Need disks scanned in the USA? I have a Kryoflux, and am willing to help get your disks archived! I also offer xbox and xbox 360 repair and modding services. PM me for details!


Top  Profile  WWW
 PostPost subject: Re: Xbox OS [Original/360/XBone]        Posted: Tue Oct 02, 2018 12:07 pm 
Reply with quote
Donator
User avatar
Offline

Joined
Mon Nov 20, 2017 6:52 pm

Posts
51

Favourite OS
Longhorn 4074
The Xbox wasn't the first game console to be capable of running a Windows operating system and have DirectX features, the SEGA Dreamcast allowed developers to use Windows CE as the environment and utilize its DirectX APIs. It wasn't that well received, but specifically PC developers used it to make porting PC games easier. It's very interesting to see how the SEGA Dreamcast was Microsoft's testbed for their eventual Xbox console.

_________________
MCSA: 70-410, Currently studying for 70-411
MTA: 98-349, 98-365


Top  Profile
 PostPost subject: Re: Xbox OS [Original/360/XBone]        Posted: Fri Oct 05, 2018 12:04 am 
Reply with quote
Donator
Offline

Joined
Sat Sep 09, 2006 6:43 am

Posts
741

Favourite OS
Win10/Debian Linux
DanielOosterhuis wrote:
The Xbox wasn't the first game console to be capable of running a Windows operating system and have DirectX features, the SEGA Dreamcast allowed developers to use Windows CE as the environment and utilize its DirectX APIs. It wasn't that well received, but specifically PC developers used it to make porting PC games easier. It's very interesting to see how the SEGA Dreamcast was Microsoft's testbed for their eventual Xbox console.


The Dreamcast ran on a heavily customized version of WindowsCE, which was a cut-down version of Win9x. I'm not entirely sure on the specifics for the underlying OS, but I suspect it was 9x based and not NT. As far as I recall,it didn't utilize DirectX, but OpenGL, via the PowerVR chipset. I don't believe that the underlying WindowsCE kernel exposed any DirectX API's, but I could be wrong. It wasn't well received in the US, but thrived for quite a while in the Japanese market. It also powered an entire generation of Sega Arcade machines, until the Chihiro came along (which was, in fact, a debug-kit Xbox connected to a Jamma interface and GDROM drive).

Edit: did some more research. The Dreamcast did support DirectX, but it also supported OpenGL for platform-specific releases. The disadvantage was a slight performance hit, but it was preferred since it made porting games a lot easier and cheaper.
-----

nVidia utilized the Xbox as a test platform for their upcoming nForce chipset. Microsoft utilized it as a means of utilizing its software IP in hardware form. It was a good deal for both companies. Sega didn't get the market backing that Microsoft could have provided, especially in the US market -- and it's likely because Microsoft had already begun on their own game console, using newer embedded OS solutions that wouldn't become part of the WindowsCE/Windows Mobile toolchain until 2003, with Windows Mobile 2003, which was the first NT-based Windows Mobile release.

At the time of the DirectXbox's creation, Windows 98 had just shipped with DirectX 6, and development had begun on the next version which would help push DirectX into a targeted platform for GPU and audio chipset manufacturers. DirectX 7 shipped with Windows Me, with DirectX 8 following not too long after. The final hardware utilized DirectX 8.0, and not the later 8.1, which would be supported in later cards from nVidia, like the GeForce 4. The silicon in the Xbox is an embedded cousin of the original GeForce3 chipset (not the Ti 200 or Ti 500 variants).

_________________
Need disks scanned in the USA? I have a Kryoflux, and am willing to help get your disks archived! I also offer xbox and xbox 360 repair and modding services. PM me for details!


Top  Profile  WWW
 PostPost subject: Re: Xbox OS [Original/360/XBone]        Posted: Fri Nov 16, 2018 1:36 pm 
Reply with quote
Donator
Offline

Joined
Sat Sep 09, 2006 6:43 am

Posts
741

Favourite OS
Win10/Debian Linux
As I delve further into researching the underlying libraries that the Xbox OS was built on, I've come to find that the shipped sdk includes are from NT5.0. It's interesting to see some form of confirmation that XboxNT was a form of the Windows 2000 kernel - which had limited Embedded application, short of "Windows-Powered", which was itself just an addon for the Workstation SKU, and not a Platform like NT4 Embedded was.
The DreamCast differed in this area, as it utilized a compacted version of the WindowsCE kernel, of which was completely separate from 9x or NT. It was platform-targeted, with very little libraries stored in ROM, and each game would come with an executable with the kernel linked into itself. The DreamCast itself didn't run WindowsCE, but a limited firmware that offered pre-boot capabilities, and full hardware control. WindowsCE provided a HAL along with DirectX API's to control the underlying hardware. It required that the underlying firmware provide bootstrapping, and basic hardware IO functionality. It was also capable of running its own software, running in OpenGL on the PowerVR chipset. The DreamCast was a testbed of sorts for Microsoft - while not footing the bill for hardware design and marketing.

The XboxOS was all that the Xbox came with, in regards to ROM. The Xbox does very little in hardware to boot the system, which is comprised of only the 1st bootloader and 2nd bootloader, hidden in the MCPX chipset. The 2nd bootloader only executes after ROM contents are verified via a cryptographic key stored in the MCPX. There's safeguards in place both in hardware and software to prevent reading of the MCPX ROM, which is one of the issues with emulation of the Xbox. As of writing, there is no way to pull the 1st and 2nd REAL code from the MCPX, as one of the safeguards is to mask the real MCPX ROM by overwriting it with a fake 2nd bootloader stored in the ROM - And, as it stands, the only way to pull this data would be to write our own crypto-signed 1st bootloader that is signed with original Microsoft keys, which no one has except for Microsoft themselves.

There are two projects with two different takes on emulating the Xbox.
Cxbx-Reloaded, which 'simply' patches game executables with corresponding Win32/DirectX API's. Under the cover, however, Cxbx-Reloaded includes its own implementation of the Xbox Kernel. They currently have lists of patches for supported and unsupported games, which the software scans through and applies on-the-fly. Many games work, some fully playable. Many games don't work, some crashing the software entirely. System speed no longer affects emulation, as the software tries to run games within the original time spec as the original xbox.

XQemu is a complete hardware emulator. It is designed to utilize all the original MCPX ROM + FLASH ROM software from the Xbox, and provide graphics emulation based on the original NV2A chipset in the Xbox. So far, it provides incomplete 1:1 emulation of the Xbox hardware. Currently missing is sound support. This is due to the fact that the emulation is based entirely on clean-room reverse engineering, and not utilizing patching of executables like CXBX utilizes. Upon starting XQEmu, you need to have the MCPX ROM, and an XBOXKRNL of some sort - one of these components is hard to come by, and is currently not available via any software means. The XBOXKRNL can be sourced via Cromwell, a linux-based drop-in replacement. Unfortunately, Cromwell does not provide DirectX API's, so only homebrew apps written against the Cromwell API's can execute.
The issue here is legality. Microsoft made it extra hard for reverse engineers to implement the Xbox in software. From this standpoint alone, Cxbx-reloaded is legally in a good spot. It doesn't use any Microsoft code. It is clean of all possible legal issues regarding using ROM from an actual Xbox console.

At this point in time, Microsoft has announced the next Xbox, code-named Project Scarlet. They're currently claiming backward compatibility. Whether or not that just means Xbox One backward compatibility, 360 compatibility, or Xbox OG compatibility, no one can be certain. There's currently speculation that it means 100% compatibility. This has yet to be confirmed, but it could mean that Microsoft is actively developing a 1:1 Xbox compatibility layer for the modern Windows 10 Embedded platform that the Xbox One runs off of. Should that be the case, work on reverse-engineering the Xbox Next's software should be considered, as it should be possible to rip the packages from the Embedded platform and migrate them to a running Windows 10, thus providing a semi-legal, fully Microsoft-implemented emulator.

The next question is whether or not Microsoft will provide this support in the Windows 10 Xbox app itself. Whether or not Project Scarlet will include porting this functionality back into the Windows 10 ecosystem is a big question - they may actually provide emulation of Xbox and Xbox 360 titles on the PC. It's a slim chance, but one that may be part of Microsoft's plans for the continued development of Xbox products.

_________________
Need disks scanned in the USA? I have a Kryoflux, and am willing to help get your disks archived! I also offer xbox and xbox 360 repair and modding services. PM me for details!


Top  Profile  WWW
 PostPost subject: Re: Xbox OS [Original/360/XBone]        Posted: Tue Dec 18, 2018 3:08 pm 
Reply with quote
Donator
Offline

Joined
Sat Sep 09, 2006 6:43 am

Posts
741

Favourite OS
Win10/Debian Linux
The more I look into the "XOS" kernel, the more I learn C syntax, and see some interesting bits.
First and foremost, internally, the Xbox OS is named XOS. It is a lightweight version of the NT5 kernel, which also utilizes minimalized windows NT 4 drivers for hardware.
The bootloader has code to boot the kernel from DOS(!!)

The Alpha I and Alpha II machines actually did boot the kernel from DOS, and included an xboxrom.bin on the update CD's. I believe it may be possible to boot the kernel from DOS - however, the kernel expects certain hardware at certain PCI slots, or it will panic and crash. I really should have kept my Pentium III system around for testing :(

The kernel assumes an Intel 440BX chipset is in use -- even within nVidia-code; The MCPX chipset was an intel 440BX-compatible chipset, despite the assumption that it had been an AMD-specific design. There are bits and pieces of leftover AMD-targeted code, but it's either unused or so generic that any x86 chipset will run it.

Ultimately, XOS is a very lightweight NT-like OS, but its own variant that only uses some parts of the Native NT code to bootstrap the system. Upon loading the kernel, the system is immediately running the Xbox Subsystem, and does not utilize any Win32 API's. Almost all API's are provided by program executables - XAPI is linked against the kernel, but is exposed in various versions in programs themselves.

_________________
Need disks scanned in the USA? I have a Kryoflux, and am willing to help get your disks archived! I also offer xbox and xbox 360 repair and modding services. PM me for details!


Top  Profile  WWW
 PostPost subject: Re: Xbox OS [Original/360/XBone]        Posted: Tue Dec 25, 2018 1:57 pm 
Reply with quote
FTP Access
Offline

Joined
Tue Feb 13, 2018 2:27 am

Posts
18
This is quite the read. It's pretty interesting how they manage to fit everything in such a small space digitally. I feel like its becoming more of a lost art with the massive storage space we have now days.

I do have a question though. Is it possible to modify the Xbox's OS to be able to run on a regular PC, or is that just technically impossible?


Top  Profile
 PostPost subject: Re: Xbox OS [Original/360/XBone]        Posted: Tue Dec 25, 2018 7:59 pm 
Reply with quote
Donator
Offline

Joined
Sat Sep 09, 2006 6:43 am

Posts
741

Favourite OS
Win10/Debian Linux
There were efforts years ago to implement the xbox api into Windows. I don't think they ever got anything working, though.
Technically, it might be possible, albeit very, very hard to implement. The XAPI is undocumented. The few efforts to document it are typically found in Cxbx-reloaded, which is the only somewhat fully-working emulator for the Xbox on Windows, aside from whatever it is that Microsoft has planned with Project Scarlet.

The original xbox hardware, despite it being based around PC hardware to a degree, is customized enough to be a completely different animal. It's an embedded x86-compatible platform, and expects certain hardware at certain places - pci hardware, video hardware, memory, etc. There's lots of layers on top of the OS intended to verify that the code is secured, too. It's not as simple as dropping the kernel in to an embedded Windows and turning the machine on. Lots of little dependencies that things like XQemu emulate are necessary to get things going.

That isn't to say that it's impossible, but the work needed to make it function with what would be thought to be minimal effort is immensely difficult.

The xbox has its own variant of NTLDR in 3 parts. It has a 16bit preloader, a 32bit bootloader, and a 32bit verify stage bootloader, which checks the keys of the system against a key stored in the hardware (MCPX). If one of these stages fail, it doesn't load. Getting the appropriate keys is the hard part. Having one key isn't enough - there's a chain of trust between all the bootloading components.
The preloader has a key, the bootloader has another key, and the "2bl"- the 32-bit verify stage bootloader, has - you guessed it - another key.

The device drivers are a whole other level of complications. The original kernel builds off of a customized nVidia driver. It has special tie-ins to the underlying kernel. From my research, it looks like Microsoft took their basic video driver from the DDK sample, and customized it to utilize nVidia's customized driver. It's a mix between Windows NT4 and NT5 drivers - likely due to the lack of a registry to store settings in. NT4's driver model is much simpler, but also a lot more temperamental to hardware changes. Everything is hardcoded.

The lack of a registry means that everything is tightly knit around the xbox hardware. Taking the hardware out of the equation and building upon this NT-like system might be possible - but again, the amount of work necessary would likely be negated by other attempts at implementing the XAPI on top of Windows - which, is very likely why Cxbx exists in the first place.

_________________
Need disks scanned in the USA? I have a Kryoflux, and am willing to help get your disks archived! I also offer xbox and xbox 360 repair and modding services. PM me for details!


Top  Profile  WWW
 PostPost subject: Re: Xbox OS [Original/360/XBone]        Posted: Thu Dec 27, 2018 3:24 pm 
Reply with quote
FTP Access
Offline

Joined
Tue Feb 13, 2018 2:27 am

Posts
18
Thanks for the fairly detailed answer. I figured hardware could be an issue, I just didn't know to what extent. It seems Microsoft really took all of the steps here to ensure the system would function well with the limited resources it had.

As far as emulators go, do you know how Microsoft is getting original Xbox games to play on the One?


Top  Profile
 PostPost subject: Re: Xbox OS [Original/360/XBone]        Posted: Thu Dec 27, 2018 8:34 pm 
Reply with quote
Donator
Offline

Joined
Sat Sep 09, 2006 6:43 am

Posts
741

Favourite OS
Win10/Debian Linux
Microsoft has provided no details on their project. We don't know if they're just using the old 360 emulator, or if it's a native emulator using hyper-v. I'd guess that they're employing a highly customized hyper-v implementation for optimal results, which is why it's taking so long to get it going.
The 360 emulator for OG xbox was sub-optimal, as it required profiles, on a per-title basis. In some cases, xbox live would pull a different executable for the game, in xex format.
The xbox one's architecture utilizes hyper-v containers for everything it runs. The dashboard runs in one container, games, apps, etc in others. It's likely that they will employ this in their OG Xbox offering, in a customized hyper-v variant.

_________________
Need disks scanned in the USA? I have a Kryoflux, and am willing to help get your disks archived! I also offer xbox and xbox 360 repair and modding services. PM me for details!


Top  Profile  WWW
 PostPost subject: Re: Xbox OS [Original/360/XBone]        Posted: Tue Jan 08, 2019 10:32 pm 
Reply with quote
Donator
Offline

Joined
Sat Sep 09, 2006 6:43 am

Posts
741

Favourite OS
Win10/Debian Linux
Continuing on other fronts of research, I've begun decoding the XE format, which the Alpha II used, as well as a title that was found on the ftp. It's not quite a Windows PE32-format format. It doesn't follow the spec. I've managed to get a bit of 010 template magic to figure out the file format. It appears that several bits are either hard-coded in the file header, which does not apply to the PE format. It also does not have the old DOS MZ header, and starts in the PE header itself. Then there's a few sections of the PE header that are missing entirely. I started from the shipped 010 template for EXE files, which may not have been the most ideal starting point, but it does make it easier to remove things that are outright missing from the XE specification.

At this point, I've isolated the sections, and verified that the data stored in those structures is valid. VirtualAddresses, for instance, point to the right places in the file for the section data.

On the section data - the values for the NumberOfSections are not located in the main header, like the PE format - they're located in 3 repeating regions of the XE - at 0x44, 0x46, and 0x48. Using two samples of this file format has helped in seeing differences between the alpha XE format and the (presumably) debug XE format. Then there's a chunk of data between the header and the sections start, which I'm unsure of. It contains the appropriate NumberOfSections data, and a bunch more data that I have yet to determine.

Ideally, knowing the format would allow someone (not me) to write a converter to the standard XBE format, and potentially make these samples run under in an unsigned xbe loader (CXBX-RELOADED, XQEMU). Or at the very least, analysis would be possible in a tool designed for XBE's. Documenting the file format may be beneficial for preserving historic builds of games that we have here at BA, and for future leaks (should there be any).

_________________
Need disks scanned in the USA? I have a Kryoflux, and am willing to help get your disks archived! I also offer xbox and xbox 360 repair and modding services. PM me for details!


Top  Profile  WWW
 PostPost subject: Re: Xbox OS [Original/360/XBone]        Posted: Tue Jan 08, 2019 11:29 pm 
Reply with quote
Donator
User avatar
Offline

Joined
Mon Nov 20, 2017 6:52 pm

Posts
51

Favourite OS
Longhorn 4074
Have you seen the recent XenonWiki? It's a new Wiki dedicated to documenting the 360's beta operating systems and hardware, and recently they have released a guide how to build your very own PowerMac G5 "FrankenXeon", along with a hard drive image of XenonOS for the Alpha G5 kit. Apparently it is capable of emulating Original Xbox titles too, but it's far from perfect and likely won't work well with a majority of OG titles, if even at all.

_________________
MCSA: 70-410, Currently studying for 70-411
MTA: 98-349, 98-365


Top  Profile
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 11 posts ] 




Who is online

Users browsing this forum: No registered users and 5 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
Jump to:  

All views expressed in these forums are those of the author and do not necessarily represent the views of the BetaArchive site owner.

Powered by phpBB® Forum Software © phpBB Group

Copyright © 2006-2019

 

Sitemap | XML | RSS