• Tag Archives arcade
  • New config files and MC8123 WIP

    Happy new year everyone !


    Regarding configuration files for SegaDecrypt, I decided to give libconfig a go as a replacement for my big clumsy xml file. I went for version 1.5 as the last version (1.6) has some problems preventing it to compile on my dev setup.

    Now each set has its own configuration file, as you can see in the following example, extracted from a real set :

    // Super Hang On Sitdown 317-0039
    name =  Super Hang On Sitdown;
    version =  317-0039;
    protection =  FD1094;
        files = [
        key =  317-0039.key;
        size = 0x20000;
        process_data_manually = true;
        irq_vector_lower_bound = 0x108a;
        irq_vector_upper_bound = 0x108a;
        post_decryption_copy = ( 
            (0x400, 0x1000,  DATA ),
            (0x1A22, 0x20000,  DATA )
        type =  outrun ;
        storage_address = 0xFF0;
        start_address = 0x1000;
        initial_block_size = 0x1F000;

    Almost everything can be overridden, allowing to handle specific cases required for some sets.

    Now that the configuration problem is solved, I started working on the MC8123 decryption. The MC8123 is a Z80 with built-in encryption, Program opcodes and data are encrypted differently, which explains why bootleggers used doubled eproms back in the days : one half was used for the decrypted program, the other half for the decrypted data, and the correct addressing was chosen at runtime.

    Using the same technique I used to decrypt FD1094 files, I should be able to generate decrypted files for MC8123.

    There are some difficulties though :

    • Opcodes operands are considered as data, and they don’t have a fixed size → a pass to check opcode type and operand size has to be done.
    • There are data chunks interleaved with Z80 encrypted code, and unlike FD1094 encrypted code, there are no data markers allowing to know their boundaries → solution will be to consider everything as data first, and then to follow code flow from interrupts start vectors, jumps, branches, etc. in order to get the program code.
    • Previous point has some weaknesses though : some opcodes (like JP (HL) for instance) are supposed to do an unconditional jump, which destination is based on a processor register. Problem is, the register content is set up at runtime, meaning that you can’t know its value without effectively running the code.

    Time to get my hands dirty !

  • New Super Hang On version decrypted

    I migrated enough of the FD1094 part of SegaDecrypt to work on the decryption of a freshly released Super Hang On version. It’s the sitdown one (317-0039).

    The decrypted set is available as usual at Jammarcade.

    I have more sets in the pipeline, but I want first to change the way configuration is handled, as I’m fed up to deal with a big clumsy xml file. A lot of sets use specific code, and moving it to a xml file won’t be easy to maintain. So I’ll move to a plain text per game configuration file, using libconfig.


    That’s all for now !

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

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