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

(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... 

