yogi

Sorry for the OT post. Feel free to remove it, or I will if you like. On another note, been modding my original prototype to be in line with your design. One point you may want to change, the READY output from the SN76489 is an OC so it will need a pull up. I would guess any value between 1K and 10K, depending on needed rise time and current draw. Yogi

Just an OT FYI, there is a fork of the Chip Maestro project that would fit in very well. Over At Shiftmore's Blog, http://shiftmore.blogspot.com/search/label/2A03 He has a version of the interface for the 2A03 based on 'HC595 SRs. He is running the synth on and Arduino but it would fit in well with a MB core instead. The CM design lacks DPCM so the reviews of the cart have been mixed, most hoping for a MidiNES work alike, (the design also uses a ATMega 168 which I feel is underpowered). Here is the Wayback page for Jarek's TSUNDERE project https://web.archive.org/web/20111001030647/http://www.soniktech.com/tsundere.php The design is clever in that the logic gates form a state machine that build op codes for the 2A03, a tight loop (~12 cycles total) to Read a value and Store at an address. The uC latches the Data and Adr (pointing to the PSG registers), and the 2A03 continues to execute this 'loop' till pwr down. The original logic design came from Kevtris http://forums.nesdev.com/viewtopic.php?f=9&t=6901&hilit=2A03+synth The real let down of the project is in the Atmega firmware features; which, with a MB core, could do alot more, IMO Yogi

WOW! Great work. I'm sorry I've been off the board for so long, a lot of family commits for the last 6 months.(First Grand son, moving another 'child' for college, youngest getting started. All good) I'm in for a few boards, for sure. (in fact was logging on to re-check the OPL board interface, to restart the Eagle layout, when I noticed your design). In fact if you need an OPN2/Sn76489 for testing I'll shot them off to you, just drop me a PM with info. I'll also dump the driver code I was working on, bad s it is, on my Dropbox if you would like. Yogi EDIT: here is the Dropbox link https://www.dropbox.com/sh/4cw32e2knefjjse/AABiUxZ-NDVPBpkd2__kcNNLa?dl=0

LOL

:smile: Looking forward to one! Yogi

Hope I didn't sound like a critic, was trying to say I trust that the code works even if I don't understand. My goal at the moment is to try to fully understand it and the impact of changes I make :) I think I'm getting there, it took awhile to follow the over all interaction between the queues, On Frame functions and SendAddrData. Yea, when I get into the synth engine, the differences between the OPL3 and the OPN2, and the addition of the SN76489, will cause major rewriting and function changes. For the most part, the opl3.c has been straight forward, adjusting array sizes for the OPN2's reg structure and changes to the minor differences in the access algorithms. I'm just the opposite, I've mess with C on and off over the years but never felt comfortable. I started out 'back in the day' on Atari 800, learning Basic and 6502 Assembly (JSR, RTS: jump to sub, return from sub). Then started in on uControllers, the MCS 8052 then the PICs. And lately got into some NES and Atari projects (back to the 6502). Tried some of the PIC Cs but Asm seemed more efficient and easier for me. But with the STM32s I'm with you, 'leave it to the compiler'! :) One of my objectives with this project, is to sharpen my C. Yea there is some tight code there :) The hard part for me was remembering that the native data width is 32bit. The bit wise sections weren't too hard, think I got it right. When I got to the later functions, things made more sense. Anyway, getting late. Talk to you later, Yogi

Hi OK. bit by bit I'm understanding your code but going through some functions I take it 'on faith' that the logic works even if I don't understand it clearly in the first read. With the 'Return', old ASM habits got the best of me, JSR with an RTS :) But Your answer jogged my memory; thanks. Only have a few more functions to port from opl3.c and edit the makefile to start testing the low level code. Yogi

Oh, I think you may want to look at this in s32 OPL3_AddChipQueue( ) Seems like the last statement should be: chip_queue_idx = (4*OPL3_COUNT)-1; Yogi EDIT: I also noticed that there is no return at the end of OPL3_SendDemoPatch(). Is this ment to fall through to OPL3_OnFrame()?

