Putting an image in the screen?

صفحة 3/5
1 | 2 | | 4 | 5

بواسطة GhostwriterP

Paladin (683)

صورة GhostwriterP

16-01-2011, 15:44

VDP registers cannot be read, so they are mirrored in ram. I think BIOS keeps copies of the first seven vdp registers at adress f3dfh up to f3e6h, for vdp register 0 to 7 respectively.
So you can read the reg value from ram, update bit(s) and store the reg in ram again and then send it to the vdp.

بواسطة Daemos

Paragon (2044)

صورة Daemos

17-01-2011, 00:38

Finally really making big time progress here. thank you all again for your very helpfull responses. The block is now custom positionable I get the black backround and furthermore the whole thing gets onto the screen at once Smile So no visible writes to VRAM.

So now the time has come to bring the excersise to the next level Wink I now want to move the block around. I will do this by using the Move command of the VDP. I just have no clue yet how to store the new coordinates. I know I can store them somewhere and load them back in each time the move is requested but I allready push and pop alot of registers around and for example do something like this 8 times makes something like this impossible. So how do you store XY info like this into the ram?

بواسطة norakomi

Paragon (1136)

صورة norakomi

17-01-2011, 12:14

just put a list of variables at the ending of your code:

blockx: db 100
blocky: db 100
variablea: db 0
variableb: db 0
variablec: db 0
etc..

so in your code you put something like this:

ld a,(blockx)
add a,b ;b is related to the cursor keys left or right pressed...
ld (blockx),a
ld a,(blocky)
add a,c ;c is related to the cursor keys up or down pressed...
ld (blocky),a

بواسطة Daemos

Paragon (2044)

صورة Daemos

17-01-2011, 18:04

Looks clear to me. however this db command is assembler specific code just like defb that sets the byte at that adres to dec 100 right? (blockx)

This value is being changed at that memory adres. so if I get this straight:

blockx: db 100 ;set byte in this adress to 100
variablec: db 0 ;set the byte in this adress to 0

ld a,(blockx) ;set the value of A at the adress to which blockx points (100)
add a,b ;Sum the key that was put into B by routine x into A
ld (blockx),a ;Change the value of the byte at adress blockx into the new A value.

If I am right then it is much easier then the solution I was afraid of Wink
Will try new things with this new knowledge soon. Big smile

I have furthermore drasticly optimized my code. Found a magical piece of knowledge at the assembly pages. My VRAM write code is twice as small and twice as fast now Cool will upload soon.

بواسطة commodorejohn

Expert (92)

صورة commodorejohn

17-01-2011, 18:16

Yes, pretty much. db in that example defines a predefined byte value at that label - equ is usually the directive for directly setting the address of a label, which is useful when you just to set up a variable location and don't need a predefined byte value there. (And in MSX-DOS, it's useful because it keeps the executable size down.)

Note that these directives tend to vary - many assemblers use DB to specify pre-defined data built into the executable, and DS or somesuch to reserve storage, but some assemblers use other directives. You'll have to look through your assembler's documentation to find out which does what.

Note also that most assemblers don't distinguish between labels located in RAM and labels located in ROM, so if you try to build a ROM executable (though you're not, at the moment,) you'll need to find a way to conveniently set a group of labels to have their base address soemwhere in RAM, and define your variables in that block. Again, you'll pretty much just have to refer to your assembler documentation.

بواسطة Daemos

Paragon (2044)

صورة Daemos

17-01-2011, 18:25

Ok it could be that I am confused so I might say very wrong things right now oO

I use Wbass2 and if I have to believe the documentation does a definition of a predefined byte.

So Basicly this db directive creates a predefined byte somewhere into the RAM? I can change this byte via my program so I might consider this byte as a global variable for my program? Am I at least thinking right about this part?

بواسطة commodorejohn

Expert (92)

صورة commodorejohn

17-01-2011, 18:46

Yes. It creates a predefined byte in the executable, so as long as the executable is in RAM (a given for MSX-DOS applications,) that'll work just fine. It's only once you're trying to write ROM-based software that things get a little more complicated.

بواسطة Daemos

Paragon (2044)

صورة Daemos

19-01-2011, 01:44

!!!!! WOHOOOO. Things are really starting to get dynamic here. After the adittion of 128 lines of code, hard sweat and thinking I now have a moving block into the screen Big smile and as a bonus it even can change colors Wink

Well as you can guess from the time of this post I am glad I pulled this one off since it took me a good night trip.


just put a list of variables at the ending of your code:

blockx: db 100
blocky: db 100
variablea: db 0
variableb: db 0
variablec: db 0
etc..

so in your code you put something like this:

ld a,(blockx)
add a,b ;b is related to the cursor keys left or right pressed...
ld (blockx),a
ld a,(blocky)
add a,c ;c is related to the cursor keys up or down pressed...
ld (blocky),a

I did have to do some modifications to this code however. i think it is an assembler thingy but I had to do something like this:

ld hl,blockx
ld a,(hl)
add b
ld (hl),a

The register I need to point to the adress must be 16 bit. I find that logical though since the Z80 has 16 adress lines. So all adresses seem to be written in a 16 bit format.

Unfortunatly there is one little mystery that remains:

Even though I have used the logical move VRAM to VRAM VDP command the VDP does not move the block but copies it to the destination point. The effect is that my block leaves behind a colorfull trail. So am I utilising the command the wrong way? or does the thingy need an extra trick? I mean the trail is fun but there has to be a way to actually really move the thing around instead of copying? oO

بواسطة commodorejohn

Expert (92)

صورة commodorejohn

19-01-2011, 01:57

You can't move chunks of background data independent of the rest of the picture - only sprites can do that. To cleanly move a bitmap object around, you'll have to first erase the object at its existing position (i.e. re-draw whatever's under it) and then copy it into its new position.

بواسطة Daemos

Paragon (2044)

صورة Daemos

19-01-2011, 12:59

You have dissapointed and complimented me at the same time with your awnser Wink

The compliment comes from the fact that After a good thinking session I came up with the same theory. First erase the object then rewrite it somewhere else.

i was hoping for an easier trick but then this whole assembly thing would be no challenge at all.

The high speed move VRAM to VRAM command will not do in this case then unless there is a way to put the block into a area of VRAM that is not visible on the screen. Or draw the block directly from the user ram into the VRAM. This means a pretty large rewrite of the program. So I guess I will have to try it from a different approach. I will keep the block into the screen and make an extra routine that first erases the block from the old position by doing a high speed ram fill on that position then copy the block and write it onto the screen. Thats just one call extra since I allready have the movement engine at hand.

صفحة 3/5
1 | 2 | | 4 | 5