New Documentation: An authoritative reference on the YM2612

[SeregaZ]

commercial? )) this software will be used by 5-10 mans... what commercial you talking? it is just for romhackers comunity.

[MetalliC]

its going off topic but...
you are wrong, here is a lot of old games was released recent times, mostly from DotEmu company. all of them emulated, for example Raiden Legacy in Steam and GoG is MAME-based.
so I'm not surprised some people like Jarek doesn't want to see their's code and research research results used by someone else for making money.

[Eke]

so I'm not surprised some people like Jarek doesn't want to see their's code and research research results used by someone else for making money.

I am not sure if he is aware that his code is being used commercially in Genesis Plus GX ripoffs that have a lot of exposure and likely make huge profits out of it:

- MD.emu on Google Play (https://github.com/Rakashazi/emu-ex-plu ... /ym2612.cc)
- Hyperkin's Retron 5 (http://retron5.in/node/9)
- Cybergadget's Retrofreak (http://www.cybergadget.co.jp/support/re ... tware.html)

That's the only part they use (with ym2413 implementation) that is still not licensed under GPL, yet they don't have any issue with that. Sadly we could not claim anything since we are not copyright holders for this code.

[r57shell]

Sadly we could not claim anything since we are not copyright holders for this code.

Really? I thought all contributers considered as holders, except if in license noted something different. For example you can't even change license, until you have approve from all contributers, that's why some people using BSD and other no-restrictive at all licenses to avoid any troubles, if for example too many contributers already, and you can't change politics and direction of project... Again, I'm not sure, but that what I thought.

[Sauraen]

I apologize for my absence from this thread for the last couple months, I've been very busy towards the end of this semester with several things (including making a complete 8-bit microprocessor at the transistor level for a VLSI class--46 instructions, 50 MHz!)

I've finally finished my VHDL equivalent description of the YM2203 / YM2612 operator unit. The code is available at https://github.com/sauraen/YM2612 .

As I explain in the file header as well, this is an untested implementation. Obviously I tried to get everything right, but it is very likely there will be a couple bit errors in the logsin and exponential tables, and also it's possible a signal should be inverted from how I have it. But I am confident that this matches the chip architecture at a high level--that is, the pipelining and register positions. This should also clear up questions about bit widths, when carry-outs are used and when discarded, etc. Also the exact use of Test Register $21 bit 4 is included.

I'm taking requests for what to reverse engineer next. (Please don't say the EG!) I would go with the LFO, but honestly I haven't found it yet. I will tell you this, it is absolutely not a sine wave LFO, it must be a triangle wave--there's no other logic interfacing to the operator unit's sine table for the LFO, and there's no other table that would be large enough to hold any decent approximation of a sine wave.

Also, in the OPL2/OPL3 which have an "exponential" waveform available, it is thought to be a "readout of the exponential table"--I doubt this, it probably just skips the logsin table completely.

[Count SymphoniC]

I've been puzzled over the math involved in determining the number of cycles to wait in between register writes. The number is 24 internal cycles * 6 = 144 68000 cycles? If a 68k nop is 4 cycles, does that mean it would take 36 68k nop's in between writes? I swear that doesn't sound right, that seems like a lot....
Where am I wrong?

[Sik]

In assuming the YM2612 is fast, it's actually way too slow, even for the Z80 it is (in Echo I have to get around this by intentionally using a slow instruction to burn cycles, without that I need to resort to adding explicit delays every time which would make code more convulted). So yes, your math is correct.

[Count SymphoniC]

Wouldn't that mean you'd need about 18 z80 nop instructions then? Why does this sound like too many...

[Sik]

You need to wait 33.6 Z80 cycles after you write to $4001/3 (the second write). You'd need about 9 NOPs for that (or be clever and waste just enough cycles as you do any other operations ;P). Note that you don't need any delay after $4000/2 (the first write), if you did then yes it would be indeed 18 NOPs as you said.

This loop in Echo barely meets the limit by 3 cycles. There isn't much you can optimize without breaking it.

EDIT: and let me stress it, yes the YM2612 is really that slow.

[Count SymphoniC]

Thank you for the clarity, I never was very sure about the best way to do this. I meant to test the wait times on hardware but wasn't sure of a good reliable method for doing so. I'm still open to doing so and posting results if someone has any accessible ideas.

