Project Titan Journal
=====================

(Build 20010411)
-------------------
Well, it's spring break and I've been trying to get some work in on Titan -- the VDP is a lost cause for me... I need to find someone else who can do it, because I certainly don't have the skill to do it myself. In the meantime, I decided to apply some of my newfound technical information, altering SMPC code and starting the peripheral implementation (which is also untested). I resumed work on the new core and started working on some more opcodes, however, I'm sure at least 50% of the opcodes I wrote or altered have major or fatal issues which I will need to debug. In the process of writing these opcodes, I re-evaluated the register caching system and decided not to use the ecx register since the memory functions were using it in their functions. Although this doesn't solve my problem with saving general register values, it's a step forward, not to mention the fact that I have another work register to play with.

----

I have to get Titan to do something to keep my motivation going, but I'm afraid everything hinges on the VDP now... unless I get something onscreen, I won't be able to tell what's working and what's not. I'm horribly underqualified to work on it, but I can only do so much without it. (I should have listened to them... the Saturn really *is* a nightmare to emulate). But I have some source code, and although I hate to copy code, I may adapt some of it to Titan to see if it will work. This is going to be the last release of Titan for a while so don't be suprised if there are no updates for a while.

(Build 20010223)
------------------
Well, before I try to complete the new core, I figured I'd give the old one a little tweaking. So, I rewrote it using functions instead of a big case statement (which I should have done in the first place, but I was in a hurry. The interpreter code should be a little cleaner now... Also, there was a little error with the M68k -- I neglected to set up Genitak68K to byteswap the data from memory, so when the Sound is reset, the reset vector is out of range and Titan crashes... In any case, it's not a result of the new core and is  fixed in this release.

I finished refurbishing the interpreter core and it should now be running a little faster than before... the old code is still in sh2old.c, for comparison while bugtesting the new method. I'll remove it when I'm sure the new interpreter is just as good or better as the old one in terms of compatibility.

After fiddling with the XGL200 source, I learned a little more about how DirectX works (and made Zelda look a little better on my computer :) I implemented some of these additions in the VDP plugin. Now that I finally have detailed information concerning the VDP, and some basic starting DirectX code, I might be able to work my way up to starting to display something. That is what I'll focus my attention on for now, as well as the missing sh2->x86 code.

Speaking of which, I finally added Ricepad's asm memSetByte() function to the i386 code. On x86 machines, it should compile it instead of the regular C function. I haven't tested it with the asm code, but assuming the compiler doesn't do anything weird, the registers that hold information should be preserved. The memGet functions, might need a little more work, but it shouldn't be too bad using the frame pointer.

(Build 20010128)
---------------
I finally worked out all the kinks in the caching system for the PATRICk core, and the only thing that's left is completing, testing, and optimizing the opcodes (and a possible rewrite of the memory functions in assembly). Please note that all the opcodes are not complete and therefore the core is *not* yet fully operational. It is disabled by *default* (if you want to trace it using MSVC, you can enable it by changing the "Settings.Engine" value to 1 in settings.c). For now the interpreter is enabled by default. I will not have nearly as much time to fiddle with Titan as I did during winter break seeing as how I'm now starting the spring semester, but because it would be a while before I finished it, I wanted to release Titan since there were so many other changes that I made in the way it was structured and such. Also, the code is fairly obfuscated and in many cases could be more efficiant, but it works, and for someone who never really programmed in assembly before, I think it's pretty good :) You're welcome to make any changes/improvements if you can follow what I was trying to do.

I think I'll work on the VDP plugin on and off during the semester, and I may cut back the build posts from once a week, to every other week. I've also been fiddling with the XGL200 Glide wrapper source, so between that, Titan, and school, you'll be seening alot fewer posts on the site, although I still intend to check the messageboard and email account, so I'm still contactable. Speaking of which, I still haven't gotten back to everyone who emailed me while I was away, but I'll try to do it by the end of the week at the latest.

There are only two plugins available, both of which are bundled with the binary. You do *not* need to worry about configuring the plugins, because there is technically nothing to configure -- they don't do anything yet, but they are still essential for Titan to run. Eventually I'll have a FAQ for all manner of commonly asked questions, but for now, the messageboard will have to do.

----

Well, I got fed up trying to figure out the VDP, so I switched to working on the new core. The new core is now codenamed "PATRICk" instead of "ReBECa" since alot of the basic theory behind how it will work has changed. You also may have noticed that I've switched to plain old C, with the exception of the VDP code (which uses DirectX and will eventually be compiled seperately anyways). I wasn't using any of the C++ features (because I personally find them somewhat cumbersome and not worth the overhead) so I figured I might as well have it compile as just plain old C.

I've also come to the realization that there are way too many global variables in the source. Alot of them, are from the soon to be separated plugins, but I made a couple small adjustments to minimize the amount of global variables. Also, in upgrading to Genitak68k 0.21, full code optimization can now be enabled in the binary build of Titan.

