Need your opinion regarding GR8NET capabilities

صفحة 29/58
22 | 23 | 24 | 25 | 26 | 27 | 28 | | 30 | 31 | 32 | 33 | 34

بواسطة Eugeny_Brychkov

Paragon (1232)

صورة Eugeny_Brychkov

13-03-2016, 13:36

SCREEN 12
SCREEN 8

136 x 102
Video: 12 frames per second
Audio: 22 kHz / 8 bits / mono

بواسطة Manuel

Ascended (19273)

صورة Manuel

13-03-2016, 14:12

Compared to EVA:
128x106 pixels (13568)
12 frames/s
15.75 kHz

So, you have slightly more pixels and a lot better audio quality.

Is there special hardware needed to play these videos?

بواسطة NYYRIKKI

Enlighted (6016)

صورة NYYRIKKI

13-03-2016, 15:10

Damn you are fast implementing things Smile

It does sound good indeed... From the videos it is hard to tell how it exactly looks, so I have to ask few questions:

- Do you sync the video to screen refresh rate?
- Can the video be played correctly both in 50/60Hz?
- Do you use triple buffering?
- Could you post an example video from some more colorful source... ie. from cartoon?

بواسطة ericb59

Paragon (1098)

صورة ericb59

13-03-2016, 15:24

seems to be good !
is it possible to have best resolution when using a turbo-r ?

بواسطة NYYRIKKI

Enlighted (6016)

صورة NYYRIKKI

13-03-2016, 16:02

ericb59 wrote:

seems to be good !
is it possible to have best resolution when using a turbo-r ?

No, usage of R800 will slow it down dramatically... Video playback is one of the rare cases where Z80 beats R800 by a mile.

بواسطة Eugeny_Brychkov

Paragon (1232)

صورة Eugeny_Brychkov

13-03-2016, 17:30

Manuel wrote:

Is there special hardware needed to play these videos?

GR8NET with file on SD-card (I implemented basic FAT32 driver in the application).

NYYRIKKI wrote:

Damn you are fast implementing things Smile

It's simple when you know what to do, how to do and you have right tools to do the job.

NYYRIKKI wrote:

Do you sync the video to screen refresh rate?

Yes, one frame each 5 vertical retrace events. For this machine is set up to work in 60 Hz mode.

NYYRIKKI wrote:

Can the video be played correctly both in 50/60Hz?

Through RGB it will play properly if displaying device supports 60 Hz. In Composite may (and most probably) there will be an issue for 50 Hz machine.

NYYRIKKI wrote:

Do you use triple buffering?

One read-ahead buffer for SD-card, and two alternating video pages.

NYYRIKKI wrote:

Could you post an example video from some more colorful source... ie. from cartoon?

Write me email how to do it. Actually quality of source matters much. This Slave to Love I used as a sample is relatively dark one in general.

ericb59 wrote:

is it possible to have best resolution when using a turbo-r ?

All depends not actually on the speed of CPU, but on the speed of VDP accepting video data. I can not answer this question because I do not have Turbo-R. See NYYRIKKI's answer above.

بواسطة Manuel

Ascended (19273)

صورة Manuel

13-03-2016, 18:57

Eugeny: which part of GR8NET is used specifically for these videos? Or can it also work on another MSX mass storage device?

بواسطة Eugeny_Brychkov

Paragon (1232)

صورة Eugeny_Brychkov

13-03-2016, 20:15

12 frames per second require about 190 kBytes per second of data prefetch. The following hardware acceleration parts are used

  • SD-card data pre-read
  • controlled interrupt generator
  • PCM function ported sequential replenishment

which off load CPU with a lot of time consuming tasks, thus CPU is just moving data from one place to another as fast as possible ensuring VDP timing is not violated, and switching video pages according to VDP interrupt.

Thus you can see that mass storage is just a part of the engine. Data should arrive in right place in right time.

بواسطة ray2day

Paladin (728)

صورة ray2day

13-03-2016, 21:18

wow oO

بواسطة NYYRIKKI

Enlighted (6016)

صورة NYYRIKKI

14-03-2016, 12:25

Eugeny_Brychkov wrote:

Through RGB it will play properly if displaying device supports 60 Hz. In Composite may (and most probably) there will be an issue for 50 Hz machine.

NYYRIKKI wrote:

Do you use triple buffering?

One read-ahead buffer for SD-card, and two alternating video pages.

I explain what I meant With triple buffering...

I expect that the inner part VDP write & PCM play routine is something similar to this: (Correct, if I'm wrong)

	OUTI	;Write picture to VDP
	OUTI	;Write picture to VDP
	OUTI	;Write picture to VDP
	OUTI	;Write picture to VDP
	EXX
	OUTI	;Write music to PCM
	EXX
	OUTI	;Write picture to VDP
	OUTI	;Write picture to VDP
	OUTI	;Write picture to VDP
	OUTI	;Write picture to VDP
	EXX
	OUTI	;Write music to PCM
	EXX
	.
	.
	.

This has the nasty side effect that if you stop to wait for screen refresh the music playing stops also, so you have to carefully plan how many times you execute the loop to keep the music playing without jitter... How ever this is mandatory to allow SCREEN2 to change palette. In SCREEN 8/12 lack of sync will only cause tearing in animation. You can make it work well with screen refresh if you fix the routine for 50Hz or 60Hz, but it will fail horribly if you change the screen refresh rate.

I meant with triple buffering while talking about SCREEN 2 is that when VDP is displaying page 0, you write page 1. When page 1 is ready you don't stop waiting for interrupt but you just write the page number to memory variable and continue immediately to write page 2. When VDP is ready drawing page 0, it will cause interrupt and see the variable. If page has changed, it will define new palette and swap the page 1 visible. Then these 3 VRAM buffers will just rotate.

The good thing in this approach is that it does not matter what speed the VDP is updating the screen... Naturally how many times each frame is actually drawn in to screen varies, but I consider that very little problem. The good thing is that Z80 can push data forward without ever waiting for anything.

In screen 8/12 this is a bit more problematic to implement. How ever because the Y-size is less than 128 lines you can theoretically have enough "pages" by using scroll register. To mask out unused screen part there are two options: You can mask the unused part with sprites, but this is not that good idea, because keeping the sprites on slows down the VDP data troughput. Other option is to use lineinterrupts to disable the screen when correct area has been displayed... This is more tricky to implment but propably faster.

Sorry if you feel that I repeat here obvious things, but just in case...

Quote:
NYYRIKKI wrote:

Could you post an example video from some more colorful source... ie. from cartoon?

Write me email how to do it. Actually quality of source matters much. This Slave to Love I used as a sample is relatively dark one in general.

I meant that do exactly what you did, but select a video that is not "dark one in general". BTW lately I've noticed that BMP2MSX gives "generally" better result if you add some contrast & gamma correction to source pictures... especially if the pictures are a bit dark. I tend to use Irfanview batch processing for these kind of corrections when there are multiple pictures to convert.

Quote:
ericb59 wrote:

is it possible to have best resolution when using a turbo-r ?

All depends not actually on the speed of CPU, but on the speed of VDP accepting video data. I can not answer this question because I do not have Turbo-R. See NYYRIKKI's answer above.

Yes, this is because R800 need to slow down in order to write to VDP... Because of bad engineering that slowdown has been implemented in hardware and it has been made ridiculously too big... IIRC it is something like "wait for 56 clocks before executing next VDP I/O". From computer perspective that is equal to "Time for coffee break".

صفحة 29/58
22 | 23 | 24 | 25 | 26 | 27 | 28 | | 30 | 31 | 32 | 33 | 34