Since the ReactOS port to Xbox has been recently revived, it's likely that users may want to boot ReactOS in addition to Linux.

@binarymaster has added this support recently here, and those patches should be ported over to this repository.

In the event a display is not attached or something fails very early, it may be useful to support printing debug output via serial port. There is a compatible serial implementation that can be used here: https://github.com/mborgerson/xqemu-kernel/blob/master/src/drivers/serial/serial.c

Ideally the cromwell binaries should include an updated copyright header and more detailed version information (such as partial Git commit hash).

There are several warnings during compilation about implicitly declared functions in various files. These warnings should be investigated to make sure the correct header files are being included.

There is a bug currently where if you have 480p or 1080i mode enable that Xromwell causes the Xbox to go into overheat mode then shutdown.

I have confirmed this with a device that presents as a HD AV Pack on my 1.0 Conexant.

Each XBE contains a 100x17 pixel, 4-bit grayscale logo that is displayed below the Xbox logo after the boot animation. A real XBE will contain the text "Microsoft".

More information can be found here http://www.caustik.com/cxbx/download/xbe.htm##XBELogoBitmap

The Xromwell logo apparently just says "Linux"; the data blob is here.

That isn't suitable as Cromwell is also able to load other software. A similar issue is present in nxdk.
So ideally a logo would be reusable. In case of nxdk the user will likely be able to change the logo through cxbe in the future - in Xromwell probably not.

In general, I feel like the default logo should remain neutral. The original purpose was probably as copyright protection, as also done by Nintendo in their GameBoy cartridge ROMs.
The other purpose is to show that the executable has loaded successfully, so it should not be completely black. As the logo is prominently displayed during boot, it should still be it visually pleasing.
As the "Microsoft" logo was on a black background, we should keep with that style, too; that also means we don't have to use the entire space.

For text style logo, I thought about these: "Homebrew" (a bit lax?), "Unlicensed" (Confusing under Xbox log), "Loading" (Misleading / depending on context), "Loaded" (Misleading / depending on context), "XboxDev" (Misleading, because also non-XboxDev software will be loaded in cromwell, and for nxdk this is even worse), "Xromwell" / "Cromwell" (okay, but still need solution for nxdk), "GPLv2+" (misleading as Xbox logo etc. are not "GPLv2+"), "{GIT revision}" (okay, but a bit cryptic), "Unknown" (very vague), ...
- longer text like "Unlicensed XBE" would probably be too small on some displays. Also it implies that the user knows what a XBE is (or they might think something is wrong with their Xbox). I'd like to avoid terms like "DVD", "Game", "App" or generic terms like "Software".

For a graphics style logo, I could imagine something simple, like dots, some gradient, a horizontal line.

I have installed this bios on XBOX 1.1 with Aladdin XTpus 2 and now it won't let me flash the chip to return to xbox bios.

It does not recognize the bios.bin recorded on CD or DVD.
and it is not entered by telnet.

I would appreciate any help.
thank you .

I'm personally against setting the LED to Orange (which could be mistaken as an error condition), as done here:

We should stick to a green LED, unless the plan is to use orange to signal a "unfinished boot" LED that returns to green once the target OS took over.
However, even in that case I'd suggest a green blinking to reflect what the MS code would do.

• Recently added ReactOS boot support partly implements multiboot support, which needs to be refactored and generalized to allow booting any multiboot-compliant binaries which Cromwell can read from the accessible storage devices
• Refactoring should be done with care to ReactOS boot (it should not be broken, or become more complicated)
• Some multiboot structures are duplicated in LoadReactOS.c and mb_header.h / mb_info.h header files, this needs to be fixed

Booting from flash rom, the video output on 1.6 with XCalibur chip seems to be blank/black..

it works in XBE mode, but not booting from rom.

The system boots and i can see the LED changes to orange etc. but nothing on screen..

any ideas?

I've only recently become aware of these two alternatives (forks of?) Cromwell.

How does this particular fork of cromwell compare? Does it incorporate the features that those forks had added?

Missing program string argument. Will likely segfault:

There's instances in the cromwell code base of cursor offsets that are not aligned on 4 byte boundaries.
The font render code does not check for this and results in incorrect bytes being set in the framebuffer. In some cases it could even result in writing to areas outside of the frame buffer.

As a minimum, this function should check VIDEO_CURSOR_POSX is divisible by 4 and fix before passing the framebuffer pointers.

The most prominent issue of this is the below comparisons in the Text menu titles. The colour should be purple.
Bad:

Cursor Positions Adjusted correctly:

An example of bad cursor position is here. The above example was created by changing X cursor position to 72.

I am trying to use xqemu to emulate an xbox and boot a hard drive image but seem to be running into a cromwell issue. It is a disk image with a single ext3 partition.
I see the following output from cromwell - Does this indicate a problem with cromwell or with my disk image?

hda: QEMU HARDDISK 2.5+ 5.591GB - HDD
Unlock OK - No FATX - MBR
BootIdeReadData data not ready ...
1: Drive not detected

