Please help testing upcoming openMSX release!

Will report, is gonna be a nice release I reckon, some cool stuff has been implemented (again)!

Very nice!

I presume this will be v0.17.0?

1. Is this the emulator only, or will this bundle catapult and debugger as well?
2. If I find a bug, I reckon I should go over and check whether it's already reported, here? https://github.com/openMSX/openMSX/issues?q=is%3Aopen+is%3Aissue+label%3Abug Is there a way to see which bugs are targeted for this release of prioritized (I'm not too familiar with the issues-functionality in github). Like what to filter for and sort on?

Ah, sorry, typo. Assumption is 0.16.0, due to headlines on frontpage here https://openmsx.org/

I see the sprite pattern base address is corrected for P2 because all my sprite patterns are now wrong
Unfortunately openMSX crashes big time after couple of seconds in my P1 project

Probleemhandtekening:
  Gebeurtenisnaam van probleem:	BEX64
  Naam van de toepassing:	openmsx.exe
  Versie van toepassing:	0.15.0.750
  Tijdstempel van toepassing:	5ea706ce
  Naam van foutmodule:	openmsx.exe
  Versie van foutmodule:	0.15.0.750
  Tijdstempel van foutmodule:	5ea706ce
  Uitzonderingsmarge:	000000000055def3
  Uitzonderingscode:	c0000409
  Uitzonderingsgegevens:	0000000000000000
  Versie van besturingssysteem:	6.1.7601.2.1.0.768.3
  Landinstelling-id:	1043
  Aanvullende informatie 1:	f314
  Aanvullende informatie 2:	f3140362be8ad166b6b71c174e0adbad
  Aanvullende informatie 3:	a08f
  Aanvullende informatie 4:	a08ff7410f875d94b9ca9163b2911c3c

The other small test programs I shared appear to work fine: ce flag test, sprite prio test and though BMXL still not fixed, the beasts test also runs fine.
What could possibly cause the crash

Some things for now:

* 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).

* 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

* 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=

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.)

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

Tested on Win7-64.