Opening soon (sort of :p)
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 !
Back to top View/add comments (1)
Damn virus ...
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)
Back to top View/add comments (4)
DSPeration
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, mostly because of 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 !
Back to top View/add comments (2)
Priority difficulty
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 ;)
Back to top View/add comments (2)
End of the (cache) tunnel
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 :)
