OK I forgot this : a 16-bits mono sound output should be easy to create.
A nice FIFO (4K words ?), a good 16-bits DAC, a configurable clock reference and we're done, right ?...
Oh, I might have found cheap ADCs (8 bits, unipolar, 200Ksps). Should I ?...
BTW the YASEP architecture has some features that are inspired by DSP but it's not the computational aspect. Yet is would be FUN to do some real-time sound processing "for educational purpose" :-)
For the "FIFO" I could reuse the IDT7132 dual-port SRAM (2K×8). The counters would be "discrete" and easy to read back. The free-running output counter is a simple 74HC4040, whose value can be exposed in a Special Register and current queue depth can be computed in SW. Sound data is sent to another SR, which increments another counter (easy to read back too). A 4th SR configures the frequency, start/stop etc.
2 channels of input and 2 channels of output, all 8 bits, sounds like a plan. Now if only I could get a reasonable, meaningful sampling frequency out of the 3.6864MHz oscillator ? It sure won't work with 48KHz or 44.1KHz systems.
- 3686400/225=> 16384Hz (this could be increased to 32768 by detecting both edges of the clock)
I consider using a faster main frequency generator, which will enable finer control signals sequencing, maybe 18.432MHz or 24.576MHz. The choice also depends on the ability to easily derive standard serial data rates:
- 18432000/48000 = 384
- 18432000/115200 = 160
- 24576000/48000 = 512
- 24576000/115200 = 213.333
18432000Hz seems to be the winner so far, though it brings only 54ns of resolution for scheduling, instead of 40.7ns@24.576.
Obviously I want to keep a single clock source and derive all the others (serial, sound) to keep the design as synchronous as possible. I don't want to have to deal with Gray codes or multiple clock domains.
A variable sampling clock can be created by feeding the 18.432MHz frequency to a 74HC4040. A 74HC688 compares the output with a value loaded in a 74HC574, and triggers a /RESET of the 4040. Minimum sampling rate would be 7200Hz (minus the off-by-one).
Feedback is welcome !
Why do I even bother about a FIFO for the output ?
A simpler approach is : just map the output buffer in one of the data RAM spaces. Create a shadow SRAM that gets written just like the other banks, addressed by the corresponding Ax register.
This saves instructions and increases speed, since a normal operation can write to the sound output. No need to execute a PUT instruction.
This also saves circuits and complexity : there is no FIFO write register to GET, you can AND the Ax register to perform circular buffering. You still have to GET the read pointer though. But this saves the 74HC4040 for the write pointer.
Something similar might be possible for the ADC input but it's hard to write to both SRAM banks at the same time. I must find another trick...
Discussions
Become a Hackaday.io Member
Create an account to leave a comment. Already have an account? Log In.
Wow nice, sounds quite fancy vs toggling a GPIO bit (ala Apple ][). :-) You should be able to enjoy some nice "chiptunes".
Are you sure? yes | no
I hope to get 8 bits out (eventually stereo) with a R/2R DAC or something like that... just enough to get a taste of "the real thing", not something hi-fi but enough for "chiptunes" and fancy tiny games :-)
Sound processing is great because it is more stringent than graphics, real-time-wise. Managing FIFO depth and queing etc. is a really cool subject :)
Are you sure? yes | no