Line

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

By wouter_

Champion (384)

wouter_'s picture

11-08-2012, 12:28

hit9918 wrote:

Please tell cycles. What Mhz is base of the video emu?

The real V9938 runs at 6 times the Z80 speed, so 6*3.579545MHz = 21.47727MHz. Though the VDP emulation in openMSX (nor any other emulator that I know of) is far from cycle accurate. We just try to get a good approximation with a much simplified emulated model of the VDP. E.g. we don't model the 'VRAM-bandwidth-scheduling' at all, I suspect this will be required to get the exact timing shape Nyyrikki got in his tests, openmsx gets a much too regular octagonal.

To get that improved timing shape in openMSX I just guessed a step in the minor direction takes 30 VDP cycles and that first guess already looked reasonably well. But it could as well be 20 or 40. This needs more detailed tests. But first we'll try to release openMSX-0.9.0.

By PingPong

Prophet (2919)

PingPong's picture

11-08-2012, 14:43

wouter_ wrote:

E.g. we don't model the 'VRAM-bandwidth-scheduling' at all, I suspect this will be required to get the exact timing shape Nyyrikki got in his tests, openmsx gets a much too regular octagonal.

emulators do not emulate at a cycle level VDP mainly because we DO not know anything about VDP model itself.
I think sw tests can hide quite some details.
For example, (correct me if i'm wrong), the Nyyrikki test is based on the fact that when you write the color register, the vdp istantly apply the change you've done. It's a reasonable assumpion? Yes. It's true? maybe no...
If one need to go *really* accurate i think the only way is @ hw level. Just sample signals from vdp under some situations (like execution of commands, a number of sprites on scanline etc...) and see what happens. This gives a true model of VDP.

But: anyone owns the necessary instrumentations and time?

By NYYRIKKI

Enlighted (4743)

NYYRIKKI's picture

11-08-2012, 21:35

wouter_ wrote:

I think you got the time of OUTI wrong. OUTI is 18 clock cycles (there are 2 extra M1 cycles in MSX for opcodes that start with 0xED). But doesn't your test use OTIR instead of OUTI? OTIR is 23 cycles per iteration. If I replace 16+1 with 23 in your calculation then I obtain numbers that approximate the cycle counts that are used in openMSX (within 5%-10%).

Total fail: I managed to look wrong instruction speed from table and calculate M1 wrong. (Someone should write a Wiki about M1 as it has not ever been very clear to me) I don't know what I was thinking, but thank you for fixing this.

With corrected calculations for horizontal line it now gives me 6.1us/pixel when sprites are on and 5us/pixel when in border.
45° line when sprites are on seems to take 8.1 us / pixel

wouter_ wrote:

Thanks this is really useful. Which of the three scenarios (screen/sprite on/off) does this model try to approximate? I have the impression that the spacing between the colors matches the screen=off scenario well, but the slope of the sides of the octagonal matches the screen=on/sprite=off scenario better.

This is trying to approximate long side vs short side effect to geometrical shape instead of any exact timing. You may also try adding other affecting variables with this model.

wouter_ wrote:

Or simpler don't change the pixel time, and only add some time when there's a step in the minor-direction ;-) (The Bresenham line algorithm _always_ takes a step in the major direction).

Yes, I'm trying to think how it actually internally works, I leave the implementation optimization for you Tongue

By wouter_

Champion (384)

wouter_'s picture

11-08-2012, 23:08

NYYRIKKI wrote:
wouter_ wrote:

Thanks this is really useful. Which of the three scenarios (screen/sprite on/off) does this model try to approximate? I have the impression that the spacing between the colors matches the screen=off scenario well, but the slope of the sides of the octagonal matches the screen=on/sprite=off scenario better.

This is trying to approximate long side vs short side effect to geometrical shape instead of any exact timing. You may also try adding other affecting variables with this model.

Yes, but the shape seems slightly different between the different modes. That's why I'm asking. (With shape I mean the slope of the sides of the octagonal. Is that also what you meant?)

By NYYRIKKI

Enlighted (4743)

NYYRIKKI's picture

12-08-2012, 12:44

wouter_ wrote:

Yes, but the shape seems slightly different between the different modes. That's why I'm asking. (With shape I mean the slope of the sides of the octagonal. Is that also what you meant?)

I can't really say that I could see that kind of effect.

By hit9918