Hi Sauraen Yes. I already ported these. Glad to know we are thinking alike:) The OPN2ChannelMap[ ] seemed redundant, the index value and the returned value are the same. But I included it in the case that I would need to re map things later, based on porting other sections of code. Are you referring to the Ch3 Mode bits in 0x27? The Yamaha doc lists combos 10 and 11 as illegal, but in fact Mode =10 is the CSM+SSG EG mode we've discussed. Mode=11 is Channel 3 Special, same as Mode=01 according to the tests. There are a couple other undocumented registers/effects that have some impact, one affects the output Vol of the Channel 6 DAC and another allows some control of panning. I need more research on them but if they are of use I'll add support. Yogi

Cool stuff indeed! Yes I do believe SSG EG is a OP by OP basis, The SSG EG parameters are mapped to each OP for a total of 24. seems very redundant if it only applies to just Channel 3. I think the Timer/auto Key on/off effect I wrote about earlier only pertains to SSG-EG + CSM on Channel 3. How the SSG-EG on the other channels work (?) I think it is tied to the normal Key On/OFF, only active when a manual on/off is. I recall seeing a chart of the different waveforms that can be used, they appeared to be the same as on the AY 3-8910 ( believe the chart came from the YM2608 doc). So when a channel is active the SSG EG begins for all OPs that have it enabled. As to to the frequency for the repeating waveforms, not sure. May be based on the LFO setting? There is another fine point with the interaction of these modes,; when CSM + SSG EG is active, a manual Key on will override the auto key on/off till a manual key off occurs. Further, register 0x28 controls key on/off, bits 2:0 select the channel and bits 7:4 are the on/off for each OP of that channel. By convention the high nibble is set/reset as a group. Either b0000 or b1111, but it may be possible to key individual OPs for a channel, at least for channel 3 in Special Mode. Very clear, thank you. I was messy with my question/explanation but that is how I understood it. So with OPL_COUNT = 3, the variable array opl3_chip would be made of 3 opl3_chip_t data types, using a total of 9 bytes in memory. I could access the first opl3_chip_t with u32 A=opl3_chip[0].ALL or as a bits field with u8 B=opl3_chip[0].vibratodepth. In the latter, u8 B would only have the bit value of the vibratodepth bit, I.E. B=0x00 or 0x01 This is the part that was the major confusion to me. Thank you for the commented code, it cleared it up. So in this You can access the individual bit values left, right, out3 and out4 or all 4 bits at once with dest. I have a feeling I understand how you set them up. But I don't know the register structure of the OPL3 well enough. The nice thing with OPN2 is it is streamlined with regards to the register mapping. For instance there is no 2OP mode to deal with. For each OP parameter there are 12 address within a 16 byte block; organized as 4 groups (for the 4 OPs) of 4 addresses ( for 3 Channels, the 4th address is null).. So Parameter Byte Address= Base Address +(OP#*4)+Channel#. The Channel registers are even simpler, with each parameter mapped to a block of 4 addresses. So Channel Byte Address=Base Address+Channel# The Base Address can be computed or in a lookup table like such: //OP Reg ADR = OPN2OperRegBegin[x] + (OP_Num_offset*4) + CH_offset static const u8 OPN2OperRegBegin[7] = { 0x30, 0x40, 0x50, 0x60, 0x70, 0x80, 0x90 }; For example, to compute the address of the 4th Parameter Register of OP4 of Channel 1: Address = 0x60 + (0x03 * 4) + 0x00 = 0x6C So at this point I don't see much need to re-map the registers, not too the extent you had to with the OPL3. I've looked over the table you have in the comments and I must say that the OPL3's address layout is way more complex then the OPN2. Thanks again, Yogi

