97

(443 replies, posted in Commodore Computers)

Merry christmas defMON users!

Some haphazard ranting below (note that this doesn't mean that I'm going to start answering questions here on a regular basis):

Amelenium is probably right that martin_demskys problems are related to the ADSR bug in the SID chip. Learning how ADSR behaves in the SID is not straightforward, as things like doing very fast notes is something that doesn't really work well on the SID chip, unless you force it to stabilize using tricks like hard restart. Many other music editors on the C64 does hard restart for the user, which is good for beginners, but it comes at the cost of not giving the user full control. defMON is rather designed to allow the user to do things the way he/she prefers (you can do hard restart in several different ways), and therefore you are responsible for dealing with the SID beast yourself. This makes the learning curve steeper, because you have to understand a bit more of how the SID actually works. It is not quite as easy as knowing what ADSR is on a general level.

Anarkiwi is right about slight differences in the note frequency tables that defMON uses, compared to what just about every other music player on the C64 uses. This is deliberate. The reason is that in defMON frequencies are not rounded to the nearest integer value (below or above, depending on which value that is closest). Instead the values are floored down to the closest integer below. When you floor the values the table actually loops in a curious way, so you can reuse part of the same table data both for the high byte and for the low byte of the 16-bit frequency register. It also enables the possibility of some nice kinds of calculations that exploit this "looping" character of the table data. Rounding or flooring of the frequency data doesn't really make an audible difference anyway.

The two WG columns behave identically, and they are combined using the bitwise OR instruction in the CPU of the C64, before being written to the SID chip. The instruction is called ORA when you write it in assembler and it works like this: Any bit (of the 8 bits that make up a byte) that is set to 1 in either of the bytes will be 1 when the bytes are combined. Some examples of this:

00001111 OR 11110000 = 11111111 (corresponding to $0F OR $F0 = $FF in hexadecimal)
00100000 OR 00000001 = 00100001 (corresponding to $20 OR $01 = $21 in hexadecimal)  
00000001 OR 00100000 = 00100001 (corresponding to $01 OR $20 = $21 in hexadecimal)  
00000001 OR 00000001 = 00000001 (corresponding to $01 OR $01 = $01 in hexadecimal)  
00010010 OR 00000001 = 00010011 (corresponding to $12 OR $01 = $13 in hexadecimal)  

This allows users to do things like controlling the gatebit (using one WG column) separately from controlling the waveform that is currently enabled (using the other WG column). It doesn't matter which of the two WG columns you use for what though.

98

(443 replies, posted in Commodore Computers)

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.

99

(443 replies, posted in Commodore Computers)

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

100

(443 replies, posted in Commodore Computers)

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.

101

(443 replies, posted in Commodore Computers)

Alright. Thanks for the clarifications!

102

(443 replies, posted in Commodore Computers)

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!

103

(443 replies, posted in Commodore Computers)

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.

104

(443 replies, posted in Commodore Computers)

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

105

(443 replies, posted in Commodore Computers)

The link didn't work here.

106

(443 replies, posted in Commodore Computers)

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

107

(443 replies, posted in Commodore Computers)

This is great. Thanks a lot for testing!

I just realized: I think it was in 2008 that defMON got finished enough to be usable, and the first user (goto80) started using it. That should be around 10 years ago now! Then it got public around 2013, when a "cracked" version was released by G*P, which is five years ago. Double anniversary!

108

(443 replies, posted in Commodore Computers)

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.

109

(443 replies, posted in Commodore Computers)

@F7sus4: Thank you very much! Now I've got what I need to be able to look into the problem.

110

(443 replies, posted in Commodore Computers)

F7sus4 wrote:

However, if you load "affected" song using older defMON build (eg. 20141108) and save it, the file will be "healed" from unnecessary data.

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?

111

(443 replies, posted in Commodore Computers)

@anarkiwi: Nice! smile I put a link to your video on the defMON wiki. Hope that was OK.

@F7sus4: Thanks! CTRL+ENTER if I remember correctly.

112

(443 replies, posted in Commodore Computers)

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