Hi Tails!

Funny how great minds think alike, I had the same idea some time ago... My initial idea was also to do line-doubling using YMMM. While I was able to space the lines just fine (using normal writes while updating the pointer every other line), I did have some trouble applying the YMMM while rendering the video. I'm not really sure what caused this, crappy code, too little VDP time or perhaps openMSX (I didn't have an IDE cart) wasn't 100% accurate. I've learned to trust openMSX though, so it was prolly just crappy code...

Anyhow, pixel doubling is an issue in screen 12 indeed. It could be possible on the turboR though, since it has to wait 00dles of time between OUTs anyways. I guess it should still be fast enough to stretch the pixels horizontally. The real question is whether there's enough time to OUT twice the amount of data to the VDP.

Below is an example of unoptimized code which shows how long the pixel-doubling would more or less take. I'm not counting the mandatory VDP wait times here, as moving the code around a bit would ensure the R800 stays busy while the VDP processes the data. Anyhow, using this code would suggest there's *just about* enough time to do this. A guestimate would suggest about 80-90% CPU time spent on recalculating the data and sending it to the VDP. With a little optimization and perhaps going with 96 lines instead of 106 lines it should be possible.

The comments show Z80 T-States, R800 T-States (cycles) and time in R800 mode, not counting refresh and/or wait-states.

	LD	A,(HL)		;  7 / 2 / 0.28us
	AND	%00000111	;  7 / 2 / 0.28us
	LD	(Kl),A		; 13 / 4 / 0.56us
	LD	A,(HL)		;  7 / 2 / 0.28us
	AND	%11111000	;  7 / 2 / 0.28us
	LD	(Y0),A		; 13 / 4 / 0.56us
	INC	HL			;  6 / 1 / 0.14us

	LD	A,(HL)		;  7 / 2 / 0.28us
	AND	%00000111	;  7 / 2 / 0.28us
	LD	(Kh),A		; 13 / 4 / 0.56us
	LD	A,(HL)		;  7 / 2 / 0.28us
	AND	%11111000	;  7 / 2 / 0.28us
	LD	(Y1),A		; 13 / 4 / 0.56us
	INC	HL			;  6 / 1 / 0.14us

	LD	A,(HL)		;  7 / 2 / 0.28us
	AND	%00000111	;  7 / 2 / 0.28us
	LD	(Jl),A		; 13 / 4 / 0.56us
	LD	A,(HL)		;  7 / 2 / 0.28us
	AND	%11111000	;  7 / 2 / 0.28us
	LD	(Y2),A		; 13 / 4 / 0.56us
	INC	HL			;  6 / 1 / 0.14us

	LD	A,(HL)		;  7 / 2 / 0.28us
	AND	%00000111	;  7 / 2 / 0.28us
	LD	(Jh),A		; 13 / 4 / 0.56us
	LD	A,(HL)		;  7 / 2 / 0.28us
	AND	%11111000	;  7 / 2 / 0.28us
	LD	(Y3),A		; 13 / 4 / 0.56us
	INC	HL			;  6 / 1 / 0.14us

	LD	A,(Y0)		; 13 / 4 / 0.56us
	LD	C,A			;  9 / 2 / 0.28us
	LD	A,(Kl)		; 13 / 4 / 0.56us
	OR	C			;  4 / 1 / 0.14us
	OUT	($98),A		; 11 / 3 / 0.42us
	LD	A,(Kh)		; 13 / 4 / 0.56us
	OR	C			;  4 / 1 / 0.14us
	OUT	($98),A		; 11 / 3 / 0.42us
	
	LD	A,(Y1)		; 13 / 4 / 0.56us
	LD	C,A			;  9 / 2 / 0.28us
	LD	A,(Jl)		; 13 / 4 / 0.56us
	OR	C			;  4 / 1 / 0.14us
	OUT	($98),A		; 11 / 3 / 0.42us
	LD	A,(Jh)		; 13 / 4 / 0.56us
	OR	C			;  4 / 1 / 0.14us
	OUT	($98),A		; 11 / 3 / 0.42us

	LD	A,(Y2)		; 13 / 4 / 0.56us
	LD	C,A			;  9 / 2 / 0.28us
	LD	A,(Kl)		; 13 / 4 / 0.56us
	OR	C			;  4 / 1 / 0.14us
	OUT	($98),A		; 11 / 3 / 0.42us
	LD	A,(Kh)		; 13 / 4 / 0.56us
	OR	C			;  4 / 1 / 0.14us
	OUT	($98),A		; 11 / 3 / 0.42us
	
	LD	A,(Y3)		; 13 / 4 / 0.56us
	LD	C,A			;  9 / 2 / 0.28us
	LD	A,(Jl)		; 13 / 4 / 0.56us
	OR	C			;  4 / 1 / 0.14us
	OUT	($98),A		; 11 / 3 / 0.42us
	LD	A,(Jh)		; 13 / 4 / 0.56us
	OR	C			;  4 / 1 / 0.14us
	OUT	($98),A		; 11 / 3 / 0.42us

arf, st00pid tabs...

arrg!

Just stumbled on a HUGE problem.

I was testing doing EVA for Screen 5 (using the 128x106 bytes to have 2x width, same height) - and was adapting the avi2eva to create screen 5 movies.

The format would be simple, the same picture size as on EVA 12FPS, the byte which would identify the screen mode as 05, and before that byte, 32 bytes with palette in format RRRRBBBB 0000GGGG.

Just now, when I got evawin to play the file, I understood one big problem: screen 5 has only 16 colors - so you cant generate palette frame by frame...one color present in one frame, maybe isnt in the other (or is darkned by convertion) - it must be a "temporal palette" so the screen won't flash much...

hmmm, actually it was a bug in my code... both on AVI2EVA and on EVAWIN... still have to fix EVAWIN though

Ok, AVI2EVA now generates *also* screen 5 videos... and EVAWin can play them... but EVAPlayer must be adapted. So, until I figure out how to do it, it's going to take a while...

Quote:

arrg! Just stumbled on a HUGE problem. I was testing doing EVA for Screen 5 (using the 128x106 bytes to have 2x width, same height) - and was adapting the avi2eva to create screen 5 movies. The format would be simple, the same picture size as on EVA 12FPS, the byte which would identify the screen mode as 05, and before that byte, 32 bytes with palette in format RRRRBBBB 0000GGGG. Just now, when I got evawin to play the file, I understood one big problem: screen 5 has only 16 colors - so you cant generate palette frame by frame...one color present in one frame, maybe isnt in the other (or is darkned by convertion) - it must be a "temporal palette" so the screen won't flash much...

Continue updating the palette at frame rete (i.e. 1 palette per frame) but
encode each palette across two frames (i.e. quantize the palette starting from 2 adjacent RGB frames).

The result is an "average" palette good for both the two frames and if you change it,
even if you are not in the Vblank, you will not see any nasty artefact.

I know that the palettes in this way are not optimal, but i think that the result will be
good and suitable for triple buffering (where you change page -and palette, when you can).

Great to see that you (I am not coder, so I can't help you, sorry) are trying to adapt the EVA format to MSX 2