V9990 write mask

Page 7/7
1 | 2 | 3 | 4 | 5 | 6 |

By GhostwriterP

Hero (527)

GhostwriterP's picture

13-01-2020, 17:53

PingPong wrote:

What do these things relate to the write mask? Is it possible to move a block without affecting plane b when working with plane a and vice versa?

Yes, by setting the write mask as specified in the manual.

Juan Luis wrote:

Then, is your test free of dirty pixels?

As far a I can tell yes, but to be honest I did not check the full vram Wink.

Quote:

Please GhostwriterP, share your code.

I integrated the code in my ongoing (never ending) GFX9000 project and it is all a big secret! Smile

GhostwriterP wrote:

For the designation the DX should be byte aligned, otherwise (in case of xflip) the nybles will not get swapped correctly. But this also results in that the sprite frame shifts one pixel to the right (or left) when flipped in x and the most right or most (left) pixel will actually fall outside your sprite, hence, this require some special considerations.

And whoops... never mind this comment. It is an emulation (openMSX) thing.

By Grauw

Ascended (8621)

Grauw's picture

13-01-2020, 18:12

Be sure to report these discrepancies to the openMSX developers' issue tracker!

By Juan Luis

Expert (100)

Juan Luis's picture

13-01-2020, 19:33

GhostwriterP wrote:
Quote:

Please GhostwriterP, share your code.

I integrated the code in my ongoing (never ending) GFX9000 project and it is all a big secret! Smile

GhostwriterP, I have shared my source code the flip sprite patterns. Your description is extracted from the comment I have written in sprite-test2.asm (this file is still shared in my Google Drive link, see above in this topic).

My comment inside sprite-test2.asm was:

;
; This routine Flip X first Rygar 32x32 sprite.
;
; Viewing PGT A as a bitmap:
; - Rygar Stopped facing to right sprite definition is defined in:
; Even bytes are in 0x20000, Odd bytes are in 0x60000
;
; IMPORTANT: However, we specify as linear address 0x40000. This is due to
; V9990 search bytes applying the next formula:
;
; ((address & 1) << 18) | ((address & 0x7FFFE) >> 1)
; Formula extracted from OpenMSX V9990VRAM.hh source code file in transformBx function.
; transformBx is called by readVRAMBx function and this one is called by
; V9990CmdEngine::executeBMXL method.
;
; With 0x40000 we have
; ((0x40000 & 1) << 18) | ((0x40000 & 0x7FFFE) >> 1)
; 0 | 0x20000
; 0x20000 <== Address of first even byte
;
; With 0x40001 we have
; ((0x40001 & 1) << 18) | ((0x40001 & 0x7FFFE) >> 1)
; 0x40000 | 0x20000
; 0x60000 <== Address of first odd byte
;
; - NX (width) = 32 pixels
; - NY (height) = 32 pixels
;
; IMPORTANT (2): BMXL supports blittering in P1 mode to destination X (DX) even coordinate.
; If we specify DX as odd coordinate (1, 3, ...) you will get a graphic artifact. It's not possible to
; copy/flip image with BMXL to X odd coordinate in P1 mode. Remember, each byte transfered contains
; the information of 2 pixels (P1 mode pixel is 4bpp).
;
; However we can specify even and odd Y coordinate without problems.
;
; IMPORTANT (3): We specify DX = 32. This is due to X coordinate is decreasing by flag DIX, so
; we start to transfer 32 pixels right. I have tested with 30 but first two left pixels are lost.
; If you are not sure, draw a frame on the sprite editor to check the transfer is right.

I understand your project is secret, but you should share the detail to avoid dirty pixels. I have shared how to reverse sprites, please share what is the detail to avoid that problem. I don't want all your libraries.

I can't find out how to solve this problem because I don't have a real GFX9000 and I don't have a real MSX either.

Due to this is the behavior of msx.org forum members, I will not share more code with anyone. Everything will be a secret!

By GhostwriterP

Hero (527)

GhostwriterP's picture

13-01-2020, 20:06

Look, I was already planning to prepare a stand alone test when I have time so openMSX team can have a go at it, no worries.
In the mean time, in contradiction with Important (2) and (3) I noticed that, unlike the abbreviation BMXL would suggest (Byte move to XY from Linear), bmxl seems to actually work on nyble/pixel level. For a 32 wide sprite I specify 31 as target (for x mirror) and gets me good results on real v9990.
Also everywhere else in the manual it is stated "Data from linear adress in VRAM is transferred to the rectangle area", hence it says nothing about byte move... could it be B stand for block (something lost in translation)? Smile

But we will find out soon enough once I am ready with the stand alone test.

By Grauw

Ascended (8621)

Grauw's picture

13-01-2020, 21:30

GhostwriterP wrote:

could it be B stand for block (something lost in translation)? Smile

I say: plausible!

Juan Luis wrote:

Due to this is the behavior of msx.org forum members, I will not share more code with anyone. Everything will be a secret!

Aw don’t generalise and affect everyone Smile. You can look at my code all day! Other code you can’t look at. Some is open some is closed. Tis the way of the world.

By Juan Luis

Expert (100)

Juan Luis's picture

14-01-2020, 18:09

Grauw wrote:
GhostwriterP wrote:

could it be B stand for block (something lost in translation)? Smile

I say: plausible!

Juan Luis wrote:

Due to this is the behavior of msx.org forum members, I will not share more code with anyone. Everything will be a secret!

Aw don’t generalise and affect everyone Smile. You can look at my code all day! Other code you can’t look at. Some is open some is closed. Tis the way of the world.

So, due to "Tis the way of the world"..., I remove my shared folder because I have the same right.

Now I'm starting to understand why MSXDev is just for MSX1 without expansions.

By Grauw

Ascended (8621)

Grauw's picture

14-01-2020, 18:33

GhostwriterP said he would share a standalone testcase later, so I don't see the problem. That also seems more useful for testing rather than an entire project.

Also if this upsets you so much, why show exactly the same behaviour in reponse? Don't really get that, for me openness and collaboration is important regardless of whether it is always reciprocated. Should I continue the chain and close all my projects as well? Of course not. By having them open I want to encourage others to do the same, but it seems in a single moment like this it is forgotten that there are many who do share and they also deserve you to do it if this is what you care about.

Sorry to even get involved in this part of the discussion, but since you said "Due to this is the behavior of msx.org forum members", I do feel somewhat personally spoken to and also feel like it's unfair to say that about the community, and ignores my and many others' contributions in the spirit of openness.

By hit9918

Prophet (2882)

hit9918's picture

15-01-2020, 15:09

now GhostwriterP posted something in the other thread
he told in openmsx github. https://github.com/openMSX/openMSX/issues/1212
"address 22000h (even) and 62000h (odd)."
I got no 9990, but if you ask me, this BADLY smells like "SIMPLY every second byte hits the other layer".
vram0 vram1 vram0 vram1

no corruption, no undocumented B Blocks

Page 7/7
1 | 2 | 3 | 4 | 5 | 6 |