VDP's strange internal unknown laws.

[greatkreator]

How the position of a tile pattern in VRAM affects anything?
Do any relations exist between tile patterns and their positions in VRAM and their positions relativelty to themselves?
Maybe anyone could suggest anything for example from the hardware point of view?

[Sik]

Huh, do you mean the graphics or the tiles in a tilemap?

Tile IDs are based on the address (it's address * $20): tile 0 is at $0000, tile 1 is at $0020, tile 2 is at $0040... tile 2047 is at $FFE0.

Tiles in a tilemap are just arranged consecutively first horizontally, then vertically, i.e. first come all the tiles from the first row, then all the tiles from the second row, then all the tiles from the third, and so on. (if your tilemap is 64×32, each row is $80 bytes, if you wonder)

Note: $ means hexadecimal here.

[greatkreator]

There are another laws except that standard.
I asked about them.

[Sik]

Nope, that's it. The only thing missing is registers $02 and $04 ($82xx and $84xx): they determine the location of the tables for the tilemaps. But that's it. If you need some quick settings without having to learn that:

$8230 = plane A at address $C000
$8407 = plane B at address $E000

Actually... are you testing in real hardware? Make sure to clear video memory first (write 64KB worth of zeroes when the program starts). Maybe your problem is that horizontal scroll is not reset. (you should clear vertical scroll too, but just write two $0000 to get by)

Also I think the word you're looking for is "rules", not "laws".

[greatkreator]

That all is known.
I do all the standard stuff right.

It seems that my code "breaks" VDP internal mechanisms.
There are no some special relations between tile positions.
It's just consequences of VDP not correct work.

We are doing Sega MD science here (: that's why I call that a law.

[Natsumi]

Could you explain a little more or perhaps show an example; anything you told and asked make no sense without proper context

[greatkreator]

I turn the screen on/off in the horizontal blank. It breaks VDP's graphics "preparation".
It seems the tile positions and their relations don't have anything special.

[Mask of Destiny]

One of the things that happens in HBlank/Horizontal border area is reading and latching the horizontal scroll value. Presumably what happens if the display is disabled during this period is that the last latched value is used instead. The Hscroll read happens pretty late, after most of the sprite rendering is done so it's hard to nuke it, but if you're pushing the limits of how much data you're transferring or if you start too late it's definitely possible.

[Sik]

To be fair, just failing to reenable display 16 pixels earlier is enough to make the first column break (Overdrive gets away with it because it still reenables display relatively early, there are even still some sprites being processed).

[greatkreator]

To Sik:

How many colors (without visible artifacts and destroying consequences) can you transfer in hblank?

[Nemesis]

How many colors (without visible artifacts and destroying consequences) can you transfer in hblank?

Without disabling the display? Two in H32, one in H40. See the following thread:
viewtopic.php?t=851
This shows you the access cycles that the VDP is doing during active scan. External access slots are marked. Those are where external reads/writes are allowed through when the display is not disabled. What this thread doesn't make clear is the distinction between the "digital" render position of the VDP, and the "analog" render position. The source for the Exodus VDP core is the best reference for this currently. In a nutshell, the digital render position is about 20 pixels ahead of the analog render position (not quite, but can't remember the precise offset off the top of my head). What this means is that the current line is actually finished being displayed, and hence the last palette colour has been read, partway through the blanking region from the digital render position point of view. This gives you two access slots before analog display starts again in H32 mode, and one in H40. If you want more than that, you must disable the display, and once you do, you are preventing the VDP performing some of its internal reads. As you can see on the timing chart, this is basically sprite pattern reads you're preventing during hblank, which will reduce the number of sprites that can be displayed on the next line. How much it reduces it by is directly related to how long the display was disabled for. For each pattern read that gets missed, you lose 8 pixels.

[greatkreator]

Thanks Nemesis! Very interesting.

I meant the disabled screen but disabled in such a magic way that it doesn't harm anything (: