chipmusic.org is an online community in respect and relation to chip music, art and its parallels.
You are not logged in. Please login or register.
ChipMusic.org / Forums / Posts by frantic
...and, actually, after some more digging, I found out that the interface is a "Steinberg MIDI2" interface, and that it should be compatible with Datel / JMS / C-Lab / Siel. So I should definitely try it out with something else than M64. It is this one:
http://blog.nebulah.nl/posts/2013-03-02 … r-the-c64/
The sticker is ripped off on the one I have though, so that's why I didn't know at first which one it is.
I finally got hold of the diskdrive and tried the interface, and I couldn't get it to work. The software I used was M64, and it has options for Sequential, DATEL, and Passport compatible interfaces. None of them seemed to work, although I could verify that M64 itself works great with another interface (that I use myself, so I'm not selling that one). There ARE other interfaces though, so it is possible that the one that I have is of yet another kind. A number of other interfaces are listed in the source code for SID Wizard, and all of them use the same type of chip for the MIDI communication, so they are similar in that sense. They just use different memory addresses.
https://sourceforge.net/p/sid-wizard/co … DI-C64.asm
* SEQUENTIAL/NAMESOFT
* PASSPORT/SYNTECH
* DATEL/SIEL/JMS/C-LAB (double-speed devices)
* MAPLIN
* MOOG SONG PRODUCER
So I guess it is possible that the interface I have actually works, but that it is of the MAPLIN or MOOG type instead. I also just noticed that the author of M64 stated that he was unsure whether DATEL actually worked in M64 even though the program itself says it is supported, so in fact it may be possible that it is of the DATEL type — only that M64 doesn't actually support it. I guess I should try the interface with SidWizard instead, since it seems to have better support for different interfaces, but I haven't used SidWizard for anything so I don't know how it works. It could of course also be the case that this interface is simply broken.
Alright. I'll let you know when I've had the chance to pick up a diskdrive and try it out.
Duh.. I made a really silly mistake. OBVIOUSLY I should have gotten a diskdrive as well (or a cartridge port expander) when I picked up the MIDI interface yesterday. I can't load any software to test the MIDI interface now, since the MIDI cartridge occupies the cartridge port, and in these days I always have a 1541U2 cart plugged in there to load software... Silly me. Also, it may take a week or so before I get back to the place where I've got the gear stored. Sorry for that. At least I plugged the cartridge in an turned on the computer, with no crash. Some faulty cartridges can cause crashes, so at least it wasn't obviously broken in that sense. Anyway, I'll get back once I've tried it out properly.
I found the MIDI interface. Now I just need to verify its functionality, and I'll hopefully be able to do that tomorrow.
Alright, that sounds reasonable. We can discuss the exact price later, when I've located+tested it. I looked around yesterday and it wasn't here in my home, which means it is in another place where I have some computer hardware stored. I will go to that place on Sunday, so after that I will know more.
I might actually have a MIDI cartridge that I could sell. I would just need to locate it first, and verify that it works. It is an old one of the standard kind (Datel, Passport, or Sequential compatible). They are all basically the same, using the same chip, only using slightly different memory addresses. Most software support all of them. What would you pay for it?
I wouldn't recommend the HerMIDI interface unless that is what you want specifically. It uses the serial port.
New version of defMON available:
Ah, yes. I also noticed that quite a while ago. Kinda strange, since I really thought I had fixed that at some point. Not sure what happened. I should have a look at that in the not too distant future. Thanks for reporting!
True that. Yes it works the way you describe. I think what i'd do would be to only use the slide functionality in that case, and leave out finetune. Like this:
One step of slide up with 00 delay. Then another step that waits a bunch of frames with slide set to zero. Those two steps would replace the finetune step in your example. Then a step that runs a bunch of frames with that 8C slide. I know it not identical in behavior to what you had in mind. Just saying how I would do it if I wanted to try to emulate the behavior you asked for.
Yep, it all makes sense. I want a way to export 2sid tunes too, so hopefully I will find the time to have a look at that some day.
Also, I appreciate all kinds of bug reporting, and it doesn't matter if it is a big or small bug/quirk. It is definitely good to know no matter what. Your bug reports have been very useful and I thank you for that.
If you want to simulate the sound of NES/Gameboy, then restrict yourself to only using certain waveforms on certain channels. Something like this:
Also, if you're using a C64. Don't use the filter of the SID, if you want to make it sound more like NES or so.
Not sure if this helps. Perhaps it wasn't this particular aspect of sound creation that you were interested in, but rather the more specific musical approach, regarding the harmonies and such things.
Hi! This is a very reasonable request, and I would like to have it myself. Anyway, there are some complications involved. The defMON player wasn't initially designed to support more than one sid, but was rather designed to allow for making tunes that could be used in demos/games with relatively reasonable CPU usage.
defMON scores reasonably alright in that respect when compared to other editors, and especially so if one uses the sid table cleverly (and do things like refraining from using two different pointers in a single channel to the sid table at the same time — if low CPU usage is really an issue). This table shows a comparison of a lot of C64 music editors, including the "raster time usage" which is a measure of the CPU load/usage:
http://chordian.net/c64editors.htm
When I implemented 2 sid support in defMON, I wanted to keep that (the reasonably low CPU usage), so rather than rewriting the player in a way that would allow for two SIDs (and losing some of the CPU usage) my solution was a weird kind of hack that introduced a new separate copy of the whole player in RAM, where each of the two players are hardcoded to work with a certain SID chip. This in turn creates some complications when it comes to the packer.
One option would be to rewrite the player itself, to have a single player that supported more than one sid, but that would be quite a lot of work (and I don't have a lot of spare time unfortunately) and it would also be likely to introduce some minor differences in sound compared to the way things would sound when played in the editor.
Another (more likely) option would be to provide some kind of new packer (perhaps executed on mac/pc) that could do this, but that would probably require re-assembling some stuff each time one wanted to "pack" a tune, so it could be that it would be hard to provide a convenient package for this, that would be understandably by anyone but myself. This solution too would require some of my time of course.
Did you have creation of compo tunes in mind, or tunes that could be used in demos/games? You asked for the executable form, which indicates that you had compo tunes in mind.
By the way: Regarding that first bug mentioned there, it must be related to the packer and the way it tries to figure out what rows that are used or unused, in order to remove the unused stuff. I'm not sure it can handle (apparently!) multiple jumps under all possible conditions, as that can get somewhat complex in some cases.
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.
Wow! Now that's clearly a fantastic testing report. 
Thanks a lot man. This is definitely much appreciated. I'll put this version up for download as an official release then.
ChipMusic.org / Forums / Posts by frantic