Sorry I haven't been updating this blog as frequently as I should be. Have lots on my plate besides this emulator atm. No worries though, I'm still eager to continue updating this emulator as often as possible.
About the SVN, this is where I'll be uploading my source code updates when I see fit. Right now, the code isn't too great, and it's kinda sloppy in some areas. In fact, it's downright embarrassing in some places! Some of this stuff was just done in a rather reckless way to get stuff to work immediately. There's lots of stuff I've been meaning to add, but just haven't gotten around to doing it yet. Maybe I should focus on getting the more annoying things emulated, such as the SMBus, PIC, EEPROM, temperature monitor, PCI, X-Codes, VGA, etc. Well, the EEPROM part is easy, I mean, you don't even need to dump your own EEPROM for this emulator to work. Creating a dummy EEPROM is pretty easy anyway. All of that stuff has to be done before I can think of attempting full blown BIOS emulation (which is going to be hard).
Oh, wait. I forgot, I was supposed to explain the threading model of this emulator! *palm hitting forehead* Ugh, sorry guys. Let me explain that now. Then you'll understand why the code is structured the way it is.
In order to understand how this threading model works, we have to understand how the emulator actually works (and why it works). I'm assuming I explained this before, but here's a diagram I drew in mspaint. Hopefully it's readable/understandable enough.
Now, remember the sole purpose of Xenoborg.exe is to reserve a specific memory address that the .xbe normally has to access to do it's dirty work. The .xbe's base address is (almost) always 0x10000, and if you EVER find an .xbe file with a different base address than that, let me know right away! Pretty much all of the code executed by Xbox is located in Ram (which is located at 0x00000000 - 0x03FFFFFF (64Mb), 0x07FFFFFF for debug Xboxes (128Mb), and Chihiro Ram range can be as great as 0x40000000 (1GB)) and since .xbe files are very specific as to what memory locations to read/write, we have to give it access to it's desired base address in order for it to work (meaning we can't just allocate some buffer and throw the .xbe contents in there and expect it to work). So we give the launcher .exe file the power to reserve that address, then transfer control over to the .dll file. This means that we never return to the .exe until it's time to exit because the .exe contents will be overwritten completely and restored at exit time.
Now we need 3 threads. One thread handles the message pump for the window being rendered to because DllMain is not suited to handle a message pump like WinMain is, so I created a thread to contain that loop. The second handles actual emulation loop, and the third just updates interrrupts and other time related things. These threads are created/organized as they are in this diagram.
Make sense? So far, it appears to work fine, but the CPU usage is really high because I suck at writing threaded code. Maybe it's the thread priorities causing problems, I dunno. If you can think of a better way to thread this, let me know because my knowledge of threading is limited.
Any suggestions? Speak up, I'd like to hear 'em!
Shogun.
