Line

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

By NYYRIKKI

Enlighted (4599)

NYYRIKKI's picture

10-08-2012, 00:05

Oops, few bugs on the test... DX,DY and SX,SY seem to be swapped... Not important, but good to know. Also bug in line 150. It should be:

150 if a$="S" then bsave mid$(str$(S),2)+".SC5",0,&H697F,S

By PingPong

Prophet (2844)

PingPong's picture

10-08-2012, 00:18

hit9918 wrote:

About active area.
If you got the timing of the whole screen and the timing of blanked screen then you can make guesses about speed in the active area. 50hz vs 60hz is different percentage of active area, also 212 vs 192, giving additional hints on whether obtained figures are plausible.

Yes, the test program is somewhat in early stage. i plan to add several cases.
By contrast i do not like the idea of relying on CPU speed, that's because there are a lot of msx with different speeds. Problems are:
- some msx have different clock sources, not the same that drives vdp & cpu
- some msx have weird speed such as 5.x Mhz
- turboR is another beast, works faster, but output to vdp more slower than a normal msx1 @ 3.5mhz

Unfortunately msx2 does not have high res timers, maybe i can use the real clock configured in high speed mode, (16Khz) but i cannot find docs about enabling this feature.

hit9918 wrote:

p.s. I wonder what sprite engine is doing in the border.
I mention it because of blitter speedup with sprites turned off, another factor.

Ah, hit9918. from an expert of tms like you i do not expect this question. ;-)
What does the vdp during horizontal border? it does a full SAT scan to find the 8 sprites that can be showed on the next scanline. This is 32 bytes (y coord) vram read.

hit9918 wrote:

But wasnt there something about collision on MSX2 being different in the border? Or was that in horizontal border?
Does MSX2 in vertical border turn off DMA.
Need to know in the whole-screen vs blank calculations.

during vertical retrace the DMA is working @ a speed like VBLANK. So more faster than active area.
i've verified this time ago. however, considering that vdp does not need VRAM for display purposes, the speed gain is moderate. that is an obscure point about vdp. I expected a lot of gain.
For example, when doing a raster line on screen 5, vdp needs 128 bytes read cycles for each scanline. (not counting z80 accesses and sprite accesses). A lot of accesses. Giving those time in vertical retrace to cmd engine, is a lot. But speed is only increased in a moderate factor.

By NYYRIKKI

Enlighted (4599)

NYYRIKKI's picture

10-08-2012, 00:38

Here you can see the timing errors pretty well:

Real MSX (tR GT on Z80):

BlueMSX:

OpenMSX:

I've added this picture generation program to linespeed.zip with name TEST2.BAS
I also fixed the original test.

As we can see from the pictures there is speed difference when drawing in vblank. To take this into account the test should be run in sync with screen draw (not implemented now, but should be easy by adding something like TIME=0:FOR I=0 to 1:I=TIME:NEXT I:FOR I=0 to ???:NEXT I inside turbo block ) I think vblank tests can be run while screen is totally disabled.

What we can also see from the pictures is that drawing lines at 0, 45, 90... degrees is a little bit faster than drawing other kind of lines.

By PingPong

Prophet (2844)

PingPong's picture

10-08-2012, 00:27

NYYRIKKI wrote:

This does not seem very accurate... I did another test that syncs to CPU speed that should be pretty accurately emulated on both BlueMSX and OpenMSX, please try it:

