Search options (Page 1 of 13)

Not sure but could it be a PAL vs NTSC issue?

Hi guys,

Sorry to say, but defMON will no longer be a public project. I started coding defMON about 15 years ago, and it has been public for the last 8 years or so. The reason for pulling the plug is that I am receiving various accusations, and since 25 of April even some vague threats. I have definitely had enough. Therefore I am now closing the doors on this project. At the moment I can't see that there will be any development behind closed doors either, as these things really made me lose inspiration for this project altogether. Of course things might change at some point, but I can't see that it will happen within the foreseeable future. Sorry, but that's how it is.

I won't delete the defMON wiki or any of the old downloadable versions though, so that will still be available. People here have been helpful in finding various bugs, and while many of them have been fixed, not all of them have, but I would still say that the current version seem to be relatively bug free. At least that is my impression. (The reason for why some of those bugs are not fixed is precisely because it has been hard/rare to even make them appear.) Hence, people who want to give defMON a try should be good to go with the versions that are already available. More specifically, the latest version is the recommended one.

As for this forum thread, I am not going to read/write in it anymore, which means that it will no longer serve as a place for bug reports.

That's all I had to say. Take care out there!

Ciao!

@Martin: Nice! Unfortunately it is no easy task to shrink the characters in the font to 4x8 size, instead of 8x8. The reason is that the graphics chip of the C64 has this "character mode" which is used in defMON, where it operates with 8x8 chunks of graphics. If one would use 4x8 characters, then one would have to do plotting of individual pixels to draw the characters instead, which would be way too slow for the processor to handle.

Another problem is that 1 pixel wide graphics on the C64 do not work well on many monitors. In some cases it can turn out barely visible on an old PAL TV. That is the reason for those "two pixel wide" fonts.

I have actually been experimenting with a custom font that shrinks the "C-3", "D#5" etc character strings to something that fits into two 8x8 chars instead of three, so some things like that are possible to do and still use the "character mode". The problem is that custom fonts have to be put in RAM, so some RAM is wasted on that. If one uses the built in font of the C64, there is no need to "waste" precious RAM on a custom font as the system font is located in a separate ROM chip. So, that is a trade off between different priorities.

Having said that, I must confess that I lost some of the inspiration for a defMON II after the conflicts raving around here and on other forums a while ago. What I am considering instead though is something like a "defMON 1.5", which builds mostly on the good old defMON, but that does some changes that might break backwards compatibility of the tunes. (defMON 2 would do that  too anyway). I haven't decided though, so at the moment this is just something that I have been thinking about. Primarily it would be a matter of investigating how much support for a midi interface ( https://github.com/anarkiwi/vessel ) I could add to defMON. Things like MIDI sync IN, MIDI note data OUT and so on.

You can use the sidfx already in the original defMON. I have that in two of my machines and it works fine with defMON.

I would say: Focus on learning the actual software, and then look at tunes made by others in that software.

Hehe.. Yeah.. I actually agree. It is funny how one thing (e.g. insistence of doing hard restart manually since that lead to more generic code in the player without special code for hard restart) led to another ("extra" step in the beginning of sequences) and how that turned out to be a quite useful feature for some things.

I also seem to remember that someone commented on this at some point in this thread and I think I said then that in a way this is actually just a result of how the sequence data is presented on the screen (and... well... where you end up if you press CTRL+G for example), since the row numbers start at the second step instead of starting at the first step. So.. if someone *badly* wants the first step to actually be the first step, they can simply treat it that way. Of course they will run into problems then, if they want to put hard restart sounds on the first row, but... at least they can.

So there was a slight difference after all in how the hardware worked. Thanks for this. I will send you a PM.

defMON uses CIA timing. The "ticks" that were mentioned here doesn't relate to that, though. That just means the number of times the player code needs to be called to advance one step in the sequence.

So.. there are two factors involved in "speed".

1. The number of player code calls before advancing one step further in the sequence. In defMON the "speed" column in the sequence specifies the number of ticks until next step in the sequence, BUT... it is somewhat non-intuitive. (There is a reason for it actually, but..)  Writing "2" in the speed column actually results in 3 ticks per step. Writing "3" results in 4, and so forth. So the actual number of ticks is always one more (+1) than what is written in the speed column.

2. The time between each call to the player code. This can be controlled with VBLANK interrupt (on C64 it would be called a raster interrupt) or with a CIA timer. CIA timers are much more fine-grained, just like you say.