ToToTEK.COM Forum Index ToToTEK.COM
Help & Support Forum
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Techincal Question: How SRAM works

 
Post new topic   Reply to topic    ToToTEK.COM Forum Index -> MD-PRO Flash Cart
View previous topic :: View next topic  
Author Message
southbird



Joined: 19 Oct 2009
Posts: 3

PostPosted: Tue Oct 20, 2009 1:54 am    Post subject: Techincal Question: How SRAM works Reply with quote

How is saving recognized?

Here's what I understand:
- Tototek cart has 256KB SRAM, broken into four 32KB "pages"
- Genesis/Megadrive header specifies presence of RAM @ $1B0
- In a real cart, there is discrete logic to push writes to the area

How does the Tototek device know how to do this? If I flash Sonic 3 for example, and select "Page 0" save, it works fine. However, in an experiment ROM, I use matching header information and select a Save page, but the area acts like ROM not RAM. Is there a step required by the program to initialize or "turn on" SRAM? Is it not a literal ROM address?
Back to top
View user's profile Send private message AIM Address
Chilly Willy



Joined: 08 Feb 2009
Posts: 174

PostPosted: Tue Oct 20, 2009 5:24 am    Post subject: Reply with quote

You have to follow the "SSF2" rules. Here's my read/write routines from Wolf32X.

Code:

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


For MD stuff, clearly you don't need to worry about COMM register or the RV bit. It would be more like this.

Code:

read_sram:
        move.w  #0x2700,sr          /* disable ints */
        lea     0x200000,a0
        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.w  #0x2000,sr          /* enable ints */
        rts

write_sram:
        move.w  #0x2700,sr          /* disable ints */
        lea     0x200000,a0
        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.w  #0x2000,sr          /* enable ints */
        rts


Don't forget to alter the rom header.

Code:
| Standard MegaDrive ROM header at 0x100

        .ascii  "SEGA GENESIS    "
        .ascii  "(C)SEGA 2009.JUN"
        .ascii  "Spear of Destiny"
        .ascii  " Shareware 32X  "
        .ascii  "                "
        .ascii  "Spear of Destiny"
        .ascii  " Shareware 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             "
Back to top
View user's profile Send private message
southbird



Joined: 19 Oct 2009
Posts: 3

PostPosted: Tue Oct 20, 2009 6:04 am    Post subject: Reply with quote

Pfft, somehow I totally missed that section in the Genesis doc. Thanks a bunch! Funny, just last night I was looking up some 32X stuff and accidentally came across your Wolf3D project. Haven't checked it out yet, but I'll be sure to. Smile

Any reason other than register protection that you're disabling interrupts? Also I'm not clear, does this replace the ROM area with the SRAM then while it's active?


EDIT:
My experiments show that it works (yay) but that it only seems to support the odd addressing scheme, which is no big deal, but good to know. It also seems fine to leave perpetually enabled and not-write-protected, working essentially as a RAM extension. Good news, looks promising.
Back to top
View user's profile Send private message AIM Address
Chilly Willy



Joined: 08 Feb 2009
Posts: 174

PostPosted: Tue Oct 20, 2009 7:46 pm    Post subject: Reply with quote

southbird wrote:
Pfft, somehow I totally missed that section in the Genesis doc. Thanks a bunch! Funny, just last night I was looking up some 32X stuff and accidentally came across your Wolf3D project. Haven't checked it out yet, but I'll be sure to. Smile

Any reason other than register protection that you're disabling interrupts? Also I'm not clear, does this replace the ROM area with the SRAM then while it's active?


I disable interrupts because the vertical blank in Wolf32X reads the sticks and I didn't want the delay of processing the vblank to slow down the reading/writing of the SRAM. As long as you know how interrupts are affecting the hardware, you don't really need to disable the ints.


Quote:
EDIT:
My experiments show that it works (yay) but that it only seems to support the odd addressing scheme, which is no big deal, but good to know. It also seems fine to leave perpetually enabled and not-write-protected, working essentially as a RAM extension. Good news, looks promising.


As long as your rom is less than 2MB, you can leave the SRAM enabled. If your rom is bigger than 2MB, you HAVE to switch the SRAM on and off to keep from interfering with the rom... which is another time you'd need to disable the ints: if your rom is bigger than 2MB and an int handler has code or data above 2MB in the same space as the SRAM, you'd need to disable ints or the int handler would fail while the SRAM was enabled.

And yes, my own experiments show only the odd bytes work on the MD-Pro, meaning the SRAM is only 128KB, not 256 as advertised. Four banks of 32KB on odd bytes is what you get. That was a "bug" that drove my crazy on Wolf32X for a while - I was trying to use 64KB of save space for two saves, but it failed in odd ways... until I realized half the data was missing - the even half to be exact.
Laughing

Hmm - maybe a test is in order... instead of four banks of 32 KB on odd banks from 0x200000 to 0x20ffff, maybe it's four banks of 64 KB on odd bytes from 0x200000 to 21ffff. I never tested that out.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    ToToTEK.COM Forum Index -> MD-PRO Flash Cart All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001, 2005 phpBB Group