• Sega FD1089 decryption

    While I was gathering information about how various Sega encryptions worked, it became obvious that some had a lot in common. So I decided to regroup all the decryption routines into the same software, to be able to capitalize on previous work instead of starting from scratch when working on a new decryption.

    I just finished adding FD1089A/FD1089B decryption to the software, meaning that I can generate decrypted sets for PCBs using this kind of encryption. So far Aurail is done (sets 317-0167 and 317-0168), and checksums are automatically fixed. You’ll be able to get them from Porchy’s when the sets will be uploaded.
    I’ll try to add more decrypted sets when I have some spare time, but if you need one quick just drop me a line πŸ˜‰

    Next step decryption wise will be to move FD1094 decryption code to the new software. After that I’ll have a look at System 24 FD1094 (floppy drive based), and MC8123 (Z80 based, which I’m far from being fluent with :p

    Cheers !

  • Back in business !

    Hi there, it’s been a long time πŸ™‚

    As my interests evolved, I decided to move the devlog to WordPress, to focus on content : why reinvent the wheel when quality CMS already exist ?
    This new version will also talk about arcade stuff (mostly repair oriented), and of course electronics.

    Speaking of arcade repair, I take the opportunity to share about a nice little program I wrote.
    But first, a little history …

    As time goes by, I’m stacking lots of defective arcade games waiting to be repaired, and I’m having hard times keeping track of what is done and/or what is left to do. At first a simple excel file was enough, then I changed for Task Coach, but this one soon have shown its limits.
    After desperately looking for the perfect software, I realized it didn’t exist.
    So I decided to create it, and AGAR was born :p

    What means AGAR ? It stands for Arcade Games Analysis & Repair, and besides it’s almost the name of my favourite Final Fight character πŸ˜‰

    With this software you can :
    – create manufacturers (without duplicates)
    – create games linked to these manufacturers (without duplicates)
    – create pcbs : with the game linked, its type (original, bootleg, conversion), its origin, its location, its state (working, wip, dead, etc.), its faults when they exist, etc.
    – for each pcb, you can add analysis and link actions to them (whether completed or not), pictures, signature data, describe faults, etc.
    – you can extract analysis/actions listing for every pcb, in text, JSON or XML format

    State of pcbs is shown using configurable colours (text and background), so you can check each state visually. You can also filter pcbs display by state and/or faults.

    AGAR is perfectly usable as is, but I intend to add some more modules in the future, like (non exhaustive list) :
    – purchase management
    – note management
    – and maybe a little components stockpile management, but don’t count heavily on this one …

    Linux and Windows binaries are available, and current version is 1.1.9. Click on “Projects” at the top of the page to get the link to AGAR’s project page on Bitbucket (including download links).

    That’s all for now, I hope you’ll find it useful, as for me I’m using it everyday.

  • 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 !

  • 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)

  • 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, 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 !

  • 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 πŸ˜‰

  • 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 πŸ™‚

  • Something fishy with onchip memory

    As I was converting different VDP2 modes to the new cache, I came across testing the game 3 Dirty Dwarves. This game got a strange problem since version 0.32, as main player characters weren’t being diplayed on screen : you could move around, see bullets fired, or punch the villains, but that was it. You could only guess your position by the scrolling moves.

    At first I thought it was related to the DSP, as some games use it to do some sprite calculations, but after a quick check that wasn’t the case.

    Some more tracing lead me to some unmapped memory access (which wasn’t logged for some reason), and reading through the SH2 hardware manual gave me the aswers I was looking for : the SH2 has an internal cache (4KB of data, and 1KB of addresses), which can be configured to be used as a 4 ways cache (all the data cache is used as instructions / data cache), a 2 ways cache (the first half is used as a high speed RAM, and the other one as regular cache), or completely disabled (4KB used as high speed RAM).

    After adding this 4KB area to the memory map of the emulator, bingo ! The sprites are displayed πŸ˜€

    Check the screenshots from current dev version :

    I’ll try to add later some code to mimic the cache behaviour …

  • Gaining speed

    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 )