Mystery: game Bestial Warrior with corrupted colors in MSX1

By ARTRAG

Enlighted (6977)

26-12-2019, 21:21

this could be very interesting if confirmed

By mcolom

Champion (320)

26-12-2019, 22:35

I found a video from Fernando García where he tests Obliterator in a Sony HB-20P and it turns out that the real machine behaves exactly the same: https://youtu.be/7HXZHeZIuJY?t=1867
I don't remember Bestial Warrior having any corruption, but I guess it's just I have forgotten about it. Curiously, the author of the video also tells that he didn't remember any corruption in Obliterator, but then it checks in the real machine and indeed it's there.
Given that the HB-10P in the video has exactly the same VDP as the HB-20P, I guess we can confirm that it's normal that it doesn't work well. There's no mystery in the end. And openMSX is doing an excellent job emulating that, needless to say :)

By ARTRAG

Enlighted (6977)

26-12-2019, 23:45

I was looking at the very same video
https://www.youtube.com/watch?v=7HXZHeZIuJY&t=481s
The real thing working is at 32:00
But from what I understand, at least on this sony HB10, the color corruption happens when you run the too fast code

By mcolom

Champion (320)

27-12-2019, 00:38

ARTRAG wrote:

But from what I understand, at least on this sony HB10, the color corruption happens when you run the too fast code

Yes, both Bestial Warrior and Obliterator update the bitmap with a speed which is fine for the 9918 (or variants), but too fast when updating the color table. Why? Probably the programmers test it only in a MSX2, where updating with a delay of 20 t-states is fine.
Still, I'm surprised that they released the games just like that. Bestial Warrior was published by Dinamic, a quite professional company, so again it find it weird that they did it like that. But it's true that this game is considered below the quality standards of Dinamic (even though it's not a bad game).
We can related this is related to a different thread in the forum (https://msx.org/forum/msx-talk/software/zx-spectrum-games-po...) about ZX-Spectrum ported to MSX. In this case it's not just that they did a direct conversion, but even worse, the games didn't work correctly! That video is the definite proof.

By pgimeno

Champion (328)

27-12-2019, 02:04

In the Obliterator video, If you see the floor where the player is standing as a meter, and compare the emulator screen (at ~3:40) with the real machine screen (at ~31:06), I notice that the real MSX shows more red than the emulated one. My interpretation is that a few more of the VDP commands succeed in the real machine than in the emulator. So it appears that it sometimes succeeds even if most times it doesn't, which would also explain the mismatch in Karateka in the issue that Manuel linked.

By pgimeno

Champion (328)

27-12-2019, 16:43

I've now tried Obliterator in a real Philips VG-8020/40 and the output is different from the HB-10P and more similar to the emulator. The emulator still seems to be disallowing more VDP accesses than the real machine.

The VG-8020/40 I tested it with contains a TMS9129NL (I've looked to be sure), while the HB-10P presumably contains a T6950. Maybe the TMS9918 is more restrictive with the timings and that's why the emulator shows differences.

Edit: As for Bestial Warrior, pretty much the same thing. The real machine shows corruption, and that corruption is different from the emulated one.

By mcolom

Champion (320)

27-12-2019, 18:02

If you look at the corruption in the video and the corruption in openMSX, you'll see that actually both are the same, but it happens sooner in openMSX.
To me, it's bad timing with the VDP access windows for the CPU.

What I did was to use a more fine access time and to make it happen earlier. How much earlier? To do it, I used your idea of the "meter" in Obliterator, and I added a small time shift (but not a multiple of DELTA, as in the current code) so the emulation matched what we can see in the video. And it matches pretty much the same
Why do we need that time shift? I don't have an explanation for that, but experimentally we can check that adding it creates the same artifacts in Obliterator as in the video and it fixes Karateka. (BTW: I'm assuming Karateka is KARATE-A.CAS with shasum da5da7ea7e7c88a29316e7119f0362e17a6b84cb).

My modifications are here: https://github.com/mcolom/openMSX/commit/406b21c0d78579bbc87...
I opened a PR also: https://github.com/openMSX/openMSX/pull/1206

It doesn't fix Utopia (the fishes scene, I guess), but fixes Karateka and improves Bestial Warrior to a point that it starts to look familiar to me, compared with my memories of my real machine :)

pgimeno: it'd be great if you could compare the emulation with my modification in a real MSX1!

By pgimeno

Champion (328)

27-12-2019, 19:08

Two typical shots with the patched emulator:

http://www.formauri.es/personal/pgimeno/temp/Obliterator%20%...
http://www.formauri.es/personal/pgimeno/temp/Obliterator%20%...

Two typical shots from the real thing:

http://www.formauri.es/personal/pgimeno/temp/Obliterator_rea...
http://www.formauri.es/personal/pgimeno/temp/Obliterator_rea...

I think that the exact VDP model makes a difference.

By Manuel

Ascended (19678)

27-12-2019, 19:29

I think it's easier to see with inline images:

Quote:

Two typical shots with the patched emulator:

Two typical shots from the real thing:

I think that the exact VDP model makes a difference.

By mcolom

Champion (320)

27-12-2019, 20:30

pgimeno wrote:

I think that the exact VDP model makes a difference.

Thanks a lot for your tests!
I agree with you, the exact VDP model is the key to this problem.
I adjusted the timing so it gave the same artifacts as in the video. The real machine in the video has a Toshiba T6950A VDP. Your VG-8020/40 has a TMS9929A or TMS9129NL.
Luckily, there are not many different VDPs along all the panoply of MSXs.

Obliterator is just great to adjust the timing
Could you modify src/video/VDP.cc line #815, and change 4930.0 to something smaller? (say, make it decrease in steps of 250 or so). The "meter" should get lower. If you can find the right value, we can change the code and use a different constant for the 6950A and the 9918/9928. As far as I know, these differences are not documented, but luckily we can adjust it experimentally with Obliterator.

I could do it myself, but I don't have your real computer to compare :/