Please help testing upcoming openMSX release!

Ascended (19469)

12-10-2018, 23:24

We ask your help to avoid getting most bug reports after the release instead of before, so we can still fix things. Any kind of testing is most welcome if you share the results with us.

Par ren

Paragon (1934)

12-10-2018, 23:41

Haven't (regularly) used the emulator recently, but will have a look.
...so nothing specific to look (out) for?

Par PatrickR

Resident (39)

13-10-2018, 20:14

I have a crash of openMSX with the following:

OS platform: Xubuntu 18.04, openMSX 0.14.0-367-ge00e2d430, flavour: opt, components: ALSAMIDI CORE GL LASERDISC

Emulated Device: Panasonic FS-A1GT with MegaflashRom SCC+ extension.

loading MIF picture with the BMV library, this is the picture which gives the crash all the time.
Other pictures work ok so far, so it might be the mif picture itself. I don't have a real msx machine here to test the picture and didnt find a viewer for this old format on linux so quickly.
Even though this pic and library could crash the MSX, openmsx should still pick it up like other crashes?

openmsx: src/video/GLUtil.hh:305: T* gl::PixelBuffer::getOffset(GLuint, GLuint) [with T = short unsigned int; GLuint = unsigned int]: Assertion `y < height' failed.
Aborted (core dumped)

crash dump of this has been sent 2 times via ubuntu reporter.
edit: also happening on Emulated Device: NMS8255 and 8250.

after some more tests, it doesnt seem to be from the MIF file, it does load it in and displays it but it happens when the BMV Library has no more pictures to load from code or disk.

Par sd_snatcher

Prophet (3659)

13-10-2018, 20:16

Did some more testing to help. The auto frame skip function goes haywire while you're debugging. It seems to think that the host computer is not being able to draw the frames at the correct pace, and increases the skipped frame ever more up to the limit configured by the set maxframeskip function.

If you manually force the maxframeskip to 0, the problem doesn't occur. But then you're not able to throttle the emulation (F9 key) anymore to skip booting, loading, etc. This forces the developer to constantly change between maxframeskip 0 to 10 and vice-versa.

Suggestion: whenever a debug break occurs, it should signal the frame skipper that the next frame has to be forcibly drawn.

Par ren

Paragon (1934)

13-10-2018, 20:36

I remember, a while ago, I had some unexpected (or nonintuitive) behavior regarding the ((auto) enabling of the) reversebar.. Let's see if I can recall/reproduce.

Something else comes to mind, feature: the max frequency I can set via set frequency is 48000.
My soundcard supports more than that.
OPL(L) is generated @ 49,716 Hz, PSG & SCC @ a lot more..
So I guess mixing @ 96 kHz would mean less loss, but I reckon this wouldn't be audible to mere mortals

(On a side note: I actually do wonder if putting my soundcard's output at a higher freq. (at driver level) taxes my system more.. Doesn't seem like it? Or if it puts a higher strain on the soundcard? Application-wise of course it does require more processing power.)

Other minor thing: record_channels all always dumps everything, including all channels from chips not generation anything. Would it be (easily) feasible to leave those out?

And this one keeps bugging me: [Bug] PSG envelopes are too loud [sf#567] #958 :)
I wonder if there would be any other examples (if someone can recall?) where this can be perceived?

Par mth

Champion (507)

14-10-2018, 04:20

@PatrickR: An assertion failing is certainly a bug in openMSX, regardless of what the MSX program does. Do you have the contents of the crash reports? I can't find them anywhere on launchpad, perhaps only Ubuntu core developers have access to uploaded crash reports.

@sd_snatcher: I checked the code and the realtime sync does get reset whenever the speed, pause or power setting is changed, but not on debug breaks. I think we can subscribe the realtime sync reset to the OPENMSX_BREAK_EVENT as well; I'll have to discuss it with Wouter.

@ren: A higher audio frequency means more data for the sound card to DMA. But compared to the amount of bandwidth that uncompressed video uses, audio uses very little. I don't think supporting 96 kHz will make the audio better in any way though. For example 48 kHz doesn't sound better than 44.1 kHz; the reason to support it is that some sound hardware only does 48 kHz natively.

I don't see an easy way to record only in-use channels, since more channels could come into use change after the recording is started, but if they are only recorded from the moment they are first used, they wouldn't be in sync with the other channel recordings.

The PSG envelopes is something we should look at, but if this is indeed caused by analog effects rather than a bug in the digital part of the synthesis then getting it to sound right would be a new and complex feature, so not something we should do just before a release.

Par PatrickR

Resident (39)

14-10-2018, 09:53

@mth I've uploaded the crash dump here for you.

Par ren

Paragon (1934)

14-10-2018, 10:35

@mth: thanks!

mth wrote:

Yeah, sure. But I'm happy I brought it back to attention, and learning you think it deserves further investigation
In fact I talked with some team members about it last fair. I learned that regarding the OPLL emulation. you actually verified some things with the real thing (I reckon must be this you (they) were talking about(?)) and perhaps some similar undertaking should be done for the PSG.

Okay, now for that reversebar thingie & perhaps other fixable bugs/issues that can be found..

Par mth

Champion (507)

14-10-2018, 15:21

@PatrickR: Thanks! While the crash log contains back traces, those were made without debug symbols though, so they're not very informative (lots of "??"). I guess they could be reconstructed using the addresses and the binary as compiled for Ubuntu, but it's probably faster if we try and reproduce it from running the same MSX software as you did.

@ren: It's Wouter who has been measuring the OPLL (with help from Joost). With the OPLL one of the problems is that the data sheet describes only how the chip works at a high level, so a lot of details are left unspecified. The PSG is a much simpler chip and therefore the data sheet covers much more of the functionality. It's still possible we implemented something wrong, or that the actual chip doesn't match the data sheet, but the PSG implementation doesn't contain a lot of guesswork, unlike the OPLL implementations.

Par PatrickR

Resident (39)

14-10-2018, 15:48

I came to this crash when looking back at one of the disks Meits sent me in the Maas en Mijn disk topic,
it's the TCI022.dsk file, it loads all the pictures and after it's done with the yellow ferrari it gives the crash.
It uses the BMV.bin library and a loader file to feed the file names of the MIF pictures to load, could shorten it if you want to speed it up even more. All files are included on that dsk file.
So far I've tried NMS8250/8255 and the FS-A1GT both with and without above mentioned extensions: same issue occurs for all tested setups.

I'll rebuild to debug, bit silly of me to not have that enabled in the first place, sorry ...