See attached photos at end of my post here. There's an other cover that is easily removed with your fingers. And an inner cover that has 6 little tabs that must be cut/clipped to access the expansion port. Nintendo designed the expansion port to be accessible by an average person.
If someone doesn't want to clip the little tabs holding the inner cover from the connector as their console is no longer in "mint condition" then sure they might not be interested in any device that uses the expansion port. Once the inner cover is clipped free it can't really be reinstalled. But the outer cover can be placed back over the expansion port to cover it up again. My design is just long enough to give enough board length to install the log pot, but also place the outer cover back over the expansion port when installed.
Quote:
The market for playing japanese games is not exactly the same as the market for playing homebrew. This thing covers both the first and potentially the future of the latter.
Indeed, I've designed up some famicom to NES converter boards as well that properly send cart audio down to the expansion port via EXP6 which most adapters don't provide. They also properly handle mirroring to support 4 screen carts which is a common flaw with adapters on the market. I'll be bundling the famicom to NES adapter and solderless expansion audio board together for a price comparable to other adapters on the market which run for ~$25-30.
Quote:
I hope it's cheap enough to reasonably pack in with every cart. After it's field-tested and I finish my next board, I'd maybe buy 100 at a time, if that helps. This could be a great thing, I like what I see!
The board itself is rather simple, hoping it won't be too much of a pain to assemble in large volumes in house. The most expensive part is the log pot, which isn't necessary if a fixed resistor is desirable. My goal is to allow homebrew games to bundle in a fixed resistor exp audio board for ~$5. Should be able to offer large quantities at discount once they're released, so just hit me up then if you're interested.
Quote:
For what can be synthesized with an MCU, you have the STM8 in mind?
I really only have the stm8 in mind for a minimalist homebrew synth as it could be integrated into the CIC's mcu giving discrete mappers expansion audio on the cheap. I'm somewhat hopeful the stm32f030 running ~48Mhz with dual PWM DAC may be able to decently replicate some original audio expansions like VRC6, sunsoft5b, & FDS. I've yet to even start tinkering with them enough to be confident an stm32f0 will be adequate. Another consideration I've had is the stm32f051 as it includes a built in DAC for close to the price of a standalone DAC.
Quote:
The advantage I can see of FPGA vs MCU for audio, is that an FPGA could do more channels at a higher sample rate.
Yes that's most certainly true. But a FPGA with adequate resources to differentiate itself from an MCU as significant entry fee with ~$3-5 FPGA, plus level shifters, fine pitched assembly, etc. If one's goals are to satisfy purists/audiophiles without much cost sensivity, FPGA is the obvious choice. It's debatable if a FPGA on that scale/cost makes sense for homebrew though.
Quote:
I imagine you would want an external clock too, if using an RC oscillator the audio will be out of tune.
Yes that's a good point, another potential solution would be to use a NES clock source multiplied by a PLL if the mcu provides one. But most internal RC oscillators are tuneable, perhaps the mcu could finely tune itself with a calibration routine at boot/post warmup.
In the case of the
STM8 CIC-synth idea it doesn't offer a PLL, and an external crystal may not align with the minimalist goals. STM8's RC oscillator is trimmable in ~0.5% which equates to ~80khz steps @ 16Mhz, I'd assume that itself is far too inaccurate for audio use. For homebrew, I'm thinking that could be overcome by a calibration routine where the mcu is able to determine it's near exact frequency and update it's tables or tuning coefficient accordingly. If the console CIC is present and operating the time between CIC data transfers would be available to calibrate against. But with the large number of disabled console CICs that option can't really be relied upon. One would probably have to rely on a NES software routine for calibration by the rom at startup. One would have to experiment to see how much drift occurs, it may prove necessary to tune more frequently than startup alone.