Prophet (2671)

hit9918's picture

12-08-2012, 14:46

" E.g. we don't model the 'VRAM-bandwidth-scheduling' "

I think this doesn't matter!
On C64 there are funny border destructing things that require the video slot model,
on MSX the "average load per scanline" makes the emu 99% of the real machine.

And in VDP speed limit topics, there is not an average value, but a worst case value.

Because MSX apps are never exactly synced to horizontal blank (even on C64 that is rocket science) this makes one clear speed limit figure. My VDP tests did not have a state "a bit too much speeding -> a bit garbage", it always is "full garbage" or "no garbage".

Feature request:
The current emu behaviour leads to speed limit violating content written!
Because the "break on vram" is on the conservative 29 cycles, lots games would halt, so default setting is OFF.

First thing is to be able to change this cycle number.

Then quickly the cycles the classic games run on would materialize. But one would have to ignore stuff written in emu times Tongue Something around 26 or 27 cycles will materialize.

Next thing is to make a warning signal.
Because bluemsx debugger brake style ends up in a "turn it all off" story.
I suggest the outside pixel of the border set to color 6 red in the violating scanline.
And on border on the other side another pixel in color 8, so with every border color one can see something.

Same could also be done for "cpu feeds LMMC without polling status".

By PingPong

Prophet (2919)

PingPong's picture

12-08-2012, 15:28

hit9918 wrote:

" E.g. we don't model the 'VRAM-bandwidth-scheduling' "

I think this doesn't matter!
On C64 there are funny border destructing things that require the video slot model,
on MSX the "average load per scanline" makes the emu 99% of the real machine.

May be does not matter for actual sw, just because they work well even with actual approximate model.
However, having a deep knowledge of how the VDP work may unleash some others uses.
For example, we all know that writing the adjust register when a command is in execution can corrupt the command result.
But does anyone have given a decent explanation of the reason? No. (If there is one let me know, i'm curious).
Having knowledge of the inner workings at a cycle level does allow us to know when or where it is safe/unsafe to write the register. Maybe one can use this information to write the register while a command is running without corrupting VRAM data.

Another example, (discovered by software, but more easy to discover if there had been a more detailed documentation available). Probably you know that writing a single byte on the port @ 0x99 does change the low byte of the VRAM pointer in TMS VDP. That's because the first byte is written into some place and also does affect VRAM pointer, (this is a hw issue) one can take advantage of this by speeding up vram random writes...

By hit9918

Prophet (2671)

hit9918's picture

12-08-2012, 20:42

I got explanation for blitter wreck! set adjust does scroll the vram slots Big smile

The cheapest way to scroll, delay the entire display generation by some cycles.
So everything is moved, including border and sprites.
Along with sprite and display DMA, the blitter slots got to move, too.

To complete this theory, the blitter only syncs to vram slots at command start.

This is the theory, made from the symptoms.

Setting the same horizontal adjust value over and over again should not wreck the blitter.
I slightly remember reading that vertical adjust does not wreck the blitter.

By hit9918

Prophet (2671)

hit9918's picture

12-08-2012, 21:05

What was the problem again with the failed STOP command?
Like, when restarting, it starts in the next scanline? I forgot.
Can one maybe switch it to point search mode?
Maybe it will finish that one without popping over to next scanline.
Then again start with the desired copy command.

Just random brainstorming.

By PingPong

Prophet (2919)

PingPong's picture

12-08-2012, 21:24

hit9918 wrote:

I got explanation for blitter wreck! set adjust does scroll the vram slots Big smile
The cheapest way to scroll, delay the entire display generation by some cycles.
So everything is moved, including border and sprites.
Along with sprite and display DMA, the blitter slots got to move, too.
To complete this theory, the blitter only syncs to vram slots at command start.

Time ago, i've suspected something similar. So i've done some tests:
1) set the adj when in active area during a scanline (i do not expect corruption, because we are in the middle of scanline generation and blitter command was running )
2) set the adj whenin vertical retace time, ( i do not expect corruption, display is generated from border color)
3) set the adj during horizontal retrace time as the opposite of (1)
instead got it :-( , in all situations.

maybe you are right about blitter sync @ command start. i however assumed that sync occoured on every scanline. probably i'm wrong.may also mean that when one start a command, this is really started at the beginning of the next scanline for simplicity? Really Hoping no... oO

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