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.
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
Hi Alex,
--- Alex Ionescu ionucu@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
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@reactos.com http://reactos.com:8080/mailman/listinfo/ros-dev
Hi Alex,
--- Alex Ionescu ionucu@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
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.
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@reactos.com http://reactos.com:8080/mailman/listinfo/ros-dev
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
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@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?
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
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
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.
-
Alex Ionescu -
Filip Navara -
Ge van Geldorp -
KJK::Hyperion -
Maritn "E.T." Misuth -
Richard Campbell -
Steven Edwards