Please help testing upcoming openMSX release!

Por Manuel

Ascended (19469)

26-08-2021, 22:24

But then you are writing to the folder, aren't you? Or what am I missing here?

Por Dolphin101546015

Champion (336)

27-08-2021, 18:07

Manuel wrote:

But then you are writing to the folder, aren't you? Or what am I missing here?

I write to the folder before using it.

Why you trying find something else, than I told before?

Problem described more than year ago, and no any tests your made. Why?

Por Manuel

Ascended (19469)

27-08-2021, 19:57

What tests can I do then? It just works for me on my Linux system. And it's not known how to trigger the issue. What did you do to find out how to trigger the issue?

Por sdsnatcher73

Prophet (3963)

27-08-2021, 21:04

Manuel wrote:

What tests can I do then? It just works for me on my Linux system. And it's not known how to trigger the issue. What did you do to find out how to trigger the issue?

It may be a platform specific issue. Some code inspection on file handling specific for Windows could be done. Or setup a VM with Windows to test it also could be done (well you asked what you could do ).

The issue here is obviously there seems to be an apparently almost random situation triggering an issue. Would it be possible to build into openMSX a recorder function based on the existing replay functionality. The record should allow to save the state of the MSX at start, include added files/dirs added to slots and drives. That way the actions could be replayed by the devs and hopefully reproduce the issue.

Por Pencioner

Scribe (1566)

27-08-2021, 21:31

Could it be related to non-latin (cyrillic) symbols in file path? (just a guess)

Por Manuel

Ascended (19469)

27-08-2021, 21:36

Who else has this issue? What are the common things between the people who experience this issue?

Those things are more important to find out first, before spending a lot of work on the issue, spending our free time whilst we could also have spent it on other openMSX or even other hobby things.
If someone experiences an issue, the most important thing is to find out how to reproduce it. Without that, it is almost impossible to fix it. So, I suggest you get on to that, my dear Dolphin101546015!

@Pencioner: that's definitely a good thing to test.

Por NYYRIKKI

Enlighted (6067)

29-08-2021, 17:02

Hello,

I just noticed that openMSX seems to expect that screen splits happen immediately when VDP registers are written... How ever this is not true at least on my MSX tR. There seems to be only certain places where the written value takes effect to screen output.

Here are some examples of such wrong assumptions:
VDP register 2:
Writing to this register has effect only 32-times during line draw effectively after each 8 pixels (or 16 hires pixels) There is exception in SCREEN 0 where the effect is applied after 2 characters in 40-column mode and 4 characters in 80-column mode. (12 pixels / 24 hires pixels)

VDP register 23 (Y-scroll)
Works almost same as register 2 change, but in 80-column mode the effect is taken after 2 characters just like in 40 column mode. (always 12 pixels on SCREEN 0)

VDP register 26 (X-scroll high)
In screen modes 1-4 the scroll is applied 32-times during line draw while in SCREEN 5-12 it is applied 64-times during line draw (4 pixels / 8 hires pixels)

I bet there are lot more details to be found, but I think these might be the "most typical" splits.

Por Manuel

Ascended (19469)

29-08-2021, 17:13

Thanks, NYYRIKKI, created a ticket here: https://github.com/openMSX/openMSX/issues/1374 If you get more information, ideally, you would add it there :)

Por NYYRIKKI

Enlighted (6067)

29-08-2021, 17:37

Thanks Manuel!

BTW I've also noticed that there is definitely something horribly wrong in status register 2 VR flag, but unfortunately I can't yet quite put my finger on the problem... I can only say it works differently in openMSX and in real machine.

Por wouter_

Hero (525)

29-08-2021, 19:23

NYYRIKKI wrote:

I just noticed that openMSX seems to expect that screen splits happen immediately when VDP registers are written.
...
VDP register 2 and 23:
Writing to this register has effect only 32-times during line draw effectively after each 8 pixels (or 16 hires pixels)...

I assume there's a connection with the vram fetch timings. Notice how the data for the (bitmap) pixels is fetched in 32 blocks of 8 pixels.

It's hard to correctly emulate this behavior without _much_ more information on the exact inner workings of the V99x8. Any volunteers to reverse-engineer this? (I don't have time for this myself).