SpritesMind.Net

Posted: **Sun Mar 08, 2009 12:37 pm**

I've been working on adding SRAM support to Wolf32X. While I've managed to make it work with emulators, it doesn't work on a real 32X.

I've tried just setting 0xA130F1 and reading/writing 0x200000. This works with emulation, but not on real hardware (my MD-pro 64 cart).

I've tried setting RV (which makes the ROM appear in the normal area for the 68000), setting 0xA130F1, and reading/writing 0x200000. Again, this works for emulation, but not on real hardware.

I've tried setting the rom bank, setting 0xA130F1, and reading/writing 0x900000. That doesn't work for either emulation or real hardware.

The MD-Pro works with SF4, so it shouldn't be a problem with 0xA130F1 or where the SRAM is located. It seems to be a 32X issue. Anyone have any suggestions?

EDIT: In case it helps, here's the current code I'm using:

Code: Select all

read_sram:
        move.w  #0x2700,sr      /* disable ints */
        moveq   #0,d0
        move.w  0xA15122,d0     /* COMM2 holds offset */
        lea     0x200000,a0
        bset    #0,0xA15107     /* set RV */
        move.b  #1,0xA130F1     /* SRAM enabled */
        move.b  0(a0,d0.l),d0   /* read SRAM */
        move.b  #0,0xA130F1     /* SRAM disabled */
        bclr    #0,0xA15107     /* clear RV */
        move.w  d0,0xA15122     /* COMM2 holds return byte */
        move.w  #0,0xA15120     /* done */
        move.w  #0x2000,sr      /* enable ints */
        bra     main_loop

write_sram:
        move.w  #0x2700,sr      /* disable ints */
        moveq   #0,d1
        move.w  0xA15122,d1     /* COMM2 holds offset */
        lea     0x200000,a0
        bset    #0,0xA15107     /* set RV */
        move.b  #1,0xA130F1     /* SRAM enabled */
        move.b  d0,0(a0,d1.l)   /* write SRAM */
        move.b  #0,0xA130F1     /* SRAM disabled */
        bclr    #0,0xA15107     /* clear RV */
        move.w  #0,0xA15120     /* done */
        move.w  #0x2000,sr      /* enable ints */
        bra     main_loop

Yes, I've tried adding NOPs. I've tried making things into subroutines. Nothing works on real hardware, but virtually everything works with the emulator. I've run Sonic 3 on the cart and it writes the SRAM just fine. From looking at the SRAM afterwards, it's like the code above isn't writing the SRAM at all. None of the bytes are altered.

Posted: **Mon Mar 09, 2009 8:53 am**

Okay, found the issue myself. I'm posting this for the next guy who comes along with this issue. The problem was that even bytes don't work with real hardware... even though they should. Switching to odd bytes works. So the code I'm currently using looks like this:

Code: Select all

read_sram:
        move.w  #0x2700,sr      /* disable ints */
        moveq   #0,d1
        moveq   #0,d0
        move.w  0xA15122,d0     /* COMM2 holds offset */
        lea     0x200000,a0
        move.b  #1,0xA15107     /* set RV */
        move.b  #3,0xA130F1     /* SRAM enabled, write protected */
        move.b  1(a0,d0.l),d1   /* read SRAM */
        move.b  #2,0xA130F1     /* SRAM disabled, write protected */
        move.b  #0,0xA15107     /* clear RV */
        move.w  d1,0xA15122     /* COMM2 holds return byte */
        move.w  #0,0xA15120     /* done */
        move.w  #0x2000,sr      /* enable ints */
        bra     main_loop

write_sram:
        move.w  #0x2700,sr      /* disable ints */
        moveq   #0,d1
        move.w  0xA15122,d1     /* COMM2 holds offset */
        lea     0x200000,a0
        move.b  #1,0xA15107     /* set RV */
        move.b  #1,0xA130F1     /* SRAM enabled, write enabled */
        move.b  d0,1(a0,d1.l)   /* write SRAM */
        move.b  #2,0xA130F1     /* SRAM disabled, write protected */
        move.b  #0,0xA15107     /* clear RV */
        move.w  #0,0xA15120     /* done */
        move.w  #0x2000,sr      /* enable ints */
        bra     main_loop

Doing the exact same code except with 0() instead of 1() as the addressing mode fails. By the way, here's the change in the header:

Code: Select all

| Standard MegaDrive ROM header at 0x100

        .ascii  "SEGA GENESIS    "
        .ascii  "(C)SEGA 2009.MAR"
        .ascii  "Wolfenstein 3D S"
        .ascii  "hareware 32X    "
        .ascii  "                "
        .ascii  "Wolfenstein 3D S"
        .ascii  "hareware 32X    "
        .ascii  "                "
        .ascii  "GM MK-0000 -00"
        .word   0x0000
        .ascii  "J6              "
        .long   0x00000000,0x003FFFFF   /* ROM start, end */
        .long   0x00FF0000,0x00FFFFFF   /* RAM start, end */
        .ascii  "RA"                    /* External RAM */
        .byte   0xF8                    /* don't clear + odd bytes */
        .byte   0x20                    /* SRAM */
        .long   0x00200001,0x0020FFFF   /* SRAM start, end */
        .ascii  "    "
        .ascii  "                "
        .ascii  "                "
        .ascii  "                "
        .ascii  "JUE             "

Note the info on the save ram. I'd noticed that every cart I've checked uses odd bytes. I guess there's a reason for that.

Okay, I'm going to go compile SOD and put together a beta 2 arc for this. It'll be up in a little while.

Posted: **Mon Mar 09, 2009 10:05 am**

MDpro and all other MD carts with SRAM never had it on even addresses. MDpro does not have Word wide SRAM in it.

PS: what you put in the header is pretty meaningless, at least it iwll be on real HW.

Posted: **Mon Mar 09, 2009 11:02 am**

TmEE co.(TM) wrote:MDpro and all other MD carts with SRAM never had it on even addresses. MDpro does not have Word wide SRAM in it.

According to the feature list, software, and ucon64, it is SUPPOSED to have word wide SRAM. Four banks of 64KB as words so that games writing to either byte are supported. When ucon64 sets a bank of sram from a file, it puts the same byte into both bytes so that it doesn't need to worry about which the game actually uses. When you save the sram, you pass a switch telling it whether to save the upper or lower byte. If it really doesn't have word wide sram, all these things are useless, and TotoTek is providing people bad info.

PS: what you put in the header is pretty meaningless, at least it will be on real HW.

True, but it's good to set it anyway. Do things the proper way even if it's not really needed. At least this way, emulators and programmers get proper info it can then display to the user. For example, when I burn the image to the cart, ucon64 tells me all this info that's in the header, including the cart ram info.

SpritesMind.Net

Accessing SRAM

Accessing SRAM