[Qemu-devel] SoC Idea: Xbox target

[Qemu-devel] SoC Idea: Xbox target

[Niel van der Westhuizen]

[-- Attachment #1: Type: text/plain, Size: 1398 bytes --]

Hey,

So I've been lazily hacking away on https://github.com/espes/xqemu for the
last few months. It's a target for the original Xbox in Qemu - it's kind of
a neat fit, since the Xbox was mostly an nForce 420 PC. It'd be awesome to
have helping out on this as a listed Summer of Code project idea. (mainly
so I could apply for it ;)

Thing is, for this to be a Qemu project it'd need to be viable to be merged
into Qemu eventually. Unfortunately so far my implementation has been far
from clean-room, which could possibly be risky legally, I dono:
    -The binaries I've been referencing while reverse engineering are from
the Xbox development kit software (since they conveniently include symbols)
that, while mostly widely available, aren't exactly public.
    -The current implementation of the GPU (
https://github.com/espes/xqemu/blob/xbox/hw/nv2a.c) and APU (
https://github.com/espes/xqemu/blob/xbox/hw/mcpx_apu.c) use register
names verbatim from a leaked register listing. If it makes a difference,
most of the GPU names could already be figured out from a combination of
registers documented in nouveau, registers listed in Dxbx (another Xbox
emulator, "uNV2A.pas"), a published register listing found in an old nvidia
sdk ("nv10reg.h"), and enums in the debug files in the Xbox development kit
software.

Oh, and someone would need to be found as a mentor.

Thoughts?

Many thanks,
Niel

[-- Attachment #2: Type: text/html, Size: 1891 bytes --]

Re: [Qemu-devel] SoC Idea: Xbox target

[Stefan Hajnoczi]

On Mon, Apr 15, 2013 at 6:38 PM, Niel van der Westhuizen
<nielgvdw@gmail.com> wrote:
> So I've been lazily hacking away on https://github.com/espes/xqemu for the
> last few months. It's a target for the original Xbox in Qemu - it's kind of
> a neat fit, since the Xbox was mostly an nForce 420 PC. It'd be awesome to
> have helping out on this as a listed Summer of Code project idea. (mainly so
> I could apply for it ;)

What is the current status of the xbox target and what would a 12-week
GSoC project accomplish?  The scope of the project needs to be clearly
defined so this information is critical.

> Thing is, for this to be a Qemu project it'd need to be viable to be merged
> into Qemu eventually. Unfortunately so far my implementation has been far
> from clean-room, which could possibly be risky legally, I dono:
>     -The binaries I've been referencing while reverse engineering are from
> the Xbox development kit software (since they conveniently include symbols)
> that, while mostly widely available, aren't exactly public.
>     -The current implementation of the GPU
> (https://github.com/espes/xqemu/blob/xbox/hw/nv2a.c) and APU
> (https://github.com/espes/xqemu/blob/xbox/hw/mcpx_apu.c) use register names
> verbatim from a leaked register listing. If it makes a difference, most of
> the GPU names could already be figured out from a combination of registers
> documented in nouveau, registers listed in Dxbx (another Xbox emulator,
> "uNV2A.pas"), a published register listing found in an old nvidia sdk
> ("nv10reg.h"), and enums in the debug files in the Xbox development kit
> software.

Are just those two files questionable?  Could they be replaced with
something that does not draw from leaked material?

Stefan

Re: [Qemu-devel] SoC Idea: Xbox target

[Niel van der Westhuizen]

[-- Attachment #1: Type: text/plain, Size: 1345 bytes --]

On 16 April 2013 18:27, Stefan Hajnoczi <stefanha@gmail.com> wrote:

> What is the current status of the xbox target and what would a 12-week
> GSoC project accomplish?  The scope of the project needs to be clearly
> defined so this information is critical.
>

Currently it runs the bios to completion (which includes the fancy boot
animation) and the "dashboard" runs, but nothing cool is displayed since
the graphics code has OpenGL bugs that I need to track down.

The rough todo has some discrete tasks that could be approached in
isolation, but mostly it's just grinding through getting things working:
  -get shit rendering properly
    -fix /all/ the bugs :/
    -fragment shader generation from register combiners
    -fix vertex shader generation
    -create/destroy graphics context properly
  -get shit making sound properly
  -game controller (xpad) emulation/passthrough
  -fatx/xiso virtual block devices
  -make x86-x86 tcg not retarded slow or get useful kernel support on
Windows if that's remotely feasible



> Are just those two files questionable?  Could they be replaced with
>  something that does not draw from leaked material?
>

Yeah. "Replaced"? Could rename the registers, but that wouldn't really
accomplish anything... I guess they'd have to be rewritten from scratch?
That'd be quite an annoying amount of work :/

[-- Attachment #2: Type: text/html, Size: 2387 bytes --]

Re: [Qemu-devel] SoC Idea: Xbox target

[Stefan Hajnoczi]

On Tue, Apr 16, 2013 at 11:03 AM, Niel van der Westhuizen
<nielgvdw@gmail.com> wrote:
> On 16 April 2013 18:27, Stefan Hajnoczi <stefanha@gmail.com> wrote:
>>
>> What is the current status of the xbox target and what would a 12-week
>> GSoC project accomplish?  The scope of the project needs to be clearly
>> defined so this information is critical.
>
>
> Currently it runs the bios to completion (which includes the fancy boot
> animation) and the "dashboard" runs, but nothing cool is displayed since the
> graphics code has OpenGL bugs that I need to track down.
>
> The rough todo has some discrete tasks that could be approached in
> isolation, but mostly it's just grinding through getting things working:
>   -get shit rendering properly
>     -fix /all/ the bugs :/
>     -fragment shader generation from register combiners
>     -fix vertex shader generation
>     -create/destroy graphics context properly
>   -get shit making sound properly
>   -game controller (xpad) emulation/passthrough
>   -fatx/xiso virtual block devices
>   -make x86-x86 tcg not retarded slow or get useful kernel support on
> Windows if that's remotely feasible

There is no KVM support on Windows hosts.  On Linux hosts, KVM could
probably be used for fast execution.

If you're interested in improving TCG perhaps this could be a project
idea on its own, which helps your xbox target without touching the
legally questionable graphics and sound emulation.  The improvements
would benefit at least i386 TCG and possibly other targets too.  For
this project we'd need specific tasks and a mentor.  Do you have any
tasks in mind?

>> Are just those two files questionable?  Could they be replaced with
>> something that does not draw from leaked material?
>
>
> Yeah. "Replaced"? Could rename the registers, but that wouldn't really
> accomplish anything... I guess they'd have to be rewritten from scratch?
> That'd be quite an annoying amount of work :/

Yes.  It seems that the existing graphics and sound code would be hard
to merge into qemu.git.  Although people have emulated other console
hardware without much legal hassle, it gets risky when copyrighted
material is used which was obtained under some sort of contract or
license.

Stefan