News & Rumors: Xbox One (codename Durango)

Status
Not open for further replies.
Why they don't make any interviews about the hardware ? Other guys from competing platforms are talking left and right about theirs , in great detail , but it seems that noone from the XB1 is doing this kind of thing .

Hardware isn't the reason Microsoft is better than Sony, it's the software stack. As for why we haven't seen any more software demos, the Xbox One will be at San Diego Comic Con (along with the PS4), then there's Gamescom, but likely those demos will be locked to games only.

It's not until we get to demo the actual OS that someone will get to experience the differences between the systems, and I have a feeling the OS fully baked yet. Should be around the bend sometime soon anyway.
 
You guys see this on reddit last night?
http://www.reddit.com/r/xboxone/comments/1i71s5/i_am_an_xbox_one_dev_ask_me_almost_anything/
Do you know anything about the rumor that Microsoft is upping the clock speed on the retail version?
Can't comment on the rumor.

It's interesting that he says he can't comment on the downclock rumour but when they ask him about yields:

Let's cut to the chase. Were the yield rumours true? Are they still true? Is there any truth to the upgrade rumours?
Don't know, no official word within the company.

He says he doesn't know rather than he can't comment...
 
Last edited by a moderator:
some questions:

1- Do you think that Xbox One custom Hypervisor is Paravirtualization or Embedded hypervisor?

2- If microsoft wants Xbox One to being Forward Compatible with next version Xboxs how they can achieve their goal? by revision in custom Hyper-V and VMs or what?

3-someone told me that if they change the Hyper-V they have to change VMs, too and therefor the games engine also needs to be changed. Then what's the profit of VMs?

4- I thought that Hyper-V has two API. One of them supposed to communicate whit X1's hardware and anoder supposed to communicate with VMs. While there is no need for to change VMs for X2.I mean somthing like this:

A further argument for using virtualisation in embedded systems is software portability. Application writers can develop code for a generic canonical machine and expect that code to run on any platform that can emulate the behaviour of the original machine, even if the physical implementation has completely different registers and memory maps. This should reduce the cost of porting code to new hardware as only low level firmware needs to change – something on which phone vendors with large hardware portfolios are keen.
http://www.newelectronics.co.uk/ele...isation-in-the-embedded-systems-market/32004/
am i wrong? if yes, then how much?

5- he says that VMs and Hypervisors are the same, is he true?

if you have proper article(s) (academic or ...)about this topics i need them too.

please answer me,at least give me some theorical confirmation that VMs make Forward Compatibllity possible. sorry for bad english !!
 
I really don't think the intent of the VM is backwards compatibility. It MIGHT end up making it easier down the road, but I think the original intent is to not saddle the GameOS with the OS being used to run the Apps.
I would bet that the App/System OS is some Win8/RT variant and that was a requirement (political) dictated to the Xbox team (speculation) and that in order to retain a more console like development experience they had to use a VM to partition resources.
There is a secondary win which is that it makes the app switching and suspend/resume easier to do.

Given the nature of the resource split, it could be an extremely thin virtualization layer, the Game OS could for example always get the same physical memory range.
I'd be interested to know if they made any changes to the GPU to support suspend/resume, or virtualization.
 
I really don't think the intent of the VM is backwards compatibility. It MIGHT end up making it easier down the road, but I think the original intent is to not saddle the GameOS with the OS being used to run the Apps.
I would bet that the App/System OS is some Win8/RT variant and that was a requirement (political) dictated to the Xbox team (speculation) and that in order to retain a more console like development experience they had to use a VM to partition resources.
There is a secondary win which is that it makes the app switching and suspend/resume easier to do.

Given the nature of the resource split, it could be an extremely thin virtualization layer, the Game OS could for example always get the same physical memory range.
I'd be interested to know if they made any changes to the GPU to support suspend/resume, or virtualization.

If the XB1's OS setup is a derivative of MS's Drawbridge and Picoprocess research then persistent compatibility is a goal as well as security and transmedia functionality.
 
Last edited by a moderator:
Yeah, ERP is right on their reasons for using VMs and that the app OS is a stripped down Win 8 variant and the game OS is a very thin virtualisation layer.

Their setup also makes the console far more difficult to be compromised by using exploits in Windows and more secure overall against hacking.
 
Yeah, ERP is right on their reasons for using VMs and that the app OS is a stripped down Win 8 variant and the game OS is a very thin virtualisation layer.

Their setup also makes the console far more difficult to be compromised by using exploits in Windows and more secure overall against hacking.

It's also interesting to note that MS could make an STB using the VMs (a lower-spec box with only a hypervisor + app OS). In theory, it would be 100% compatible with the app OS in the XB1.
 
Wow thats crazy. Guess its easier to lock down by using something else. Its clear ms wants you to use "official" accessories.
Afaik, they are going to use Miracast. Other than that I am not too fond of kb/mouse on a console except for some games.

News.... How the Project Spark and projects like the Kodu Kup in the United Kingdom are building for the future of the industry, with young -and I mean very young- developers.

http://www.oxm.co.uk/58559/features...ox-one-is-building-for-the-industrys-tomorrow

 
Also, how quickly we forget 360 had ~half the main bandwidth of PS3 yet outperformed it due to EDRAM...main memory bandwidth is not even close to the whole story in a EDRAM design unless you know nothing about technology (but it seems a lot of people conveniently forget. MS added 1.6 billion transistors for no purpose no doubt).

Hmm i thought the main issue with the PS3 memory was the lack of unified memory ohh and a weak RSX in regards to the performance.

It took way to long to come around those issues and produce the best looking games this generation has seen.. All of those main issues have been solved with the PS4. Looking at the XBOX180 there isn't weak points as such, just compromises because of the DDR3. If it weren't for the PS4 the XBOX180 would be "fine".
 
Hmm i thought the main issue with the PS3 memory was the lack of unified memory ohh and a weak RSX in regards to the performance.

It took way to long to come around those issues and produce the best looking games this generation has seen.. All of those main issues have been solved with the PS4. Looking at the XBOX180 there isn't weak points as such, just compromises because of the DDR3. If it weren't for the PS4 the XBOX180 would be "fine".

It was the above and some really bad bandwidth issues with reads and writes from the separate pools of memory.

If the PS3 had a unified pool of XDR then the ESRAM benefit from the 360 would have practically been negated. The PS4 doesn't have that restriction plus the bandwidth is huge. It's like a role reversal in that respect.
 
Status
Not open for further replies.
Back
Top