It's been a while since I've given any updates about this emulator. Sorry about that. Lately, I had to sit back and think about what's best for the emulator, such as balancing portability with compatibility, as well as the ease of coding burdens in the future. So, I decided to let go of the direct code execution method completely. I was going to keep it for an experimental HLE build, but that didn't turn out nearly as well as I hoped after a few tests, and it was a grim reminder why HLE is far more trouble than it's worth.
Having said that, I've been using libemu for a basic interpreter since it was the same as my intended source licence (GPL) and to save me a bit of time on the CPU issues here. It's a really easy library to implement for your own code, but it does come with a bit of a price, so to speak. Not in dollars or euros, the price of getting it to compile properly with Visual Studio .net, removing the paging table code and replacing it with a flat memory model, adding your own implementations for privileged instructions as well as MMX and SSE, and some of the various bugs that were never fixed or discovered. The first two aren't exactly difficult, but the third and fourth are the most time consuming. Other than that, it was worth the effort I put in so far (as evident in the screen above).
Oh, about that screen shot... it was generated from a tutorial written by Ben_3D on xbdev.net, formerly known as xfactordev.net (see the non-xdk tutorial section). Not too impressive, but I went through hoops getting it to work. "Why is it upside down?" Oh, that's because I used OpenGL's framebuffer manipulation APIs to draw that (glDrawPixels). I just never got around to adding code to change the Y orientation. There are better and more interesting ways than using glDrawPixels to do that, but the point is getting something working, then improve it later on, i.e. the K.I.S.S. rule.
A few other things I wanted to mention is that I'm going to HLE the kernel for the time being until the emulator is further along. I'd much rather use an authentic BIOS, but there's too much missing functionality for that to happen; plus I'd like to keep it as an alternative for a while.
Next task: do some more work on the HLE kernel, integrate some of my old PCI emulation code, get some basic USB emulation going and attempt to emulate the basic features of the AC'97 for sound (PCM). Until next time.
Shogun.
EDIT: Oh, I forgot about emulating threads. This won't be too challenging to implement (at least I hope not) except maybe the stack part, but I'm not too worried about that.
Nice to see some progress!
ReplyDeleteHi there Brandon, it's great to see you make good progress in Xenoborg! So, you got CPU emulation and framebuffer capture going - did I ever email you the hybrid HLE/LLE Cxbx sourcecode done my KingOfC? You could learn a thing or two about DMA emulation from that code. Combine that with the NV2A opcode emulation I wrote for Dxbx, and you could come a long way in hardware-emulating 3D graphics in Xenoborg.
ReplyDeleteOh, and did Jannik ever send you his code? As he seemed to've been doing about the same thing as you, but judging from his screenshots, he even got some XDK samples working...
Anyway, thumbs up from me - cheers!
Oh, hey Patrick! Glad to see you check in once and a while. Hopefully all is well on your end. Still would like to cruise across the ocean sometime, but hopefully this new job prospect pays off.
ReplyDeleteAnyway, I never did see the original source code that Kingofc wrote. I'd really like to see that and see what I can get going from that. I'm curious to see how he handled VBlank/VSync in his code. Mine isn't being done properly and I need to fix it soon since I'm going to be working on VGA for the other various OpenXDK samples. Another side note, fortunately for me, the Xbox framebuffer is directly compatible with GL_BGRA_EXT so I don't have to modify the incoming pixels!
So, JayFox showed you his source code? He never sent it to me, but I never did ask because I assumed he wanted to keep his source closed until release time. I've seen his screens and they are quite impressive. Guess I have some catching up to do! :)
Oh, and I think I might have some basic sounds playing soon. Fortunately for me, sending PCM data to the AC'97 looks pretty straight forward, only the registers don't make much sense to me because the OpenXDK didn't document exactly what they were.
Shogun
The source code does not plan to update? The service Google.Code.
ReplyDeleteGreat! keep it up =)
ReplyDeleteI never realized you had a blog dedicated to Xenoborg. >_>
ReplyDeleteAnyway, this post says you had to drop direct code execution. This wouldn't happen to be the running of x86 code directly on the PC's x86 CPU, would it?
If so, no offense, but that's really depressing to me...IMO, one of the biggest hopes and benefits of an Xbox emulator would be the performance achieved from directly running x86 code. Xbox already has only a few exclusives (vs GCN & PS2), and loosing its strength in multi-platform games will likely doom Xbox emulators to a fate similar to Saturn ones...
Hi Blue, any news lately?
ReplyDeleteOut of curiosity, why did you strip out the page table support from libemu if you're going down the full BIOS support road? The kernel uses the MMU pretty heavily.
ReplyDeleteSorry for not keeping you all up-to-date on this. Been busy IRL again and not much time for this.
ReplyDeleteAnyway, I removed the page table support because it was causing problems when trying to emulate some basic OpenXDK and assembly .xbe files. It kept giving me incorrect addresses and what not. That was probably due to the fact that I didn't port it properly for Visual C++ (this was the main thing causing Visual Studio to generate errors before). As soon as I used flat mode address handling, everything worked fine.
I should upload my source so others can see it, ASAP.
Hey.. Fascinating stuff. If you ever get a working version that will run Bloodwake, let me know.. Damn all the other games. Haha.
ReplyDeleteGood stuff
ReplyDelete