30 Nov
2004
30 Nov
'04
10:21 p.m.
As most of you know, I'm dabbling around a little bit with a port of ReactOS
to the Xbox. I think most of the differences between a standard PC and the
Xbox can be handled by using a custom HAL for the Xbox, after all, that's
what the HAL is for.
At the moment, we build 1 HAL, based on the value of MP in config it's
either a UniProcessor HAL or a MultiProcessor HAL. Which code is compiled is
based on preprocessor statements. I'd like to be able to build 3 HALs in
parallel, the UP, MP and Xbox HALs. When installing ("make install"), the
correct HAL would be selected based on the MP config var. When creating a
boot cd, all three would be copied to the CD and the setup program would
select the correct one to copy to the harddisk. This will allow us to build
a single boot CD for different configurations. I'm aware that we'll need a
NTKRNLMP.EXE on the boot CD too (I will try very very hard not to need a
different kernel for Xbox) for this "single boot CD" idea to work, but
that's a different problem and I'd like to tackle that later.
The three HALs will share a lot of the code. To avoid code duplication, I
propose to create a directory structure like this:
hal
|
--- hal
|
--- halx86
| |
| +----- generic
| | |
| | +----- include
| |
| +----- up
| |
| +----- mp
| |
| +----- xbox
|
+-- hal68k :-)
|
+-- etc...
The "generic" subdir will contain most of the code. The "up" subdir
will
contain mostly simple .c files which just include a .c file from generic.
For example, the HalMakeBeep() function will be defined in generic/beep.c.
In "up" there will be a file beep_up.c which contains only 'include
"beep.c"', which will be compiled with the include path set to
"../generic".
The "mp" and "xbox" directories can either include "generic"
files or have
their own implementation of a given routine (e.g. display_xbox.c for
HalDisplay* functions on the Xbox).
Doing it this way we should have little code duplication and our dependency
tracking system should work.
Comments?
Gé van Geldorp.
30 Nov
30 Nov
10:35 p.m.
Ge van Geldorp wrote:
I'm aware that we'll need a
NTKRNLMP.EXE on the boot CD too (I will try very very hard not to need a
different kernel for Xbox) for this "single boot CD" idea to work, but
that's a different problem and I'd like to tackle that later.
You will most probably need a different kernel, because as hard as MS
tried, the kernel is still a bit architectural dependent.
We might be able to make a single kernel handle both the xbox and a
normal pc, but IMO that would require special flags and complex code
that is if..then instead of a compile-time ifdef, and it would make our
code more bloated. I think having a separate kernel binary is fine.
Best regards,
Alex Ionescu
1 Dec
1 Dec
12:10 a.m.
Hi Alex,
--- Alex Ionescu <ionucu(a)videotron.ca> wrote:
tried, the kernel is still a bit architectural
dependent.
We might be able to make a single kernel handle both the xbox and a
normal pc, but IMO that would require special flags and complex code
that is if..then instead of a compile-time ifdef, and it would make
our
code more bloated. I think having a separate kernel binary is fine.
The xbox is a x86 pc lacking in a BIOS. ntoskrnl should not talk to the
bios directly in any case. Other than that its the same. There is one
PCI device you cant probe or it will lock the system. I think we can
take care of that issue via a 4 line patch because you can detect if
you are running on the xbox. (if memory serves) There is a extra PCI
device ID that is only present on the xbox so the HAL can search for
that device and then have logic built in to it to avoid the other
device. According to my converstation with the xbox Linux people that
really should be all we need aside from rippping out the direct
hardware access stuff in freeldr which GvG has already done. The hard
part will be keyboard and mouse, the xbox uses USB for that and we need
it anyway.
Sure it has the magic built in to the firmware and the OS to keep
people from running unsigned apps on it but there are three known ways
to boot off of it and I think we can do all of them now that freeldr
can chain load from grub.
Thanks
Steven
__________________________________
Do you Yahoo!?
Take Yahoo! Mail with you! Get it on your mobile phone.
http://mobile.yahoo.com/maildemo
1:36 a.m.
Steven Edwards wrote:
Hi Alex,
Hi Steven!
The xbox is a x86 pc lacking in a BIOS.
Much more then just a BIOS however. Graphics are highly proprietary, as
is a lot of the PnP. And forget about Legacy I/O. There are other subtle
details too.
ntoskrnl should not talk to the
bios directly in any case.
It doesn't but it does do other things which are unsupported/done
differently on the xbox architecture. However, it does depend on how far
you're willing to go to support it. I was a very early adopter of the
xbox and the first mod chips/software that came out for it...and many
people found out that it's more then just "x86 with some stuff missing".
Some things about it are really tricky. I agree that they should all be
in a HAL, but unforuntately, IIRC, there still is some arch-specific
code in ntoskrnl. In NT4, all the different supported architectures had
a different kernel...not only a different HAL.
Other than that its the same. There is one
PCI device you cant probe or it will lock the system. I think we can
take care of that issue via a 4 line patch because you can detect if
you are running on the xbox. (if memory serves) There is a extra PCI
device ID that is only present on the xbox so the HAL can search for
that device and then have logic built in to it to avoid the other
device. According to my converstation with the xbox Linux people that
really should be all we need aside from rippping out the direct
hardware access stuff in freeldr which GvG has already done. The hard
part will be keyboard and mouse, the xbox uses USB for that and we need
it anyway.
There's also the problem with text-mode and the video in general, imo.
Sure it has the magic built in to the firmware and the
OS to keep
people from running unsigned apps on it but there are three known ways
to boot off of it and I think we can do all of them now that freeldr
can chain load from grub.
Easy stuff to fix, and GvG is doing a great job.
Thanks
Steven
Best regards,
Alex Ionescu
P.S Much like the Appollo missions brought us so much stuff here at
home, I can't wait to see the effects that the xbox port will have. USB
probably is the coolest.
__________________________________
Do you Yahoo!?
Take Yahoo! Mail with you! Get it on your mobile phone.
http://mobile.yahoo.com/maildemo
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.com
http://reactos.com:8080/mailman/listinfo/ros-dev
2:44 a.m.
Hi Alex,
--- Alex Ionescu <ionucu(a)videotron.ca> wrote:
Much more then just a BIOS however. Graphics are
highly proprietary,
as
is a lot of the PnP. And forget about Legacy I/O. There are other
subtle
details too.
"highly proprietary" is a standard NVidia GeForce Chip minus a VGA
Bios. VBE works fine on it and we have been in discussion with the
xbox-linux people about how to trick it in to working with the Nvidia
windows binary driver. The Windows driver supports everything from the
old Riva cards up through TNT, GeForce[2,3,4}, etc. All we have to do
is add a few hacks to videoprt.sys, the HAL and a few other places and
it should load according to the research I have done. They have not
done this on Linux already because of lack of resources.
Some things about it are really tricky. I agree that
they should all
be
in a HAL, but unforuntately, IIRC, there still is some arch-specific
code in ntoskrnl. In NT4, all the different supported architectures
had
a different kernel...not only a different HAL.
I think there might be a few challenges but I have yet to see anything
yet that would require a new kernel.
There's also the problem with text-mode and the
video in general,
imo.
I think blue.sys will have to be hacked or a new one will have to be
developed but the Linux text mode console works so I dont think it will
take much.
Easy stuff to fix, and GvG is doing a great job.
Yeah its been great. I can now boot ReactOS, Windows and Linux all from
one master bootloader.
P.S Much like the Appollo missions brought us so much
stuff here at
home, I can't wait to see the effects that the xbox port will have.
USB
probably is the coolest.
Yes I hope so as well. If nothing else it will bring more news about
ReactOS which in turn will help us get more developers.
Thanks
Steven
__________________________________
Do you Yahoo!?
Take Yahoo! Mail with you! Get it on your mobile phone.
http://mobile.yahoo.com/maildemo
9:09 a.m.
From: Alex Ionescu
There's also the problem with text-mode and the video in general, imo.
I think there are only 3 places where we use text-mode: FreeLdr, HAL and
blue.sys. I've already adapted FreeLdr to simulate text-mode in
graphics-mode (i.e. there is a routine which takes a char and an attribute,
that routine looks up the char in a font table and sets the correct pixels
in the frame buffer). Same could be used in HAL. To keep the code clean I'll
probably write a Xbox specific version of blue.sys based on the same
principle.
The game plan for graphics mode is to first start using framebuf.dll and a
custom video miniport driver. I see no problems there. It would be nice to
be able to use the Windows nVidia driver later on. There are a few problems
with that (driver will probably look for specific PCI vendor/device ids,
might try to call INT10, might try to scan the video BIOS) but we'll cross
that bridge when we get there.
In general, right now I'm just following the execution flow of the kernel
and when I hit a problem I try to solve it, one problem at a time. I still
have good hope that it won't be necessary to put Xbox specific code in the
kernel, but I'm not 100% sure about that. But, in the spirits of the
beginnings of ReactOS (lots of talk but no code for FreeWin95 --> emphasis
on writing code for ReactOS) it's enough to have a general feel for the
direction we want to move in and start writing code.
Gé van Geldorp.
9:31 a.m.
Keep in mind there is an XBOX emulator: CXBX available at
http://www.caustik.com/cxbx/, that, though incomplete, runs at least 1
commercial game and might be complete enough to run an xbox port of
ROS. Also, i'm sure you already know about the OpenXDK at
http://www.openxdk.org/.
Ge van Geldorp wrote:
From: Alex
Ionescu
There's also the problem with text-mode and the video in general, imo.
I think there are only 3 places where we use text-mode: FreeLdr, HAL and
blue.sys. I've already adapted FreeLdr to simulate text-mode in
graphics-mode (i.e. there is a routine which takes a char and an attribute,
that routine looks up the char in a font table and sets the correct pixels
in the frame buffer). Same could be used in HAL. To keep the code clean I'll
probably write a Xbox specific version of blue.sys based on the same
principle.
The game plan for graphics mode is to first start using framebuf.dll and a
custom video miniport driver. I see no problems there. It would be nice to
be able to use the Windows nVidia driver later on. There are a few problems
with that (driver will probably look for specific PCI vendor/device ids,
might try to call INT10, might try to scan the video BIOS) but we'll cross
that bridge when we get there.
In general, right now I'm just following the execution flow of the kernel
and when I hit a problem I try to solve it, one problem at a time. I still
have good hope that it won't be necessary to put Xbox specific code in the
kernel, but I'm not 100% sure about that. But, in the spirits of the
beginnings of ReactOS (lots of talk but no code for FreeWin95 --> emphasis
on writing code for ReactOS) it's enough to have a general feel for the
direction we want to move in and start writing code.
Gé van Geldorp.
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.com
http://reactos.com:8080/mailman/listinfo/ros-dev
2 Dec
2 Dec
12:28 a.m.
At 23.21 30/11/2004, you wrote:
As most of you know, I'm dabbling around a little
bit with a port of
ReactOS to the Xbox. I think most of the differences between a standard PC
and the Xbox can be handled by using a custom HAL for the Xbox, after all,
that's what the HAL is for.
green light all the way. Also feel free to add ReactOS-specific functions
to the HAL if that saves us conditional code in the kernel
11:06 p.m.
Ge van Geldorp wrote:
As most of you know, I'm dabbling around a little
bit with a port of ReactOS
to the Xbox. I think most of the differences between a standard PC and the
Xbox can be handled by using a custom HAL for the Xbox, after all, that's
what the HAL is for.
At the moment, we build 1 HAL, based on the value of MP in config it's
either a UniProcessor HAL or a MultiProcessor HAL. Which code is compiled is
based on preprocessor statements. I'd like to be able to build 3 HALs in
parallel, the UP, MP and Xbox HALs. When installing ("make install"), the
correct HAL would be selected based on the MP config var. When creating a
boot cd, all three would be copied to the CD and the setup program would
select the correct one to copy to the harddisk. This will allow us to build
a single boot CD for different configurations. I'm aware that we'll need a
NTKRNLMP.EXE on the boot CD too (I will try very very hard not to need a
different kernel for Xbox) for this "single boot CD" idea to work, but
that's a different problem and I'd like to tackle that later.
The three HALs will share a lot of the code. To avoid code duplication, I
propose to create a directory structure like this:
hal
|
--- hal
|
--- halx86
| |
| +----- generic
| | |
| | +----- include
| |
| +----- up
| |
| +----- mp
| |
| +----- xbox
|
+-- hal68k :-)
|
+-- etc...
The "generic" subdir will contain most of the code. The "up" subdir
will
contain mostly simple .c files which just include a .c file from generic.
For example, the HalMakeBeep() function will be defined in generic/beep.c.
In "up" there will be a file beep_up.c which contains only 'include
"beep.c"', which will be compiled with the include path set to
"../generic".
The "mp" and "xbox" directories can either include "generic"
files or have
their own implementation of a given routine (e.g. display_xbox.c for
HalDisplay* functions on the Xbox).
Doing it this way we should have little code duplication and our dependency
tracking system should work.
Comments?
Gé van Geldorp.
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.com
http://reactos.com:8080/mailman/listinfo/ros-dev
I've heard that XBOX WinNT kernel implementation has only around 120 kb
in mem, allows single process only, (propably windows messaging) is done
by polling and has not memory protection, so games can access hardwae
directly. Will ReactOS on XBOX mimic this behavior?
11:14 p.m.
Maritn "E.T." Misuth wrote:
I've heard that XBOX WinNT kernel implementation
has only around 120
kb in mem, allows single process only, (propably windows messaging) is
done by polling and has not memory protection, so games can access
hardwae directly. Will ReactOS on XBOX mimic this behavior?
No. ;-)
- Filip
11:16 p.m.
Maritn "E.T." Misuth wrote:
I've heard that XBOX WinNT kernel implementation
has only around 120
kb in mem, allows single process only, (propably windows messaging) is
done by polling and has not memory protection, so games can access
hardwae directly. Will ReactOS on XBOX mimic this behavior?
No. We are not making an XBOX OS. We are porting ReactOS to XBOX. The
XBOX Kernel is not (and never meant to be) a port of Windows 2000 for
XBOX. It's a specially crafted kernel with the limitations you
mentionned for the purpose of gaming. ReactOS is only being ported so
that it can run on the platform, not so that it can be used only for
running XBOX games.
Best regards,
Alex Ionescu
11:21 p.m.
From: Maritn "E.T." Misuth
I've heard that XBOX WinNT kernel implementation has only
around 120 kb in mem, allows single process only, (propably
windows messaging) is done by polling and has not memory
protection, so games can access hardwae directly.
Single process only is correct, "no memory protection" and "direct
hardware
access" are more or less correct (the games run in kernel mode). Don't know
about the in-mem size or the polling.
Will ReactOS on XBOX mimic this behavior?
No. We want to run standard Win32 apps so we need to behave as Windows does,
not as the Xbox kernel does.
Gé van Geldorp.
7287
days inactive
7289
days old
11 comments
7 participants
participants (7)
-
Alex Ionescu -
Filip Navara -
Ge van Geldorp -
KJK::Hyperion -
Maritn "E.T." Misuth -
Richard Campbell -
Steven Edwards