Print

[hargle]

ok, too many projects going on for me at the moment, but this one's been in the back of my head for awhile so I thought I'd ask:

I have a nice DOS utility I wrote ages ago that displays and dumps hardware devices (PCI, cmos, smbus devices, memory, etc) and I've started porting it to the xbox as I think it could be useful for hardware tweaking, and to help me learn development on this machine.

The deal is, since it's a DOS based program, I'm expecting the (PC) to boot up in real mode.  I then switch the CPU into flat real mode (unreal mode) in order to access 4gig of system memory without the CPU fighting me from accessing memory I shouldn't be playing with.  

So my question is, when I launch an app from XBMC, what CPU mode is it currently running in, and is it possible to get out of that mode and back into real mode, so my program can do it's normal thing from there?  
Anyone have pointers to source for doing such a thing?  I've never even done such a thing on a PC before, it's always been real->protected or real->unreal, and never backwards.

[torne]

Anything that runs on the xbox, unless it takes specific steps to become otherwise, is running under the MS Xbox kernel and is thus 'stuck' in protected mode. You can return to real mode (or unreal mode) via the normal mechanisms for doing so on x86 (read the intel/amd manuals) if you want, but you will have to provide all your own interrupt vectors and so on first, as the Xbox's are not going to work if you leave the MS kernel environment. You effectively have to provide your own OS.

The XBE build of Cromwell, xromwell, does something similar in order to escape from under the thumb of the MS kernel and become a suitable free XDKless environment for starting Linux in, though I doubt it bothers to leave protected mode (probably just turns off interrupts, rewrites all the IDTs and vectors and so on, and turns them back on again once all methods for the Xbox kernel to reestablish control have been overwritten with its own code).

You will be running in ring 0, though (as the xbox doesn't normally make use of user mode, all games run with kernel privileges) so you are free ultimately to do whatever you want.

If you're gonna go around probing PCI bus locations and so on, though, be aware that certain parts of the PCI bus and certain parts of the physical address space cause the xbox to hang if you touch them - see the xbox-linux kernel patches for what to avoid (I don't recall off the top of my head).

If you have any issues that can't be solved by reading an x86 arch manual, PM me or post here and I'll see what I can do to help (IMG:style_emoticons/default/wink.gif)

[hargle]

QUOTE(torne @ Jun 15 2006, 06:00 PM)

Anything that runs on the xbox, unless it takes specific steps to become otherwise, is running under the MS Xbox kernel and is thus 'stuck' in protected mode. You can return to real mode (or unreal mode) via the normal mechanisms for doing so on x86 (read the intel/amd manuals) if you want, but you will have to provide all your own interrupt vectors and so on first, as the Xbox's are not going to work if you leave the MS kernel environment. You effectively have to provide your own OS.

Yep, not a problem, and I'm fully ready for that.  My existing program only uses INT 16h for keyboard input, which isn't going to do me much good on an xbox anyway, so that's obviously got to go!

All of my hardware read/write routes do stuff directly to the hardware without those mamby-pamby kernel/interrupt interfaces! (those are for wimps)  (IMG:style_emoticons/default/tongue.gif)

QUOTE(torne @ Jun 15 2006, 06:00 PM)

The XBE build of Cromwell, xromwell, does something similar in order to escape from under the thumb of the MS kernel and become a suitable free XDKless environment for starting Linux in, though I doubt it bothers to leave protected mode (probably just turns off interrupts, rewrites all the IDTs and vectors and so on, and turns them back on again once all methods for the Xbox kernel to reestablish control have been overwritten with its own code).

Perfect.  That's the rabbit hole I was hoping to chase down.  
(15 seconds later)
Ah yes, escape.s in sourceforge is exactly what I was looking for.  Why I didn't go there before is beyond me, but at least now you know what else I'm up to beyond the fatx kernel hack.
thanks again torne!

QUOTE(torne @ Jun 15 2006, 06:00 PM)

If you're gonna go around probing PCI bus locations and so on, though, be aware that certain parts of the PCI bus and certain parts of the physical address space cause the xbox to hang if you touch them - see the xbox-linux kernel patches for what to avoid (I don't recall off the top of my head).

Yeah, I was just reading about the PCI no touch zones a few days ago, and this should be easy enough to avoid. I was unaware of anything in memory being like that though.  Interesting.  I may have bumped into something like this earlier in my experiments and then blamed it on the CPU  instead.

[torne]

QUOTE(hargle @ Jun 15 2006, 09:44 PM)

All of my hardware read/write routes do stuff directly to the hardware without those mamby-pamby kernel/interrupt interfaces! (those are for wimps)  (IMG:style_emoticons/default/tongue.gif)

That doesn't mean you can get away with not having any interrupt vectors, the hardware has all been fully initialised already and will thus be generating interrupts all over the place (timer, network, etc) unless you leave them totally disabled, which is unlikely to be convenient. (IMG:style_emoticons/default/smile.gif)

QUOTE

I was unaware of anything in memory being like that though.  Interesting.  I may have bumped into something like this earlier in my experiments and then blamed it on the CPU  instead.

I may be mis-remembering and it's just PCI, but the PCI configuration space that corresponds to the devices you can't touch may be mapped somewhere perhaps?

[_zlinky]

Hey guys, I just have a quick question about interrupts on the xbox.  I was wondering are the interrupts that are used on your PC all compatible with the xbox?  Or are there certain ones that you cannot use?  For example, setting the screen resolution using int 10h.  Thanks.

[hargle]

QUOTE(_zlinky @ Jul 1 2006, 05:51 PM)

