(WIP) New modchip coming in

Hello,

Formatting the HDD with Linux-compatible partitions is possible in Cromwell(so in XBlast OS too). There is already code in there that would require a little effort to properly implement.
However, creating custom Linux partitions (customs as in something other than reformatting the entire HDD after basic partitions: C, E, X, Y and Z) would require rework in the Linux distributions themselves. Since the Xbox HDD does not include a standard MBR with partition table, it's not possible for Linux to determine by itself where would a Linux-compatible (native)partition be located on the HDD. That's why most distribution will only give you the choice between a rootfs file inside a designated FATX partition or native partition install without the possibility of having a F and/or G FATX partition. These choices are hardcoded and synced with cromwell which will checkup all possible cases it knows and boot whatever turns out valid. Then it's the Linux kernel job to make sure it can handle the proper method of running.

With this in mind, I think that putting such effort into this is not worth it. Get a dedicated Xbox to run Linux on it and take the whole drive, problem solved. I know it would be cool to have it all in one device but the fact is that running Linux on the Xbox not useful anymore in my opinion.

I've got to set some limits to which suggestion I take into consideration. It was clear in my mind that the OS for my modchip would not include support for Linux. Source code is freely available, you'll be able to modify it at your will.

However, I do remember about the HDD switching thing. As you say, it's probably not a very popular feature but I might be able to make something that could be "generic". Put leftover IOs of the CPLD on a header port and map them to a register accessible by writing to the LPC bus. Make a menu in the OS that would define output state of each pin depending on the selected bank to boot. You'd be then free to create a small circuit connected to that output pin that toggles a relay (through a transistor please) depending on the booted flash bank. That relay could then switch power between the 2 drives. Others could use this feature as they please; maybe light up some leds depending on the booted bank.

I'll see into this.

 

Benny where can I get one of them? Sounds really great. What are the costs for 2 chips with shipping to Germany?

 

He isn't selling them currently, he's still in the development stages.

 

Oh real pity. But sounds great what this Chip can do.... against that my smartxx looks like garbage.

 

There will be another PCB revision (3rd)!

Thanks to Xphazer from XBMC4Xbox forums for lending me his Chameleon modchip, I was able to reverse the process that makes it possible to do TSOP recovery without pulling wires by hand.

With some modifications to the current XBlast Mod's PCB(adding buffered A15 control line), I am now able to flash tsop_d6.bin to a bank and let the BIOS do its magic all by itself. Just like on a real Chameleon. 100% success rate on a 1.2!

However, there are some catches to this process:
-As most of you know, this tsop_d6.bin bios will not work on 1.4/1.5 consoles.
-Also, tsop_d6.bin magic will not work if Evox M8+ or X2 5035 is flash on your TSOP. I suspect it's because those BIOS are so advanced they either changed the boot process too much(probably by moving 2bl at the end of the image) or custom compressed the Kernel to make it still fit in a 256KB bin file (in M8's case, 512KB for X2).

I also discovered that you can make this TSOP recovery process work by letting the Chameleon(or Xblast Mod now!) control one address line from A12 to A16. Why did they go for A15 specifically if it works on other pins?

Anyway it works now so a new cool feature to add to the list.

 

Benny that is absolutely AWESOME!
I cannot wait to get my hands on some of these chips, They are going to be a dream to work with!

 

Really excellent work, Benny - another brilliant addition to the already feature-rich list!

Thanks once again for all the midnight oil you are burning for us - really appreciate it mate.

Best regards, Mark

 

mmmm i read the entire thread and i think if is possible to add an sd card on your modchip
with more apps encoded inside. i think is good idea bootbios----------cromwellll------search sd------menu screen

 

New PCB revision has General purpose inputs(2) and output(4) ports. You could create a program that access a SD card in bit-banged SPI.


I have created a WTB thread for a 1.4/1.5 Xbox if anyone has a cheap spare to sell.
http://www.assemblergames.com/forum...-Xbox-Original-console-Revision-1-4-1-5-only!