Just a quick search. These are from Aly James, SSG effects on Sega HW- SSG + CSM on YM VST- Considering the first Vid, the SSG-EG seems to be independent of CSM (Channel3 Special Mode). This would explain the Mapping of 0x90+, low nibble listed as "SSG-EG". From the main doc it's just listed as 'proprietary' and should be set to 0 according to Yamaha. OTOH, Experiments done by Nemesis @ SpritsMind on this register show D3 as enable and D2:0 as ENV waveform. At the time I thought this was only for the CSM +SSG-EG mode, but SSG EG may be usable for all OPs as indicated by mapping this register for the 24 OPs. I'll need to search some more but I now think an SSG-EG can be enabled for all OPs, by setting 0x90+ D3=1 with a waveform selected by D2:0. I'll try to nail this down some more, and ask AJ as he has explored this mode a bit. You bet! plan to have switchable selection for both Right and Left channels :smile: This is just a Cap value selection so users could vary the filter to their liking. OK. After digesting your notes above, it confirms what I thought I understood. but one question from the opl3_channel_t typedef{} So the Typdef union{ u8 ALL[3] Creates a new type called ALL made of 3 bytes and the following struct { } defines names for the bit fields within? The second union{ } with 2 structs{ } ? It is within of the typedef union{ }, so does it create a 1 byte element (the 3rd byte of the first union ) that can either hold the //Byte 2 bits OR the dest nibble? As to usage I think I understand: Here is created a Variable array called opl3_chip_t. So A= opl3_chip_t.opl3mode[1] would return with A holding the 1 bit OPL mode value at D 0 for the 2nd chip EDIT: Chip #1. And A= opl3_chip_t.csw[2] would return A with the csw bit for chip 3 EDIT: Chip#2 in D7 or would it be at D0? In other words, is the bit position preserved? EDIT: So I mixed up opl2_chip_t with opl3_chip[], the first being the data type and the last being the variable right? Thanks for your help, yogi

HI Sauraen So I've been doing allot of searching and study regarding our discussion. The SSG EG may not be a 'left over' as I thought, as it is an independent structure on chips that also had the SSG PSG, according to decapped scans. Don't know the intent of Yamaha, but I think that it was added to the FM channels to compliment the PSG's EG. When they dropped the PSG from the OPN2, seems they abandoned it, at least in their Docs. This mode is set thru 0x27, bits 7:6. It also requires Timer A to be running and the SSG EG bits for each Channel 3 OP to be setup. When enabled, at each Timer rollover an alternate Key on followed by a Key off are issued. With the attack set for 0 the OP moves directly to the D1R, first release, but the key off occurs and the output goes into the RR, release rate. So by selecting the value of Timer A and RR value you can design the sound. At least this is my understanding ATM :) There aren't any official docs so info is gleamed from experimental efforts and scattered in forums. The best source so far is this thread on SpritesMind http://gendev.spritesmind.net/forum/viewtopic.php?t=386 It's a monster at 47 pages, but there is allot of good info within. I'll work on a Eagle schema for it but for my proto I just worked off the MB OPL header pinout +OPN2/TI PSG basic design + Mega Amp design for a basic board (currently waiting on a parts order for some finial bits). So about half way through porting the OPL3 module and I'll have to write some test code to test and get some sound :) I've got a few C questions I've been running down in regards to the Typedef Union{} structures and their usage, but I think I understand. I won't pull your ear here, at least till after I do some more homework. Yogi

Maybe a default set in flash, with it loaded to ram at runtime, as well as SD support. Ok thought is was something similar. I've mapped the channel reg for the audio output bits in the typedef and I assume there is a function using the dest structure for each channel also, so I'll add it back in and adjust the bit value. Not confusing at all :) yes my only question was the naming rules. whether or not I could reuse labels. Which it only makes sense that you couldn't have different data types with the same name. DUH! Very good, I knew C is very liberal with white space, but i'd never seen a pointer array that way. No problem. Not sure of what the initials stand for, Sound ? Generator. From Wikipedia: So 'SSG' is not entirely correct, on the YM2612. It's the leftover envelope generator from the parent chip YM2608, I think. When Yamaha redesigned the chip they removed the internal AY 3 8910 (YM2149) but left the Env generator silicone on the die. The slim manual for the YM2612 only notes it as an 'illegal' mode (which some claim was due to a J to E translation error) but it does in fact work. Though it wasn't used in Sega music (perhaps because it was listed as Illegal) it is capable of producing format sounds and crude speech to a point. Thanks for your help, Yogi

