Depends upon the system and your background knowledge, and how accurate you care to be. The megadrive is maybe not quite the pinnacle of complexity in sound creation but it can hang in the same circles, nowadays it is pretty much all digital/software from the bottom to top. There might be more channels (the DS has 16 for instance) but the complexity drops as people can just make it in wave/PCM instead, and still have looping available if they need it.
A link worth having, not for the megadrive but as an overview of sound cards
http://macgateway.com/featured-articles/sound-card-history/
Anyway you will probably find yourself having a crash course in the fundamentals of analogue and digital electronics if you go into this. If only so you understand what a decay is, why you might want two of them, general analogue signal manipulation, have an introduction to the ideas of noise and enough digital to handle the digital to analogue conversion (DAC) and possibly vice versa (ADC). If you go on all the fancy audio hacking/fiddling sites (
https://hcs64.com/mboard/forum.php being the one I would usually look at first, not sure where the others are at these days), and stuff like the game system plugins for foobar2000 they will be concerned with this sort of thing, and often able to spot sloppy emulation here by ear and what is causing it (abilities way beyond anything I have or are likely to gain this side of ear replacement).
Accuracy comes in to play when you want to keep it all in sync.
We will go for the megadrive
It has two processors
one is a Motorolla 68000, once upon a time an incredibly popular embedded processor (I can't say as well known as ARM is today as ARM did something quite rare in this and got themselves known to the public*) aka 68K. This is the workhorse of the machine.
The Z80. The master system used this as its primary processor, as did many other machines throughout history (the gameboy for instance uses a slight variation on the theme). Here in the megadrive/genesis though it governs the sound and farms things out to the two chips you mention. It is not held in lock step with the 68K as you can disable it in software and have it return later but the 68K can reach out and touch things in the Z80 memory area.
To be accurate in the emulation you would have to emulate the behaviours of the two sound chips, the z80 that they respond to and then the 68K beyond that (on top of any other things like controls, graphics, general memory handling, any extra chips, any extra devices like the megacd...) all in real time as it were. Any one of those things is trivial for a vaguely modern computer but getting them all to happen fast enough that your game runs at full speed is a harder trick to pull off, hence why you get articles like
https://arstechnica.com/gaming/2011...-3ghz-quest-to-build-a-perfect-snes-emulator/ (for the SNES I know but it holds).
Such things are why you get statements like you need a machine 10 times more powerful than the thing you are emulating to do the tricky, maybe a bit less if the machine being emulated is close to the machine it is running on. Today it is not a very accurate statement as we have dynamic recompilation for newer systems**, and coming the other way you have people doing stuff like the article above (
or worse).
*a little over a decade ago I was in an electronics department of a university. On the walls were posters saying about all the things this little known company called ARM powered.
**In case you were not familiar with things then dynamic recompilation aka dynarec is a thing where game systems programmed in languages that can be compiled (earlier systems were mostly still assembly, aka what the processor itself runs or near enough as does not matter here) can have their code remade in real time (kind of needs to be for reasons I will skip for now, though halting problem would be a search term if you want to start on that).
Said analogue electronics is what will see many have some trouble, or a steep learning curve -- programming training will handle memory manipulation and boolean logic, graphics in any 2d game system is usually fairly basic (flip, rotate, translate, scale, colour lookup all being obvious terms, and probably handled in high school maths or earlier) and with that you have the basis to make an emulator, might not be easy but enough to plug away and get things going. Sound on the other hand is more in the domain of electrical engineering and signals which few programming courses will go all that far into. 3d can be hard as well but many programming courses will cover what people need to know there (matrix maths, vectors and such maybe not being handled in all maths classes or programming courses but it is a staple of plenty of them, and if you do come from a more traditional engineering background, certainly an electronics one, then you will have done that extensively).
