don't click here

VRAM transfer problem

Discussion in 'Engineering & Reverse Engineering' started by Xenowhirl, Dec 24, 2006.

Thread Status:
Not open for further replies.
  1. Xenowhirl

    Xenowhirl

    Tech Member
    175
    0
    0
    I'm trying to make some animated tiles in Sonic 1 load to elsewhere than the normal $F000 location in VRAM. I thought it'd be as easy as changing the destination address, but nothing ever gets written past $F2E0 even though that VRAM is unused, and I'm completely stuck trying to find why. Here's the code I'm looking at, I only added 1 line.

    Code (Text):
    1. LoadSonicDynPLC:
    2.         moveq   #0,d0
    3.         move.b  $1A(a0),d0; load frame number
    4.         cmp.b   ($FFFFF766).w,d0
    5.         beq.s   SPLC_return
    6.         move.b  d0,($FFFFF766).w
    7.         lea (SonicDynPLC).l,a2
    8.         add.w   d0,d0
    9.         adda.w  (a2,d0.w),a2
    10.         moveq   #0,d1
    11.         move.b  (a2)+,d1; read "number of entries" value
    12.         subq.b  #1,d1
    13.         bmi.s   SPLC_return
    14.         lea ($FFFFC800).w,a3; I think C800 = VRAM + F000
    15.         move.b  #1,($FFFFF767).w
    16.  
    17.     ; why doesn't this work?
    18.         lea $2E0(a3),a3; start loading tiles into VRAM at $F2E0 instead of $F000
    19.  
    20. SPLC_ReadEntry:
    21.         moveq   #0,d2
    22.         move.b  (a2)+,d2
    23.         move.w  d2,d0
    24.         lsr.b   #4,d0
    25.         lsl.w   #8,d2
    26.         move.b  (a2)+,d2
    27.         lsl.w   #5,d2
    28.         lea (Art).l,a1
    29.         adda.l  d2,a1
    30.  
    31. SPLC_LoadTile:
    32.         movem.l (a1)+,d2-d6/a4-a6
    33.         movem.l d2-d6/a4-a6,(a3)
    34.         lea $20(a3),a3; next tile
    35.         dbf d0,SPLC_LoadTile; repeat for number of tiles
    36.         dbf d1,SPLC_ReadEntry; repeat for number of entries
    37.  
    38. SPLC_return:
    39.         rts
    It works if I try to load compressed art to that same location, I don't know why this doesn't work.
     
  2. Stealth

    Stealth

    Tech Member
    594
    31
    28
    Sonic Mania, HCGE, Sonic Megamix, SonED2, [...]
    Why are you copying to System RAM $FFFFCAE0?
    Sometimes what you're looking for isn't where you might think it is
     
  3. Hivebrain

    Hivebrain

    Administrator
    3,074
    210
    43
    53.4N, 1.5W
    Github
    Sonic's graphics are transferred from RAM to VRAM during VBlank. If you want to change the VRAM destination, you'd need to change the DMA routine (which is in VBlank).
     
  4. Hayate

    Hayate

    Tech Member
    C800 is simply the address for writing to VRAM.

    VRAM is not part of "ordinary" RAM so you can't write to it with simple move instructions.

    If I had my disasm on this computer, I'd post a bit of code I wrote (well, wrote/modified) for the purpose of loading uncompressed art from the ROM into VRAM.
     
  5. Xenowhirl

    Xenowhirl

    Tech Member
    175
    0
    0
    I looked through the VBlank code (starts at B10 in the ROM, right?) but it didn't make enough sense to me for me to pick out where it actually writes to VRAM. Something about C00004, but nowhere do I see reference to the transfer length ($17 tiles). I managed to cram the only animations I needed this for into the same area as Sonic's tiles in VRAM, so I don't really need it now, but I'd still like to know how to do this sometime.
     
  6. Hivebrain

    Hivebrain

    Administrator
    3,074
    210
    43
    53.4N, 1.5W
    Github
    You won't actually be able to see data size or addresses in the VDP instructions, because they use some peculiar format where the bits for those things are all jumbled up. There's a guide to VDP instructions on Hacking CulT.
     
  7. LocalH

    LocalH

    roxoring your soxors Tech Member
    3,314
    37
    28
    Nunya
    Rock Band 3 Deluxe
    Here's the breakdown of command writes to $C00004 to set up VDP RAM accesses (X = don't care):

    Code (Text):
    1.     CD1 CD0 A13 A12 A11 A10 A09 A08  (D31-D24)
    2.  
    3.     A07 A06 A05 A04 A03 A02 A01 A00  (D23-D16)
    4.  
    5.      X   X   X   X   X   X   X   X    (D15-D8)
    6.  
    7.     CD5 CD4 CD3 CD2  X   X  A15 A14  (D7-D0)
    CD basically tells the VDP what part of RAM you want, and what you're going to do to it:

    Code (Text):
    1. +-------------+---+---+---+---+---+---+
    2. | ACCESS MODE |CD5|CD4|CD3|CD2|CD1|CD0|
    3. +=============+===+===+===+===+===+===+
    4. | VRAM WRITE  | 0 | 0 | 0 | 0 | 0 | 1 |
    5. +-------------+---+---+---+---+---+---+
    6. | CRAM WRITE  | 0 | 0 | 0 | 0 | 1 | 1 |
    7. +-------------+---+---+---+---+---+---+
    8. | VSRAM WRITE | 0 | 0 | 0 | 1 | 0 | 1 |
    9. +-------------+---+---+---+---+---+---+
    10. | VRAM READ   | 0 | 0 | 0 | 0 | 0 | 0 |
    11. +-------------+---+---+---+---+---+---+
    12. | CRAM READ   | 0 | 0 | 1 | 0 | 0 | 0 |
    13. +-------------+---+---+---+---+---+---+
    14. | VSRAM READ  | 0 | 0 | 0 | 1 | 0 | 0 |
    15. +-------------+---+---+---+---+---+---+
    The docs also say you have to use at least 16-bit access when reading or writing from the VDP for correct operation. Charles MacDonald has done some testing, and basically if you write a byte to the VDP, it treats it as a 16-bit access, with the same value in MSB and LSB. For example:

    Code (Text):
    1. ; VDP sees data as 8787h
    2. move.b  #$87, $C00004
     
  8. drx

    drx

    mfw Researcher
    2,254
    350
    63
    :rolleyes:
    So yea, if you still have troubles finding that, there are 4 DMAs inside the VBlank that copy the patterns from RAM to VRAM.

    Here's an example:

    Code (Text):
    1. ROM:00000E34                 tst.b   ($FFFFF767).w
    2. beq.s   DontDMASonic
    3. lea  ($C00004).l,a5
    4. move.l  #$94019370,(a5)
    5. move.l  #$96E49500,(a5)
    6. move.w  #$977F,(a5)
    7. move.w  #$7000,(a5)
    8. move.w  #$83,($FFFFF640).w
    9. move.w  ($FFFFF640).w,(a5)
    10. move.b  #0,($FFFFF767).w
    11.  
    12. DontDMASonic:
    Here you can read more about DMAs
     
Thread Status:
Not open for further replies.