Thanks

 

Chainloading to a bios on sd card? Nice. Maybe chihiro?(probebly not nececary)

 

Too bad you dont need a v1.6. Would have traded one for a mod chip

 

As you write, I dont think it's necessary. Maybe a basic spoof of the mediaboard on the LPC bus could be useful. I'll go ask in the proper thread.

Thanks but 1.6 are easy to find. I already have a 1.6 and a 1.6b.

 

because of the onboard storage (erproms) but maybe you cab add some routines that any request on a certain memory locations on the bus is redirected to the spi (of the sd card connector) so a additional card can do some processing? Maybe a wifi sd card, hacked linux to look like a mediaboard and download the image over wifi? (they cost 33€ or something and im just crazy dreaming here) or a special other board connected to the sd port(spi) and your board redirects requests and data stuff?

 

read an article about xbox memory speed training
not all memory on xboxes run at the same speed
the bootloader do a test to find the most stable frequency,i want to ask if is possible to show memory frequency

 

That's a reasoned approach. 2x2.5" drives and a 3.5 adaptor bracket and I'm in business Benny. U da man

 

it heared the same what bestplayer from germany had made. i got a silverx for that simple switch between two hdds per remote. the only thing i must made by myself is a IDE Cable with 4 connectors. With a button combo for different bioses.

 

Update time between multiplayer games of Halo MCC (I have time to write, this game is really a mess...).

I received the PCBs of RC1 revision. Final design will be almost identical if everything is proven working on these. I will post pictures when I have some assembled, surely this weekend.

During that time, I've been busy adding features:
Added IOs to interface whatever your heart desires.
-2 inputs and 4 outputs. 2 of the outputs can only be toggled when in OS. In the event you would want to hook up a circuit to toggle between 2 HDDs, you wouldn't want some random program changing the state of those outputs while your Xbox is running!
-Evolution-X partial control of the modchip. Reboot to any bank (modchip or TSOP) and flash banks. More info on this another time.
-A19 pad to split 1MB (or 512KB) TSOPs in half. This signal is buffered to override MCPX control of it. No need to cut trace between MCPX chip and TSOP(but you really should if you don't ever plan on returning to a full, unsplit TSOP).
-A15 pad to enable the TSOP recovery trick as with a Chameleon modchip. Buffered too, same as A19.
-Onboard LED that lights up when booting from modchip's bank and turns OFF when booting from TSOP. When using TSOP recovery BIOSes (tsop_d6 or tsop_m7), the LED will turn ON since modchip is accessed to finalize the boot process.
-LCD and IO ports are accessible even when booting from TSOP except on 1.6(b) consoles(how sad!).
-Chihiro MediaBoard *very basic* spoof. Will reply to revision ID being a FPGA version and reply 1024MB DIMM size. Should I change it to ASIC instead of FPGA?

The OS has also seen some improvements:
-Flashing banks from a web server is now working but not finalized.
-Ability to specify static network configuration. Of course DHCP still works.
-Automatic BIOS mirroring to fill the whole bank/chip (ex you want to flash a 256KB BIOS on a 512KB bank).

Some of the work to come next in OS:
-Control IO ports in OS(like select state of output ports depending on which BIOS bank is booted)
-Save and load OS configuration to/from file on C: drive (will have to code write support in FATX driver!)
-Update OS from web. (will have to code DNS resolver and find reliable host so not sure if it will happen)
-Improve 128MB RAM tester to correctly identify a failing chip(not sure if possible, I doubt all upper 64MB could return as failure even if only 1/4 (1 chip) is failing).
-Improve on flashing BIOS process by erasing and flashing sector by sector (or block by block) if the flash chip supports it.


That's pretty much it. I'll update when I try the new modchip.

 

Very nice chip

 

Very excited to see the progress you have made.

 

Bloody hell Benny - this just gets better and better. Loving the way you are incorporating user requests too.

As always and without wishing to sound like a parrot - thanks for your hard work mate.

Cheers, Mark