The problem is the speed of real hw, not bluemsx or openmsx ones.
What kind of time result you get with those commands? (I'm interested on Real hw, but because i cannot try on it, i ask you , assuming you can access a real msx2 not modded with strange things ;-) )
200x200
200x100
100x200
100x100
200x1
1x200

(numbers are the nx,ny register values on line command)

By NYYRIKKI

Enlighted (4599)

NYYRIKKI's picture

10-08-2012, 00:53

PingPong wrote:

The problem is the speed of real hw, not bluemsx or openmsx ones.

No, but I hope this will improve the emulation as well. What is nice to notice is that these emulators are actually quite accurate when talking about vertical or horizontal lines. On the other hand 45 degree lines are quite a much off.

PingPong wrote:

What kind of time result you get with those commands? (I'm interested on Real hw, but because i cannot try on it, i ask you , assuming you can access a real msx2 not modded with strange things ;-) )

Actually I don't have MSX2 now hooked up, and I'm too tired to start calculating now anyway. (Where is ARTRAG when you need his math skills? Cool ) The colors in pictures are done in OTIR command and 14 color rotation, so when you know how long the distance is and how many color changes there are, you know MHz and OTIR T-states + M1 waitstate handling you should be able to get very accurate reading.

By wouter_

Champion (378)

wouter_'s picture

10-08-2012, 13:08

hit9918 wrote:

About active area.
If you got the timing of the whole screen and the timing of blanked screen then you can make guesses about speed in the active area. 50hz vs 60hz is different percentage of active area, also 212 vs 192, giving additional hints on whether obtained figures are plausible.

When working on the VDP command timing model in openMSX we indeed found out that (for a good first approximation) you only need 3 speed numbers (per command):
* command speed when screen is disabled (= same for vertical border)
* screen enabled, sprites disabled
* screen enabled, sprites enabled
The speed difference between PAL/NTSC and between 192/212 display lines then naturally follows from the ratio between display and (vertical) border lines in those modes.

NYYRIKKI wrote:

What we can also see from the pictures is that drawing lines at 0, 45, 90... degrees is a little bit faster than drawing other kind of lines.

Euhm, the way i read the graph is that lines at 0 and 90 degrees are fastest and lines at 45 degrees are slowest (the speed of lines at all other angles lies between these two extremes).

Very nice graph BTW. Maybe as a first approximation we can see this 'timing shape' as an octagonal. And the square timing shape in openMSX/blueMSX can be seen as a degenerate case of an octagonal where pairs of adjacent sides have the same slope (fully horizontal or fully vertical). I think this 'timing shape' can be approximated by modeling some extra time for each 'step' in the minor direction, so each time you have to do some extra work in the Bresenham line algorithm. ATM this extra time is zero in openMSX, hence the square shape.

By hit9918

Prophet (2602)

hit9918's picture

10-08-2012, 13:55

Maybe it is this:

when the plotter makes an x step, add some cycles
when the plotter makes an y step, add some cycles.
maybe also add some "default cycles" always needed.

Modding the emus cycles relationships (size of "default" vs xstep/ystep),
if there is something to the theory, then you can aproach this shape.

By NYYRIKKI

Enlighted (4599)

NYYRIKKI's picture

10-08-2012, 18:17

wouter_ wrote:

When working on the VDP command timing model in openMSX we indeed found out that (for a good first approximation) you only need 3 speed numbers (per command):
* command speed when screen is disabled (= same for vertical border)
* screen enabled, sprites disabled
* screen enabled, sprites enabled

Yes, that is correct. I now made screens on my GT (Z80, V9958) from these situations:

Line speed on border time:

Line speed when sprites are off:

Line speed when sprites are on:

For comparison I also made similar pictures on BlueMSX emulator (seems to me same as OpenMSX) :

Emulated line speed on border time:

Emulated line speed when sprites are off:

Emulated line speed when sprites are on:

It seems that current emulation thinks that the speed is same when drawin border or when sprites are off, but that is not true in real life.

By NYYRIKKI

Enlighted (4599)

NYYRIKKI's picture

10-08-2012, 19:37

I'm not a math expert, but I try to do some math from the pictures. Please correct the math, if I do something wrong here:

Time to draw one pixel on horizontal line: (Real hardware, Red color 8 test points from "sprites on" picture: X=135, Y=100 & X=253, Y=100 Cycles with 14 colors in between: 8)

rotation cycles * colors in cycle * ((1 sec / clockspeed in Hz * (OUTI T-states + M1)) / (X2-X1))

With values this means:

PRINT 8*14*((1/3579545*(16+1))/(253-135))

This gives me 4.5 us / Pixel

Similar calculation for border picture gives me 3.7 us / pixel

Is that correct?

By PingPong

Prophet (2844)

PingPong's picture

10-08-2012, 19:38

wouter_ wrote:

Euhm, the way i read the graph is that lines at 0 and 90 degrees are fastest and lines at 45 degrees are slowest (the speed of lines at all other angles lies between these two extremes).

I agree. Also i got the same reesults, 45° is the slowest

Page 3/10
1 | 2 | | 4 | 5 | 6 | 7 | 8
My MSX profile