Hey there, Thanks for the input. Been working on porting opl3.c and opl3.h so far. The typedef structs are changed for the OPN2 specifics and of course changed all the related structures that use the new data types. I've edited most the pin and chip level functions but I'll have to come up with some test apps to verify the changes I've made. Following the naming from here http://www.smspower.org/maxim/Documents/YM2612#reg2a I'm getting a feel for the flow of your code and am trying to maintain compatibility with the higher level FM synth functions. Some OPL function don't have any meaning on the OPN, such as waveform or 2 op channels. And as you pointed out the alt modes of channel 3 and 6 have no OPL meaning. So there is a bit of sorting involved but for the most part translates well. Yes indeed, If I do implement a /RD, will also have to control the /WR strobe separate from the /CS pins for the YM chips.This isn't a huge deal but requires two more ARM pins (depending on the fanout for the pins could also require a buffer for mutii-chip setup) as well as complications for reversing the data bus (which may be a HUGE deal). I plan on testing the timed write access first before I make thing more complicated. After all, the only advantage here is saving some cycles waiting for the YM to be ready. It's really not too different then accessing an LCD. For the PSG (I assume you meant that rather then SSG), it's write only; so just needs it's own /CS (or /WR) strobe. Not too sure about the READY but think it can be ignored for the most part. When I dive into the PSG code will review LittleScale's SN76489 code, he has several blog posts for multi-chip PSG projects. The alt channel modes, CH3 Special, SSG and DAC, will need to be handled separately from the main functions but I haven't gotten in to them just yet. Want to get the basic sound handling covered first off. Good question :) Haven't planned that out yet, but there would need to be a sample data set to draw from. It could be a const array in Flash but would like to load the samples from SD into ram. For drum samples wouldn't have to worry about loop points and samples on the YM or PSG chip are 8b (I think less on the PSG) so the sample set wouldn't be huge. Can you answer a question about one of the data types, u8 dest:4? I haven't tracked it's usage in code yet, is this nibble used for voice allocation? Another DA question, that's more of a general C coding question, can I reuse label names in the typedefs, I.E. for padding u8 structures, using u8 dummy2:2; for 2 bits or u8 dummy1:1; for 1 bit at more then one location in the def? And here is a snippet that may be a typo In opl3.c. Is the space between 'OPL3CSPins' and '[OPL3_COUNT]' valid? Thanks again Yogi

Hi Sauraen, been going through and learning FM2.1 code, mainly the OPL3 module. Looks like much of it will work very well :) and retain the multi chip support. So I'll plan for support of at least 4 synth boards, 24 FM Chns, 12 Sq Wave Chans and 4 Noise Chans :p Multi-Midi cables, both USB and serial, will accommodate the 4 count nicely, allowing CC controls for all the parameters. I didn't change too much with the OPL header on the synth proto board, just brought out the YM's /RD and /CS to separate pins and a /CS (functions as a /WR strobe) for the PSG. The /RD may not be needed if I allow for the worst case timing on the setup waits (~80 cycles); about the only thing you can read from the chip IS it's status for the next write. Not sure with the OPL but the OPN2 is very variable, some registers only require < 18 cycles and others about 80. And of course, which is which isn't documented very well. So I'll try it with both ways, a timed wait or a read status check between writes. Yes, much like the SID synth engines are implemented. The CC based control engine would offer DAW based sound design and a more traditional multi timbral engine offers simpler live play, I think both require strong patch handling; which was one of the limitations of LS's design. The Teensey's limited RAM/Flash couldn't support (very many) patches, so to change instruments on a voice required re-writing the parameters (28 for each 4 op voice) via CCs between Note messages.Kind of cumbersome, especially with the limited Knob/Buttons on a keyboard. Your 1U FP looks good and kind of what I have in mind. As far as the soft buttons being to the side of the LCD, don't think that will be too big an issue. Would seem natural after abit of use, i'm sure; no worst then using a joypad while watching game video. Yogi

