Jump to content

NoobDog

Members
  • Posts

    4
  • Joined

  • Last visited

    Never

About NoobDog

  • Birthday 01/01/1

Profile Information

  • Gender
    Not Telling

NoobDog's Achievements

MIDIbox Newbie

MIDIbox Newbie (1/4)

0

Reputation

  1. thorsten, your support is very much appreciated! i guess i should learn som ASM ;). when i get on with any of the suggested solutions and when this project reaches a descent stage of development, i will keep the community informed. thanx again! nd
  2. ups, sorry, i must have had an old documentation. i can find the declaration in the c header, but did not find it in the docs. you can remove the entire thread if you like and if you can, nothing interesting to other forum readers. when i searched the forums i must have found old posts where a wait was not jet implemented.. i'm sure i saw a post by tk where he was pointing out this solution with the ack-msgs thanx
  3. Hi, as the name indicates i'm a noob, not to c-programming but to electronics. Whatever, i managed to build sucessfully a midibox fm. As fm enthusiast in general, it was fun doing it but i want to go on. On of my wet dreams is a midibox DX7 programmer in the style of the Jellinghaus programmer, a very rare hardware object. I made my first steps using the mbfm knobs and buttons as interface and was quite successful, i already was able to program a patch randomizer for the beloved DX. And here is where the trouble start. This thing is a dinosaur and very very slow, particularly the midi buffer is very easily overloaded. So basically i need a wait() function when sending out sysex data (e.g. a whole program) to the dx. There is no such function in the current API, and when i search the forums, i found some posts indicating that the only remedy is to send between each useful sysex call a few acknowledge messages, so any descent synth should just dump them or not even recognize them, and this would then generate the required space in between the calls. Sadly this is not the case at all with the DX. It constantly sends itself such acknowledge messages, and that's why i belive, it also receives such messages. A prove for my thesis is, that when i have MIOS-studio in between the "DXProgrammer" and the DX, this one filters out the acknowledge sysex's, and everything works fine, but a soon as i connect it directly to the synth (definitely a thing a want to do ;), it has the same buffer overflow problemz as before. Can anybody help me write a descent busy wait function in MIOS C Style? I know very well how to do this on a computer, but to PIC programming i'm also very a noob. I can post the code, but i don't think this is very interesting for the current topic. greetings ND
  4. Hi All! Olli Niemitalo just posted this to the music-dsp list. As i am currently a very proud ownder / builder of a midibox-fm (right now the minimum version, next month i'll start with the "UI"), i just thought some readers of this forum might be interested in his findings. i asked for permission to reproduce his post here, and he agreed. here we go! Post sent by Olli Niemitalo to music dsp mailinglist 18.4.08: ----- Me and Matthew Gambrell have an interest in emulation of YM3812, which is the OPL2 sound chip found in the Adlib and 8-bit Sound Blaster cards. A later derivative OPL3 is found in early 16-bit Sound Blasters. We sent one YM3812 and one YMF262 (OPL3) to MEFAS for decapsulation; the cost was around 90 USD each. They indicated that the chips would still be operational after decapsulation, but we had no need to test this. Looking at the revealed YM3812 die surface with a microscope turned out two ROM's. See: http://docs.google.com/Doc?id=dd8kqn9f_13cqjkf4gp The contents could be read bit-by-bit. The first ROM was a log-sin waveform table, containing one quarter of a sine wave, 256 samples long. The second ROM was an exponential table, 256 samples long. There were no other ROM's larger than 16 samples. This is strong evidence that YM3812 produces the sound without any multiplications, using for frequency modulated (actually phase modulated) synthesis the formula: out = exp(logsin(phase2 + exp(logsin(phase1) + gain1)) + gain2) There was first some difficulty understanding the ROM's because they were compressed. Every second sample was stored as a difference value to the previous. Once this was understood, we were able to derive formulas that met our expectations and re-created the contents of the ROM tables exactly (yes, they used the same rounding and everything at Yamaha, back then when they created these tables). Exponential table: x = 0..255, y = round((power(2, x/256)-1)*1024) When such a table is used for calculation of the exponential, the table is read at the position given by the 8 LSB's of the input. The value + 1024 (the hidden bit) is then the significand of the floating point output and the yet unused MSB's of the input are the exponential of the floating point output. Indeed, YM3812 sends the audio to the YM3014B DAC in floating point, so it is quite possible that summing of voices is done in floating point also. Log-sin table: x = 0..255, y = round(-log(sin((x+0.5)*pi/256/2))/log(2)*256) This is the first (rising) quarter of sine wave. The rest can be constructed by flipping all the bits of x and/or by changing the sign of the samples. I hope this will be useful for anyone writing a good emulator. Also, there are no extra ROM's on the YMF262 (OPL3), so the additional waveform is probably simply the exponential table. -olli
×
×
  • Create New...