He even has an OPL2 to MA3 conversion demo : https://youtu.be/-R5K8wFJCRA
So I think he has figured out a lot already 😀
I already found these videos, but it seems that this guy is unwilling to share their knowledge (feel free to correct me if I'm wrong).
What's more, our goal is to completely figure out how this chip works, and write open source software to interface with it, not just relying on the leaked proprietary Yamaha code.
This should be easier now as I figured out how to control the FM engine.
Opl2Emu branch (https://github.com/noway2pay/MA3_YMU762_AND_DISCOVERY_F407VG) has most of the Yamaha middleware removed - it is only the low level "machine handler" (machdep etc) code that remains. All the SMAF/SMF converters with all these channel allocators are gone - they were not needed for "OPL playback".
Anyway - MA chips seem to be made for "MIDI-like" purposes and not being able to control the individual registers is painful. See this: https://gist.github.com/noway2pay/9b6a3dd866f … ed94c4d16340ada
JO-Fly-in-spiders-web.txt is what my OPL2/DRO converter spits for debug - check the "**** Instrument table **** at the end, I had to go through the whole DRO file to extract the instruments (well, in the end I do it on the fly, my first attempts were really lame 😉 ).
The other file, JO-Fly_in_spiders-web-LOG.txt, is debug from the actual player - look for "MaDevDrv_SendDirectRamData: adrs=4000 type=0 ptr=0x8009925 size=16", this is when I start sending instrument definitions to the internal RAM.
Ymu765-s have just arrived. If only there was some "leaked middleware" somewhere 😉
Now the question is if it is going to work with the Ymu762 code. I still have Ymu759 board that was my target initially, I will replace the chip and see what is the result.
MA5 has the same FM capabilities as MA3, but it also has e.g. the "Analog lite" (i.e. the filter engine).
Ymu765-s have just arrived. If only there was some "leaked middleware" somewhere 😉
Now the question is if it is going to work with the Ymu762 code. I still have Ymu759 board that was my target initially, I will replace the chip and see what is the result.
MA5 has the same FM capabilities as MA3, but it also has e.g. the "Analog lite" (i.e. the filter engine).
Sorry in advance for the necro.
That same "leaked middleware", assuming you mean the same source, has the 765 variant of the library (there are two leaks I'm aware of). If you or anyone else doesn't have it and wants it, PM me. Unfortunately I'm not aware of any leaked middleware for MA-7 or the like, but based on the similarity of MA-3 and MA-5, I'm guessing you could jank it into working without too much effort. Also noting that MA-5 seems to have double the RAM of MA-3 (16kB instead of 8kB). I mention it because it doesn't really seem to be a documented fact anywhere. I'm guessing MA-7 has even more.
I'm actually working on a general GM FM synth based on YMU762 already. I intend to adapt my current prototype into being a waveblaster module. Not sure how to go about releasing anything with it, though, since the clandestine nature of the library used means that it's probably not legal to release either source or final product, despite there not being any license text expressly forbidding it in the middleware source code. While I'm guessing Yamaha probably doesn't care, I might have to find someone to clean room reverse engineer it for that to happen. Haven't found anyone that cares as much as I do to actually help me with that. Oh well.
Note that the on-chip ROM only contains definitions for a 2-op bank. To get the most richness out of the chip as possible, you'd want to use a 4-op bank. There's sort of one baked into the middleware, but it's not very good, and it lacks coverage for drums iirc. The banks provided in the SMAF decorator are more or less the correct raw format for loading on MA-3 and MA-5. Caveat emptor: Thanks to the PCM samples they include, the YMU762 can't load all of it at once. You'd want to cache and bank load on demand, which is what I do. Double the RAM means this is less of a problem for YMU765 -- it can load any of those decorator banks without a memory management scheme.
Fun fact: There's a PCM sample for one of the standard GM drum bank instruments in ROM that they forgot to map in the ROM bank. Lol.
At any rate, I hink the current prototype works quite well and consumes MIDI messages over DIN-5, so I've had lots of fun "testing" it with my 486 and old DOS games. Attaching some recordings using YMU762 in case anyone is curious what it sounds like.
EDIT: As a point of comparison, attaching a recording of the same prototype playing ninja2-3.mid featured in https://www.youtube.com/watch?v=wFPPzIiRzqY, but using the standard 4-op bank from Yamaha. Cut a little short to fit upload limit.
EDIT 2: Figured I might as well slap in my sloppy notes on the VM3 bank format. I deduced this from looking at data output by the MA-5 Authoring Tool, without decompiling anything, so this is clean information. Should be useful for using the official decorator banks or using the authoring tool to put together your own banks. Would be fun to write something that converts various OPL2/OPL3 GM banks to this format, but I haven't gotten around to it. VM5 (for MA-5) is probably almost the same but with the analog lite filter stuff tacked in somewhere.
VM3 bank format notes
1 // vm3 format 2 3 // voice definition header 4 "FMM3" // magic number 5 00 00 1B 71 // 4 byte UINT32 voice definitions length 6 7 // voice definition 8 00 00 // 2 byte UINT16 sequential id 9 34 // 1 byte UINT8 voice definition length (remainder of this block); generally 0x34 for FM and 0x25 for PCM 10 7C // bank MSB 11 01 // bank LSB 12 00 // program change 13 00 // drum key 14 00 // flag (0=FM, 1=WT) 15 <string> // 16 byte cstring voice description 16 <raw 31> // (if FM) 31 bytes FM voice parameters 17 <raw 16> // (if WT) 16 bytes WT voice parameters 18 19 // wave definition header 20 "WVM3" // magic number 21 00 00 1D 2C // 4 byte UINT32 wave definition length 22 23 // wave definition 24 00 // wave id 25 02 56 // 2 byte UINT16 wave definition length (remainder of this block) 26 00 // format (0=4-bit ADPCM, 2=8-bit PCM offset, 3=8-bit PCM 2's complement) 27 <string> // 16 byte cstring voice description 28 [...] // raw wave data, 4-bit ADPCM is packed LSB then MSB 29 30 // custom waveform header 31 "FWM3" // magic number 32 00 00 1B 71 // 4 byte UINT32 custom waveform definitions length 33 34 // custom waveform definition 35 0F // 1 byte UINT8 waveform number (can be 0x0F, 0x17, or 0x1F) 36 08 00 // 2 byte UINT16 waveform definition length (remainder of this block) 37 [...] // raw wave data, 4-bit ADPCM is packed LSB then MSB (always ADPCM?)
Ymu765-s have just arrived. If only there was some "leaked middleware" somewhere 😉
Now the question is if it is going to work with the Ymu762 code. I still have Ymu759 board that was my target initially, I will replace the chip and see what is the result.
MA5 has the same FM capabilities as MA3, but it also has e.g. the "Analog lite" (i.e. the filter engine).
Sorry in advance for the necro.
That same "leaked middleware", assuming you mean the same source, has the 765 variant of the library (there are two leaks I'm aware of). If you or anyone else doesn't have it and wants it, PM me. Unfortunately I'm not aware of any leaked middleware for MA-7 or the like, but based on the similarity of MA-3 and MA-5, I'm guessing you could jank it into working without too much effort. Also noting that MA-5 seems to have double the RAM of MA-3 (16kB instead of 8kB). I mention it because it doesn't really seem to be a documented fact anywhere. I'm guessing MA-7 has even more.
[...]
Not that I intend to do anything with MA now, I guess most of the Poles (I am Polish) have other things on their minds currently...
I guess I should publish my DRO to OPL converter, it also outputs the VM3 format voice bank (just for reference; I was using MA authoring tools to check how I converted the OPL voices to MA). And maybe put up some documents about my findings. But really, I am too demotivated, especially after I have recently contacted the guy that first ported this MA middleware.
I am to fresh here to have the PM possibility, so could you please contact me at konrad@noway2pay.com ? Maybe I will get back to this in the future.
While I'm guessing Yamaha probably doesn't care, I might have to find someone to clean room reverse engineer it for that to happen. Haven't found anyone that cares as much as I do to actually help me with that. Oh well.
My "OPL player" is actually a stripped down MA3 middleware, with just "machdep" - or the lowest level - functionality left from the original package. But OK, I created a DRO (OPL2 only at the moment ) to MA3 converter so I am just issuing "voice on", "voice off", "pitch change" commands based on what I got as a conversion result. This is not a realtime converter though - now, as Dan Fry did his cool stuff with Ymf825 (I have two SwitchScience boards as well but never find time to play with them) I may possibly to something similar with MA3/MA5 - in the future.
I had three MA boards/adapters - I sent one to some guy that I made few oldschool projects with in the past, another one is the one that I do YouTube/Soundcloud recordings with and the last one is based on Ymu759 - and it does not work
(apparently MA2 cannot be initialised with the code from MA3 middleware and I have no time to figure out how to do this - I tried reverse engineering MA2 based phone firmware, but I guess at that time Yamaha may not even have a proper MA2 middleware, even though MA3 code suggests it was based on MA2 code). So now I could possibly replace Ymu759 with the "765".
Back to the subject... MA3 "DRO" player can easily be rewritten to get rid of the Yamaha's code, there is not much of it left in fact. Buf for MIDI - I give up. MIDI implementation with MA was not a thing I was excited about until I saw Dan Fry's "YMF825 Custom MIDI Implementation" on YouTube. If he ever publishes his work I may look into adapting it to MA-3/MA-5.
plgDavidwrote on 2021-07-13, 00:36:I also did quite a lot of MA-2/3/5 reverse engineering two years ago and need to brush off on it and compare notes.
My goal was […] Show full quote
I also did quite a lot of MA-2/3/5 reverse engineering two years ago and need to brush off on it and compare notes.
My goal was also to make new use of those chips (on Famicom carts). So I made a board for it that transforms its pinout to OPN2 pinout..
Just because its easier to integrate in existing setups.
I have a bunch of register dumps of various Samsung phones (booting up+chime, playing some MMF files etc).
It will be a while before I sort all that and publish.
David, this may no longer be needed, at least not for MA-3 and MA-5. MA-2 is still a little bit of mystery, but IMHO - with abundance of MA-3/5 chips, MA-2 is pointless.
Expect the OPL player on MA5 (well, sooner or later).
I would be in favor of a Discord server. That could be very useful, if only as a way to coordinate findings and be more rapid and casual than the "forum post" format. There's a lot of information that needs finding and a lot of potential social contact that needs to be made, say with Delek, kb77, the MMFPlay authors whoever they are, etc.
I've created a server and you can discuss all these in the `chipyard` channel