I spotted this a few weeks ago https://www.pjrc.com/store/cable_usb_panel_micro.html Though it wouldn't allow USB OTG Yogi

Hi Sauraen The pin driver will be very similar I think, with just the addition of handling of A0 and A1. Haven't looked too close but the OPN2 probably has fewer register per voice due to the fixed 4op voices and fixed waveform, as well as fewer voices. I'll work on a comparison between the chips' register and work them into a matrix which should ease porting some functions. I do intend to try and keep things as modular as possible and expandable. Being able to have two or three YMs and PSGs would rock. That is a really good idea with the separate midi ports, hadn't thought about it that way (still thinking in 8bit terms,). Foobat's original project was for two YMs and the only reason I chose to start with a single YM and a SN was to have a baseline close to the Sega design. But yes there are several people interested in expanded designs. Following Littlescale's Midi assignments does impose limits and makes it hard to use standard midi tracks, which is easier with the MBFM implementation. In fact there is a native Sega tracker project by Count Synphonic that will include a standard midi patch set to help with mapping midi songs to YM. His work may be useful for a alt midi interface. Here is a thread that touches on the OPN line a little. http://gendev.spritesmind.net/forum/viewtopic.php?t=386&sid=b6f09aeaa39b1346034bfb281f085806 I'm not real sure on the SSG usage with the 2612; the YM2608 doc in that thread may help. Aly James has demoed some format effects that sound very interesting. His FMDrive VST does replicates the SSG but the Yamaha docs only refer to it as 'illegal' so it wasn't used with most (or any) MD music. Seems overlooked for the most part which is a shame. Glad to have your appraisal of the F4, my gut says that it should have enough cycles but you've put it through it's paces with the OPL3s. Haven't thought too much about the UI, just kind of like the simplicity of the sammichFM but don't know how people find it for use-ability. There seems like two camps, one for 'a knob for every function' and the other likes 'a menu system with softs buttons'. I kind of wander between the two; but thats the beauty of MIOS, build as much or as little as you like. I like your FM 2.1 CS very much but space is always at a premium around here so leaning towards a more minimal CS. Being built on the MB NG foundation would hopefully allow builders to expand easily. Yes I'll open a User Project thread/wiki page when I get a little something more then vapor-ware. Didn't mean to highjack your thread :) Much Thanks for your input, Yogi

Awesom! (SVN is so cool and easy!) Good advice. Yes the bit level chip access is different then the OPL3 so will be the first task to conquer. Thanks again Yogi

Good point. The Mega Amp does allows for different filters; there are taylored schemas for the different YM version used in the range of models produced. In fact, a mod board that is being produced does have switches for the filter caps. So yea, it's do-able. Switches would also be needed depending on the YM chip used by builders, YM2612s or YM3834s. The 3834 has better drive levels and the mixing is fixed to eliminate the 'zipper' effect, but some like and want the Version 1 sound dynamics. So two DPDT, one per output channel, to switch the filter caps between two settings: Light filtering and Classic. Yogi

Hi Sauraen. OK very good VGM files are a recording of Register writes with timing. With the inclusion of 8b PCM samples a VGM would be larger then a Midi file. Unlike the SNES rompler type synth, Mega Drive music mainly uses the PCM channel for drums so while bigger then a Midi file, it's still compact. Most of the projects I've reviewed rely on an Arduino and the USB VCom to stream the file, and choke with files that include PCM voices due to bandwidth, RAM limits and timing . There was one project that uses an 8b AVR that did handle the streamed data well, using HID bulk mode, I think, and coded in straight C. I'm hoping the block transfers (512 bytes ?) from the SD card will be fast enough for playback from a large RAM buffer. A VGM player isn't the #1 priority but VGMs are the file of choice for most cross platform trackers so supporting them would benefit a few users. Will probably have to filter the VGM either on a PC or real time on the arm, to strip and redirect the console's addressing but I haven't investigated too much; on the ToDo list :) But for right now will be happy to get a simple synth framework working. I would like to support poly midi modes but I think that it would require selecting the synth mode, kind of a 'Midi' or 'GenMDM' mode switch; somewhat like the MBSid engine. So I think it will have to be added in the future. ​ Will definitely hook you up when I do a board run, maybe late spring? Depends on how much time I can devote. Yogi

