about vtest

open vtest.asm

all you really need here is the subroutine "level2vram"
this is the initialization routine that copy the level ram->vram

open test.asm

go to ".loop", this is the mainloop:

Platupdate evaluate the x-y position of the bouncing VDP text (actually this is a 32x4 are copied with tpset)

testdir eveluate the keyboard and the scrolling direction

display does some preparatory math before the Vblank (in order to exploit all the vblank time only for copies)

here the program waits for vblank and moves to scr5

plotscreen copies the background screen in 4 -8 fast copies

plottop copies the foregroung sprite in 1-2 tpset copies (this part is very unoptimized, as it was only tho demonstrate the idea, and must be redone in order to support a genaralized size of foregroung)

here the program moves back to scr4

done

Quote:

sorry you are right, it was a typo, the part of A that goes out of the pattern is set in E.

Not using R#18 or R#23 can I say:
dynamic tilesets enable you to scroll with 4 (or less) pixels in all directions, instead of 8 pixels?

Correct !! and as each tileset needs 16K you can have up to 8 "frames" of animation in 128KVRAM

hmmm, but whats the use of that,
then there is no more space in VRAM for the gamescreen or the spritedata ??

My fault, I should be more precise:

the tiles (definitions+colors) take 6+6=12K or 6+2=8K
the PNT takes 768bytes
the sprites take 640 bytes + 2K

So if you use 8 tilesets you spend 12*8=96K or 8*8=64K
There is plenty of room for sprites and the PNT

The sole problem is that, as I sayd in a previus post,
the VRAM cannot host the levelmap (becouse is full of tilesets)
and you cannot use the VTEST method to render the screen

In this case, you can use the VDP in a different (much easyer) way.
you move the whole screen with fast copy
copying the VRAM area on itself with a small offeset (quick and dirty,
you need only one command)
In case of X scroll, copy the PNT at +/- 1,
in case of vertical scroll, copy the PNT at +/- 32 positions.

This allows both X&Y scroll, but the z80 must be incharged to fill the new
extra line that enter rigth/left (forX scroll) or up/down (for Y scroll)

The cpu gain is in any case HUGE

compare 768 OUTs (pure z80) against

32+2 OUTs for Y scroll
3*24=72 OUTs for X scroll

moreover the VDP does only ONE single command (easy and quick)
so all the VDP processing time can be freely used by the z80

Quote:

In this case, you can use the VDP in a different (much easyer) way. you move the whole screen with fast copy copying the VRAM area on itself with a small offeset (quick and dirty, you need only one command) In case of X scroll, copy the PNT at +/- 1, in case of vertical scroll, copy the PNT at +/- 32 positions.

let me be more precise, you need to copy the PNT on itself

assume that the PNT is at 1800H, its size is 32X24

at vblank you switch in scr5 (it is very similar if you go to scr8),
1800H corresponds to pixel at (0,48) in the scr5 page,
the 768 bytes of the PNT corresponds to the box (0,48)-(256,54)

[in scr8 1800H corresponds to pixel at (0,24) and the whole PNT is the box (0,24)-(256,27) ]

if you want to move X of +/- 1 do

fastcopy (0,48)-(254,54) to (2,48)-(256,54) [here pay attention to the x copy direction of you get only a replica of the first column]
or
fastcopy (2,48)-(256,54) to (0,48)-(254,54)
Still you need to update the left/right border, but this must be done by the z80 (3*24 outs)


If you want to move Y of +/- 1 the easyest way is to use two PNT's
(one at 1800h and one somewhere you like) and switch between the two
let's call p=0 the first at 1800h and p=1 the second where you like

for moving down do
fastcopy (64,48)-(255,53),p to (0,48)-(255-64,53), p xor 1
fastcopy (0,49)-(63,53),p to (256-64,53), p xor 1
the z80 fills the last line (2+32 OUT)
swap PNT

for the other direction it is similar

Quote:

