Also, if won't work on screen12... I just did a small program myself to read EVAs (veeeeery slow, and in Pascal heh) - that doubled the screen like I said - and there was lot's of color clash in scr12

But in scr8, the image was beautifull

Quote:

Also, if won't work on screen12... I just did a small program myself to read EVAs (veeeeery slow, and in Pascal heh) - that doubled the screen like I said - and there was lot's of color clash in scr12 But in scr8, the image was beautifull

Sorry I've no specified the time requested by the vdp to move those 175KB mentioned before... They are 175KB/Sec so basically the same as NYYRIKKI said about. 175KB/Sec on a screen of 27KB means 6,4 frames/sec.

Also i know we need to do out, but i've mentioned the VDP pure speed because is the situation where you can achieve the best performance. OUTs from z80 are a bit slower, so about 6frames/sec.

No matter how you move the data, from ram or from vram. the theoric limit is near 175Kb/Sec, or if you prefer 6 fps.

Quote:

It really does not matter what you write to VDP, speed will still be the same. So writing 128 bytes two times takes same amount of time as writing 256 bytes one time. 27k -> ~6fps

Ah, but there's the trick: you don't need to write those 128 bytes twice
Just have a line interrupt routine that adjusts VDP reg 23 on every second line, so that the same line is shown twice.

LSTART  equ     0               ; it takes about 4-5 lines to get things
                                ; to start, 
LLINE   equ     255             ; start value for display offset reg.
; -------------------------------------
VDPREG          macro   _reg,_val
                ld      a,_val
                out     ($99),a
                ld      a,_reg
                or      $80
                out     ($99),a
                endm

; -------------------------------------
_exec:
                VDPREG  19,LSTART       ; lineint on line START

                ld      hl,H.KEYI
                ld      de,oldhks
                ld      bc,10
                ldir

                ld      hl,newhks
                ld      de,H.KEYI
                ld      bc,10
                di
                ldir
                ei
mloop:          ret

newhks:         jp      lineint
                ret
                ret

                jp      interrupt
                ret
                ret

; -------------------------------------
interrupt:
                ld      a,(RG0SAV)      ; enable line interrupt
                or      $10
                VDPREG  0,a

                ret

; -------------------------------------
lineint:
                VDPREG  15,1
                in      a,($99)         ; read status reg
                rra                     ; this is line int?
                jr      c,intline
                VDPREG  15,0
                ret

intline:
                ld      d,LLINE
                VDPREG  23,d

                VDPREG  0,(RG0SAV)      ; disable lineint

                ld      b,90            ; 180 real lines of double doing

                VDPREG  15,2            ; read status register 2
intloop:
wait0:          in      a,($99)        ; wait two lines
                and     $20
                jr      z,wait0
wait1:          in      a,($99)
                and     $20
                jr      nz,wait1
wait2:          in      a,($99)
                and     $20
                jr      z,wait2
wait3:          in      a,($99)
                and     $20
                jr      nz,wait3
                dec     d
                VDPREG  23,d        ; adjust vertical offset
                djnz    intloop   

                VDPREG 23,0
                VDPREG 15,0
                ret

Aurora: That not the biggest problem, the biggest one is to draw twice the pixels horizontally!
(I thought of doing vertical *and* horizontal scanlines - aka skipping one pixel both horizontally and vertically, which still produces nice results, but wouldnt help much, since still would have to OUT to re-position screen writes...)

But changing the subject, a quick question: is there any way to know if a EVA was made for screen 8 or screen12?

I just adapted avi2eva to generate screen8 movies (no dither, but it should get better results than EVACON, which converts EVA from scr12 - which are more "blocky" due to color clash - to scr8) , but evawin plays them wrong - because it thinks it is a screen 12 eva file

Quote:

What could be done, for fullscreen (even on scr12!) would be to duplicate the pixels horizontally (when drawing them on VRAM)

Quote:

Ah, but there's the trick: you don't need to write those 128 bytes twice

In screen 12 it just does not work that way. You have to draw whole line and it takes 256 writes.

@Slotman No, there is no way for autodetect, you have to use commandline parameter. BTW I think that there are many (including me), who would like to get your version of AVI2EVA because this means also, that you can make EVA files for standard MSX2!

