As above it is not something that tends to appear too easily. If it is for an 8-16 bit era thing then chances are there was never really source code either -- source code as a meaningful concept to what it is understood as today came around for consoles with the rise of the PS1 and N64 that were coded using C rather than assembly.
1) The devs release it. Rare, especially for console stuff and even more so for Japanese stuff, with the added bonus of devs maybe even not having it these days (see lost source code in various gaming news sites). Best you can hope for there for this sort of thing is they included it on the disc by accident (has happened a few times in various capacities, one of the Princess Maker games on the DS being notable for this one).
2) The devs wrote it in a language that turns back into source code. Ideally this would be C#, Lua, Java, Python or something else in the just in time world but there are cases where the game is written for a runtime/engine that ports across more easily.
3) Leaked in some manner. See gigaleak for various Nintendo and related parties things in more recent times. Rare as well, even more so for unknown games. Legal concerns with this one.
4) More of a cleanroom recreation approach. If you can observe the actions of a game you can recreate it in your own code.
5) Disassembly and decompilation. Technically different actions, and as above for it to be decompiled then it would have had to have been compiled in the first place. Also decompilation is limited these days to pretty much C rather than C++ or anything later or more exotic which means PS1, N64, maybe Saturn, PC from late DOS/early Windows 95, GBA, DS through to maybe some PS2 stuff and PC games +5 to 6 years on from that timeframe when C++ became the weapon of choice (and OOP is good stuff for game programming so adoption was quick).
If you are asking this sort of question then consider it more like if your game is not on https://osgameclones.com/
then you are going to be facing a lot of learning in your future, both programming in general and reverse engineering.
Decompilers if you want a jumping off point
Hex Rays. Their disassembly tools (see IDA) and to a lesser extent hex editors are often considered some of the best out there and will be seen across hacking discussions/conferences. Their decompiler is relatively new compared to the other tools they do but it is still one of the best that is not someone's university projecthttps://www.hex-rays.com/products/decompiler/
Radare 2. IDA costs quite a bit of money so one of the big open source answers is Radare2. Cutter is its decompiler, though grab all of it.https://rada.re/n/
Ghidra. The US government does not like to be beholden to commercial things so tends to roll its own. In this case the NSA supports the Ghidra project and it is very good.https://ghidra-sre.org/
PC will be the main focus for those but most also get twisted towards other architectures, especially the popular ones underpinning consoles.
That said for PC stuff
This is more of a PC debugger but worth noting in this.
Many others like it. DLL exports if you watch the video on Diablo... I am sure you can see why they are usueful.
is another popular tool
exe unpacker (also going under the banner of PE aka Portable Executable analysis, PE is what Microsoft calls their format, the open source world tending to favour ELF)https://blog.malwarebytes.com/threat-analysis/2014/05/five-pe-analysis-tools-worth-looking-at/https://alternativeto.net/software/pe-explorer/
Should your subject be scrambled, packed, compressed, obfuscatedm encrypted or otherwise protected you will need to work around them. Many methods of this, especially for vintage games, are already known and bypassed but you may encounter others. Consoles tend to face this less, or least any methods employed are far less extreme.https://dzone.com/articles/packers-how-they-work-featuring-upx
is good stuff here.