VDP VRAM to VRAM Copy by VRAM Address?

Supporter (16)

05-10-2021, 15:10

I'm looking to create a slot machine type game in Screen 4, and I think I've come up with an interesting way to manage the independent scrolling of the reels. However, I'm having a little difficulty understanding the VDP enough to get a proof-of-concept up.

My plan is to change the data in the pattern table for Screen 4 by shifting everything in the reel up by two lines or so. (Each column of the reels would have its own dedicated pattern space that gets changed, rather than changing the nametable.) This is easily done by just feeding different data into the pattern table, but I imagine doing it by feeding the VDP that data one byte at a time would be painfully slow. I had seen the HMMM command, but that doesn't quite do what I expect it to do in Screen 4: it copies blocks of pixels while in a bitmap/graphics screen, whereas I want just a straight and fast VRAM to VRAM byte-for-byte copy that can hypothetically be used in any screen mode.

Does such a function exist within the VDP? Even if it's an assembly routine (I've improved somewhat since my last set of questions)?

Entrar ou registrar-se para comentar

Por ducasp

Paladin (677)

05-10-2021, 16:34

You probably are better off and having better performance, if you have space to do so, to have the patterns pre-shifted in vram, so you just change the pattern bell line 0 to bell line -1 and so on... Preferrably on VBLANK As far as I remember, moving VRAM is done only through coordinates, so, you can move squares related to those coordinates, if the patterns you want to shift can be translated to those square/rectangle coordinates, you might try using YMMM, but my guess is that this is not going to be easy and probably you will want to have patterns pre-shifted at VRAM

Por Metalion

Paragon (1622)

05-10-2021, 16:36

On the V9938, the VDP blitter commands are only available in bitmap modes (Screen 5 and up).
However you can use them outside of bitmap modes on the V9958.

Outside those VDP blitter command, the only thing you can do is to use the Z80 to do the job.

Por CodeIndigo

Supporter (16)

05-10-2021, 17:13

Metalion wrote:

On the V9938, the VDP blitter commands are only available in bitmap modes (Screen 5 and up).
However you can use them outside of bitmap modes on the V9958.

Outside those VDP blitter command, the only thing you can do is to use the Z80 to do the job.

Well, crap. That makes what I was planning a LOT harder, and maybe not even feasible during vblank if it takes too long to update the VDP data from system memory.

Part of why I wanted to do this is so that I didn't have to keep partials of each combination of reel symbols in the pattern table, but this may be solvable with a one-tile blank margin on top/bottom. It's still going to eat a LOT of pattern space, but it might be possible.

Thank you both.

Por thegeps

Paragon (1175)

06-10-2021, 00:35

I'm not sure, but I think I've read somewhere that blitter command could be used even in screen4 bit you need to disable the screen before launch them

Por Metalion

Paragon (1622)

06-10-2021, 08:11

thegeps wrote:

I'm not sure, but I think I've read somewhere that blitter command could be used even in screen4 bit you need to disable the screen before launch them

You're almost right. Actually, the technique was described by Artrag: you switch to Screen5 during VBLANK and then use the VDP blitter commands, and then switch back to Screen4 before display.

Por Grauw

Ascended (10707)

06-10-2021, 12:35

I wouldn’t call feeding VRAM data from the CPU painfully slow, it isn’t much slower than the VDP command speed. At 60 Hz you can transfer up to about 3300 bytes per frame, while HMMM can transfer about 3600 (with sprites disabled).

Por albs_br

Champion (467)

06-10-2021, 15:04

Grauw wrote:

I imagine these two operations can be made in parallel, right?

Por CodeIndigo

Supporter (16)

08-10-2021, 15:08

Grauw wrote:

I was going with my previous assumptions based on my awful experience with interrupt programming; in short I didn't know what I was doing. I'm going to go with this approach especially since I don't think I'm going to be pushing quite that much data at once, and 30fps will be enough anyway.

Por Grauw

Ascended (10707)

08-10-2021, 16:02

albs_br wrote:

Grauw wrote:

I imagine these two operations can be made in parallel, right?

That too, although it is situational and often not easy to achieve that parallelism. Also the CPU VRAM access slows down the command execution speed somewhat. So I would treat it rather like a convenience, that you are free to access the VRAM even though a command is executing, instead of something that you must do in order to achieve more speed.

You can parallelise here and there if it is easy to do so. But attempting to reach or even approach the theoretical ceiling of 100% CPU and VDP utilisation is very difficult in practice, and increases the program complexity by a lot. I think a project will have a higher chance of success if it just uses the functions that are most suitable for what it needs, and doesn’t depend on squeezing every last drop out of parallelising the CPU and VDP.

Por DarkSchneider

Paladin (984)

12-10-2021, 14:21

Yes you can reach the top memory bandwidth. The real parallelism of VDP command execution is that the CPU could execute logic, instead more copy. But that implies VRAM transfers only. RAM<->VRAM transfers are a weak point in the MSX architecture with the 2 memory pools.