The white screen flashing didn't cause any delay. It only takes 6 cpu cycles to execute that code out of 19656 cycles available for one frame. Maybe it seemed that way due to the way perception works, or there was some kind of slight delay when changing patterns for some other reason (but I don't think so) unrelated to the white flash. On old TV sets having a white background may also distort the screen slightly, so maybe that phenomenon was involved as well, when shifting from black to white background.

Bug-report for 20181027 build. sad

Basically, in current build, the player somehow reaches way lower filter values than expected while using Cxxx command (ACID) and/or filter offset (CP), but only after loading a song. This results in music getting "muffled" in some places, because the filter goes down to e.g. 0040, where it would normally be ca. 0240 there (in all builds up to 20171026). It's always difference of 0200 in the "bottom" values.

95% songs from all previous versions are getting affected as a result, but it's difficult to tell what exactly triggers this behavior.
5% songs that do not become affected are "empty songs", e.g. using 1 sequence and barely a few instrument lines.

It's not possible to trigger this bug before loading any song.

This leads me to guess that this behavior is still somehow related to disk operations issue.
__________________________________________________________________________

edit: Ok. I realized that the lowest possible filter value for defMON always was 0200 (playback-wise). Well, it still is, except when loading a song - then the tracker "loses" that feature, thus making the playback noticeably inconsistent between loading and saving.

PS. Sorry to be the "bad messenger" again. wink

Last edited by F7sus4 (Oct 30, 2018 8:53 am)

Thanks for reporting. I don't remember exactly right away, but I think the 0200 limit that you mention is only for 8580 SID chips, and is part of some code that treats filters slightly differently on 6581 and 8580 to achieve a little more similar results irrespectively of what SID chip that is used. I don't see why it would affect only the most recent version, since that code has been there for a long time, but I guess it is possible. I'll look into it!

Since this may also be related to SID chip detection, I wonder if you use a real machine or an emulator, and if you use 6581 or 8580?

Keep the bug reports coming!

Last edited by frantic (Oct 30, 2018 12:26 pm)

@Frantic: Yes, 0200 is the "hard-cap" for 8580 and my current report is based on realC64 with 8580, but it behaves identically in emulated environment as well (Vice+reSID-fp). Because the tracker loses that feature after loading a file only (therefore it cannot be triggered from "clean start" in pre-load state), it leads me to rather strong conclusion that it's somehow part of the file operation issue. Once the "don't go below 0200" rule is broken, the behavior cannot be "healed" and C64 restart is needed.

I think SID chip detection is a bad guess. Even in emulator environment it's perfectly possible to switch between 6581 and 8580 without restarting and defMON reacts accordingly by applying 0000 "hard-cap" to 6581 and 0200 "hard-cap" to 8580 when playback starts (F1/F3). But once this feature becomes broken by loading the tune, again - there's no coming back and restart is needed.

Last edited by F7sus4 (Oct 30, 2018 2:55 pm)

Alright. Thanks for the clarifications!

I'm sharing defMON 20181027 in bugged state freezed with AR. I know freezing is dork-ass stupid, but the bug does not trigger consistently.

New findings:
- The bug does never happen when loading songs that were saved using 20181027 build.
- Only songs from 20171026 build and older (20171024, 20141108) seem to break the player. Not all, though. (All are mono SID songs with proper mono flag.)
- Annoying, but possible workaround is to load "affecting songs" in 20181027 build, save to disk, restart C64 and reload new file.

F7sus4 wrote:

Even in emulator environment it's perfectly possible to switch between 6581 and 8580 without restarting and defMON reacts accordingly by applying 0000 "hard-cap" to 6581 and 0200 "hard-cap" to 8580 when playback starts (F1/F3)...

...but not anymore once it becomes broken. (This can be tested with attached "broken defMON" freeze.)

Last edited by F7sus4 (Nov 1, 2018 1:40 pm)

Great bughunting there!

Looking at it, and I found some things that do go wrong, but still haven't found the root cause. Somehow the player sometimes believes (after loading a new file) that the second SID resides at $1500, which then causes some other code to write $00 to $1517, which accidentally happens to be a memory location right in the middle of the player code (for sid1) that ensures that the filter never sweeps lower than 0200 for 8580 SID chips.

Last edited by frantic (Nov 1, 2018 6:00 pm)

@F7sus4: Maybe I found the bug now. Does this do the trick? http://toolsforscholars.com/defmon/defmon-20181101.zip

Last edited by frantic (Nov 1, 2018 6:00 pm)

@Frantic: Long story short: Everything seems fine now! smile

- Tested both playback and disk operations (ca. 30+ load/save attempts using songs from various versions, ranging 20090304 to 20181027) for malfunctioning, including data loss, filter misbehavior, 2SID playback etc. All good! heart

- Since you mentioned it might be related to SID chip detection, I also tested several realC64 setups: 1) vanilla 8580, 2) dual 8580+8580 (@$D500/$DE00), 3) dual 6581+6581 (@$D500/$DE00), and 4) 6581+8580 combo-build (mono @$D400) that I suspected might be quirky, but everything was fine too and defMON adjusted the filter accordingly to SID model whichever was active at given time.

- The same applies to emulated environment (Vice 2.xx+3.xx).

Hurray! wink

Last edited by F7sus4 (Nov 1, 2018 7:49 pm)

Wow! Now that's clearly a fantastic testing report. big_smile Thanks a lot man. This is definitely much appreciated. I'll put this version up for download as an official release then.

Got another question big_smile This is not wishlist but just thinking if this wouldn't be total dope additional feature maybe in the future?

WG table - Rx sets random waveform ($10-$70). Now imagine the melody being played with different waveform each single note big_smile
ACID table - Rxxx sets random filtervalue (0000-7FFF). Similar purpose. big_smile