Mystery: game Bestial Warrior with corrupted colors in MSX1

Page 4/5
1 | 2 | 3 | | 5

By Grauw

Ascended (8621)

Grauw's picture

28-12-2019, 13:34

PingPong wrote:

So What is the point of having this feature fully emulated if no sw can use or take advantage of it and if doing to fast I/O make a sw defective or useless? It has no reason to be accurate. What's the point in emulating an undefined behaviour?

Having even the undefined and timing problem behaviours emulated is very important for development. Otherwise developers will create something that seems to work fine on the emulator used in their development environment, but then breaks on the real machine. Not only does it waste time, but it is also much harder to debug on a real machine, and some developers don’t even have a real machine so they will discover such problems very late in the development process.

For me, I’m glad that the VDPs are quite well emulated by openMSX, but the FM sound chips still have inaccurate (no) emulation of the timing restrictions, which has caused me quite a bit of hassle in VGMPlay development.

By PingPong

Prophet (3495)

PingPong's picture

28-12-2019, 18:18

Let me clarify:
To me the point is another. I agree to the fact that the vram timing limit should be reported in openMSX, (and is great that openmsx does this) what i consider totally pointless is the need of emulating this corruption in a perfect way. To know that i'm doing too fast I/O to vdp it is more useful and reliable a message in the console or screen. When i see a small corruption on openMSX and a more large corruption on real machine what is the gain? In both cases i know i'm doing a too fast I/O. The fact that the corruption appears in openMSX and real is non identical way does not help me in solving the issue. It only show me that there is a issue.
It is more useful to get a message like 'too fast I/O at address xxxxx' than relying on a relatively small pixel corruption that may also disappear from time to time anytime i do some screen update.

By Manuel

Ascended (15979)

Manuel's picture

28-12-2019, 18:48

FYI, l_olivera ran Bestial Warrior on a machine with TMS9128 and got this:

and

As he put it:

Quote:

the "tools" portion of the screen on bestial looks a bit "scrambled" lol
bestial also has some random lines appear sometimes on the screen

By mcolom

Resident (57)

mcolom's picture

28-12-2019, 20:27

Manuel wrote:

FYI, l_olivera ran Bestial Warrior on a machine with TMS9128 and got this

Thanks to him for testing Smile
But it seems that the pics can't be accessed :/

I used the Sharp_HB-8000_1.2 with the patched/original openMSX code, and it turns out that the blue block that you can see in the menu (at the bottom) is useful to adjust the timing. Of course, this is not accurate at all, but it gives a rough idea. I emulated the Sharp_HB-8000_1.2. In other machines with the TMS9128 the blue block doesn't appear (no matter if it's patched or not).
Original:

Patched:

The more (negative) delay in the VDL access slot, the earlier the blue block begins.
If we could see that menu in real machine it would give us a better idea of the time shift needed in the TMS9128.

By Manuel

Ascended (15979)

Manuel's picture

28-12-2019, 20:46

Perhaps you are using another crack... the one we used doesn't show any blue bock on an 9128 in openMSX (I tried Gradiente XP-800).

By Manuel

Ascended (15979)

Manuel's picture

28-12-2019, 21:08

Reposting....

Manuel wrote:

FYI, l_olivera ran Bestial Warrior on a machine with TMS9128 and got this:

and

As he put it:

Quote:

the "tools" portion of the screen on bestial looks a bit "scrambled" lol
bestial also has some random lines appear sometimes on the screen

By mcolom

Resident (57)

mcolom's picture

28-12-2019, 21:53

Oops, please forget about my last pictures. It turns out that actually I didn't have "calibrated" yet this VDP and the only difference was that I use DELTA_32 and the original code DELTA_28.

Now, using a constant of 1440 for this VDP, I obtain the following:

Not exactly the same as the real machine, but similar.
More tests are needed to validate this, of course.

By pgimeno

Resident (48)

pgimeno's picture

29-12-2019, 12:44

The owner of a VG-8020 has told me that back in the time, Dinamic games which were direct conversions from Spectrum ones were very often affected by this issue. It appears that indeed, they shipped these games to the users with that defect.

There's one issue with the tests as I devised them. Apparently, having the CPU clock in sync with the VDP one is not all that common, and that has potential for causing non-deterministic results. Manuel told me in IRC that the models with separate clocks are identified as such in the machine XML files. The V9938 has a CPUCLK pin which is probably used in most models, so the MSX2 results will probably be more consistent.

I guess that the emulator will always run with synced clocks no matter the model.

By PingPong

Prophet (3495)

PingPong's picture

29-12-2019, 13:13

Msx2 vdp is faster and it is unlikely that this corruption happen

By mcolom

Resident (57)

mcolom's picture

29-12-2019, 13:34

pgimeno wrote:

The owner of a VG-8020 has told me that back in the time, Dinamic games which were direct conversions from Spectrum ones were very often affected by this issue. It appears that indeed, they shipped these games to the users with that defect.

In this page https://xtremeretro.com/bestial-warrior-parte-2/ (in Spanish, but I think it can be Google translated without much problem) the authors speak about the game. I love the last paragraph, when the authors says that "The MSX was borrowed from a cousin" :D
So yes... most probably what happened is that him used an MSX2, showed quickly to Dinamic, and then the green light was given to sell them game. Without much testing.
In MSX2 the artifacts don't appear since they have usually the 9938 VDP, which is faster than the 9918 and equivalents in MSX1.

Looking at the captures Manuel posted here, it seems that indeed the artifacts are not deterministic, unfortunately. The frame of the menu's screen up colorized at the beginning, and its colors are never changed. However, two different executions of the game (and I assume they're different) give different colors in the frame. In the emulator (patched or not) it's always the same.

If that's the case, then it's much more complicated that a simple time shift. I think it might look like a time shift + some random shift. This "random" actually is not, but I don't there's any way to simulate it with the discrete master clock of the emulator. It's more like forcing the VDP to be outside its working rate, and then probably it's not just that less access windows are caught by the problem, but also that the VDP internally behaves in a pretty (literally) chaotic way that probably not even its designers really master.

To me the key question is to understand if the observed time shifts (that I assumed are in the access windows). I'm thinking of several options.
1) A normal behaviour of the VDP. They open access windows regularly, but with a time shift that the emulator doesn't take into account.
2) There's a bug in openMSX. The code assumes all the time that it's a V9938 and it divides its speed by 8 in the case of one MSX1. But it could be that the time the V/H syncs or starts of display are not accurate. Actually, it never adjusts the number of ticks per line. I'm not saying that there's a bug there at all or that the approach is not exact. Actually the code of the emulator is so great :) All I'm saying that I'll have a look to understand better how its done.
3) The 50/60 Hz difference causes a de-synchronization time shift. This could be related with the previous point.
4) Some changes might be activated with raising edges and some others by falling, and (perhaps) this is not taken into account.
5) Outside its working rate, most of the assumptions about the VDP are not valid. It could advance the access windows just because it's not working correctly.
I'm just guessing some possibilities, without any confirmation.

My guess is that there's a real large time shift in the appearance of the access windows of unknown origin + some (small) "random" malfunction of the VDP because it's working out of the specifications. At least, the observations suggest this to me.

Page 4/5
1 | 2 | 3 | | 5