[Release] XBlast OS v0.3Beta

Thanks for your answer.
I was aware about the fact that most biosses use a mix of different banks. According to the leaked MCPX code, the xcodes are fetched from bank 0. The original Cromwell and gentoox bios (256MB versions) used bank 3 to find their Kernel, and also had the bootrom ld file setup so that the 2bl was copied from bank 3 to ram. I changed those settings so that both point to bank 0. Xblast_os already worked that way. The modified bios combined with some others in bank 1 2 and 3 work fine in xqemu. (Besides a problem with the controller emulation which is an xqemu issue and not a bios one.) When I tsop flash them on an xbox, they won't boot.
I checked how xqemu loads it's bios files, and it is loading the whole 1MB, so it's not like it's only using 256MB and replicating that area.
So basically, there is something on the real xbox that needs another bank .
I had noticed that xblast_os starts it's 2bl at another address, but it's only the 2 last instructions of the xcode that need to be checked for that. Since it run's on a modchip and on xqemu, I assume there is no problem there.
Do you still have some modchips for sale, or do you intend to produce another batch?
Is it possible to alter the LPC bus behavour on it?
I am trying to modify a chihiro bios so that it run's on a retail mobo with 128MB ram. Without the other 2 chihiro boards connected, it simply isn't showing any video. I remember reading somewhere that your modchip was responding to the commands queuering for the other board id's. It could be usefull for testing the new bios without the other 2 boards.

 

I remember doing this now(I,ve done so much stuff it hard to recollect what was modified). I did it when I moved the 2bl starting offset in the image. I never understood why other BIOSes do it differently. It just make so much more sense to load everything from the same bank image...

That's weird but I think there few MCPX IC revisions in early Xbox consoles. Maybe the supported dumped image in XQEMU isn't the same revision as the one in your physical Xbox console?

No problem there, all other BIOSes use 0x1000 as 2bl starting offset just because MS stock BIOS used that. Since BIOS development, specifically regarding Xcodes, basic init and 2bl unpack is basically dead, I figured I could get back a few bytes of rom space by moving the 2bl right next to the Xcodes (instead of having a gap of nothing between them!).

Frankly I don't know right now... The batch of "Pre-Edition" I have isn't sold out yet and I figured if these don't sell well, I don't think it would be justified for me to drop $3000USD for a batch if I'm left with most of them unsold...

What do you mean by that? XBlast Lite's HDL code respond to a couple of offsets in memory because they need to be addressed at any time while the console is active. However, due to space contraint in the CPLD, there is no user configurable register space...

If I recall well, the XBlast Lite will report 2 things that are Chihiro related. MediaBoard revision and DIMM size. MediaBoard revision is set to "FPGA" (other valid choice is ASIC) and DIMM size to 1024MB. I have absolutely no idea if it's going to be of any benefit to your goal. In fact, it could make things worst as the console is reporting a MediaBoard with 1024MB DIMM when there is none in reality. I just implemented this feature because there was almost no cost in terms of ressource to add it and didn't cause any trouble with normal Xbox operations.

 

Thanks again for the detailed reply.

I figured out the issue with cromwell and xblast os on the real thing. The bios in bank 3 was the original one. Due to that, the TEA hash of 2bl was correct and the thing happy continued the bios from bank 3 instead of overflowing to address 0x00.
So, if I understand correctly, you still have some Pre-Edition modchips for sale?
Altering the HDL code might be needed to change the DIMM size. Besides that, I am very interested to learn how programmable logic works. The tools probably aren't free and it wouldn't suprise me if you needed a special programmer to program it.
I studied the xqemu code a little more. Basically, there aren't much differences between it's xbox and chihiro code.
The memory is 128MB on chihiro and 64MB on xbox.
It also responds with fpga or asic and reports a dimm size of 128MB
The 2MB additional mediaboard rom is loaded as a slave drive at an offset of (dimmsize * sector) size.
This seems to be how the chihiro bios sees the original mediaboard code.
I created a drive image of 128MB * 512 = 64GB and appended the fpr21042_m29w160et.bin to the end of it twice. The reason I did it twice was because xqemu originally had a 4MB ram buffer for it.
When I load that drive in xqemu, I can run the modified chihiro bios on the xbox. I just added the code from chihiro that gives the type of mediaboard and size of dimm board.
So, in theory, it should be possible to test the chihiro bios with a real drive connected as slave and your modchip. With a dimm size of 1024MB, you will need at least a 750GB drive to be able to place the fpr21042_m29w160et.bin at the correct sector offset.
I modified a 1.1 retail and installed the additional 4 ram chips. They all seem to pass if I use your os, so I guess there are no shorts. Still wonder if some unconnected pins could be left undetected? Problem is, it's not showing the chihiro boot screen (yet).
So, I'll need to debug on the real hardware to see why it's not working. Doing this with 2 harddisks connected is a more stable setup than doing it with all chihiro hardware connected. There is the base board that comes on top of the xbox board, and the mediaboard is an additional cage that fits on top of that base board. It's very service unfriendly.
I somehow get the feeling I am derailing this Topic. Sorry about that.
The dream is to elimenate the 2 additional boards used for a chihiro and to be able to build one yourself using an xbox and some house and kitchen equipment. (Like the 4 ramchips and a harddisk) It's still a long way to get there, but it keeps me off the street.