Search options (Page 3 of 13)

Looks like that!

@4mat: that's a really cool idea. Seriously. I like the explorative spirit of your work. A pre-built record bag+tool seems like a reasonable approach in this case. I think I understand why.

Sure! The short form of the explanation is something like this: C64 #1 is put into a polling wait loop, which is just waiting for the other C64 to set the CLK bit. When that bit is set, it just starts playing. The tunes running on each computer are assumed to run in the same speed, so this is really just starting them at the same time. It is not actively listening for more sync signals after the initial start. Both C64s sends sync singnals every time a new sequence/pattern is started though, so it is possible for any C64 to re-sync at a new pattern start at any time.

So.. to elaborate a bit. That wait loop in C64 #1 just looks like this:

-                bit $dc01 ;Check STOP-key, in order not to get locked in the polling loop
                bpl .stopwait
                bit $dd00 ;Wait until CLK bit is set..
                bvs -

Before that $dd00 is set like this in C64 #1:

                lda $dd00
                ora #%00100000 ;Set DATA bit (makes it 0 on the other side)
                sta $dd00

C64 #2 sets the CLK bit like this to make C64 #1 start playing:

                ;Send sync signal
                lda $dd00
                bmi .nosyncrequest
.syncrequest:    ;Reply by setting CLK bit
                ora #%00010000 ;Set CLK bit (makes CLK 0 on the other side)
                sta $dd00
               
                ;Some delay to allow the other C64 to react
                nop
                nop
                nop
                nop
                nop
                nop
                nop
                nop
                nop
                nop
                nop
                nop
               
                lda #%11000111 ;=199 - back to normal
                sta $dd00 ;Back to normal...
.nosyncrequest:

That delay is probably just quite arbitrary. I don't think I did any careful calculations to figure out how many nops were enough.

So this is really quite simple. The longer version of the explanation would also involve explanation of some other features that surrounds this stuff. There is some code that actively prevents the other C64 from sending sync signals when the other has gone into the disk menu, and things like that, which means that there are also some other things going on. Don't hesitate to send me a PM in case you want me to elaborate on this.

Alright. Yes, I haven't been in touch with him in quite a while either, so that may very well be the case. Not sure if this BPM calculator helps:

http://toolsforscholars.com/defmon/bpm.html

Note that you may need to add 1 to the speed value seen in the sequence in defMON to get the right value for that bpm calculator. So, if the speed in defMON is "2", that corresponds to "3" in that bpm calculator. At least that is how I remember it. You'll notice.

Another thing that may be good to know is that the next version of defMON will introduce a "nudge" feature, so you can nudge the tune one tick forward/backward with a keypress. That's useful when two sources are running in the same speed, but when the beats are not fully aligned. Hopefully that new version will show up in just a few days.

It would be cool to have some info on programming FM hardware on the C64 at https://codebase64.org/ if anyone feels like writing up something about that.

Yep yep. I think everybody had their say now and I suspect the discussion won't lead further from this point, so I suggest that we leave it here. Other users at the forum may find a continued discussion disturbing.

d3Ni$e: Well, no matter what your intention was, that last post of yours certainly came across as "You are ignoring me. Please explain your intentions behind defMON and defMON 2. Will it only be for [different categories of bad people] or will be it for [different categories of good people]? I like to donate money to various projects, but not if it turns out to be a fraud."

What I was reacting to mostly was that last part, where it sounded like you were saying that defMON/defMON 2 was a potential scam. I understand now that this is not what you meant, since you just stated that clearly. But, to be honest, I still don't understand why you thought it was relevant to bring up the idea of fraud if you didn't think that was relevant in relation to what you were discussing here (my work and intentions with defMON/defMON 2).

To be frank, the rest of that post didn't sound overly constructive and friendly either. It seemed to be coloured by your recent conflict with F7sus4, and since that has absolutely nothing to do with me or with defMON, or even with the "C64 scene" in general, you may want to consider that it is not super interesting for me or other people to listen to that sort of talk. Regarding your initial post, that you complained that I didn't respond to, I want to point out that it mostly a number of statements and it wasn't clear to me at all that you were seeking a response.

I am grateful that you donated money, and that certainly helped my inspiration lately when I've spent quite some time lately to fix a number of bugs in the original defMON + setting up that forum for bug reports and discussions about defMON, some personal support relating to your assembler coding problems, and many hours of work on the new player for defMON 2 over the last few months. Yet another version of defMON is coming out soon too, after Goto80 has done some more testing of the features included in it. However, I would prefer if you don't donate more money in the future. It is probably best that way.