YM2612 write/read/register select
Moderator: BigEvilCorporation
I think that is a good idea I have been working on that. My program allows you to send an instrument to all the channels and send registers writes I will add more features sooner or later but if anybody needs it now just reply.KanedaFr wrote:The funny thing is I bought a Teensy 2 years ago for (among other things) play with the ym2612
My goal was to made a USB toy with Serial and Audio mixed so any emu/player/whatever can send ym2612 command throught serial and user could listen like if playing a CD or throught a jack
eeeew windows
I'm making mine a MIDI receiver at the moment. It's kind of tough to support midi correctly since ym2612 channels aren't polyphonic, so you have to use multiple channels to express chords. Midi also can't handle sending instrument specifications so I'm going to try to make a hardware interface (buttons and knobs, maybe an LCD) for selecting/editing voices and a 4k EEPROM for storing them.
I'm making mine a MIDI receiver at the moment. It's kind of tough to support midi correctly since ym2612 channels aren't polyphonic, so you have to use multiple channels to express chords. Midi also can't handle sending instrument specifications so I'm going to try to make a hardware interface (buttons and knobs, maybe an LCD) for selecting/editing voices and a 4k EEPROM for storing them.
woot
http://www.youtube.com/watch?v=uLTO9vh7B5o
Also have an mp3 I recorded from it. It's using 3 channels right now, all of the same (default, Grand Piano from sega2.doc) voice. http://7355608.net/sketchbook/ym2612/test.mp3
http://www.youtube.com/watch?v=uLTO9vh7B5o
Also have an mp3 I recorded from it. It's using 3 channels right now, all of the same (default, Grand Piano from sega2.doc) voice. http://7355608.net/sketchbook/ym2612/test.mp3
Fooboat, I have just done the same think albeit with an arduino. Here is a video: http://www.youtube.com/watch?v=_OiOyxsI5n8
Still a work in progress...
Still a work in progress...
Cool, lookin' nifty.
FYI: there's a pretty big FM synthesis community that uses the Yamaha OPM chipsets in their synthesizers. The register banks on these chips are (mostly) directly compatible with the YM2612, and they sound extremely similar to the 2612. There's a plugin for one of the more popular music making programs, Virtual Studio Technology, called VOPM (virtual OPM) that emulates these OPM chips. The file format used by VOPM, .opm, is very easy to work with.
I added an i2c eeprom to my circuit, which is basically the same as yours, and I store packed .opm files in it as my instruments. The Atmel has 4Kb of eeprom in it too, I think, accessable via the eeprom library, if you don't want to use a discrete chip.
If you want to check it out, I have a short utility I wrote in Python that will take an OPM file and convert it into a packed list of bytes preceeded by a 16-byte title for the instrument. I use "cat" in linux to concatenate a bunch of these files together, then send them to the Atmel via a dumping program (that will currently only work in Linux).
I haven't figured out a good way to name the instruments yet so right now I just fill the name bytes with alphabet characters.
OPM packer: http://7355608.net/sketchbook/ym2612/tools/opm2pak.py
OPM segment to bit # map: http://7355608.net/sketchbook/ym2612/tools/bitlist.txt
Serial dumper: http://7355608.net/sketchbook/ym2612/tools/tserial.py
Feel free to post in this thread or ping me via a message if you want to work together or ask me anything. I just got 6-key-simultaneous polyphony working. Next I'm working on adding an LCD screen and LED matrix to my circuit to use as a display and level/trim indicators. My end goal is to design a PCB for this and stick it in a project box with rotary encoder knobs and the screen and such-as to use as a MIDI instrument. I'll probably put 2 YM2612s in it and a SN76489.
I have 10 ym2612s and 5 sn76489s in the mail
FYI: there's a pretty big FM synthesis community that uses the Yamaha OPM chipsets in their synthesizers. The register banks on these chips are (mostly) directly compatible with the YM2612, and they sound extremely similar to the 2612. There's a plugin for one of the more popular music making programs, Virtual Studio Technology, called VOPM (virtual OPM) that emulates these OPM chips. The file format used by VOPM, .opm, is very easy to work with.
I added an i2c eeprom to my circuit, which is basically the same as yours, and I store packed .opm files in it as my instruments. The Atmel has 4Kb of eeprom in it too, I think, accessable via the eeprom library, if you don't want to use a discrete chip.
If you want to check it out, I have a short utility I wrote in Python that will take an OPM file and convert it into a packed list of bytes preceeded by a 16-byte title for the instrument. I use "cat" in linux to concatenate a bunch of these files together, then send them to the Atmel via a dumping program (that will currently only work in Linux).
I haven't figured out a good way to name the instruments yet so right now I just fill the name bytes with alphabet characters.
OPM packer: http://7355608.net/sketchbook/ym2612/tools/opm2pak.py
OPM segment to bit # map: http://7355608.net/sketchbook/ym2612/tools/bitlist.txt
Serial dumper: http://7355608.net/sketchbook/ym2612/tools/tserial.py
Feel free to post in this thread or ping me via a message if you want to work together or ask me anything. I just got 6-key-simultaneous polyphony working. Next I'm working on adding an LCD screen and LED matrix to my circuit to use as a display and level/trim indicators. My end goal is to design a PCB for this and stick it in a project box with rotary encoder knobs and the screen and such-as to use as a MIDI instrument. I'll probably put 2 YM2612s in it and a SN76489.
I have 10 ym2612s and 5 sn76489s in the mail
Hi !
Congrats on your project. There's a lot of very interesting things to learn in these situations !
If I may suggest something about your Arduino code, you should always try to avoid digitalWrite at all times because it is a very slooooow instruction. Especially when you'd theoretically need several pins to switch state together at the same precise moment. Even if you're using Arduino, you can use the syntax PORTX = [byte] which is the fastest way. I suppose you wired the YM data bus to a full port on the Atmel, right ?
Keep on !
BTW : My hardware player with both YM and SN chips working (I'm very late on this one) : http://www.youtube.com/watch?v=8f1lFdWioaM
And a very first attempt to use the SN76489 over MIDI : http://www.youtube.com/watch?v=Xz3ZNvXIEVQ
Cheers !
Congrats on your project. There's a lot of very interesting things to learn in these situations !
If I may suggest something about your Arduino code, you should always try to avoid digitalWrite at all times because it is a very slooooow instruction. Especially when you'd theoretically need several pins to switch state together at the same precise moment. Even if you're using Arduino, you can use the syntax PORTX = [byte] which is the fastest way. I suppose you wired the YM data bus to a full port on the Atmel, right ?
Keep on !
BTW : My hardware player with both YM and SN chips working (I'm very late on this one) : http://www.youtube.com/watch?v=8f1lFdWioaM
And a very first attempt to use the SN76489 over MIDI : http://www.youtube.com/watch?v=Xz3ZNvXIEVQ
Cheers !
makin' progress
http://www.youtube.com/watch?v=hp5VuO0urzc
http://www.youtube.com/watch?v=hp5VuO0urzc
Hey SigMate,
It looks like you're sending data over the serial port. How did you do that fast enough to send pcm data? I just got PCM streaming to work, but I'm doing it like this:
I first send a byte that specifies what the next bytes will be. 0x01 for write to bank 1, 0x02 for write to bank 3, 0x03 for pcm data write.
The following 2 bytes for bank writes are {address, data} and simply {data} for a PCM write.
There are so many PCM commands for "write a byte to 0x2a then sleep 0-15 samples" in VGM files that doing this seems to be actually too slow. With only a 64 byte serial buffer I'm overrunning it all the time and playback gets really slow and jerky - but only when there's PCM data flowing.
What do you do?
edit: Actually I think I might understand your "PORTX =" comment now. If it's taking a long time to set the pins, that could be a problem.
It looks like you're sending data over the serial port. How did you do that fast enough to send pcm data? I just got PCM streaming to work, but I'm doing it like this:
I first send a byte that specifies what the next bytes will be. 0x01 for write to bank 1, 0x02 for write to bank 3, 0x03 for pcm data write.
The following 2 bytes for bank writes are {address, data} and simply {data} for a PCM write.
There are so many PCM commands for "write a byte to 0x2a then sleep 0-15 samples" in VGM files that doing this seems to be actually too slow. With only a 64 byte serial buffer I'm overrunning it all the time and playback gets really slow and jerky - but only when there's PCM data flowing.
What do you do?
edit: Actually I think I might understand your "PORTX =" comment now. If it's taking a long time to set the pins, that could be a problem.
If you use port manipulation, you can't manipulate a single bit without first setting the bits that you don't want to change. I think that is all the arduino libs are doing under the hood anyway?
I'm just speculating.
Anyway, digitalWrite is fast enough for my purposes. If it becomes a problem, it is easy to refactor.
I'm just speculating.
Anyway, digitalWrite is fast enough for my purposes. If it becomes a problem, it is easy to refactor.
Hi !
I don't know if digitalWrite is a hundred times slower than port manipulation but I clearly remember looking into Arduino source code to figure it out and I was just shocked Although I perfectly understand the philosophy of Arduino and I'm not blaming. It's just that it's... slow Of course you cannot manipulate a single pin with this technic (port manipulation) but it's quite easy to read a whole port then apply some bitwise operator and you'll still save a lot of cycles.
@foobat: I'm not using the serial protocol but the RAW HID protocol, which allows to send up to 1000 packets of 64 bytes per second. And also, I use a circular buffer of 64kB. Your logic seems alright tough. It's probably a matter a timing issues which can exist at multiple levels (microntroller internals first, then microntroller to external components, then computer to microntroller if needed). Also note that my VGM player is written in C for avr-gcc, not Arduino, because I needed to use hardware timers interrputs (and RAW HID as well).
Good luck !
I don't know if digitalWrite is a hundred times slower than port manipulation but I clearly remember looking into Arduino source code to figure it out and I was just shocked Although I perfectly understand the philosophy of Arduino and I'm not blaming. It's just that it's... slow Of course you cannot manipulate a single pin with this technic (port manipulation) but it's quite easy to read a whole port then apply some bitwise operator and you'll still save a lot of cycles.
@foobat: I'm not using the serial protocol but the RAW HID protocol, which allows to send up to 1000 packets of 64 bytes per second. And also, I use a circular buffer of 64kB. Your logic seems alright tough. It's probably a matter a timing issues which can exist at multiple levels (microntroller internals first, then microntroller to external components, then computer to microntroller if needed). Also note that my VGM player is written in C for avr-gcc, not Arduino, because I needed to use hardware timers interrputs (and RAW HID as well).
Good luck !
Using raw HID mode instead of serial and clumping PCM data into two bytes instead of three (first byte high nibble = command identifier, low nibble = wait time, second byte = pcm data) was enough to make the difference between "completely unplayable" and "sample-accurate"
Now I just have to find a better way of recording my device's output, since it sounds a lot better than the microphone input on my laptop can record
Thanks for the tips sigMate!
Now I just have to find a better way of recording my device's output, since it sounds a lot better than the microphone input on my laptop can record
Thanks for the tips sigMate!