Hmmm... maybe it's too slow for screen8/12, but on screen 5, where 128 bytes = 1 line, it could work... you just have to skip 1 line, and *boom* fullscreen video

Quote:

@Slotman No, there is no way for autodetect, you have to use commandline parameter. BTW I think that there are many (including me), who would like to get your version of AVI2EVA because this means also, that you can make EVA files for standard MSX2!

I will release it - I just finished testing a debug version, so I need to clean it up a little bit

I'll take a look again on Evaplayer... it would be nice to autodetect, since one of the features I implemented on EVAWin was to play EVA files just by double clicking them...

@SlotMan: are you developing eva msx player working in screen 5 version? please let me know about... thx

Nope... I don't understand the eva player source very well

For a screen5 version (I'm thinking about it right now) - with a fixed palette (yeah I know...) you could achieve full screen - but I have absolutly no clue how to "skip lines" on screen within the eva player...

To encode the file, having the same byte replicated twice (so writing 128 bytes on scr5 will give you a full line) is easy... re-writing eva player source to play that file, not so much

are you guys sure there's no way to auto-detect if a EVA file is SCR12 or SCR8? I just found this at evaplayer source:

        ld	(filehandle), a	; frame = number of PCM data.
	ld	de, buffer
	ld	hl, 3
        ld      c, 048h
	call	5
	or	a
	jp	nz, error3

	ld	a, (buffer)   	     ; Checks if it's normal EVA format
        cp      2                       ; or screen8 with PCM  sound 4 bits 
	call	z, msx2format	; a traves del PSG. (couldnt translate this heh)

Problem is, I have no clue where (buffer) points to in the file

It seems there is a flag to identify if it's screen8 or 12:

; Formato EVA 12fps:
;
; 1 cuadro = 30 sectores = 15.360 bytes
;
; Ventana screen 12, 128x106
; Sonido PCM 15,75 KHz = 1312 bytes (variable)
;
; Imagen y sonido intercalados.
;
; [{ PCM (1 byte) + PIC (11 bytes)} * 11 + PCM (1) + PIC (7)] * 106 lineas
; + sonido + basura + tamanyo PCM
;
; Marca del formato MSX2 (screen8 y sonido PCM 4 bits a traves del PSG):
;
; #02 en el bit anterior al tamanyo del PCM.

As I figured just now, even EVACon is generating movies wrongly - by not setting that byte (where ever it is). If it was set, evaplayer would auto-detect the format, and switch to screen 8 automatically (not needing the /8 parameter to play the movie correclty)

Just found out: the Byte 3BFDh should be set to 02 if the video is for screen8 - but also, the eva player must be fixed, since it was doing this:

msx2format:
        ld      a, (options)
        or      010001000b
        ld      (options), a
        ret

and it should be this:

msx2format:
        ld      a, (options)
        or      000001000b
        ld      (options), a
        ret

With that, you can play both screen 12 and screen 8 eva files without having to use any parameters... and evawin will be able to autodetect the file type

So, when I release this stuff, I will release a new evaplayer (with that problem fixed), a new evawin (with scanlines, "file association" and scr8 support) and a new avi2eva (with scr8 support)

Quote:

Nope... I don't understand the eva player source very well For a screen5 version (I'm thinking about it right now) - with a fixed palette (yeah I know...) you could achieve full screen - but I have absolutly no clue how to "skip lines" on screen within the eva player... To encode the file, having the same byte replicated twice (so writing 128 bytes on scr5 will give you a full line) is easy... re-writing eva player source to play that file, not so much

It should be possible to do 256*106 fullscreen SCREEN 5 video even with palette, but I think you must write the "EVA" player again as in this case you really need to syncronize the HD loading with VDP.

I think it's best 180x150, same ratio and no distortion instead of 256x106 ...

[EVACon author speaking]
Slotman: I never knew there was that screen identification bit. I just thought that EVA was inherently SCR12 (or GFX9000, but I never seemed to get that to work) and that the movie was shown in SCR8 only by the /8 parameter. I'll dive into the sources sometime soon and update EVACon when I've sound that byte and fixed it!

Slotman: it'd be nice to inform Sonic_aka_T of your plans - he's the author of ViewMSX, a tool that supports EVA files as well. Maybe you can do some work collaborately!