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.
Last edited by frantic (Dec 24, 2018 2:46 pm)