Search options (Page 7 of 13)

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.

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!

Goto80 digged up a few old versions. One is from April 2008. One is from a disk labelled October 2008, but I am not sure if that means that this defmon version was created then, or if it is just the tunes that was on the disk. The defMON version may be some months older. The other two I don't know, but I think they are both pre 2009 too.

http://toolsforscholars.com/defmon/oldversions.zip

Goto80 may have some old versions. I may have that too, but the floppies and my diskdrives are in different places, so it may take a long time before I would be able to check. Nowadays I'm only using the 1541U2 as "diskdrive".

I think I finally managed to find and fix that "inflated file size" bug. Let me know if things work as expected:

http://toolsforscholars.com/defmon/doku … d:download

It may be wise to keep a backup copy of your tunes before trying this version, since I made changes to code that relate to the saving of tunes. I think it will work fine though.

That is very useful to know! Thank you very much! Could someone send me one or a few "inflated" tunes? That would help debugging.

I have a feeling that that particular version (2014-11-08) may be the last one that doesn't have this problem with "inflated size" of some saved tunes, since the version after that (2017-10-24) involved some fixing of bugs related to packing of worktunes when saving them, and possibly therefore created a new bug in the packer code.

Could you or someone else confirm that 2014-11-08 would fix the inflated size problem, whereas loading the tune in 2017-10-24 would not?

@F7sus4: Thanks for the input. I had missed that post, so sorry for not responding. This information will be useful for sure. Minor comment in the meantime: RAW save of $1000-$1F11 includes the actual player code, not only music data, so that is why it seems huge.

@Anarkiwi: If you look at the list of sequences used in the song (the list of values on the right side of the screen when you start defMON), and look specifically at the first line, you'll see that it says 01 00 00. This means that in the first channel, sequence 01 is shown. Both of the other two channels show sequence 00. Therefore, when you edit sequence 00, you'll see these changes in both channels, as it simply is the same sequence shown in both places. In general it is a good idea to leave sequence 00 alone (empty that is). Normal workflow would be to go to the sequence list, place the cursor on one of those "00" values, and press SHIFT+U to automatically change the sequence number to "next Unused" sequence. If you're starting on a new blank song, that would of course be sequence 02. You could achieve the same thing by simply writing 02 instead of 00 at that location in the sequence list.