at vblank you switch in scr5 (it is very similar if you go to scr8), 1800H corresponds to pixel at (0,48) in the scr5 page, the 768 bytes of the PNT corresponds to the box (0,48)-(256,54)

It is not similar if you go to screen 8.
In screen 8 the vdp uses a different way of addressing the video ram; the bytes that have addresses under 0x10000 in screen 4 have even addresses in screen 8 and the bytes that have addresses starting from 0x10000 have odd addresses in screen 8.
The reason for this obfuscation is that the vdp needs to do so many memory per line reads that it wouldn't work if they all had to come from the same memory chips. Distributing the burden allows the usage of slow (cheap) dram chips for screen 8.
The same trick is used for screen 7, which is equally demanding for the memory.

does this mean screen 8 is out of the question.
Or maybe usable for an interlacing effect ??

Quote:

does this mean screen 8 is out of the question. Or maybe usable for an interlacing effect ??

If by 'interlacing' you mean on the byte level... And since that's prolly not what'd you want, then indeed, Screen8 (or any '64kB' mode) is out of the question. You can still use Screen5 though, tho personally I don't see the point in using commands unless you've got a whole lot of static data to move around. Sure, it's faster, but there's also a limit to what you can manage to move around during VBLANK though. Apart from that, you're still going to have to write all the new data to the screen like you would normally, and that means doing 24 seperate writes if you're scrolling horizontally. You'll probably also have to do a bunch of 'timp copies' if you have an animating map, so it really depends on the specific requirements wether or not commands are a viable alternative or not. Most of the time, you'll have more than enough CPU time to do a direct write, and the advantage of being able to take almost an entire frame to update the backbuffer outweighs the speed-gain you'll get from using commands. Just try it at first using normal writes, and if you find you're short on CPU time you could always consider using commands. Since 'the normal way' is usually just a few LD's combined with a bunch of OUTI's you won't waste much time creating this, and it might end up working just fine. The one thing commands can be very useful for though, is updateting pattern data if you plan this a little. If you keep pattern animations nicely aligned, a swift HMMM/YMMM can prove to be an excellent way of 'animating' something by quickly updating the tile-patterns of it. Anyhow, like said, it varies and really depends on *what* you're trying to do. First plan what it is you're going to want to do. Once you've got that planned, it should be easy enough to see what will and what won't be handy.

Quote:

and the advantage of being able to take almost an entire frame to update the backbuffer outweighs the speed-gain you'll get from using commands.

How much time (in horizontal lines) does it take to out 32x24 bytes to VRAM ?
And what about writing 32x24 bytes for the background and then writing (some) bytes on top of that background as a foreground ??

Quote:

. Just try it at first using normal writes, and if you find you're short on CPU time you could always consider using commands. Since 'the normal way' is usually just a few LD's combined with a bunch of OUTI's you won't waste much time creating this, and it might end up working just fine. The one thing commands can be very useful for though, is updateting pattern data if you plan this a little. If you keep pattern animations nicely aligned, a swift HMMM/YMMM can prove to be an excellent way of 'animating' something by quickly updating the tile-patterns of it. Anyhow, like said, it varies and really depends on *what* you're trying to do. First plan what it is you're going to want to do. Once you've got that planned, it should be easy enough to see what will and what won't be handy.

I will thanks

Quote:

How much time (in horizontal lines) does it take to out 32x24 bytes to VRAM ? And what about writing 32x24 bytes for the background and then writing (some) bytes on top of that background as a foreground ??