I needed a change of pace from doing all those opcodes in assembly, so I migrated the existing VDP and CDROM code into plugins. They don't do anything, but now it should be possible for a plugin to be made that is not open source (if anyone wants to protect their work), but for now (and probably forever), the source for the default plugins is bundled with the main source. There isn't a Sound plugin yet, because the Sound/DSP interface isn't even implemented yet, and I currently have bigger fish to fry... Now it's back to writing opcodes again...

----

Well, after some work and alot of debugging, the system by which the opcodes are decoded and translated into x86 code is now complete... There were some unforseen problems with the memory functions since they do not retain the values of some registers. I created a workaround for this, but it adds about 4 bytes to each opcode that accesses the memory functions. Until I either rewrite the memory functions in assembly, or come up with a fix that doesn't involve rewriting alot of opcodes, this will have to do.

Once the opcodes are done (or at least the vast majority of them are) I'll focus my efforts towards the VDP. Hopefully by then I'll have the documentation to be able to write code that does something.

The Win32 plugins are now completely seperated and are bundled with the binary build. The current code for the plugins is included with the source, although I intend to reserve the right to keep the source for any future plugins closed.

(Build "2000X")
---------------
Remember when I said the interpreter should be bug free? Well I was wrong... some more SH2 bugfixes as well as some more miscellaneous additions. I've been trying to figure out this VDP thing using the docs and some of anarko's code... I'm still at a loss, although I'm going to keep working on it. If I get completely fed up with it, i'll switch to the Rebecca core (I got some ideas while reading some articles, so I may finally redo the framework and start the opcodes. 

By the way, my apologies for anyone who is using the DJGPP/GNU compiler, I've just been coding away on MSVC++ without checking for compatibility... I worked on it a little, and the majority of the files will now compile on the GNU compiler, but I still have to put the makefile together (it's been a while since I last used one of those...) in a suitable fashion... Anyways, that's all for this build.

(Build 20001208)
----------------
Well, it seems as if the BIOS doesn't have a problem with the CDROM stuff from last week's build and as I was tracing, it seems as if migh be stoping at some SCSP reference... I don't think that's the problem, though -- it's more likely an SCU problem... the DMA was due for a rewrite anyways (even though that's not the problem). I haven't had time to investigate the issue further, with exams, final projects, and travel plans looming, it's a wonder I was able to do what I did at all.

The DMA rewrite is a bit complicated, because I wanted to do implemement code for all direct transfers, not just some on one memory region. Theoretically it should work, but then again, theoretically, the interpreter should be bug free... Anyways, while I was at it, I improved the interupt system and I more clearly defined the difference between checkHW() and updateHW(). For Win32, the debugger window is displaying output, but it is still disabled by default since it's more of a nuisence at the moment, that a help. The flag is in global.h if you want to see it make lots of dots...

I switched over to Genital68K from Starscream for the 68K engine... Still haven't got around to actually implementing anything of interest, but the init and reset stuff is in place.

I seriously doubt there will be a weekly build next week (or possibly even the week after that) since I'll be doing exams and trying to finish up work at the last minute ( which I should really be doing now... :/ ). 

(Build 20001201)
----------------
It's back to the future for this release... I repaired some "fixes" from the last build, fixed some longstanding issues, and reverted to an older (but slightly modified) VDP memory model (now instead of the plugin handling the memory calls, it is just notified when a register is changed). Most of the problems that cropped up in the previous build and before, should be gone now.

After a couple hours of tracing and debugging, I figured out that the BIOS is looking for the CD implementation (it's starting to get rather picky as of late...) so it looks like I'm going to switch over to that for now... I also need to adjust the memory access for the ABus region... (these memory problems are cropping up because when I originally designed the memory scheme, it was difficult to piece together the memory map for the Saturn.) I'm designing the CD code similar to the VDP code, so that it can be eventually modularized along with the VDP. Speaking of the VDP, I was able to make the code alot nicer, and the code doesn't have to be disabled for the program to work anymore, so that's a plus... more important than getting DirectX to work, is the actual emulation of the VDP, which I should get to over the next couple of weeks, depending on how far into the BIOS I get.

(Build 20001124)
----------------
Progress! Thanks to the generosity of anarko, I was able to use his code to solve the SMPC problem... now it's back to unhandled opcodes and the like, but i'd prefer that over SMPC troubles anyday. I managed to fix some of the opcodes, but there's still some stoppage, so the debugging continues...

I decided to take a little break from the core and work on the VDP... I pieced together some DirectX code (I'm learning as I go along so it's not the prettiest code, but it should work for now) and then I did a little plugin stuff, so now the abstraction layer is starting to take shape. Currently, the VDP is integrated with the program, but the abstraction layer is supposed to make it easier to "modularize" the code into a plugin. As for the actual DirectX code... let's just say after a day trying to learn DirectX, I'm a little mystified to say the least... if anyone wants to work specifically on the DirectX VDP Plugin, you're more than welcome to it.

I finally decided to stick a debugger in Titan, but it's going to be a while before it is functional... I added some code that starts up a console window, but it's disabled by default since it doesn't do anything and sort of gets in the way.

On a side note, I'd like to thank everyone who has contacted me with offers of help and encouragement. I almost thought it was some kind of mistake to be honest. I thought that with other Saturn emulators such as SSF, GiriGiri, Hyperion and the like, that this one would fall under the radar screen of most people, but I've gotten a healthy response of code, code fixes, and other neat stuff. For those who wanted to help contribute, hopefully there will be an established way to do so soon -- most likely in the form of a message board, but until then, it's going to have to be by email.


(Build 20001117)
----------------
Bingo! I found the problem, and for once, it's not the core. The BIOS is getting choked up on the SMPC. It took me a little while to figure it out, but I finally did. I expected the problem to be with the interpreter, but imagine my suprise when I realized the core was actually working correctly (for a change). So I did a little mumbo jumbo on the SMPC code and voila, it worked -- until it hit *another* SMPC refernce. I'm going to try to figure this out, since working on anything else is pretty much pointless unless I get this working. So the struggle continues...

Things are moving really well -- with the preliminary part of the block compiler ("ReBECa") working and the BIOS stopping at an SMPC reference (as opposed to a interpreter bug). The program is actually starting to show signs of doing more than just spitting out error messages.

The project got a spot on EmuHQ, so now I can sit back and watch the eager programmers roll in... :) Don't let my crusty homepage scare you away -- the last time I made a real homepage, Netscape 2.0 was all the rage. (anyone remember the big purple N from Netscape 1.0?) Seriously though, I could use all the help I can get, so if your interested, send me an email. I also apprieciate all the web hosting offers I have recieved and by the end of next week, the project will probably be located somewhere else, so I'll try to post it on the current page when the move is complete.