[Stef]

The main problem for me is that ym2612 (MD1) and ym3438 (MD2) does not have same busy cycles and if you test your cycles on a MD1, you might be greatly disappointed when you will test then on a MD2 as the ym3438 seems to require more time after some register writes. In my case I preferred to test the busy flag when I require to do many ym writes in a short period of time.

[Sik]

Well, Echo works with both so I assume that part of the timing stands. I guess the YM3438 is just less lenient about not respecting it =P

The biggest problem with checking the busy flag is that when it comes to the Z80, a busy wait loop may very well take longer than it takes for the busy flag to clear in the first place (whoops!), at which point you may as well just insert a delay instead. A wait loop may make more sense with the 68000 which is much faster.

EDIT: by the way if you're using the Z80, using the IX and IY registers is a good way to burn extra cycles and reduce the amount of clobber needed to meet the timing requirements (also you can just keep $4000 always there, which frees up other registers for more important purposes).

[Sauraen]

FWIW here's the timing in MIDIbox Quad Genesis:

http://svnmios.midibox.org/filedetails. ... gmplayer.h
http://svnmios.midibox.org/filedetails. ... gmplayer.c

This driver was developed on the first MIDIbox Quad Genesis synth I finished the hardware of, which contains four YM2612s (and four SN76489s). However, that synth is now in the possession of my client, and I've finished the hardware of a second copy for myself, which instead contains four hardware YM3438s. The driver worked immediately with no changes, so I left it alone. But because I don't have the YM2612 version, any experimentation with reducing the wait times can only directly be confirmed on the YM3438.

Right now I'm using a wait time of 2100 ticks at 84 MHz/tick (a total of 25us or 200 external OPN2 cycles at 8 MHz [which the chip is clocked at, not at 7.67MHz] or 33.3 internal cycles). This works on both YM2612 and YM3438 with no audible dropped commands, and the performance is high enough that I can play four VGM files at the same time, one on each OPN2/PSG. So I haven't tried to push it, but I can do so and let everyone know the results.

[Count SymphoniC]

Whoa talk about a show of technical prowess. Very nice. Actually, lately I've been having a wild itch for building a YM synth, I've seen posts here and there with schematics, but are these completed? I have the software programming knowledge but my electronic engineering skills are at a very basic level. I'd really like to chip away on a side project like this while developing my Sega Genesis tracker.

Quad Genesis... Wow.

[Sauraen]

@CountSymphoniC Thanks!

Not to derail the thread or shamelessly self-promote, but here's the current state of the MIDIbox Quad Genesis project. The MBHP_Genesis boards which I designed, each of which holds one YM2612/YM3438 and one SN76489 and provides appropriate glue logic for a parallel interface to your MCU of choice, are finished, fully documented (at the above link), and available for $5 each on the MIDIbox Shop. (Disclaimer: I profit from the sale of these boards.) To interface to the STM32F4 microcontroller from the MIDIbox hardware platform, a simple level shifter board is also required, which you can build by hand. The remaining hardware you need is all from the MIDIbox platform, and all the required PCBs are available on the MIDIbox Shop.

Three software applications for the MBHP_CORE_STM32F4 are in progress. (All three support up to four MBHP_Genesis modules, i.e. four of each sound chip.) The first project is MIDIbox VGM Player, which just allows you to play VGM files from a SD card on the MBHP_Genesis boards. This application is completed (though I will update it as I continue to develop the VGM driver), and information is available at the link above that should be sufficient for you to build one. The second application is MIDIbox Genesis Tracker, which is currently in progress and should be released soon. This application controls the pairs of sound chips exclusively via MIDI commands, according to the GENMDM spec. Finally the third application is the entire application layer for MIDIbox Quad Genesis, the full-featured synth with the large front panel whose hardware is shown in the videos above. The software for this will probably not be anywhere near completed before the end of the summer, although when it is, I intend to sell a few sets of custom parts for constructing the front panel (finished aluminum, front panel PCB, and 3D printed button caps--it won't be cheap though, expect around $400-$500, plus you'll have to buy the hundreds of LEDs yourself, not to mention solder them all!)

I'd love to have some people build some VGM Players or Trackers and give feedback to help improve the design and documentation. If you have issues building the hardware or using the software, I offer technical support on the MIDIbox Forums.