Well, usually you would use a RAM->VRAM transfer so you *wouldn't* have to do something as wasteful as copying the same area twice. Whats to keep you from doing LD HL,FOREGROUND | LD DE,BACKGROUND | LD A,(HL) | | OR A | JR NZ,.SET | LD A,(DE) | .SET: OUT ($98),A | INC HL | INC DE | DEC BC | LOOP NZ, which of course is an oversimplification of what you'd probably end up with. Anyhoo, I'm sure you get the idea. That also more or less answers your first question; the time it takes really depends on whatever loop you use to send the mapdata to VRAM. A block-OUTI would of course be a lot faster than the routine above, but then the routine above manages to draw two layers using a single out. The same would work of course for foreground objects using normal tile-data. A boss for instance, could also use normal SC4 tiles which you may offset left/right up/down in 2pixel steps. You could then quickly switch between tilesets to simulate semi-smooth movement of the boss creature. Anyhoo, it really depends on *what* you want to do.

Quote:

Quote: at vblank you switch in scr5 (it is very similar if you go to scr8), 1800H corresponds to pixel at (0,48) in the scr5 page, the 768 bytes of the PNT corresponds to the box (0,48)-(256,54) It is not similar if you go to screen 8. In screen 8 the vdp uses a different way of addressing the video ram; the bytes that have addresses under 0x10000 in screen 4 have even addresses in screen 8 and the bytes that have addresses starting from 0x10000 have odd addresses in screen 8. The reason for this obfuscation is that the vdp needs to do so many memory per line reads that it wouldn't work if they all had to come from the same memory chips. Distributing the burden allows the usage of slow (cheap) dram chips for screen 8. The same trick is used for screen 7, which is equally demanding for the memory.

@arnold_m
I think that there is a big misunderstanding.
What you are pointing out about HW does not affect in any way the method I was sketching to use vdp commands during vblank.
@norakomi
You can safely use in vblank scr8 for VDP commands to move the tiles inscr4, the sole difference is in the mapping of the scr8 pages on the scr4 PNT.

@Sonic_aka_T

I see your point, and more or less I agree, nevertheless, I think that one should keep in mind the VDP command option and plan the development accordingly.

If you limit the scrolling of the background layer to animations based on multiple tile sets (and this can be safely done when you use large blocks of NxM tiles), you need to modify the bocks in the PNT belonging to the background layer only every X horizontal steps (if you have X different “animation frames” of the tile set).

In this case X-1 times you only move the screen adding only and extra line/column, only at the Xth step you need to redraw all the screen.

In this case my technique to move the full screen using the VDP is excellent, while you need the z80 and a loop similar to yours only once each X frames.

@arnold_m
converting the two vdp commands I gave in scr4 in order to move the scr5 PNT to scr8 is trival.

Quote:

@norakomi You can safely use in vblank scr8 for VDP commands to move the tiles inscr4, the sole difference is in the mapping of the scr8 pages on the scr4 PNT.

o_O

Are you sure about that? Cause as far as I know the VRAM data would still be interleaved in Screen 8, while it's not in Screen 4.

Now I see that I have done some small errors in the copy sizes above:
in scr5 the whole PNT of scr4 is the box (0,48)-(255,54) (NOT 256 as I said)
so you should decrease of 1 the X width in all the copies I mentioned.
Again, double check the copies for vertical scrolling as I an no more sure about
the coordinates.

@Sonic_aka_t
Quite sure.
In scr8 1800H corresponds to pixel at (0,24) and the whole PNT of scr4 is the box (0,24)-(255,27)

Assume you use double buffer [i.e. two PNT's, p and p xor 1, one at 1800h and one anywhere you like],
and you swap between the two at each frame.
In this way, as you use two PNT's, you never get replicas and the x copy direction doesn't matter

if you want to move X of +/- 1 do

fastcopy (0,24)-(254,27),p to (1,24)-(255,27),p xor 1
or
fastcopy (1,24)-(255,27),p to (0,24)-(254,27),p xor 1

Still you need to update the left/right border, but this must be done by the z80 (3*24 outs)

-------

If you want to move Y of + 1 do

fastcopy (0,24)-(223,27),p to (32,24)-(255,27), p xor 1
fastcopy (224,24)-(255,26),p to (0,25), p xor 1

the z80 fills the first line at 1800h (2+32 OUTs)

swap PNT (invert p and p xor 1)

for the other direction it is similar