(WIP) New modchip coming in

As soon as finances permit I will PM you and order one from you benny! Thanks for the reply and that's great news about the OS update! I'm sure we all are looking forward to that!

 

Do you have one ? my xbox is 1.6b halo 2 edition blue ntsc-j 2005 .

how can i buy it from you ?

thanks

 

I sent you a PM good sir (at least i think i did.. AG runs a bit different from what I'm used to)

 

hi, didnt get

 

I sent it to benny.

 

Yay, a new release!

Man it took so much time. Here's the break down of the development since last release...

Developing XBlast OS software isn't like developing a "regular" computer software. For the initiated, it's a baremetal x86 environment with lots of undocumented(or unofficially documented) hardware. There are no premade libraries, no kernel support and worst of all, no debugger support! Unlike developing software with the XDK, you cannot just connect your PC to your Xbox and manually step in the program or even take a peek at the memory content. I have tried to setup XQemu but never got it to work with XBlast OS.

Developing without debugger takes far much time as you cannot spot a programming mistake first hand while executing code. You either need to deduce it by witnessing a bug from a user standpoint and carefully reading back your code or create external testbench programs on your PC with the same algorithm to try and catch the error when running it. Adding new features or fixing bugs usually take more time but the rewarding feeling of success once you get it right is so much better

Fortunately, I have developed a way to retreive detailed debugging data through XBlast Lite hardware. I have set up a bit banging SPI output port on my XBlast Lite's GPIO pads and with a simple arduino board, I can convert this SPI data into serial's which can be read with a terminal emulator, such as Putty or even the serial monitor of the Arduino IDE through a USB port on your computer. You only need a couple of wires and the cheapest arduino board you can find that has a USB port on it(if you don't want to use an external USB-Serial adapter)! I was able to find a Arduino Nano clone with a ATMega168p for less than $2. It works fairly well but in order to not slow down the execution of XBlast OS too much, the Xbox transmit SPI data at a faster rate than what the Arduino can handle in real time. The arduino as a limited dept circular buffer to store incoming SPI data while it converts it to serial. When there's a big data burst from the Xbox and the Arduino can't keep up, there are characters here and there that get dropped. Still, in most circumstances, it's very reliable and helps a ton to debug more complex issues!
I know could have chose a better, faster microcontroller to do the same job but the Arduino is still the cheapest around with USB connectivity, doesn't require an external programmer and has a very easy to set up IDE!

So here's what happened during the last year.
Begining December 2015, I starting working on making XBlast OS build and run using a modern version of GCC. Up until then, I had to develop on a Linux virtual machine with gcc 3.3 sideloaded onto it. Adding back a previous version of GCC on a Linux environment is usually not a piece of cake. Bringing the project to build under the latest version of GCC would add the benefits of me not having to maintain an old build setup but would also bring better code optimization(run faster and take less space) and compilation bug fixes. Since the last version of GCC 3.3 released on May 2005, you can guess a lot of things had changed since then. Then began the trial and error phase. I had to update makefiles, linker script files and bits of code to satisfy the new standards GCC gained on the course of 11 years. After a couple of weeks of changing things around, asking obscure technical questions and reading through pages and pages of doc about GCC and LD, I finally had a compiled binary! Excited, I tried to run it on a Xbox...

I kind of anticipated it but didn't want to believe. Of course it did not work! I was greeted with a green screen on my TV and nothing else. Tinkering with the build process and removing bunch by bunch optimizations that were added to GCC on the course of 11 years, I ended up getting a working bin!!! Without those optimizations though, there were no points into migrating the project to this newer GCC version. I then began to try and isolate the pieces of code that were causing the problem. A few couple of weeks of trials and error, I found the culprit. Some GPU initialization code that did what was intended under GCC 3.3 but was simply removed by aggressive optimization on newer version of GCC because it was identified as useless code. Of course, you can tag code (with the "volatile" prefix) and instruct GCC to not remove it when it thinks it's useless. The problem is that this feature was infectious to sub routines in GCC 3.3 whereas it isn't anymore in newer GCC. When you pass data tagged as volatile to a function, you must now reinstate its "volatility" in said function. It wasn't done this way in cromwell because it wasn't a problem when building with GCC 3.3.
Finding this issue and checking up all the code for other possible occurences took a very long time. Now it's done!

I can ditch the old virtual machine and use whatever newest Linux distribution I want and it will build. I even made it possible for it to build using the 64bits version of the gcc-linux compiler(with ia32 compatibility libraries installed). You can technically take any x64 linux distribution, install a couple of packages to build 32bits linux executables and it will work just fine!

On the side, I also updated Gentoox Loader project with the same changes to make it build under the same conditions as XBlast OS. I also updated its network interface driver as I did on XBlast OS. I know other projects, like Chimp, uses it and I figured it could be of interest.

After all that work, I decided to tackle the whole network part of the OS. Some people had already reported having trouble flashing a BIOS through the web browser. I did find myself in the same situation as I changed my network setup drastically during the year. Netflash would either take an eternity or just not work at all! I also had noticed that my 1.6b seemed to have trouble starting the net interface in XBlast OS when coming from the XBE version.
I found out the "forcedeth" driver used in all cromwell projects originated from a very old version of the now outdated etherboot software. The successor of etherboot, gPXE 1.1 (also outdated...) had a newer version of the driver that seemed pretty close to the one of etherboot in terms of code structure. The changelog also suggested bugfixes that could fix the issues. I wanted an easy port and I figured if it fixed my problem, I wouldn't need to spend more time adapting a newer version that probably add bloat due to it's increased amount of supported hardware. I don't need to support network interfaces that not used on Xbox hardware anyway. After a couple of hours, I had it working, and the 1.6b issue was resolved! Netflash started every time in the XBE version. The only downside is that the interface takes 1 extra second to initialize due to added stabilization delays. Sadly, there were no improvement concerning the bios flashing issue. I turned my efforts on the TCP/IP stack, LwIP.

LwIP is a fairly common network stack for embedded devices. Chances are a some of your IoT devices uses it. Anway, all network enabled cromwell projects seem to be stuck using LwIP version 0.7.2 which was released April 2004! As you all now, the world of computer communications is always changing. I figured bringing back the network stack to an up-to-date state would not hurt. I began integrating lwIP 1.4.1 into XBlast OS. LwIP is a big beast. It contains a lot of code for a lot of network protocols. You can get lost very easily and the documention requires an intricate knowledge of supported protocols you want to use. I spent a lot of time reading documention, tweaking the code, testing changes and sniffing network data. At some point, I got it all working: ARP, ICMP, TCP, UDP, DHCP and finally HTTP! Then, I figured I could also update the HTTP server as Firefox developer tools were always nagging me that the HTTP server used outdated stuff! So I took the HTTP server template supplied with LwIP and coded back the necessary POST data handling code to accept BIOS binary. I even improved on it by adding a text field in which you can supply a custom BIOS name when flashing a user bank from the comfort of your PC's keyboard. Once I got it all working and ready to leave it alone, LwIP 2.0.0 got released! Heck, why not use that one instead?
Then another problem arose. I had random freezes and weird screens artifacts when I compiled with LwIP 2. Weirdest thing was those issue were present at the very start of XBlast OS. I hadn't even initialized the network interface! After some days of tinkering, I found out that due to the increased size of the program by the introduction of the beefier LwIP 2 stack, the linker was now placing runtime data (BSS segments for the geeks here) inside the reserved RAM memory space for the graphics card framebuffer (a place reserved to the graphic cards that contains the raw screen data to be displayed). The weird artifacts were actually parts of my program that were erased as I tried to refresh the frame buffer! Turns out the original creators of cromwell didn't think the whole program would take more than 2MB of RAM space once uncompressed and pushed everything near the top RAM. I moved this a tad further away from the framebuffer and found an interesting bug (still present in other cromwell project) where the initial location of the x86 memory stack pointer is placed in such way it could again overwrite runtime data if the stack of the program was to get big enough. I fixed all that in XBlast OS and what do you know, everything was working again! I now had a fully working system with LwIP 2.0.0 managing all the networking stuff.
A couple of days ago, LwIP 2.0.1 was released lol! Not a big deal, I spent so many days tinkering with earlier versions that getting this one to work only took a few hours!

So with all that, XBlast OS now has updated networking components that work very well with modern browsers (tested Firefox and Chromium). NetFlash worked fine but at that point, I wasn't particularly fond of the flash device driver... it did what it had to do but was hard to follow, had limited expandability and didn't provide much feedback in case of error. I also wanted it to be non blocking. While the (old) flash driver works, the rest of the entire system is halted. Nothing else can work in the background. Ultimately, my goal is to not block the system for any operation to have "background" running tasks like an always ON Web server and FTP server! So on the course of a couple of days/week, I wrote an entire new flash device handling engine that is non blocking and can provide much more insight on how things are going while doing the operation. The downside is that any operation takes a couple of extra seconds to complete compared the old driver. It's a consequence of having it non-blocking. It's been extensively tested on multiple types of flash chips, including the TSOP chips used in Xbox consoles.

With this new flash engine, I decided to refactor how OS settings are loaded and saved from and to the flash chip. I added a setting's versionning structure as well as integrity checking (so to make sure not to load corrupted settings that could harm the system like fan speed set at 0%). This allows, starting from now, to migrate the settings across an OS update, something not possible up until this release. For the next release and then on, you won't need to reconfigure XBlast OS after an OS update, unless you purposedly choose to downgrade your OS version, in which case the system will warn you before attempting to flash your OS if it finds settings cannot be migrated. Settings migration is only possible on XBlast Lite compatible hardware. As the current release is a transitional update, the settings of your current OS version will not be migrated into v0.50Beta.
Finally, I added check ups to make sure settings should be wrote back to flash only if a XBlast OS image is detected on the active flash bank. This is to prevent any BIOS corruption in the event someone would have booted from a bank containing XBlast OS image (on non Xblast modchip) and then switched bank, possibly to flash another BIOS, and forgot to change it back to XBlast OS' bank before saving settings back to flash!

While messing up with settings, I decided to add support for Frosty's VGA mod. In system settings, it is now possible to set the video interface to work with the same VGA mod used in Frosty's patched BIOSes. I previously had worked on Frosty's VGA mod for Conexant video encoder so I had a bit of experience with it. Unfortunately, it's only supported on Conexant video encoder for now. I don't have a VGA modded Focus Xbox nor do I have a Frozen video cable and I want to test it myself before releasing anything. I plan on adding support for Focus encoder but I'll get myself a frozen cable before.

After settings were done tinkering with, I also reworked the "Uncommitted Changes" information menu. It's a menu that displays all the changes made in OS settings and EEPROM that have not yet been wrote back to flash and/or Xbox EEPROM. You get to see the parameter's name as well as the original and newly set values.

After all that, I checked a couple of filed bugs and fixed them.

We've had a brief period of beta testing and for that, I'd like to thank Bad_Ad84, clabs, ToxicMedz, weinerschnitzel, MrMajst3r and professor_jonny over at XBMC4Xbox

Tested the OS on multiple XBlast Lite modchips installed in Xbox consoles of different revisions. Tried the BIOS version on Aladdin XBlast, non XBlast modchips and TSOPs. It works fine in all cases.

And there you have it, more than a year's worth of development on XBlast OS!

 

Thanks Ben !

 

Great write up on your adventures in developing XBlast OS. I really had no idea how much work you had put into this project to make it as versatile and up to date as it is now.

 

Yep it's a challenging process. It's sometime infuriating as you can see in the sources that Cromwell was put together very quickly and some code in it is just plain ugly. I understand they worked fast to get the prize money for providing a way to run Linux on the Xbox back in the days. It's not that the devs were bad, on the contrary, they did an amazing job. They just did not conceive this software to be anything else than a Linux kernel loader. If it worked, it was good enough.

For me it isn't however! I need this soft to be stable all the time. That's why I take the time to rework the code I work with. It's a long process, to understand dirty code, reorganize it and fix potential issues in some cases. I also didn't rework much of it in previous releases and I'm paying for it right now. I wanted something that just worked and I got it but I'm paying the price of refactoring my own code I simply piled on top what was already there. Now it takes more time than if I had done it in the first place.

Sometimes I miss the comfort of a well feature development environment. I tried setting up XQemu as I could debug using GDB but I never got it to work. Maybe someday I'll succeed.
On the other hand, the Arduino SPI "debugger" I made does provide a good way to get runtime data. The only downside is I must always either flash a modchip or transfer the XBE manually onto my dev rig.

In the early days of Cromwell development, they made a device called the filtror that could load up a cromwell image directly onto a flash device from a PC's parallel port. It also had a dedicated RAM space on the device to which both Cromwell and the PC could exchange and read data. Something similar, but more up to date, could be useful but I don't see the necessity of investing time and money in such device when the tools I have right now seem to work out fine.

 

I'm very curious about these xblast chips and modified Aladdin chips....
Which one is the better selection if I'm just looking to play with modified BIOS's? I need to read more about the official xblast chips as well......
How large is the flash bank (s) on the xblast?

Is the Xblast a complete wire install or does it use a pin header like other chips?

How complicated is it to actually install?
Can BIOS files be flashed from other normal means like the X2 flasher or is there a programmer needed?
I'm willing to try one out just out of sheer curiosity honestly, I was looking for a mod chip that supported at least 1 flashable 512 bank seeing as how all the other decent mod chips seem to have gone extinct.

 

You can find details on the XBlast Lite modchip here: https://bitbucket.org/psyko_chewbacca/lpcmod_os/wiki/xblast_lite_manual/About

It supports 2 BIOS banks: 1 x 512KB and 1 x 256KB

 

Looks like a good replacement for my X3 looks like it might even work with the X3LCD I have lying around if I could ever figure out its pinout......how does one go about buying a couple of these?? Just message benny (the op/dev)?

 

I am looking for the CPLD code to turn an aladdin into an Aladdin Xblast device. The post here seems to have a dead link

 

https://assemblergames.com/threads/and-the-aladdin-xt-became-a-decent-modchip.52234/#post-894033

That's the post that lead me here to the xblast any how

 

Give this a try: https://mega.nz/#!OsRAGLoa!DmHussQh4E9y6FhnTxSfBroT1fXgPaSeQ_W0dCtvkrc
rso posted it in another thread -- https://assemblergames.com/threads/mod-aladdin-xblast.55068/#post-940009

bennydiamond's thread, And the Aladdin XT Became a Decent Modchip, has a link that worked for me -- AladdinXT_Newcode.zip -- on 20170704. However, the CPLD SVF files in AladdinXT_Newcode.zip are older than those found in Aladdin_XBlast.zip that rso's link downloads.

[UPDATE] My mistake, you were asking for a new link to Aladdin_XBlast.zip as the original dropbox URL now returns a 404 Error - File Not Found.

 

I haven't seen the second thread yet looks like a good read going to ha e to check it out maybe I'll try one of these chip mods myself while I wait to get my hands k one of these xblasters this xblaster sounds truely awesome honestly

 

Hi BennyDiamond, I hope you're well.

I'm so sorry I just upped and left without buying an XBlast Chip, but I still couldn't work out how to buy Bitcoins, but due to the massive increase in interest in Bitcoin this year, it's SO MUCH easier to buy and send them now. I really wanted to buy one a few months ago, but due to Assemblergames going down, I couldn't.

Any-who, enough of the rambling, if you tell me the total for the chip and shipping (yes... again, I'm sorry), I'll buy some bitcoins and get them sent to you (after a few PM's, obviously).

Also, sorry, noob question (and you've probably already answered this), is the XBlast compatible with (any) 128 X 64 Dot graphical LCD's? My guess is it depends on whether it uses a Parallel or Serial interface (trying so hard no to sound completely clueless).

Okay, seriously, enough of the rambling.

Thank you in advance

Kind regards

Daniel

 

IIRC, the LCD port is only for a parallel character-based LCD screen (1, 2 or 4 line) not a graphical dot-matrix LCD screen.

XBlast LCD information found here.

 

Damn, alright, I guess I'll just get a cheap four row HD44780 LCD of Aliexpress instead.

Thanks for the help, and your quick responce.

 

Your welcome, would make a lot more versatile display if it was graphical.

You need to check the dimensions of any display and make sure it will fit in the space available behind the front panel. Most I've seen are too tall. The PCB sticking out the top and bottom edges make it too high/tall to fit.