As the last item of the week, I want to clarify the use of Starscream in Project Titan. I posted the Starscream source as a courtesy to the talented Neill Corlett. Technically, Titan will compile without it at the moment (though that should change by the end of the month). Neill doesn't seem to mind GiriGiri bundling the precompiled object file with the source, so, to simplify things, I may do the same. But I'm going to keep the Starscream library posted so that the documentation is still available.


(Build 20001110)
----------------
Work, Work, Work... The project slowed down this week seeing as how some assignments started catching up with me this week... I did manage to fix alot of SH2 bugs in a marathon session on Tuesday. It seems as if I messed up alot more of the opcodes than I originally thought, but most of the major ones work, since the BIOS traces into the 0x06000000 region. The lack of speed of the interpreter is starting to become evident, since it takes a couple seconds for an error message to come up. I think the problem is either a faulty MOV opcode or the memGetByte() function (more likely the mem function) -- in either case I'll have to work on it a bit more.

I worked a little bit on the dynarec core and I finally figure out NASM well enough to be able to link in a little bit of the code. After some manipulation and careful dissasembly, I tested the dynaEmulate() function and it didn't crash... it worked flawlessly... or so it seemed. I'll have to start some opcodes to really make sure it's alright, but it's looking really good. Other minor objectives have been the VDP, Win32 plugin interface, 68k support (most likely to be chipped away at by the end of next week), and maybe some SCU stuff, but for now, I want to see the interpreter get further into the BIOS.

On a side note, I'm still toying with the idea of HLE, but it would only work for libraries with a sort of vector address, but the only one I've found is the backup RAM library (which I don't imagine being too useful to emulate) and I don't wish to "patch" every rom/program just because I'd like it to work without INI files and the like. SO unless someone knows something I don't, for the moment, HLE is on hold.


(Build 20001103)
----------------
I started fiddling with NASM and I actually got a file to compile... although it's not very useful at the moment. If I can find a way to get the block "prologue" and "epilogue" to run without the blue screen of death, then I'll be set. But I'm getting tired of massive crashes, so I've decided to change gears a bit. I'm moving from the DynaRec engine to the Interpretive core and hardware -- specifically, the VDP. I found out how buggy the core really was (I guess I can't watch Toonami and program at the same time :) and I've been working hard trying to fix it. The Hitachi Documentation has typos and errors that threw me off a bit, but luckily, there are plenty of debuggers out there to give me a hand.

I did more research on HLE, and it's no longer a question of if, but when (and in some cases how and is it worth it). It'll take some work, but it'll probably be the most enjoyable part of this project. I don't know how I'll do some of the HLE with the plugin system, but things simple like backup RAM stuff can definately be done. But I need to get the low level stuff running, and that will keep me busy for a while.

So... to summarize, for the next week, I'm going to focus on the current core (and maybe the VDP when I get bored :) We'll see what happens next week.


(Build 20001026)
----------------
Next on the agenda is a hardware check on every cycle ( checkHW() ) so that things like timers and such can be started. Also a dynaRec emu function ( dynaEmulate() ) so the interpretive core can be retained for compatibility. I have to get a crash course in NASM before I can really fiddle with the x86 DynaRec core. The furthest I got with dynaRec was a blue screen of death (which is progress, nonetheless) so it needs some work. I'm going to try to have weekly milestones (because I don't have enough time for daily ones and I don't think anyone else does either) that I will try to achieve to continue the progress of the emulator. This upcoming week I have a Circuit Theory test so don't expect much... 

