81

(19 replies, posted in Trading Post)

I haven't used the Ultimate64 personally, so I don't know much about it. As far as I have understood, the general idea should be that it should be fully compatible with the C64, but maybe it is more like 99% compatible in actual practice. However, in this case I guess it could also be the case that the Ultimate64 emulates a cartridge at the same time as you have the midi cart inserted. If so, there may be a conflict between the emulated cartridge and the MIDI cartridge. The DATEL cartridge uses the following addresses:

MIDIcontrol = $de04 ;write-only
MIDIstatus  = $de06 ;read-only
MIDI_Tx   = $de05   ;write-only
MIDI_Rx   = $de07   ;read-only

If the emulated cartridge interferes with this in some way, the MIDI cart won't work. Then you would either need to disable the emulated cart, or your would need to use a cartridge ROM that doesn't interfere (I think the Retro Replay ROM may be worth a try for example).

(Cartridges such as Final Cartridge, Action Replay, Retro Replay, and so forth generally also use the $dexx adress range. I seem to remember that I used a cartridge port expander at some point, to get a MIDI cart working at the same time as an action replay/retro replay cartrdige, and the cartridge port expander allowed me to shift the MIDI interface to the $dfxx range instead. Then I also had to modify the software I used so that it used the $dfxx adresses to communicate with the MIDI interface, instead of $dexx.)

82

(19 replies, posted in Trading Post)

...aaaaaaand now I tried it with some other software that supports DATEL as well (King Fisher's "Midislave Manager") and the interface didn't work there either.

Conclusion: The interface doesn't work.

83

(19 replies, posted in Trading Post)

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

84

(19 replies, posted in Trading Post)

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.

85

(19 replies, posted in Trading Post)

Alright. I'll let you know when I've had the chance to pick up a diskdrive and try it out.

86

(19 replies, posted in Trading Post)

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.

87

(19 replies, posted in Trading Post)

I found the MIDI interface. Now I just need to verify its functionality, and I'll hopefully be able to do that tomorrow.

88

(19 replies, posted in Trading Post)

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.

89

(19 replies, posted in Trading Post)

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?

90

(19 replies, posted in Trading Post)

I wouldn't recommend the HerMIDI interface unless that is what you want specifically. It uses the serial port.

91

(443 replies, posted in Commodore Computers)

New version of defMON available:

http://toolsforscholars.com/defmon/doku … d:download

92

(443 replies, posted in Commodore Computers)

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!

93

(443 replies, posted in Commodore Computers)

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.

94

(443 replies, posted in Commodore Computers)

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.

96

(443 replies, posted in Commodore Computers)

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.