Line

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

By Jorito

Mr. Ambassadors (1746)

Jorito's picture

25-08-2012, 04:55

Huey wrote:

C'mon guys. Quit yapping over and over about these VDP subjects. Start coding.......

Amen to that! It would be nice to see some actual results in stead of endless theoretical discussions Smile

By PingPong

Prophet (3104)

PingPong's picture

25-08-2012, 09:20

@hit9918: i think we should move all those discussion to a separate thread... leaving this for the original subject

By PingPong

Prophet (3104)

PingPong's picture

25-08-2012, 15:50

@Wouter. Now i suspect that in openMSX the B constant is zero even for block fill (line , BF). With this method maybe will be easy to calculate B even for rectangle area logical fill & rectangle area byte fill. So having B parameter i suspect it's easy to apply even the same B value to copy operations because i think the time needed for B is the same in logical copy and logical fill. What do you think about?

Will this suggestion improve the openMSX VDP engine emulation?

By wouter_

Champion (388)

wouter_'s picture

25-08-2012, 16:27

PingPong wrote:

@Wouter. Now i suspect that in openMSX the B constant is zero even for block fill (line , BF).

Indeed the current model for block-operations in openMSX (and blueMSX)is simply
time = A * block-area

PingPong wrote:

With this method maybe will be easy to calculate B even for rectangle area logical fill & rectangle area byte fill.

I once started doing measurements for HMMV, assuming a timing model
time = A * area + B * y-size + C + D * x-size
(parameter D was just for verification, and I indeed found it's likely equal to zero)
(I measured I relatively high value for C, but I didn't yet investigate what fraction of this parameter was due to setup time in my test program or setup-time in the VDP command engine).

The method I used was not based on NYYRIKKI's color changing trick, instead it required the TurboR E6-timer (or even better an external timer with Z80-clock resolution). I think I already explained this earlier in this thread.

I didn't finish the measurements yet because it takes a lot of time .. and then other more interesting things came up. Though I plan to continue this someday. Help would be appreciated.

PingPong wrote:

So having B parameter i suspect it's easy to apply even the same B value to copy operations because i think the time needed for B is the same in logical copy and logical fill. What do you think about?

I agree that theoretically parameter B should be the same for all block operations. BUT also in the LINE command I would expect the same value for this parameter for the different modes (sprites on/off, ...). Though my measurements for the LINE commands show that you can get better approximations with different B-values for the different modes. I guess this is because the timing model doesn't take the subsystem-vram-access-slots into account. So the test doesn't measure the 'true' value of 'the B-parameter', but instead you measure a combination of updating the registers + waiting for the next vram-access-slot. And so for the same reason I expect you'll get better approximations for the block commands if you allow different B-values for the different modes and command-types.

PingPong wrote:

Will this suggestion improve the openMSX VDP engine emulation?

What would short-term help the most is a volunteer for doing the measurements (not just running some test program, but actively extending the existing tests, collecting data, and analyzing the results).

By PingPong

Prophet (3104)

PingPong's picture

25-08-2012, 17:03

unfortunately this is not possible to me. :-( because all you request require having access to real machine almost *always* that is a thing that i cannot do pratically. Maybe if there is some other.
I think discovering the vdp internals is somewhat interesting. By the way i realized that vdp itself has a signal that say "i'm doing vram access for display generation" or "i'm doing vram access for other reasons". Maybe a hw guy can capture the signal. The precise meaning of this signal is however not clear.

By wouter_

Champion (388)

wouter_'s picture

10-04-2013, 20:25

FYI, after the VDP command engine improvements (described in this article) the latest development snapshot of openMSX now generates the following output for NYYRIKKI's (modified) test program, see post of 10-08-2012:

This is the output from a real turbor (Z80 mode):

The output is _very_ close but not identical. But running the test multiple times on the same configuration gives similar differences, so I'd say for now this is accurate enough ;)

This test is only for the LINE command, but other VDP commands got similar improvements.

By PingPong

Prophet (3104)

PingPong's picture

10-04-2013, 21:59

@wouter: really GREAT job except for your affermation: "but other VDP commands got similar improvements". This should be "but other VDP commands got similar worsening" :-(

By Manuel

Ascended (14470)

Manuel's picture

10-04-2013, 23:03

PingPong, what do you mean with that last remark??

By PingPong

Prophet (3104)

PingPong's picture

11-04-2013, 14:26

Manuel wrote:

PingPong, what do you mean with that last remark??

the original model, was less accurate, but in this model the VDP was faster. Instead the real model means a slower vdp, so the emulation accuracy is improved, but the vdp speed no..... :-(

By Hrothgar

Champion (478)

Hrothgar's picture

11-04-2013, 14:36

Why would you prefer emulation that exceeds the original machine's capabilities?

Granted, it isn't likely to break anything (like not emulating sprite loss with >4 per scanline, causing Knightmare and MoG gateway passages to look odd in fMSX) but still it could only be harmful.

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