NC100 sound chip
Russell Marks
driven by a separate chip at all?) I've written a simplistic emulation
for nc100em which seems mostly ok [1], but if I can base it on
something more than guesswork, that'd be nice. :-)
-Rus.
[1] I can't figure out how to emulate the severe distortion, though.
Did Amstrad `do a +3' again, or could this be a hint that they're
really doing two-channel sound on something like a Spectrum beeper?
Kevin Thacker
> Does anyone know what the NC100 sound chip is? (Is the sound even
> driven by a separate chip at all?) I've written a simplistic emulation
> for nc100em which seems mostly ok [1], but if I can base it on
> something more than guesswork, that'd be nice. :-)
Russell,
I don't know for sure, but I got the impression, after reading Cliff's
NC100
technical documentation, that the sound generation is very simple.
The documentation doesn't mention volume, so I assume it is fixed.
There appear to be 2 sound channels (A and B), and it is possible to
set the frequency of the sound using I/O registers. I assume the sound
is a square wave.
What is not described:
- are the sound channels mixed to produce a single sound output; and
if they are the mixing method used. (possible distortion from here)
- the volume appears to be fixed; distortion could be produced from
the internal speaker not being able to play the sound properly.
- if the channel is enabled/disabled, does this restart the sound
wave?
The sound generation, from memory, was similar to the PCW.
Regards,
Kev
Russell Marks
> Does anyone know what the NC100 sound chip is? (Is the sound even
> driven by a separate chip at all?) I've written a simplistic emulation
FWIW, I've now had a proper (more or less) go at recording output and
having a look at it, and my eyes still hurt. It seems to generate a
fixed base tone [1] of something like 3300Hz, with the `frequency' you
actually specify controlling the `wavelength' of an on/off filter on
this tone. For lower frequencies, you seem to get about four cycles
(roughly 1.1ms long I think, so more like 3.6 cycles) of the tone
being let through every so often (at timings matching the frequency).
Higher frequencies still get that, but as the frequency approaches the
four-cycle-ish length you get the tone most of the time, only being
cut out occasionally. [2] (I suppose that makes this a PWM scheme?)
The `two-channel' capability looks like a complete fake - it seems to
XOR the two different filter on/off values together. And the second
channel counter *seems* to be offset by half the maximum `wavelength',
but I'm not certain of that one (and to be honest I haven't tested the
two-channel stuff all that closely so far).
This really is very strange sound hardware indeed. Anyway, I'll post
about it again if I manage to figure out some more precise details at
some point.
BTW, about the chip - I've since remembered about Hans-Jürgen
Böhling's "Surgical Guide To The Amstrad Notepad Computer" (aka
sg-nc100.txt), and in it he describes a NEC µPD 65034 ("Customer Chip
with multiple funktions"), which among other things he claims to be
the "Sound generator for speaker". So presumably an Amstrad custom
chip is to blame for the sound implementation. :-)
One final digression. Playing around with the numbers (and noting that
this custom chip also generates the CPU clock), I noticed something.
Previously, I've measured the effective clock speed the NC100's Z80
runs at to be about 4.6MHz - my tests suggested it was more like
4.606MHz, but I could only be really confident about the 4.6 bit.
Now, take the formula given for note frequency in nciospec.doc, and
put in a `data' value of 1. That gives 1000000/(1*2*1.6276)=307200 and
change (about 0.79, presumably due to inaccuracy in Cliff's 1.6276
figure). So it seems reasonable to suppose that 307200Hz might be the
`clock' the sound generator uses.
But it gets interesting when you find that 307200*15 is 4608000,
suspiciously close to my (quite independent) effective CPU clock
measurement. Ok, 15 seems an unlikely multiple, but perhaps memory is
contended for 1/16th of the time by (say) the display hardware? My
measurement program was running in RAM, after all, and the display
memory *can* be anywhere in RAM. That would give us a more plausible
307200*16, and 4915200Hz as a base clock.
You can take this a step further, too. Say my "1.1ms" timing above
(for the `pulse' length) was slightly wrong - perhaps due to my rather
crappy "mike"! - and that the real time is slightly shorter. That
gives you this intriguing possibility:
256/307200=0.0008333333
i.e. 0.833ms. Not so very far from 1.1ms, and it could explain why the
sound glitches when you write less than 100h as the `wavelength' value
(see 2nd footnote).
There's a whole lot of conclusion-jumping going on above, of course,
but the numbers do look interesting. Any comments on how plausible (or
otherwise) this sounds? [4]
-Rus.
[1] In my samples the base tone looks fairly sinusoidal, but I suspect
this is due to the somewhat unconventional microphone I was using. [3]
Given how crude the rest of the sound hardware seems to be, it's
almost certainly a square wave.
[2] Curiously, once the word written to the relevant ports goes below
100h, the counter seems to `wrap' or something - you get a single tone
burst, then nothing. Perhaps 100h represents continuous tone with no
cutoff at all. To be honest it's a bit hard to tell without being able
to do better samples, or check the speaker input on an oscilloscope or
something.
[3] i.e. one of the speakers on a cheap old pair of headphones. Hey,
don't knock it, it worked... :-)
[4] One thing I will note is that I tested the RAM-contention idea by
seeing if ROM code ran faster than RAM (ROM page 15 has 16k of zeroes
which it was handy to loop over for this), and it doesn't. The quick
5-minute test I ran gave an effective CPU clock speed of 4.614MHz -
the margin of error on the test was about 1% since I was checking
start/stop times with the RTC's seconds-resolution output, so this
isn't *hugely* accurate (just to within 0.05MHz or so), but it's
easily enough to disprove the RAM-contention theory's suggestion that
the ROM code would run at about 4.9MHz.