HomeForumsWhat's newResources 
 
 
VDP2 questions
AntiPasta - Apr 3, 2003

 1  2  3  Next> 

 AntiPasta Apr 3, 2003
I was trying to set up the VDP2 in a way to get a 512x256x32bit bitmap mode in a 320x240x24bit resolution using NBG0... so after reading that darned long PDF file I found some registers that apparently need to be set:

-TVMD to %1000000000010000, to set the proper resolution

-EXTEN to 0 (dunno why but Antime does this in copper2.asm)

-BGON to $101, to enable NBG0 and turn it's transparency off

-CHCTLA to %1000010 to set a 512x256x24bit bitmap

But I feel that isn't all - I mean, where exactly IS NBG0 located in VRAM? Do I need to set that somewhere? Moreover, what is this thing with windows? I don't have a clue how they fit in with the multiple screens thing...

/me is really really confused now :-(

 antime Apr 3, 2003
I set EXTEN to zero, because I don't use its features. There's little harm in leaving the functions enabled but if someone happens to leave a lightgun plugged in and starts playing with it you might get crashes. The register should be cleared on startup, but it is a good practice to set registers to known values and only enable the features you use.

Anyhoo, I believe the map offset register is what decides where the bitmap starts in memory. Bart Trzynadlowski has a bitmap sample program on his page, maybe you can find out the details from that.

 TakaIsSilly Apr 3, 2003
EDIT: antime already awnsered to the question that was here.


  
	
	
Moreover, what is this thing with windows? I don't have a clue how they fit in with the multiple screens thing...



Ever seen a SNES game with a curtain effect, like the Super Mario World opening (the cartoon-style "ball" fade-in)? It's a setting that "clips" a BG to a given size. Saturn has the mother of all clippers... SNES had horizontal clippers only to a given color. Saturn can do clipping on the horizontal and vertical locations, and show the inside, the outside, overimpose two windows with AND (a way to create transparency without cost) and er... lots of other fancy stuff.

To add to that, you had to make a special DMA mode in SNES to let the window do fancy drawings, that had some processor cost. VDP2 eats stuff like that for breakfast It's very exciting stuff ^^;;;

 AntiPasta Apr 3, 2003
yeah I'm pretty darn certain VDP2 holds a lot of untapped power... but I should add the PSX' GPU is a LOT easier to program <_<

 TakaIsSilly Apr 3, 2003
Hell, yeah. But where's the fun in that? ^o^

 AntiPasta Apr 4, 2003
okay I've looked up the map offset register (MPOFN). The bit layout, however, makes no sense to me! There are these 3-bit groups like N0MP8, NOMP7 and N0MP6. Now the documentation isn't very clear on this, how is an address formed from these values? Are they somehow combined with the MPxxN0 registers? And what are these planes?

 antime Apr 4, 2003
The bits are explained on page 86 of the doc (page 104 of the PDF). For NBG0, use bits N0MP6-N0MP8. The bits are numbered 6-8 because for tiled modes they are combined with the Normal Map Screen Scroll Registers, which hold bits 0-5. For bitmaps the start address seems to be 0x20000*offset bit value.

 AntiPasta Apr 17, 2003
okay I wrote some more code to deal with the VDP2... however I keep getting stuff like this:



Now here's what I write to the registers:

-%1000000000010000 to TVMD

-0 to EXTEN

-0x101 to BGON

-0 to LCTAU and LCTAL

-%110010 to CHCTLA

-0 to CHCTLB

-0 to MPOFN

And then I blast some test pixels to $25E00000 (I believe this is the greeny bar you see) - but instead of a 'clean' screen with some the lines of pixels that I wrote I get all this garbage - what did I do wrong?

 AntiPasta Apr 18, 2003
bump

I'm sorry I have to do this, but I desperately need some help on this for the contest. Please don't ban me

 ExCyber Apr 18, 2003

  
	
	
Now here's what I write to the registers:

-%1000000000010000 to TVMD

-0 to EXTEN

-0x101 to BGON

-0 to LCTAU and LCTAL

-%110010 to CHCTLA

-0 to CHCTLB

-0 to MPOFN


I may be mistaken, but it looks like your write to BGON enables NBG2, and you never configure it anywhere else, so your writes to VDP2 RAM are probably translating into garbage on NBG2.

 AntiPasta Apr 19, 2003

  
	
	
-0x101 to BGON


That's a hex value (stupid of me to mix number systems), so it sets bit 0 and bit 8... by the way printf told me to try some other values for MPOFN, and setting it to 3 got me a clear screen (so apparently the garbage comes from VRAM and sits somewhere in the lower region)...

 ExCyber Apr 19, 2003
If you're still interested in finding out what caused this, page 265 (PDF page 283) of the VDP2 doc has a table of all data structures that use VRAM, and their corresponding configuration registers. You might want to try setting it up so that nothing shares the same address and then run through a loop throwing your test pixels at each area and waiting a few seconds or some similar diagnostic.

 paul_met Oct 14, 2019
In order not to create a new topic, I’ll ask here. Is it possible to make layers 1 and 2 translucent for layer 3 at the same time (when I see layer 3 through layers 1 and 2)? If it possible, what should be the settings for all layers.

 fafling Oct 19, 2019
It is possible only in standard resolution.

I suppose that layers are numbered in decreasing priority order, layer 1 has the highest priority and 3 the lowest.
I also suppose that layer 3 has no transparent pixels. Otherwise, replace layer 3 in the following explanation by whatever mix of layers is below layers 1 and 2.

Page numbers are those of VDP2 manual.

So you have to :
  • Set VDP2 horizontal resolution to normal graphic A or B (p. 18).
  • Enable extended color calculation and disable gradation (p.240-241). Extended color calculation can't be used with gradation.
  • Set color calculation ratio mode and color calculation mode (p. 241). Any value can be used, but for the sake of simplicity (this is complicated enough), I suppose they're set to classic values : CC ratio are used and taken on the top layer.
  • Enable color calculation on layers 1 and 2 (p. 242). If sprites is one of those layers, set their color calculation condition (p. 207).
  • Set CC ratio on layer 1, and, if layer 1 has transparent pixels, on layer 2 (p. 210-212 for sprites and 243-244 for other layers). This CC ratio is only used when a layer is the top layer, so layer 2 CC ratio is used where layer 1 has transparent pixels.
  • One of the following conditions must be met :
    • Layer 3 must contain only RGB pixels (sprites color mode set to 1 p. 207, with only RGB pixels in the framebuffer, or character color mode set to RGB format for the other layers p. 60-61).
    • If layer 3 contains palette pixels, the color RAM must be set to mode 0 (p. 46).
When layer 2 is under a semi-transparent pixels of layer1, it is first blended with layer 3 with a fixed 0.5 CC ratio (see table p. 238), then blended with layer 1 using this layer's CC ratio.

Not the simplest subject for my first post here !

 paul_met Oct 20, 2019

fafling said:

This is exactly the effect I want to achieve. But so far it does not work out. Here are screenshots with layers and layer settings.
As you can see, when you turn on the translucency for the topmost layer, the second layer becomes opaque and the third layer is not visible through it.


 fafling Oct 20, 2019
You're using a palette layer as layer 3. Is color RAM mode set to 0 ?
It can be checked in Kronos v1.7.0, where it is added in General info of VDP2 debug window, under Sprite stuff.

 David Gámiz Jiménez Oct 20, 2019
From I know and see of vdp2. It not can blend more than once layer between other. In simply words. Only one layer can be have translucy, not multilayer.

 paul_met Oct 20, 2019

David Gmiz Jimnez said:

That's why I was embarrassed, why the developers did not make the dialog box translucent on the screen with the global map (in other cases, the dialog box is translucent).


fafling said:

Yes . There are no different visually from CRM=0 and CRM=2. But when CRM= 2 is activated, it turns out like this.

 fafling Oct 20, 2019
@David Gámiz Jiménez... Sure you can have multilayer blending, that's what extended color calculation is for. Check Sonic R, it uses that for the water ripples and reflections in the first stage.

@paul_met... You mean color RAM mode 0 and 1 are not different visually. Mode 2 is different because it uses 24 bit colors instead of 15 bit colors like the other 2.
The difference of mode 0 is that colors are mirrored so it contains twice as less colors than mode 1. It's probably to enable a faster access to the color RAM than in mode 1.
I see that the mosaic effect is enabled on NBG0, it could be what prevents the blending effect in the emulator. Since there's no such restriction in the manual, could be an emulator bug. Have you tested on the console ?

 paul_met Oct 21, 2019

fafling said:

No, I don’t have the original hardware. But I tried on another emulator (SSF) and double translucency works! But it works only if Color Ram Mode = 1. So, you are right, Yabause have a bug with ECC. Anyway it is strange why developers did not want to use ECC...

 1  2  3  Next>