The VDP Questions Topic

Discussion in 'Discussion & Q&A' started by MarkeyJester, Jul 20, 2010.

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

    Hanoch Well-Known Member Member

    Joined:
    Aug 3, 2008
    Messages:
    312
    Location:
    Israel
    Sorry for double posting but I didn't understand something.


    Lets say I set a map plane A location, how big will it be? Does it end where the next one (ie map window) starts? Or maybe it depends on how much data I put there? Also what kind of data is in there (I assume enigma mappings)?


    And, are the registers all you had to explain for vdp and that's it, from here on its just questions we ask?
     
    Last edited by a moderator: Oct 1, 2010
  2. MarkeyJester

    MarkeyJester !%#@ Member

    Joined:
    Jun 27, 2009
    Messages:
    2,660
    This register you should be concerned with...

    if for example WX is 00 and YZ is 01 then the map plane size is "Vertical x Horizontal" 32 x 64 tiles large (20 x 40 in hex), each tile's map is worth two bytes, so the simple math here is: "Vertical x Horizontal = S x 2 = A" (20 x 40 = 800 x 2 = 1000).


    1000 bytes would be the size, so if you have the plane A location set to C000, the map area would be between C000 and CFFF.

    No, Enigma is the name given to a decompression algorithm used frequently by SEGA, it is used to reduce the size of data in the MC68 rom, this map data is decompressed from Enigma into a ram space somewhere and then sent to V-Ram as uncompressed, the VDP in the megadrive is not able to decompress Enigma's algorithm.

    It wouldn't be called "The VDP Questions Topic" otherwise =P
     
  3. Hanoch

    Hanoch Well-Known Member Member

    Joined:
    Aug 3, 2008
    Messages:
    312
    Location:
    Israel
    Does it also apply for the window plane (that was my main question)? Because what i'm trying to do is, load tiles in a vram address (or uncompressed from the ROM, but that depends on the limits) and use enigma mappings to arrange them on the screen and display them on the window map plane.


    From what I understand:


    A VRAM address has a bunch of tiles, and they all can be used in all map planes (that explains why when pausing in sonic crackers, the combi chain uses wrong graphics). Now when talking about VDP addresses (IE, plane A is in C000)


    do you mean something like this:




    move.l #$C0000001,($C00004).l ; load the first row of 8 pixels in $C000-C007



    please note, I might be wrong with the '1' at the end, I know 3 is positioning mode.
     
    Last edited by a moderator: Oct 2, 2010
  4. MarkeyJester

    MarkeyJester !%#@ Member

    Joined:
    Jun 27, 2009
    Messages:
    2,660
    V-Ram location C000, in order to set the VDP to write to that location, you need to follow the instructions on "The first post" which i clearly made sure was the first thing to be explained. The resulting answer would be 70000003 for V-Ram location C000.


    Also, all data in V-Ram, C-Ram and VS-Ram is uncompressed (This applies to everything including the window plane), if you have the data uncompressed in the rom, you can send it directly to V-Ram, if it is compressed in rom, you need to decompress it and then send to V-Ram.
     
  5. Selbi

    Selbi Plug in, baby. Retired Staff

    Joined:
    Jul 20, 2008
    Messages:
    2,394
    Location:
    Northern Germany
    I had a few issues with converting VRAM values into VDP values, e.g. $A660 (VRAM) into $66600002 (VDP). While I can do it, it takes me like 5 minutes until I'm 100% sure that I did everything correct. MarkeyJester, the VDP hero of the scene, can do it within a few seconds and I asked him if he could do a little program which does all this for you (after all, it's not really an "I'll do everything for you"-program, because it just saves you a lot of time).


    Link: http://mrjester.hapisan.com/01_PBLC/VDP.rar


    Using this program is pretty easy, but it was made in a rush and requires some information:

    My personal thanks to MarkeyJester, as this program already saved me 15 minutes of senseless value converting. =)
     
  6. Hanoch

    Hanoch Well-Known Member Member

    Joined:
    Aug 3, 2008
    Messages:
    312
    Location:
    Israel
    Haha I was planning something similiar to that but I needed more time to learn C# and how to work with bits.


    Good program though.
     
  7. Sonic master

    Sonic master Well-Known Member Member

    Joined:
    Mar 27, 2010
    Messages:
    303
    I have this code to display an image with a map


    The tiles load fine and it works with plane a but I want to use plane b




    lea ($FF0000).l,a1


    lea (level1map).l,a0 ; load mappings for Japanese credits


    move.w #0,d0


    bsr.w EniDec


    lea ($FF0000).l,a1


    move.l #$40000003,d0


    moveq #$27,d1


    moveq #$1B,d2


    bsr.w ShowVDPGraphics2



    I changed this from



    move.l #$40000003,d0


    to
    Code:
    	move.l	#$60000003,d0
    

    and it still does not work


    also I am using basiegaxorz with some stuff borrowed from sonic 2 (show vdp grapics)
     
  8. MarkeyJester

    MarkeyJester !%#@ Member

    Joined:
    Jun 27, 2009
    Messages:
    2,660
    Ah now, this is because you haven't set the VDP display mode on, as I mentioned a few posts back, you can enable it by this register here:

    Of course, a more simpler way would be to follow the way Sonic Team enabled it, by using this:



    move.w ($FFFFF60C).w,d0
    ori.b #$40,d0


    move.w d0,($C00004).l



    This will load data "81??" (with ?? being whatever it was set to) to d0, while the OR will set the display mode bit on, and then it's saved to the VDP address area.
     
  9. Sonic master

    Sonic master Well-Known Member Member

    Joined:
    Mar 27, 2010
    Messages:
    303
    I got the problem solved layer a was hiding layer b


    but now I am music sonic 1's show vdp grapics and the tiles are at at 128 tiles offset (80 hex)


    i am currently trying to edit this code:




    ; ---------------------------------------------------------------------------


    ; Subroutine to display patterns via the VDP


    ; ---------------------------------------------------------------------------


    ; ||||||||||||||| S U B R O U T I N E |||||||||||||||||||||||||||||||||||||||


    ShowVDPGraphics: ; XREF: SegaScreen; TitleScreen; SS_BGLoad


    lea ($C00000).l,a6


    move.l #$800000,d4;I think I need to edit this?


    loc_142C:


    move.l d0,4(a6)


    move.w d1,d3


    loc_1432:


    move.w (a1)+,(a6)


    dbf d3,loc_1432;draws a row


    add.l d4,d0


    dbf d2,loc_142C;go to next row


    rts


    ; End of function ShowVDPGraphics



    EDIT:


    fixed it myselft like this




    ; ---------------------------------------------------------------------------


    ; Subroutine to display patterns via the VDP


    ; ---------------------------------------------------------------------------


    ; ||||||||||||||| S U B R O U T I N E |||||||||||||||||||||||||||||||||||||||


    ShowVDPGraphics: ; XREF: SegaScreen; TitleScreen; SS_BGLoad


    lea ($C00000).l,a6


    move.l #$800000,d4


    loc_142C:


    move.l d0,4(a6)


    move.w d1,d3


    loc_1432:


    addi.w #$80,(a1); add to offset tiles


    move.w (a1)+,(a6)


    dbf d3,loc_1432


    add.l d4,d0


    dbf d2,loc_142C


    rts


    ; End of function ShowVDPGraphics



    edit2:


    better sulution that does not glitch




    lea ($FF0000).l,a1


    lea (titlemap).l,a0 ; load mappings for Japanese credits


    move.w #$80,d0;offset in tiles (hex)


    jsr EniDec



    edit3:


    How do you clear this area of the vram
     
    Last edited by a moderator: Jan 17, 2011
  10. Hanoch

    Hanoch Well-Known Member Member

    Joined:
    Aug 3, 2008
    Messages:
    312
    Location:
    Israel
    I watched a few genesis games on youtube with outstanding 3D effects (Virtual Racing). And I assume its also possible in sonic? Not to mention, if genesis cant do what nintendoes, mostly the super FX stuff, then why not move some engines to super nintendo?


    Anyway I relised that to stretch/skew stuff (like the water in ghz) you need to find the number of lines, and the first line will move right a few pixels per frame while the last line will move left the same value of pixels per frame, reversed.


    The lines in between will just decrease the pixels per frame value by an amount untill the middle where it reverses stuff.


    This makes me wonder, what would it take to make this thing apply on sprites? I know you can just build a bunch of objects like the chain platform object and use obj15 code as a referrence, but is there a more efficient way that takes less object space?
     
    Last edited by a moderator: Jan 23, 2011
  11. OrdosAlpha

    OrdosAlpha RIGHT! Naebody move! Administrator

    Joined:
    Aug 5, 2007
    Messages:
    1,779
    Location:
    Glasgow, Scotland
    The Super Famicom has a slower CPU, so any Mega Drive engine, when ported, wouldn't run at the same speed as it does on the Mega Drive. So, why bother?


    Plus, Virtua Racing used more than the MD, it used the Sega Virtua Processor on cart to handle the polygon to 8x8 tile generation.
     
    Last edited by a moderator: Jan 24, 2011
  12. SpirituInsanum

    SpirituInsanum Well-Known Member Member

    Joined:
    Feb 11, 2010
    Messages:
    642
    I have a question regarding this:


    [​IMG]


    You probably noticed it before, that square in the top-right corner. This is in the original s1, it can be bigger or smaller.


    Is the "map plane" 's wrapping system causing this glitch?
     
  13. MarkeyJester

    MarkeyJester !%#@ Member

    Joined:
    Jun 27, 2009
    Messages:
    2,660
    I "believe" it's draw code specific, Sonic 1 calls it's level drawing routine after the DMA transfers during the vertical blanking interval (V-Blank), it's possible that it isn't fast enough to write those last few tiles before the end of the screen's V-Blank. Of course, this is only a theory on my part, being the only one that makes sense, so feel free to correct me if there happens to be a more valid reason.
     
  14. SpirituInsanum

    SpirituInsanum Well-Known Member Member

    Joined:
    Feb 11, 2010
    Messages:
    642
    Like I could correct you on these matters xD


    Well, I more or less understand it's related to how fast the tiles are being loaded, but what I mean is this:


    [​IMG]


    The tile in the left circle, which isn't being used anymore, appears to the right, but before the right tile is loaded?


    I'm asking this because, at first, I thought the top-right chunk wasn't loading fast enough, but since it's happening with your "sonic 1: two-eight" as well, I was probably wrong about this being related to chunks, since 128 chunks should load faster than 256 chunks. So the problem wouldn't lie in chunk loading, but rather in the tile loading routines (LoadTilesAsYouMove in Hivebrain's disassembly).


    It seems there are a few more things in s2's equivalent routine, as well a several other differences, which I thought could be optimizations to avoid this problem.
     
  15. TmEE

    TmEE Mélodie is powerful ! Member

    Joined:
    Feb 28, 2009
    Messages:
    111
    Location:
    Estonia, Rapla
    That problem is most likely relating to what Markey told. One solution would be to process playfield stuff before some of game logic related things, or scroll after all tiles are loaded... just throwing out ideas ^^


    TMS9918 is the VDP that SMS VDP is based on, its not the one in MD... MD has Yamaha YM7101 in it :(
     
  16. SpirituInsanum

    SpirituInsanum Well-Known Member Member

    Joined:
    Feb 11, 2010
    Messages:
    642
    Still no luck with scrolling only when the pattern load cues are empty :p


    Would it mean the game is not even trying to load those tiles soon enough?


    Btw, "LoadTilesAsYouMove" is part of the "v_int" routine, I never doubted Markey was right, just trying to find which part of it is the problem ^^


    What I mean with that picture is that the engine could be loading tiles that are too close on the right and too far on the left. Because it's redrawing the map plane, right? (that's how I understand the "Register 10 (90) - "Map Plane Size"" part on the previous page, but I could be wrong)
     
  17. FireRat

    FireRat "The grand imitator..." Member

    Joined:
    Oct 31, 2009
    Messages:
    528
    Okay. I tried to do a experiment: Make the hidden japanese text appear on Plane B, instead of Plane A.


    So, as I understand about manipulating registers, I did this:


    From:



    move.w #$8230,(a6)
    move.w #$8407,(a6)



    To:



    move.w #$8207,(a6)
    move.w #$8430,(a6)



    After that, I just get a blank screen. Also, If I open a savestate of that screen with GSavestate, it tells that Scroll A and Scroll B points to $0000.


    What is the problem here?
     
  18. SpirituInsanum

    SpirituInsanum Well-Known Member Member

    Joined:
    Feb 11, 2010
    Messages:
    642
    Not sure that's the problem, but one important thing to keep in mind is that plane A and plane B aren't using the same addressing system. If A is set to "30", it points at C000, but if B is set to "30", it points at 60000. Originally, in the code you're showing code, it was C000 for A and E000 for B.


    for A, divide the address by $400, and for B by $2000.
     
Thread Status:
Not open for further replies.