Official Microsoft Japan Summit 2005

I remember reading that the OS and other things are located in the 512MB of unified ram. So in actuality Devs only have like 480MB to work with or something like that.
 
Hardknock said:
I remember reading that the OS and other things are located in the 512MB of unified ram. So in actuality Devs only have like 480MB to work with or something like that.

But it has to be stored somewhere to be loaded into RAM on startup, no? The GDDR3 will lose its data if it isn't kept powered.

PC-Engine said:
Can't you have 32MB of flash on board for the Dashboard and OS?

don't see why not
 
Of course the OS will be loaded into RAM at startup, it has to be stored somewhere when the console is switched off though...

Oops, San Greal beat me to it.
 
Here's a picture of the motherboard:

xbox-360-xavbox.jpg


I'm guess there must be more ROM located on the underside that stores the OS.
 
FYI: The Dashboard and OS files take up around ~90mb on my xbox-1. Includes the executables, font-files, related files, and audio files.

x360's dashboard is obviously much more complex, and also include the media extender which would basically act as a TiVo, so I would expect a much larger application than the very simple dashboard of xbox1.

An install of the homebrew software Xbox media Centre, which should have similar fxn's than the the extender, rings in around 108mb. Obviously this isn't very relevant, but it gives some idea of scope.

It would have to be 128 or maybe 256mb of flash memory? Although, I guess it could be compressed, but I still don't see it fitting on 64mb.
 
Nice interview...

Game Informer: This is an impressive list of games and developers that you are announcing today.

Maruyama: That is not the complete list because we have more than what we are announcing today under development. Basically we’re giving a list of 37 companies working on 45 titles today. In reality, we have close to 50 publishers working on around 100 titles. Gradually we’ll be announcing more and more titles closer to the launch of the 360.

http://www.gameinformer.com/News/Story/200507/N05.0725.1321.09238.htm
 
x360's dashboard is obviously much more complex, and also include the media extender which would basically act as a TiVo, so I would expect a much larger application than the very simple dashboard of xbox1.
Maybe... X360's OS will not be weighed down by the legacy crap that the Win2k kernel of Xbox was. Still, the heavy part of it would be content, which is why its memory footprint is so much larger... That and the fact that the user can supposedly customize it and create their own skins and load up their own fonts. The dashboard GUI you've been seeing in screenshots is pretty much identical to the one we've had on Xbox-1 devkits -- it's just blue instead of green.

Also, the API for the dashboard is something that developers are permitted to use, although I don't know if it's a requirement or not. It's entirely feasible that we may publish "themes" on the disc with the games in the "special editions."

Still the main problem of reserving a flash block for the actual memory footprint is just that flash is slow. Reserving a main memory region is really the only way you'll get any sort of performing OS.
 
Maybe... X360's OS will not be weighed down by the legacy crap that the Win2k kernel of Xbox was

Just wondering what you consider that legacy crap to be.......

The only thing that is really left is the process management and some of the API naming conventions almost everything else was rewritten, what's to dislike?

Having worked on both Xbox and PS2, I know which OS I think is better designed and implemented and it wouldn't be Sony's effort.
 
I can't remember the source, I think it was Allard, said the 360 OS would be based on the NT kernel like the original dashboard was.

i just hope it supports filenames longer than 32 characters this time, it sucks when many of your mp3's are over 32 characters and you can't transfer them.
 
The only thing that is really left is the process management and some of the API naming conventions almost everything else was rewritten, what's to dislike?
Actually, the biggest dog would have to be that driver model. DirectX was the one thing worth hating with a passion about Xbox.

Having worked on both Xbox and PS2, I know which OS I think is better designed and implemented and it wouldn't be Sony's effort.
Granted, but that's given you can even consider Sony's work to be an effort worth mentioning.

I can't remember the source, I think it was Allard, said the 360 OS would be based on the NT kernel like the original dashboard was.
That's odd... in the beginning, they were making such a big deal about how huge the improvements would be because of using Longhorn and the new driver model and the CLR runtime and everything. Frankly, CLR is probably the toughest sell of them all -- probably a total failure in the gaming arena. Longhorn Driver Model would be an easy sell, otoh.
 
Allard has said a few times that the 360 OS is based on the Xbox1 OS and that they dind't go back to the Windows codebase.
 
ShootMyMonkey said:
Actually, the biggest dog would have to be that driver model. DirectX was the one thing worth hating with a passion about Xbox.

Funny that you say that, the box was actually named after DirectX

Its the DirectX-Box, it was a codename used by Ed Fries and the other early developers of the console, they never expected it to be the final name but it kept winning in al the focis testing so the name stuck.

Just a little interesting fact.
 
ShootMyMonkey said:
The only thing that is really left is the process management and some of the API naming conventions almost everything else was rewritten, what's to dislike?
Actually, the biggest dog would have to be that driver model. DirectX was the one thing worth hating with a passion about Xbox.

But there is no real driver on Xbox, almost every call just shoves stuff in the push buffer. About the only thing you can't change is the push buffer management and I'm not sure you'd want to if you understood how it worked. We reverse engineered the Pushbuffer format relatively early on, but in the end we used the provided calls to do the compilation.

OK Perhaps I buy not liking the API, but the implementation is about as thin layer as it gets. The only thing that doesn't directly represent how the hardware works is the specification of the vertex DMA streams.

If your going to pick on poor software on Xbox at least pick on the broken stuff. DirectSound is horribly implemented.
 
OK Perhaps I buy not liking the API, but the implementation is about as thin layer as it gets. The only thing that doesn't directly represent how the hardware works is the specification of the vertex DMA streams.
That's odd, because the API overhead is still not lightweight. There's probably a reason why they allow us to bypass it on 360. I don't know if there was still a separation between kernel space and user space or what on Xbox, but there was no significant difference in API call overhead between Xbox and a 733 MHz PC w/ a GeForce3.

Funny that you say that, the box was actually named after DirectX
Well, that's far from surprising, considering it was sort of a proving ground for the then new DX8 API design.

Also, there's nothing new about using "X" in marketing names because it's an easy sell. The general idea is that if you say the letter 'x' repeatedly a few times, it'll come out sounding like you're saying "sex."

Hence, DirectSex, ActiveSex, SexBox, SexNA, SexML... Well, you get the idea.
 
ShootMyMonkey said:
I don't know if there was still a separation between kernel space and user space or what on Xbox

How could you have written any significant code for xbox without knowing this? :oops:
 
How could you have written any significant code for xbox without knowing this?
I haven't... I've only debugged existing code for Xbox, and most of any newly written code has been purely computational. All my experience prior to my current job has been with PCs.
 
That's odd, because the API overhead is still not lightweight. There's probably a reason why they allow us to bypass it on 360. I don't know if there was still a separation between kernel space and user space or what on Xbox, but there was no significant difference in API call overhead between Xbox and a 733 MHz PC w/ a GeForce3.

RTFM.....

Better yet just look at the header files or stick a breakpoint in your code and look at the disassembly in an optimised build. Some calls can be expensive but they are expensive for one of three reasons, either you're copying a lot of data into the pushbuffer (in which case use precompiled lists!) or you've filled the push buffer and you're stalled waiting for the GPU (make the push buffer bigger or use jumps to precompiled lists) to process some of the data or you locked the resource hyou're trying to use and you have to wait for the GPU to finish with it.

I have a racing game on disc here (never published) pushes a peak of somewhere around 30Million polys/second, and finishes submitting all it's geometry in less than 30% of a frame.

There is no seperation between Kernel and user space on Xbox, and you're answers aren't convincing me you have much more than a passing experience with Xbox.
 
Back
Top