Hi Maxon. the original project that I got interested in is over @ Spritemind.net http://gendev.spritesmind.net/forum/viewtopic.php?t=1470&sid=86c0fd483001fc05b12fa14c4ec97f08 I'll have to draw up a schema of the FM/PSG board that I prototyped, will get that together in the next few days. The basic changes from Foobat's project are: a single YM2612 and a SN76489 with stereo output via a 'Mega Amp', as per the post at Sega16.com http://www.sega-16.com/forum/showthread.php?26568-Introducing-the-Mega-Amp-The-universal-Genesis-audio-circuit As to the firmware well just starting with that :) Yogi

Hi Sascha. Just some ruff ideas on how I would go about it, but there are probably better ways. 1 Setup a variable array to store the note value for each step. Each element/step represents a encoder value. 2 Setup a background timed step function. Seq_bpm() may help 3 In app.c, when APP_ENC_NotifyChange() fires, increment/decrement the associated array element for the active encoder 4 When the Step function fires, kill the current note, fetch the new step value from the array and output the new Note On till the next step. This is a very basic outline and there are some examples for the build blocks that may help. I would start with #017 the simple Sequencer, and modify it with the variable array in place of the note stack. Look at #014 or #015 for encoder handling. You may want to also add a second encoder or pot for each step to set velocity values. Yogi EDIT After looking closely at Example #017, most of what you want to do is setup there. At the top of sec.c there are 3 arrays for Note, Vol and Length. the values in these arrays are used to build a midi package for each step. Though a Notestack is used, it controls the Seq Start/Stop functions; the Seq run only when a Midi Note On is received and stopped when a Note Off comes in. You may want to change the handling and do away with the Notestack Adding the Encoder handling is almost verbatim from Example #014. The above is basic and you will also have to add the int enc code to APP_int() for your needs Yogi

Hi Sauraen, no worries. When you can is fine. The differences between the OPL and YM2612 will demand a fair amount of unique code, but I'm hoping, at some point, to adapt some of the great features of MBFM; LFOs, EGs, Wavetables and Mod Matrix. I'm planning to implement the the same CC assignments that Littlescale chose for the GenMDM interface, mainly to maintain compatibility with user patches and VST software. With his design each of the 6 4op voices is assigned to a midi channel (1-6) and CC values are used for the voice's registers (~88 per voice). In addition there is special handling for Channels 3 & 6 and SSG 'Illegal' mode as well as support for the SN76489 PSG. So polyphonic channels are at odds with this design so far. Being so 'non-standard', patch handling will be important for live play. The original design is limited due to the Teensy uC's resources, so on the STM32 I expect far better control. I mentioned Midi file playback because I had in mind some sort of VGM file player. Midi bandwidth wouldn't support VGM streaming too well, especially if the VGM has heavy use of PCM samples, but I was thinking that it might be workable via SD card. It's not a priority ATM but would be an interesting feature or separate project. Coming back to your project, I will definitely be building a dual OPL synth at some point soon. I've been working on-n-off on a PIC based FM but will re work it I think :smile: Yogi

Hi Sauraen, really great work. The dual OPLs sound so good. I would very much like a copy of your code; at some point I want to build this monster and ATM I'm planning a related project based on a YM2612 and a SN76489 for a Sega Gen synth. Have been going through the PIC18F code but like you, see the STM32F4 as the future. Seeing a working example would help a great deal to get me started on the platform. I know I'll have to write a new HW driver and adapt some/lot of the synth engine, but the YM2612 seems like a sub set of the OPL in a lot of ways. Have you considered some file playback from SD card. Don't know the difficulties involved but it would be interesting to be able to play Adlib Tracker II songs :) Yogi

Hi Rowan, here is a related topic that may be of interest Yogi