Category: Emulation

Last months, I’ve been working on Saturnin with one goal : going open source (yay)
So, after spending countless time on it, everything’s done, and I finally moved my sourcecode to BitBucket (I’ll get back to that point another time).

But there’s still one thing to take care of (well amongst others :p), before opening the depot to the public : I need to choose a licence.
Of course, there are constraints :
– the future version will use plug-ins, and I don’t want to force anyone contributing one to provide its sourcecode
– some of the actual code used in Saturnin wasn’t done by myself (the SCSP core is Stef’s for instance, the 68K code is from either Turbo68K or Musashi) … I will put it into separate dlls also, but that must be taken into account
-some other things that I don’t remind now :p

After looking into existing licenses, I think GPL is too restrictive to my point of view, but LGPL could be a good candidate.

As I’m pretty new to that kind of stuff, I’m seeking advice … so If you have anything relevant to say about that, please leave me a comment.

Thanks !

My dev machine was overwhelmed by a nasty variant of virut … luckily enough I was able to save everything, but the computer had to be reformatted 🙁 Long story short, I’m now using Windows 7 64 bits 🙂

Saturnin works well under 7, I was a bit worried that it wouldn’t, and I migrated it to Visual Studio 2010.
I put aside the DSP for now, as I decided to do the “preparation to open source” migration (ie renaming french comments / variables into english, using boost naming convention for types, documenting headers using Doxygen, etc.)
I’m not far from the end now, but this kind of work is a real pain, as you don’t have any results visible (until you break something) For instance, I spent a whole month understanding why some polygons weren’t well displayed anymore, while others were just fine … it turned out that I made a cast error in a SH2 opcode, sometimes resulting in coordinates miscalculation …

Anyway, time to go back to work 🙂 (and thanks for the kind comments, I know I’m not posting as much as I want to, but I really appreciate)

Well, the title is maybe a bit strong, but this processor is a really complex piece of work …
The disassembler is done, the interpreter skeleton is ready, and I’m done coding the Operation commands (24 opcodes).

I’m now working on the Load Immediate commands (11 opcodes), DMA, JUMP and LOOP commands will follow shortly (I hope :p)

Understanding how the opcodes really work is difficult, thanks to poor / erroneous documentation, and I won’t be able to test anything until every opcode (and the main loop) is coded … Timing must also be taken care of, as DSP clock is only half of the main SH2’s … so there’s still a lot to do until I can get any sound during the logo assembly :p

I’ve also started toying around with various UI libraries (finally :p), and I think I’ll chose Juce for the next UI overhaul … primary testing with OpenGL gave good results, I’ll have to fire up my image creation software to create some nice icons (ph34r my mad Gimp skiils :D) I’ll try to post some screenshots when I’ll have something more tangible 😉

Until then … have a nice day !

Before moving on to something else, I wanted to understand why Dracula X title screen still had some priority problems, as it shouldn’t be happening with my new cache. After a bit of debugging, I was able to get to the origin of the problem : the sprite priority calculation wasn’t done on the right register.
Now everything is correct, as you can see on the following screenshots (left one is from 0.40 version) :

I also tweaked the cd block a bit, changing some return flags, and now it doesn’t get stuck anymore : it still doesn’t play smoothly, but it gets to the end of the video without blocking the emulation.

Last but not least, I started working on the DSP. Nothing fancy just yet (adding memory and registers, getting to know how the beast work), but the hardest part was to get into it, so I guess I’m on the right track 🙂

Oh, I almost forgot : a few years back, I did some testing for Charles Mc Donald using an Action Replay + and an ISA CommLink card … unfortunately, the card fried (a chip got cracked in two), I hadn’t got another one for replacement, so I forgot about it. After that I changed my computer, and the new one didn’t have any ISA port, so I forgot about the possibility to get the computer and the Saturn communicate … until today 🙂
Thanks to www.GamingEnterprisesInc.com, I replaced my old ISA CommLink card by a brand new USB DataLink device, meaning that I can now send data again to the Saturn !