Hey guys, I just have a quick question about interrupts on the xbox.  I was wondering are the interrupts that are used on your PC all compatible with the xbox?  Or are there certain ones that you cannot use?  For example, setting the screen resolution using int 10h.  Thanks.

None of that stuff exists.  
Those are software interrupt services, and have been usurped by the kernel.  

[_zlinky]

QUOTE(hargle @ Jul 2 2006, 05:03 PM)

None of that stuff exists.  
Those are software interrupt services, and have been usurped by the kernel.

Ok, so you are saying on the xbox that the int instruction is not used?

[torne]

They won't perform their DOS/BIOS functions. The Xbox is always running in ring 0, so xbox apps don't need to make software interrupt calls to access the functions of the MS kernel - they just link to the kernel's import library, and call its exported functions directly. The MS kernel will contain a handler somewhere for software interrupts, but what exactly it will do with them, I have no idea. It may well just fault.

[hargle]

Check out http://www.xbdev.net/non_xdk/nonxdk.php
There are some examples there in assembly which call directly into the kernel using what's known as a "thunk table"  (I assume you're doing stuff in assembly anyway, which makes me proud!)

Essentially it's just a jump table that is VERRRRY much like an interrupt table, except you'd do call instead of INT.

CODE

; kernel thunk table
AvSendTVEncoderOption   dd      080000000h+2
AvSetDisplayMode            dd      080000000h+3
HalReadSMBusValue         dd      080000000h+45
HalReturnToFirmware        dd      080000000h+49
HalWriteSMBusValue         dd      080000000h+50
MmAllocateContiguousMemoryEx  dd      80000000h + 166
MmGetPhysicalAddress       dd      80000000h + 173
NtAllocateVirtualMemory       dd      80000000h + 184

        dd      0              ; end of table

.
.
.

        pushd   0                       ; do some screen init
        pushd   1                       ; disable
        pushd   9                       ; VIDEO_ENC_VIDEOENABLE
        pushd   VIDEO_BASE
        call    [AVSendTVEncoderOption]
        

(sorry about the formatting)

I know there are full lists for all the various thunk table entries, but I can't find one at the moment.  
This stuff isn't documented in the XDK, as the xdk wraps more code around the raw kernel functions.

[PedrosPad]

QUOTE(hargle @ Jul 5 2006, 07:00 PM)

I know there are full lists for all the various thunk table entries, but I can't find one at the moment.  
This stuff isn't documented in the XDK, as the xdk wraps more code around the raw kernel functions.

One such place is the "src/kexports.inc" file in the NKPatcher sources available here.
 (IMG:style_emoticons/default/smile.gif)

This post has been edited by PedrosPad: Jul 6 2006, 09:06 AM

[_zlinky]

First of all, I wanna say thanks for the links and info guys, I really appreciate it.  www.xbdev.net has taught me almost everything I know about low-level xbox programming.  This could really come in handy for a homebrew programming library of my own.  I really want to find time to do this, but I need to increase my asm programming skills (with MASM).  Second of all, I also noticed that the openxdk source code has a list of all of the kernel functions.  And certain ones can be found in Cxbx (the xbox emulator) source code and you can see how they work.  I was hoping to find a list that shows all the kernel thunk entries with their parameters and return types, but so far, the closest I could find was this book on WinNT driver programming.

Hold on a sec while I find the link...

Ok, here it is.  Good thing I added it to my favorites.  And too bad its out of stock, I really want this one (IMG:style_emoticons/default/sad.gif)
http://www.bookpool.com/sm/0201695901

This post has been edited by _zlinky: Jul 7 2006, 06:56 PM

[d0wnlab]

Try google searching for the function names as you need them, a lot of them are slightly renamed copies of the NT function (try removing the prefix from the function name).  I think the ReactOS source code is one place to look as well.

[hargle]

QUOTE(_zlinky @ Jul 7 2006, 06:21 PM)

I really want to find time to do this, but I need to increase my asm programming skills (with MASM).  Second of

Just a word of warning: building .xbe files with MASM is a royal pain in the cheeks.  I'm an old dos MASM guy myself, and at least the dos MASM 6.11 version that I'm used to using has a really hard time with the ORG statements to put all your datafields in the XBE header in the correct area.  (perhaps masm32 works better, but switching to NASM or FASM is a reality that I'm quickly realizing, but old habits die hard)

I'm working on porting one of my old dos programs over, as mentioned in the start of this thread, and I'd be happy to push the source code over to you and my build environment to get you jumpstarted.  It doesn't do much other than dump some text on the screen at the moment, so don't expect much!   (IMG:style_emoticons/default/tongue.gif)

[_zlinky]

QUOTE(hargle @ Jul 8 2006, 02:21 PM)

Just a word of warning: building .xbe files with MASM is a royal pain in the cheeks.  I'm an old dos MASM guy myself, and at least the dos MASM 6.11 version that I'm used to using has a really hard time with the ORG statements to put all your datafields in the XBE header in the correct area.  (perhaps masm32 works better, but switching to NASM or FASM is a reality that I'm quickly realizing, but old habits die hard)

I'm working on porting one of my old dos programs over, as mentioned in the start of this thread, and I'd be happy to push the source code over to you and my build environment to get you jumpstarted.  It doesn't do much other than dump some text on the screen at the moment, so don't expect much!   (IMG:style_emoticons/default/tongue.gif)

That indeed would be great.  Thanks for your offer.  In fact, I have a much easier time with MASM then NASM (simply because I still cant get NASM to install).  It took me a while, but I got xbes to assemble on MASM.  And the reason why I'm using MASM is so that the ASM code will be compatable with MS compilers.

@d0wnlab:  Thanks for your suggestion, I'll check that out some time (IMG:style_emoticons/default/smile.gif)