VDP VRAM to VRAM Copy by VRAM Address?

By CodeIndigo

Supporter (16)

CodeIndigo's picture

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)?

Login or register to post comments

By ducasp

Champion (466)

ducasp's picture

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 Smile 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

By Metalion

Paragon (1451)

Metalion's picture

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.

By CodeIndigo

Supporter (16)

CodeIndigo's picture

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.

By thegeps

Paladin (896)

thegeps's picture

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

By Metalion

Paragon (1451)

Metalion's picture

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.

By Grauw

Ascended (10181)

Grauw's picture

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).

By albs_br

Champion (343)

albs_br's picture

06-10-2021, 15:04

Grauw wrote:

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).

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

By CodeIndigo

Supporter (16)

CodeIndigo's picture

08-10-2021, 15:08

Grauw wrote:

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).

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.

By Grauw

Ascended (10181)

Grauw's picture

08-10-2021, 16:02

albs_br wrote:
Grauw wrote:

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).

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.

By DarkSchneider

Paladin (942)

DarkSchneider's picture

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.