OpenMSX / G9K / Real hardware issue / V9990

Prophet (2482)

16-08-2021, 13:51

Hi All, currently we are trying to get pattern mode running (for g9k) for SymbOS but we are facing an issue on real hardware. It is about scrolling. We have a back layer, a front- layer and a sprite layer. As soon we build the project everything works fine in openMSX (It scrolls like this: Example how it should work)

But as soon we run it on real hardware (CPC or MSX) the only thing you get is a scrolling background layer. The other 2 layers (front layer and sprite layer) are not visible anymore. If we disable the scrolling for the background layer the other 2 layers are visible again and the background layer is static behind but visible. But as soon we enable the background layer again for scrolling we are getting this issue.

So we think it is in this part of the code:

Does anybody facing the same issues and have a suggestion? Many thanks!

;LIBRARY QUIG.G9K.SCROLL.A
;**************************
;DE=X
;HL=Y
.Quig_G9K_SCROLL_A	
		;Y
		ld		a,g9k_SCROLL_LOW_Y
		ld		bc,CG9K_REG_SELECT
		out		(c),a
		ld		a,l
		ld		bc,CG9K_REG_DATA
		out		(c),a		
		ld		a,2
		rrca
		rrca
		or		h
		out		(c),a
		
		;x
		ex		de,hl
		ld		a,g9k_SCROLL_LOW_X
		ld		bc,CG9K_REG_SELECT
		out		(c),a
		ld		a,l
		and		7
		ld		bc,CG9K_REG_DATA
		out		(c),a
		ld		a,l
		srl		h
		rra
		srl		h
		rra		
		srl		h
		rra
		out		(c),a
		ret
;LIBRARY QUIG.G9K.SCROLL.B
;**************************
;DE=X
;HL=Y
.Quig_G9k_Scroll_B	
		;Y
		ld		a,g9k_SCROLL_LOW_Y_B
		ld		bc,CG9K_REG_SELECT
		out		(c),a
		ld		a,l
		ld		bc,CG9K_REG_DATA
		out		(c),a		
		ld		a,2
		rrca
		rrca
		or		h
		out		(c),a
		
		;x
		ex		de,hl
		ld		a,g9k_SCROLL_LOW_X_B
		ld		bc,CG9K_REG_SELECT
		out		(c),a
		ld		a,l
		and		7
		ld		bc,CG9K_REG_DATA
		out		(c),a
		ld		a,l
		srl		h
		rra
		srl		h
		rra		
		srl		h
		rra
		out		(c),a
		ret

Por GhostwriterP

Paladin (683)

16-08-2021, 19:30

For p-mode rolling by image space size should be specified (this specified by 00------ on reg # 18 and definitely not specified at all on reg # 22), hence the following parts may be the culprit

ld a,2
 rrca
 rrca
 or h

try replacing with

ld a,h
and 1

Por edoz

Prophet (2482)

16-08-2021, 20:46

Thanks! That was the correct solution!

Por edoz

Prophet (2482)

16-08-2021, 21:11

Thank you all by your support as well by email from GuyveR800!

Here is how it looks on the CPC, but it does the same on the MSX
It is funny, i have the feeling i'm behind a MSX but when i go to the keyboard it seems a CPC

Youtube

Por GhostwriterP

Paladin (683)

16-08-2021, 22:25

glitch at 1:06?

Por Manuel

Ascended (19471)

16-08-2021, 22:52

Can someone create a fix for openMSX with this info?

Por edoz

Prophet (2482)

17-08-2021, 11:12

Yes, it is not perfect, but it is a start. Now we need a good interrupt in SymbOS to make it better and more stable but all must be in compatibility with all Z80 supported /models/machines and of course with the SymbOS multitasking operating system. This time i was really glad for example that SymbOS is not using the videoram for storing bitmap data for the desktop. For the simple reason some of the machines don't even have videoram but in this case it was very helpfully to go back to the desktop in a split second! That is what i think is very cool! To jump to pattern mode, keep the OS and the running applications alive and do you thing in pattern mode, jump back to bitmap mode and see the desktop again. That is what i like here So in a way, you could very easy access the symbos network layer while running your game. The goal is now to make a small nice game and hopefully with some kind of sound daemon, as symbOS is still lacking on that part a lot. However, prodatron already did basic support for OPL4 (mod's) in SymAmp now and is trying to split s+SymAmp in 2 applications. One daemon, and other part as just a client that connects to the daemon... anyway.... a lot of work still
But i love to work on this anyway

Por edoz

Prophet (2482)

17-08-2021, 15:49

This is how it runs on a MSX now

G9kMSX

Por Trebmint2

Master (242)

07-09-2021, 15:17

Hi genius members of the msx community. As some probably know I'm coding the g9k library for Quigs now and I'd like to implement in P1 mode to do a 8x8 pattern copy from one pattern number to another, so you can do anims like waterfalls etc etc and even increase the range of the sprites from the 256 to the full vram area.

It seems using the BMLL command I'm copying just 4 bytes, 8 times... as patterns are not linear data. Or am I being dense, as this seems insane as it takes so long to set up the Source,dest,bytes format to start with. Its surely quicker just to copy from vram into ram and back.

Anyone who's a v9990 god, who knows, and wants to help with the z80 side of quigs and create a new gen of games like Edo's Flappybirds please let me know

Por Grauw

Ascended (10772)

07-09-2021, 16:09

Have you tried to use LMMM? The patterns are laid out in rows of 32 afaik.

Por Trebmint2

Master (242)

07-09-2021, 19:30

Hi thanks for you help Grauw. Its definately the better solution... however I have is copying every 2nd horizontal pixel so you get 1st pixel (original) 2nd (copy) 3rd (original) etc etc. Ive heard mention of a mask???? Can anyone help with this?

; HL = Pointer to data  (format: SourceX,SourceY,DestX,DestY,Width,height) struct G9K_COPY_XY_XY
.Quig_g9k_Pattern_Copy:
		ld		hl,Quig_g9k_Pattern_Copy_Data
		ld		a,g9k_sc_X
		ld		bc,CG9K_REG_SELECT
		out		(c),a
		ld		bc,CG9K_REG_DATA
		;Our 12 times
		inc 	b:outi:inc b:outi:inc b:outi:inc b:outi:inc b:outi:inc b:outi:inc b:outi:inc b:outi
		inc 	b:outi:inc b:outi:inc b:outi:inc b:outi		
	
		ld		bc,CG9K_REG_SELECT
		ld		a,G9K_OPCODE
		out		(c),a
		ld		bc,CG9K_REG_DATA
		ld		a,G9K_OPCODE_LMMM
		out		(c),a
		
		ret
.Quig_g9k_Pattern_Copy_Data:
		dw		33,0
		dw		0,0
		dw		16,32

Oh yes I know I don't need to use outi on MSX, but the CPC requires 16bit Port address