Please help testing upcoming openMSX release! | MSX Resource Center (Page 13/65)

Paragon (1932)

01-05-2020, 17:11

Space Manbow issue: seems to happen only on boosted EN (as soon as you start the game). Boosted JP is fine, as is regular 8250. Same results in 0.15 release. Regular unpatched rom runs fine on boosted EN. So issue is either caused by patch, or emu bug..?

By Manuel

Ascended (19330)

02-05-2020, 00:32

Dolphin101546015 wrote:

Seems like my issue, what I reported is disapear in new release.
I continue testing.

Please do so, thanks. I'm not sure what you mean with the first thing, but I have to tell you that we cannot solve everything at once... but if it's a critical bug, we'll try our best to solve it as soon as we can.

By Manuel

Ascended (19330)

02-05-2020, 00:33

GhostwriterP wrote:

Unfortunately openMSX crashes big time after couple of seconds in my P1 project

What could possibly cause the crash

Please share with me or us your program and a scenario (so we can reproduce the crash) and we'll fix it.

By Manuel

Ascended (19330)

02-05-2020, 00:43

ren wrote:

* When scanning with Catapult, it initializes every device found, and creates multiple 100MB disk images, and some other relatively large .sram & .sdc files.
ATM a default openMSX user folder, after scanning with Catapult, is around 436MB.
I think it would be better to create these files only when they're actually required, i.e. when starting the machine or extension for the 1st time. Not a biggie though (if you want to reclaim the space you can delete the files).

Good point, I put this here: https://github.com/openMSX/openMSX/issues/1250

Quote:

* There have been requests to be able to specify directory where openMSX puts files, and concerns about using CSIDL_PERSONAL for Windows. I see it's actively discussed in the issue tracker as well ATM.

There's OPENMSX_USER_DATA (that's undocumented I believe).
Persistent data still goes in CSIDL_PERSONAL, regardless that setting.
A solution could be to add an OPENMSX_PERSISTENT env var as well. That would give user enough means to customize the dirs (along with the filepool setting).

Other workarounds include:
* using symlink(s) (dubbed junction in Windows/NTFS);
* run openMSX/catapult via .bat:

@echo off
setlocal
set USERPROFILE=%~dp0_data
openmsx.exe

Thanks for your valuable input. I put it in the corresponding tracker ticket: https://github.com/openMSX/openMSX/issues/1246

Quote:

* mention SDL_VIDEODRIVER env var in setup guide and/or FAQ
I mentioned that in msx-talk/openmsx/openmsx-does-not-start
Some users might have that variable set, and may run into issues.
For windows/SDL2 the var should be unset or 'windows', unset via set SDL_VIDEODRIVER=

Do we actually know a case where it was wrongly set? As you said, only one value is supported anyway.

Quote:

I had this issue where the SDL renderer would give a corrupted screen, but running the latest build no issue.
Still think setting blur from 0 to 1 is somewhat of a leap when using PP ;)

Oh, and I had Space Manbow FRS turbo fix running in the bg on a Boosted MSX2 EN machine, which got corrupted (had it running (demo mode) for 15 minutes or something - sound playing fine, screen was all 8x8 squares or something, then it crashed when I wanted to investigate :) (black screen, some static noise)) (Will look into that a bit.)

Space Manbow issue: seems to happen only on boosted EN (as soon as you start the game). Boosted JP is fine, as is regular 8250. Same results in 0.15 release. Regular unpatched rom runs fine on boosted EN. So issue is either caused by patch, or emu bug..? Smile

I bet it's an issue in the patched game. That Boosted machine is quite heavy, maybe the interrupt routine is too long?

Quote:

Liking the drag-drop on the openMSX window stuff, that's new right?

Yep, thanks! Glad you like it.

Thanks a lot for your feedback (so far!)

By Manuel

Ascended (19330)

03-05-2020, 23:28

GhostwriterP wrote:

Unfortunately openMSX crashes big time after couple of seconds in my P1 project

What could possibly cause the crash

I think we fixed it, for details see https://github.com/openMSX/openMSX/issues/1251 Thanks for reporting!

By ren

Paragon (1932)

04-05-2020, 09:53

Manuel wrote:

Do we actually know a case where it was wrongly set? As you said, only one value is supported anyway.

My machine I must have set that in the past for some game/program that required it. DOSBox probably? Chances are slim, but can't hurt to mention in the FAQ or a troubleshooting section I think?

Regarding the data dir stuff - I think having the option to specify via cmd line would be favorable as well. That would take precedence then over the env vars. An .openmsxrc could be one of the possibilities as well. On Windows you see vendors using USERPROFILE (the root) for that. Would be cool to have multi-scope support as well for that. i.e. an .openmsxrc in the (an) openMSX app directory would take precedence over the/an global user config. This could e.g. make it easier to config things when running multiple openMSX versions, testing etc. Npm is an example that incorporates all these ways of configuring.

My use case has been indeed wanting to reclaim space on the system partition (and wanting to move the openMSX dir out of My Documents anyway ;)) I tend to use fillepool to point to a central common system roms dir. And I do want to test things sometimes in a fresh data dir, then I use either renaming of the current My Documents openMSX dir, or the .bat trick :)

Quote:

Thanks a lot for your feedback (so far!)

Cheers!

By Dolphin101546015

Champion (335)

06-05-2020, 15:28

Pioneer PX-7 not starting. Window open and disapear again without any messages.

By Manuel

Ascended (19330)

06-05-2020, 17:36

Dolphin101546015 wrote:

Pioneer PX-7 not starting. Window open and disapear again without any messages.

Can you be a bit more specific on what you are doing?
- which version exactly
- which OS
- which way are you trying to start it (Catapult, command line, something else?)

For what it's worth: it works fine here, so I need more info to find out how to reproduce the issue.

By Grauw

Ascended (10720)

06-05-2020, 23:04

The new setting sync_to_vblank_mode and the accompanying change of the default value from sync to immediate is a bad default for MacOS.

If you remember I reported a stutter issue on MacOS after the migration to SDL2. That issue disappeared at some point (probably 706793b) so I was a happy camper. But now it has returned. What was a smooth scroll now looks terribly stuttery once more. Also at 50 Hz it looks worse than it does at the other settings. Using the sync and sync_adaptive settings it looks as fine as it did in openMSX 0.15.0.

By Grauw

Ascended (10720)

06-05-2020, 23:27

If I would describe the effect, it runs smooth for a bit and then starts stuttering for a couple of seconds and then runs smooth again and the cycle repeats. This goes on and off, ~8 seconds good ~8 seconds bad. Clearly there is some variance and jitter in the timer of either the display or openMSX (probably they have different crystals), and this is the effect you would expect to get. I don’t really understand how immediate can ever work for any computer, but anyway, it doesn’t on MacOS.