OK ok, not completly.
xbe files works, and there is output for cromwell.bin and cromwell_1024.bin

But xqemu doesnt boot them, it just stays at black screen.
Thanks to the fellows on the Discord we found the gcc version 10 might be the isue here.
As suggested there, ive installed GCC 8, and modified the makefile to point to gcc-8 (Arch doesnt symlink to a gcc version, else CC=gcc-8 make might have worked? Thanks dracc for this idea)

I can build cromwell using gcc 8, but 10 is not so cute.
Using source cromwell-build-20200812-e2d1f85 or git clone.

$ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/ --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++,d --with-isl --with-linker-hash-style=gnu --with-system-zlib --enable-__cxa_atexit --enable-cet=auto --enable-checking=release --enable-clocale=gnu --enable-default-pie --enable-default-ssp --enable-gnu-indirect-function --enable-gnu-unique-object --enable-install-libiberty --enable-linker-build-id --enable-lto --enable-multilib --enable-plugin --enable-shared --enable-threads=posix --disable-libssp --disable-libstdcxx-pch --disable-libunwind-exceptions --disable-werror gdc_include_dir=/usr/include/dlang/gdc Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 10.2.0 (GCC)
a different isue might be:

    5 | #include "BootFATX.h"
  +++ |+#include <string.h>```
or does gcc10 just check more harder? a hex compare between 8 and 10 seems a small shift in code (resulting hash and jumps do reflect the compiler/linker being aware of whatever is happening). 
Does the slowly move towards x86_64 has anything to do with this? I hope I can help narrow down the isue or fix. 

We really need to rename DVD_TRAY_STATE and other globals in boot.h to not look like macros.

This would allow to make such code simpler, and to avoid reassigning framebuffer address (as in here and there) when booting an OS.

Currently video framebuffer address is hardcoded with FB_START value, and does not depend on available RAM. The check for available RAM is performed after video initialization.

Unfortunately, booting cromwell is not possible without a proper MCPX ROM and associated X-code interpreter. Cromwell is not encrypted, but uses the x-code interpreter to do basic system init before exploiting the interpreter to take over control (see Xcodes.h). Therefore we should allow cromwell to host the reset vector and perform Xcode initialization itself in the event an interpreter is unavailable.

Detailed information about the X-code interpreter and reset boot flow is available here: https://mborgerson.com/deconstructing-the-xbox-boot-rom/

My reset vector code is available here: https://github.com/mborgerson/xqemu-kernel/blob/master/src/start.nasm

Note: I will likely resolve this issue myself, but anyone else is of course welcome to work on it.

Since Cromwell and Xromwell is basically the same thing, just loaded in different ways, in the XboxDev Discord we decided to rebrand Cromwell name, specifically:

• Cromwell BIOS to Cromwell (ROM)
• Xromwell to Cromwell (XBE)

The same naming scheme is used in XBlast OS.

See also discussion in #28.

VIDEO_ATTR variable is used to change text color attributes, which is printed via printk() function.

It has 32-bit unsigned value which is represented in ARGB color space, 8 bits per channel:

VIDEO_ATTR = 0xAARRGGBB; // pseudocode

VIDEO_ATTR = 0xFFFF0000; // red color
VIDEO_ATTR = 0xFF00FF00; // green color
VIDEO_ATTR = 0xFF0000FF; // blue color
etc.

Note that the alpha (transparency) channel seems to be not implemented, and its value is always equal to 0xFF in the existing code. Changing the value of this attribute does not affect printed text visually (at least in XQEMU).

All assignments to this variable should be converted into C macros for better code self-documentation.

CI should produce up-to-date binaries that can be downloaded by users.

Setup guide: https://docs.travis-ci.com/user/deployment/releases/

I've tried compiling this with the latest gcc / clang but the code is a nightmare.
Even with old standards it did not compile.

The -Werror and modern sophisticated error-checking don't help some of the 20+ year old code :)

It was brought to my attention that the 2015 xblastos modchip also runs cromwell: https://bitbucket.org/psyko_chewbacca/lpcmod_os .
That cromwell repo seems to have support for modern toolchains (Don't be fooled by the README, check the makefile instead).

I'm not aware which changes were made.

We should consider moving the xblastos branches here too or at least link to it as it seems to be the latest / most maintained version of cromwell.

(Related to #1 )

Currently Cromwell have this terminology for boot devices:

• CD for booting system from DVD drive
• FATX for booting system from FATX (E:) data partition of Xbox
• Native for booting system from MBR formatted HDD, and from any filesystem supported by the GRUB code, which is partly incorporated into Cromwell

This issue is for discussion how we should improve the terminology for better code readability.

Hi
Just tried xromwell on my 128mb 1.0 xbox and it gets as far as initializing usb and just hangs i was interested in trying reactos after seeing a youtube video

startLinux() and startReactOS() functions are different, but they have some similar code that needs to be factored out.

Currently building requires multilib to be installed for certain system headers. We should not depend on such headers.