I still have to setup a Saturn dev environment, and familiarize with Saturn programming as it’s not really the same than programming a  Saturn emulator, but I’m sure it won’t be a problem 😉

At least ! After months of work, my cache is finally up and working ! I spent the last weeks trying to understand why some pages weren’t properly reloaded. After adding a cell viewer to the debugger, it dawned on me that I wasn’t detecting any color ram change, hence the cache trouble I was experiencing …

Now everything works fine, and I can move on something else. I will come back to it later, as there’s a lot of room for improvement, but currently I need to work on something else for a change 🙂

What’s next :
– understanding why the cdblock gets full while playing some videos, and doesn’t clears itself
– start working on the DSP, as it’s used in quite a lot of games
– adding the rotating backgrounds (yeah, some mode vdp2 :/)
– adding the line / cell scroll (used by some Capcom games)

I also have to understand why some games (like Radiant Silvergun or Metal Slug) run that slow ingame … it’s not a display problem, as when it’s disabled the speed stays the same, but it’s annoying.

Well, that’s all for now 🙂

VDP2 cache debugging wasn’t that easy : I had to redesign the way threads were handled in order to get it working, as you can’t share a rendering context between OpenGL and Windows. I decided to use Boost for those too, as I don’t need something complicated. Now it works the way I wanted, ie you can display backgrounds by priority.

Bitmaps and cell mode now work using the cache, I used similar functions than for the VDP1 in order to handle cached textures.

I also used the block transfer mode from OpenGL, in order to speed up transfers to the graphic card memory. The results are interesting, as during the logo assembly of the bios the speed is over 70 fps, and around 45 fps (with bitmaps enabled) ) in the cd player.

I still have to convert all the display modes from the VDP2 to the cache system, and when it’s done I’ll move on (there’s still plenty of stuff to do :p )

May 2009 be a great year to everyone 🙂

There’s not a lot of news regarding Saturnin, as last month and a half corresponded to a peak of work into my real job. So my free time was drastically reduced during this period, and I couldn’t work on Saturnin as much as I wanted …

But that didn’t mean that I didn’t do anything : I created a local subversion server and put the source code on it, as I never gave up the idea to move the project to open source (don’t expect anything soon though :p)
I also started using a task manager to handle all the notes lying around and the todo list (it’s Task Coach for those interested), with the hope to have everything a bit more formalized.

On the code itself, I did some rearrangement to clean everything up, to put all the related functions into the same files, etc. …
And now I’m back on adding the bitmaps to the rendering engine, but there are some difficulties that can’t be solved right now, forcing me to create a more advanced VDP2 texture debugger.
So I’m 100% on that right now.

The cache is finally working for the VDP2 cell mode (the one used in the bios). I had some transparency problem due to textures not being reloaded when the transparency bit of the screen was changed, but that’s now corrected.
Performances are quite interesting in the current cache state, ie around 50 fps when the “Sega Saturn” text is displayed, and between 30 and 40 fps inside the cd player.

You might say it’s not that fast, but actually as the whole page is displayed (ie 512*512 pixels) instead of just the visible part (ie 320*224 in that case), a lot of extra calculation is done, which slows down the display. Of course I’ll change that in the future, but right now it’s already faster than it was in the previous release, so that’s a good start 🙂

Now that’s the cache is running for cell mode, I’m now in the process of integrating bitmap mode to it … I took the opportunity to redesign the way both modes are setup, and to put it in different functions.
My goal is to have the whole bitmap to be added as a single texture to the texture map. That implies to modify the texture class structure, as until now each VDP2 texture was considered to be 8*8.

Now the bitmap texture will just be considered as a big cell (up to 1024*512), and displayed like the others.

So what are the next steps ?

• add bitmaps to the VDP2 cache
• convert the other display modes to use the cache
• test the cache speed, and improve it

That’s all for now (but that’s a lot, believe me :p)