Some VDP command for linear transfer?

Page 1/2
| 2

By DarkSchneider

Paladin (942)

DarkSchneider's picture

29-07-2016, 12:01

I wonder why the MSX-Video lacks the most elemental type to transfer data. From source to destination and size bytes. In other words a simple memcpy and its reverse. You can copy rectangles, which include linear copies and the VDP handling the change line by itself. Why that linear copy is not available for programmer?

Using HMMM implies many issues with data align position and sizes, and it depends of the mode you use.

Login or register to post comments

By PingPong

Prophet (3885)

PingPong's picture

29-07-2016, 22:33

there are only 4 bit in the command part of the command register... the most useful operations first.
i think a memcpy is not as useful in gfx as a rectangle copy.
Also note that the available command set is not orthogonal.

By Sandy Brand

Champion (277)

Sandy Brand's picture

29-07-2016, 23:07

Exactly, I am not sure what you could achieve with a linear transfer.

I mean, you could copy around sprite data or patterns maybe yes. But often you could just as well change the location of sprite attribute/pattern tables, which is much faster?

By DarkSchneider

Paladin (942)

DarkSchneider's picture

30-07-2016, 09:37

That is not an option. Due to design failures sprite color data must be copied. Also if you want to surpass the low patterns limit (and you will do because it can't mirror sprites) you have to copy gfx. Can't change tables because it implies all the sprite patterns in screen must match with the ones in that table, and that is impossible.

It can also be used to update data in VRAM from another VRAM store location. It has many uses. So I don't know why is not implemented.

By ARTRAG

Enlighted (6828)

ARTRAG's picture

30-07-2016, 12:18

I agree, it would be handy for sprite management, eg for rotating the crappy enormous sat
Anyway using rectangles, you can cope with this problem as well, just less efficiently
The restriction is that you need a graphic mode

By DarkSchneider

Paladin (942)

DarkSchneider's picture

30-07-2016, 14:20

Yes indeed that was an option, split in multiple operations. Unfortunately all the checks to do in addition to multiple small commands (with all parameters to set) is even slower than directly doing a LDIRVM + LDIRMV for standard size sprites operations.

We have to check both the source is well aligned but also the destination, so none of them break the line alignment (128-byte for SC5-6 and 256-byte for SC7-8). This can be a bit complex and for Z80 can be even more work than a pair of copies from and to VRAM of small chunks of data.

I.e. draw a character (usually 4 sprites, multicolor body and legs), then a bullet (single sprite), now other character... what pattern?, is aligned any of the source or destination? How many copies implies and what size?. In the worse case, we should do up to 3 operations (1st incomplete line, 2nd block of full lines, 3rd incomplete line) if at lest source or destination are aligned, if not can be even more. Add many checks that we need to do before using the CPU to set the operations to do.

For typical sprite size (4 sprites for a character) using the CPU directly is even faster as said. Unfortunately I am afraid I'll have to use the CPU in any case.

The idea was to use the interrupt time to set SC5 and copy some data CPU-free. Also it would be great on V9958 that works always in bitmap mode (there is no reason to use SC4 on V9958, right?) handle completely the sprites and possibly other VRAM data using only the VDP. It would be really great.

By ARTRAG

Enlighted (6828)

ARTRAG's picture

30-07-2016, 15:37

My suggestion would be to use two layers for anything. For larger sprites 4 or 8 layers.
Moving 32 bytes with the vdp is about as fast as using the sole CPU.
The best would be to put in parallel vdp copy and CPU copy
It is quite tricky and parallel slows down the vdp, but it is a better option with respect to CPU only copy

By hit9918

Prophet (2921)

hit9918's picture

30-07-2016, 19:28

for patterns it would be nice to have a cache. then have masses of things with no copying.
vram pattern allocation array: 64 bytes telling which vram P is free
and 256 patterns in RAM. 256 patterns in the game Smile
with a 256 bytes table RAM P -> vram P

	ld c,the RAM P number
	ld a,(bc)			;B = lookup table RAM P -> vram P
	ld (ix+P),a			;the vram P of YXPC of SAT

and a 256 bytes reference count array for multiple users of one pattern.
every object creation / killing needs to call patternalloc / patternfree with RAM P numbers.

the colorcopy quirk is solved with C mirror bytes array.

By DarkSchneider

Paladin (942)

DarkSchneider's picture

30-07-2016, 19:42

@ARTAG I use batching so all the contiguous pattern sprites are copied in a single operation. Precisely because that I looked for VDP, and at the same time gives me the align problem. And yes for only 32 bytes is not worth.

@hit9918 yes and it would be nice the Z80 also had a cache Wink
Remember that for 16x16 we have 64 sprite patterns only not 256.

By hit9918

Prophet (2921)

hit9918's picture

30-07-2016, 20:32

but, I didnt mean small sprite mode, I meant 256 patterns in 16x16 sprite mode.

a new sprite enters the screen.
one of the 256 RAM patterns is copied to one of those 64 vram patterns.
and there are dozen sprites onscreen.
they already got their things in vram, no copying.
when they leave the screen then they free their vram slots.
so. 256 patterns and little copying.

By PingPong

Prophet (3885)

PingPong's picture

30-07-2016, 22:28

DarkSchneider wrote:

That is not an option. Due to design failures sprite color data must be copied. Also if you want to surpass the low patterns limit (and you will do because it can't mirror sprites) you have to copy gfx. Can't change tables because it implies all the sprite patterns in screen must match with the ones in that table, and that is impossible.

It can also be used to update data in VRAM from another VRAM store location. It has many uses. So I don't know why is not implemented.

Not a good point. the problem are SAT/SPRITE RELATED. That's the point. You need a functionality that does not have reasons to exists other than to patch another problem (design of sprite system). The problem is of course the sprite subsystem not the vdp command engine lack of operation. vdp commands are tailored to manipulate vram in a useful manner from a graphics perspective not to fix others problems.

Page 1/2
| 2