Sonic and Sega Retro Message Board: sonicblur - Viewing Profile - Sonic and Sega Retro Message Board

Jump to content

Hey there, Guest!  (Log In · Register) Help

sonicblur's Photo
Group:
Oldbie: Oldbie
Active Posts:
849 (0.31 per day)
Most Active In:
General Sonic Discussion (210 posts)
Joined:
18-February 08
Profile Views:
5945
Last Active:
User is offline Yesterday, 05:23 PM
Currently:
Offline

My Information

Age:
29 years old
Birthday:
April 17, 1986
Gender:
Male Male

Contact Information

E-mail:
Private
AIM:
AIM  sonicblr
ICQ:
ICQ  21980539

Previous Fields

National Flag:
us
Wiki edits:
6
SA2 Emblems:
2

Latest Visitors

  1. Recent Status Updates
  2. About Me
  3. Topics
  4. Posts

Topics I've Started

  1. AMBextract

    09 October 2010 - 01:50 PM

    Here's an AMB extractor that I threw together early this morning.

    Windows:
    ambextract-windows.zip
    Linux:
    ambextract-linux.tar.gz
    Mac OS X:
    Download the Linux version and run it with Mono. The Windows and Linux builds were built with MonoDevelop on OS X, and I did all of the development under OS X so I know it works there.

    Usage:
    ambextract filename.amb
    Optionally, you can provide multiple filenames to extract multiple files at once.
    -l argument will force filenames to lowercase. I added this because PVRTexTool doesn't see uppercase .PVR files in it's file open dialog.
    -f argument will display filenames only without extracting, so you can see what's in a file.

    What is this for? Almost everything in Sonic 4 seems to be packed into these AMB files.

  2. PAR Code Handling

    29 August 2010 - 02:36 PM

    So I noticed this post in the ERE forum mentioning that a PAR that works in Kega didn't work correctly in Gens.

    It appears that Gens does not handle PAR codes like the hardware does. In gens, the write size for RAM writes is based on how many characters are after the :, but since the real hardware forces you into FFXXXXXXXX format, you don't have a choice on that. Gens also supports 32-bit writes, which isn't possible on the real PAR hardware.

    As described in this post, if a PAR code is <= 0xFF, it is considered to be 8-bit and written that way. Thus a code with a value of :00FB would only write FB at the 8-bit address specified.

    The problem lies in gg_code.c:
    CODE
        int data_chr_len = strlen(code) - pos_colon - 1;    // Length of the data segment.
        
        if (data_chr_len <= 2)
        {
            // 1-2 characters: 8-bit code.
            datasize = DS_BYTE;
            data &= 0xFF;
        }
        else if (data_chr_len <= 4)
        {
            // 3-4 characters: 16-bit code.
            datasize = DS_WORD;
            data &= 0xFFFF;
        }
        else if (data_chr_len <= 8)
        {
            // 5-8 characters: 32-bit code.
            datasize = DS_DWORD;
        }


    Could you add
    CODE
    if(data <= 0xFF){
       datasize = DS_BYTE;
    }
    to the end of the data_chr_len <= 4 case so that it properly handles PAR codes in the original format?

    Would you agree with this change? I guess it may break 16-bit codes designed specifically for Gens, but for accuracy it would be correct.

Friends

sonicblur hasn't added any friends yet.