Newsgroups: comp.sys.amstrad.8bit,comp.sys.sinclair
Xref: vanilla comp.sys.sinclair:4158
Path: vanilla!asbach!noris.net!blackbush.xlink.net!howland.reston.ans.net!gatech!arclight.uoregon.edu!usenet.eel.ufl.edu!warwick!spuddy!spuddy.mew.co.uk!arcsalt
From: Darren Salt <arcsalt@spuddy.mew.co.uk>
Subject: Re: AY-3-819x PSG sound generation
Message-ID: <46DF53D390.DC90@spuddy.mew.co.uk>
Lines: 114
Sender: arcsalt@spuddy.mew.co.uk (Darren Salt)
X-Posting-Agent: RISC OS Newsbase 0.55d
Organization: Spud's Public Usenet Domain
X-Newsreader: Messenger v0.24 for RISC OS
References: <4p12ck$hqo@lyra.csx.cam.ac.uk> <4pm9rj$chl@lyra.csx.cam.ac.uk> <8526.imc@comlab.ox.ac.uk> <4pmkbk$ktb@lyra.csx.cam.ac.uk> <8530.imc@comlab.ox.ac.uk>
Date: Sun, 16 Jun 1996 20:20:35 GMT

In article <8530.imc@comlab.ox.ac.uk>
          imc@ecs.ox.ac.uk (Ian Collier) wrote:

> Let me desribe how I think the sound chip works...

[snip diagram]
> Each channel has a tone generator, a mixer and a volume controller.
> There is also one sound generator and one envelope generator shared
> between the channels.  Each unit works independently of the others.

Seems reasonable enough to me. Now unless you're going to send the output to
one (real) sound channel, it makes sense to have either three or six volume
controllers, depending on whether you generate noise and tone separately.
(AYSound generates them separately - two voices each attached to three
channels.)

I'll have to check that information on a single envelope generator, if only
to confirm it for myself.

> Let us take channel 0 as an example.

> The tone generator outputs a continuous tone [...] What happens when R1R0
> is zero is not known exactly (see later).

If you want an exact emulation... I just went for a slightly less
time-consuming approach and decided that very high frequency sounds would not
be emulated correctly - at a sample period of 48us, this worked out at R1R0 <
11.

[snip]
> The noise generator outputs noise continually at a frequency in some way
> related to R6 AND 63.  Call this output N.

You mean R6 AND 31 don't you? My information is mostly from the +3 manual,
which says (on p274):
	R6 - Noise generator control, D4-D0

> The mixer just outputs (!R7_0)*T + (!R7_3)*N.  (The '+' could possibly be
> 'or').  (Changes to R7 take effect immediately).

No worries there - I just let the sound system take care of the mixing :-)

> The envelope generator continually outputs a number between 0 and 15.  The
> number changes clock/R12R11 times per second in accordance with the wave
> form number R13.

Hmm. My emulation is done a little differently, but in an easier-to-write
way.

[snip]
> Now then.  Suppose you set R1R0 to zero.  What happens?  There are three
> choices...

>  1. The zero is treated as 4096 [...] This seems unlikely because if it
>     were true you would hear a very low note, and you don't.

I'd already discounted this.

>  2. The tone generator stops completely and outputs a constant signal of
>     either +1, -1 or zero (depending on various factors - mainly, which
>     values it normally produces).

>  3. The tone generator outputs a tone at a very high frequency.

Hmm. The comment on the noise generator (below) makes it seem like option 3
is correct since if this only resets when decrementing the counter results in
a negative number, surely it would be the same for the tone generator? (It
would, presumably, simplify the logic circuitry if this was the case.)

> We have a similar problem with what happens if you set R6 to zero, but
> this time we know that it does produce a sound, and I think the sound
> has a frequency that makes the progression R6=63, R6=62, ... R6=1,
> R6=0 produce a smooth sound.  That makes me wonder whether the formula
> frequency=clock*16/R6 is correct.  Maybe it's R6+1 or something.

Right... I'll have to have a look at that.

[snip]
> In case (3) the output will be either...
[snip graphics]
> (a) an amplitude modulated half-wave, or...
> (b) an amplitude modulated fullwave.
> (don't you just love ASCII graphics!)

;-)

> It depends whether the tone generator oscillates between 0 and 1 (as in
> (a)) or between -1 and 1 (as in (b)).

No argument; no idea which though I lean towards B.

> Now since the carrier frequency is going to be 50 or 100 KHz, it is
> inaudible and what we hear is its average.  In case (a) we hear the sample
> being played, while in case (b) we do not.  So it had better not be case
> (b)!

? Surely case B would represent the speaker states "in" and "out"?

  /    /
[|)  [|(
  \    \

> Possible solutions are 2(a), 2(b) and 3(a).  It should be possible to
> distinguish between (2) and (3) but not between 2(a) and 2(b).

3b, just to be awkward ;-)

-- 
+---------------------------------------------------------------------------+
| Darren Salt - arcsalt@spuddy.mew.co.uk - Toon Army - A Windoze free zone! |
| Acorn A3010 - Spectrum +3 - BBC Master - Season ticket - ARM powered! :-) |
+----01268-515441-for-free-email-&-Usenet------We'll-win-it-next-season!----+

This sentance has threee errors.


----

Xref: vanilla comp.sys.sinclair:4192
Path: vanilla!asbach!noris.net!blackbush.xlink.net!tank.news.pipex.net!pipex!usenet.eel.ufl.edu!warwick!lyra.csx.cam.ac.uk!news.ox.ac.uk!news
From: imc@ecs.ox.ac.uk (Ian Collier)
Newsgroups: comp.sys.amstrad.8bit,comp.sys.sinclair
Subject: Re: AY-3-819x PSG sound generation
Date: 17 Jun 1996 16:19:57 GMT
Organization: Oxford University Computing Laboratory
Lines: 64
Message-ID: <8556.imc@comlab.ox.ac.uk>
References: <4p12ck$hqo@lyra.csx.cam.ac.uk> <8530.imc@comlab.ox.ac.uk> <8541.imc@comlab.ox.ac.uk> <4ps0cr$qod@lyra.csx.cam.ac.uk>
NNTP-Posting-Host: boothp2.ecs.ox.ac.uk
X-Local-Date: Monday, 17th June 1996 at 5:19pm BST

In article <4ps0cr$qod@lyra.csx.cam.ac.uk>, rison@hep.phy.cam.ac.uk wrote:
>Is this true of all registers where some bits are not significant
>(1,3,5,6,7?,8,9,10,13)?

Yes it is.  The full list is as follows.  Registers 0, 2, 4, 7, 11 and 12
will store anything you put in them.  Registers 6, 8, 9 and 10 hold 5 bits,
and registers 1, 3, 5 and 13 hold 4 bits.

>> Also, if you try to read register 15 you just get 255.

>Is that so even if you've previously written something else to it,
>and irrespective of the direction bit in R7?

Ah, I forgot to check the direction bit (actually I don't know whether
the direction bit is used in the same sense on the 8912 as I had got the
impression that the upper four bits were always inputs and the lower four
were always outputs, but maybe that's wrong).

Anyway, now I have checked it turns out that both R14 and R15 return 255
only if the appropriate direction bit equals 0. If the direction bit is 1
then R15 returns whatever you last stored whereas R14 returns whatever you
last stored possibly modified by the current inputs.

>Funky!  This also explains why some technical manual I've got says
>that to stop sound on a channel requires not only the enables to be
>set to off, but the volume to be set to zero.

Any number other than 16 would be OK though, as long as you don't keep
changing it.  :-)

>> Doing the above experiment and varying the value of R12R11 reveals that
>> changing R12R11 affects the waveform immediately, rather than when the
>> current counter reaches zero. 

>Ahaa!  This disagrees with the thinking to date.  Can you tell whether
>the phase is reset, or whether the steps in the ramp just change in
>duration (the latter would make more sense if we're still thinking
>changes to R0-R6 only take effect at the end of the current cycle)?

I don't understand the question.  However, further experiment shows
something weird happening.  If you set the envelope on slow and then
suddenly put it to very fast, it speeds up immediately.  On the other
hand, if you repeatedly set it to the same value then the envelope continues
normally.  It seems like the internal counter is being set to the minimum
of whatever it is at the moment and the new value of R12R11.  Whatever is
happening, the volume does not suddenly go back to its starting value.

[Now we have to ask: does this minumum thing apply to the tone generators
also?  I don't know a good way to find out, unfortunately.]

>Hm, so 0 behaves as 1 for all the counters.  The interesting question
>is whether the traditional formula f=1/p is wrong and should be f=1/(p+1)
>or whether 0=1 is just an implementation accident.

The "f(p)=1/(p+1)" conjecture is certainly not true for the envelope
counter [because for small values of p the frequency of the envelope
is always within audible range and it is easy to tell that f(0) is the
same as f(1) and also that f(5) is 2*f(10)] and probably not true for
the noise counter [because I can't hear a difference between 0 and 1],
so I infer that it is probably not true for any of the counters.  The
answer must thus be "implementation accident".

Ian Collier - imc@comlab.ox.ac.uk - WWW Home Page (including Spectrum section):
http://www.comlab.ox.ac.uk/oucl/users/ian.collier/index.html


----

Xref: vanilla comp.sys.sinclair:4180
Path: vanilla!asbach!noris.net!blackbush.xlink.net!tank.news.pipex.net!pipex!usenet.eel.ufl.edu!warwick!lyra.csx.cam.ac.uk!news.ox.ac.uk!news
From: imc@ecs.ox.ac.uk (Ian Collier)
Newsgroups: comp.sys.amstrad.8bit,comp.sys.sinclair
Subject: Re: AY-3-819x PSG sound generation
Date: 17 Jun 1996 16:30:46 GMT
Organization: Oxford University Computing Laboratory
Lines: 53
Message-ID: <8557.imc@comlab.ox.ac.uk>
References: <4p12ck$hqo@lyra.csx.cam.ac.uk> <4pmkbk$ktb@lyra.csx.cam.ac.uk> <8530.imc@comlab.ox.ac.uk> <46DF53D390.DC90@spuddy.mew.co.uk>
NNTP-Posting-Host: boothp2.ecs.ox.ac.uk
X-Modified-on: Monday, 17th June 1996 at 5:30pm BST
X-Local-Date: Monday, 17th June 1996 at 5:28pm BST

In article <46DF53D390.DC90@spuddy.mew.co.uk>, Darren Salt <arcsalt@spuddy.mew.co.uk> wrote:
>If you want an exact emulation... I just went for a slightly less
>time-consuming approach and decided that very high frequency sounds would not
>be emulated correctly - at a sample period of 48us, this worked out at R1R0 <
>11.

Well I was describing the actual sound chip, rather than any emulation of
it. :-)

>[snip]
>> The noise generator outputs noise continually at a frequency in some way
>> related to R6 AND 63.  Call this output N.

>You mean R6 AND 31 don't you?

Yes.  I was going off someone else's info. :-)

>[snip]
>> In case (3) the output will be either...
>[snip graphics]
>> (a) an amplitude modulated half-wave, or...
>> (b) an amplitude modulated fullwave.

>> It depends whether the tone generator oscillates between 0 and 1 (as in
>> (a)) or between -1 and 1 (as in (b)).

>No argument; no idea which though I lean towards B.

>> Now since the carrier frequency is going to be 50 or 100 KHz, it is
>> inaudible and what we hear is its average.  In case (a) we hear the sample
>> being played, while in case (b) we do not.  So it had better not be case
>> (b)!

>? Surely case B would represent the speaker states "in" and "out"?

Er...  no.  In theory, the speaker is going in and out at a frequency of
110KHz with the total distance moved being given by register 8. You wouldn't
be able to hear this.  In practice, this is way outside the speaker's range,
so it stays approximately stationary at the average position.  But, since
the waveform goes down almost exactly the same distance as it goes up, the
average is the zero position and you still can't hear anything.

The difference between case (a) and case (b) is that in case (a) the bottom
position is always zero, so the average is half of the top position and so
you can still hear something.  This is how AM radio detection using a diode
works.

>This sentance has threee errors.

Aargh - paradox alert!

Ian Collier - imc@comlab.ox.ac.uk - WWW Home Page (including Spectrum section):
http://www.comlab.ox.ac.uk/oucl/users/ian.collier/index.html


----

Xref: vanilla comp.sys.sinclair:4187
Path: vanilla!asbach!noris.net!blackbush.xlink.net!tank.news.pipex.net!pipex!dish.news.pipex.net!pipex!news.be.innet.net!INbe.net!news.nl.innet.net!INnl.net!hunter.premier.net!news.mathworks.com!newsfeed.internetmci.com!in1.uu.net!news.interlog.com!sprite
From: cyrel@interlog.com (Ulrich Doewich)
Newsgroups: comp.sys.amstrad.8bit,comp.sys.sinclair
Subject: Re: AY-3-819x PSG sound generation
Date: Mon, 17 Jun 96 18:17:00 GMT
Organization: InterLog Internet Services
Lines: 14
Message-ID: <4q47d5$9g1@news.interlog.com>
References: <4p12ck$hqo@lyra.csx.cam.ac.uk> <8530.imc@comlab.ox.ac.uk> <8541.imc@comlab.ox.ac.uk> <4ps0cr$qod@lyra.csx.cam.ac.uk> <8556.imc@comlab.ox.ac.uk>
NNTP-Posting-Host: cyrel.interlog.com
X-Newsreader: News Xpress 2.0 Beta #0

To settle the questions about what happens if the period of a tone channel is 
set to 0: experiments with an oscilloscope have shown me that a value of 0 
produces _exactly_ the same as if you program a period of 1. With a 1MHz clock 
(CPC) you get 62.5kHz - which is inaudible. Same applies to R6 (noise): a 
value of 0 produces the same as a value of 1, only the random fluctuations 
make it audible this time.

Any other questions?! <g>

Ulrich Doewich.


PS: the new _digital_ SB code for CPCEMU/CPE is starting to shape up fine.. 
tone + noise already working!


----

Xref: vanilla comp.sys.sinclair:4193
Path: vanilla!asbach!noris.net!blackbush.xlink.net!tank.news.pipex.net!pipex!oleane!jussieu.fr!math.ohio-state.edu!howland.reston.ans.net!surfnet.nl!rug.nl!gerton
From: gerton@PROBLEM_WITH_INEWS_GATEWAY_FILE ()
Newsgroups: comp.sys.amstrad.8bit,comp.sys.sinclair
Subject: Re: AY-3-819x PSG sound generation
Followup-To: comp.sys.amstrad.8bit,comp.sys.sinclair
Date: 17 Jun 1996 22:16:27 GMT
Organization: Rijksuniversiteit Groningen
Lines: 22
Message-ID: <4q4lfr$nk1@info.service.rug.nl>
References: <4p12ck$hqo@lyra.csx.cam.ac.uk> <8530.imc@comlab.ox.ac.uk> <8541.imc@comlab.ox.ac.uk> <4ps0cr$qod@lyra.csx.cam.ac.uk> <8556.imc@comlab.ox.ac.uk> <4q47d5$9g1@news.interlog.com>
NNTP-Posting-Host: ciwi1.math.rug.nl
X-Newsreader: TIN [version 1.2 PL2]

Ulrich Doewich (cyrel@interlog.com) wrote:
> To settle the questions about what happens if the period of a tone channel is 
> set to 0: experiments with an oscilloscope have shown me that a value of 0 
> produces _exactly_ the same as if you program a period of 1. With a 1MHz clock 
> (CPC) you get 62.5kHz - which is inaudible. Same applies to R6 (noise): a 
> value of 0 produces the same as a value of 1, only the random fluctuations 
> make it audible this time.

> Any other questions?! <g>

Great, someone with an oscilloscope!

I think the only question yet to be settled is: what is the base frequency
of the noise generator?  That is, if R6 is set to 0 (or 1), what is the
smallest amount of time between edges?

My guess would be 1/221660 sec, because the tone generators are also driven
by a clock of 221660 Hz: a complete period of the top frequency 110830 Hz
consists of two edges 1/221660 seconds apart.


Gerton.


----

Xref: vanilla comp.sys.sinclair:4196
Path: vanilla!asbach!noris.net!blackbush.xlink.net!tank.news.pipex.net!pipex!oleane!jussieu.fr!math.ohio-state.edu!howland.reston.ans.net!swrinde!newsfeed.internetmci.com!in1.uu.net!interaccess!thymaster!arturj
From: arturj@thymaster.interaccess.com (Artur Jasowicz)
Newsgroups: comp.sys.amstrad.8bit,comp.sys.sinclair
Subject: Re: AY-3-819x PSG sound generation
Followup-To: comp.sys.amstrad.8bit,comp.sys.sinclair
Date: 17 Jun 1996 22:18:13 GMT
Organization: Chips'n'Bytes
Lines: 11
Message-ID: <4q4lj5$lq3@nntp.interaccess.com>
References: <4p12ck$hqo@lyra.csx.cam.ac.uk> <8530.imc@comlab.ox.ac.uk> <8541.imc@comlab.ox.ac.uk> <4ps0cr$qod@lyra.csx.cam.ac.uk> <8556.imc@comlab.ox.ac.uk>
Reply-To: arturj@interaccess.com
NNTP-Posting-Host: thymaster.interaccess.com
X-Newsreader: TIN [version 1.2 PL2]

This is a very interesting discussion. I've been watching it for a while.
It seems that some of the participants don't have precise data on the AY 
chips.
I just uploaded to ftp.nvg.unit.no/pub/sinclair/incoming/ a file called 
ay.tzf It contains scans of pages from GI's data book of AY family. Hope 
this helps :)

--
--             Artur Jasowicz               --
--          arturj@interaccess.com          --
-- http://homepage.interaccess.com/~arturj/ --


----

Xref: vanilla comp.sys.sinclair:4214
Path: vanilla!asbach!noris.net!blackbush.xlink.net!tank.news.pipex.net!pipex!oleane!jussieu.fr!math.ohio-state.edu!uwm.edu!news-res.gsl.net!news.gsl.net!nntp.coast.net!news.kei.com!newsfeed.internetmci.com!usenet.eel.ufl.edu!warwick!lyra.csx.cam.ac.uk!news.ox.ac.uk!news
From: G.A.Lunter@math.rug.nl (Gerton Lunter)
Newsgroups: comp.sys.amstrad.8bit,comp.sys.sinclair
Subject: Re: AY-3-819x PSG sound generation
Date: Tue, 18 Jun 1996 00:38:32 +0200
Organization: Oxford University Computing Laboratory
Lines: 226
Sender: imc@ecs.ox.ac.uk (Ian Collier)
Message-ID: <8562.imc@comlab.ox.ac.uk>
References: <4p12ck$hqo@lyra.csx.cam.ac.uk> <4pmkbk$ktb@lyra.csx.cam.ac.uk> <8530.imc@comlab.ox.ac.uk> <8541.imc@comlab.ox.ac.uk>
NNTP-Posting-Host: boothp2.ecs.ox.ac.uk
X-Local-Date: Tuesday, 18th June 1996 at 1:11pm BST
Originator: imc@boothp2.ecs

[Gerton sent me this and asked me to post it, so I have done.  My name should
 be in the Sender field, in accordance with the relevant RFC. -imc]

In article <8556.imc@comlab.ox.ac.uk> you wrote:

> Anyway, now I have checked it turns out that both R14 and R15 return 255
> only if the appropriate direction bit equals 0. If the direction bit is 1
> then R15 returns whatever you last stored whereas R14 returns whatever you
> last stored possibly modified by the current inputs.

I think direction bit = 1 means lines are used for output, and = 0 means used
for input.  R14 changes when selected for output because the interrupt
routine of the '128 writes to it.  (That is also the reason why, from
Basic, you have to do Out reg number, Out reg value several times to get
it right for sure).

Next part is about the enveloper:

> I don't understand the question.  However, further experiment shows
> something weird happening.  If you set the envelope on slow and then
> suddenly put it to very fast, it speeds up immediately.  On the other
> hand, if you repeatedly set it to the same value then the envelope continues
> normally.  It seems like the internal counter is being set to the minimum
> of whatever it is at the moment and the new value of R12R11.  Whatever is
> happening, the volume does not suddenly go back to its starting value.

I have come to the conclusion that the envelope generator is reset by
writing to R13, but not by writing to R12 or R11.  If R12R11 is set to
'very fast' halfway into an envelope, the envelope becomes very fast
apparently immediately.  However, during a whole envelope period the
envelope counter wraps 16 times, so actually you have to listen whether
the 1/16th slow part is finished slowly before the enveloper starts to
get fast, or whether it starts running fast directly.  In any way, changing
R12 or R11 does not reset the phase of the enveloper in the way writing
to R13 does. (Ah, you noted that too.  Read before writing, my dear Gerton!)


I have collected the discussion in this thread and some other info I had
on the shelves for the AY section in the docs of Z80 v3.04.  There are only
very few gaps still open.  Could you check it for accuracy (and also
whether it is understandable as it is written now?)

I wanted to post this to the newsgroup, but my tin refuses to post tonight.
I can't complain to the system operator 'caus he's already gone to bed...
Could you post it for me?


Gerton Lunter.
(gerton@math.rug.nl, haven't got the Inews gateway file problem corrected
either yet.)




5.3  The AY-3-8912 sound chip.


    This chip is used in for instance the Sinclair ZX Spectrum 128/+2/+3,
    Amstrad CPC 464/664/6128, Mattel Intellivision, BBC Micro, Atari ST,
    Sega Master System.

    The AY has 16 internal registers.  A register is selected by OUTing the
    register number in bits 0-3 to port #FFFD (only A15, A14 and A1 are
    decoded).  Then write to a register by OUTing to #BFFD, read it by
    INning from #FFFD.  When reading from a register, unused bits are
    always 0.  Reading always yields the value last written to the
    register, except for R14 and R15 when bit 6 or 7 of R7 are reset (R14 /
    R15 used for input).  On the AY-3-8912, when R7 bit 7 is reset, R15
    always reads 255.  Writing to R14 or R15 when they are selected for
    input does load the output register.

    Here are the names of the AY registers:

        Register        Name                                Bits used:

        R0              Fine tone control (FTC) channel A      0-7
        R1              Coarse tone control (CTC) channel A    0-3
        R2              FTC channel B                          0-7
        R3              CTC channel B                          0-3
        R4              FTC channel C                          0-7
        R5              CTC channel C                          0-3
        R6              Noise generator pitch control          0-4
        R7              Mixer and I/O control                  0-7
        R8              Amplitude channel A                    0-4
        R9              Amplitude channel B                    0-4
        R10             Amplitude channel C                    0-4
        R11             Envelope fine period control           0-7
        R12             Envelope coarse period control         0-7
        R13             Envelope control                       0-3
        R14             RS232 i/o                              0-7
        R15             I/O port 2                             0-7

    The AY chip consists of three tone generators, one noise generator, an
    envelope generator, three mixers, and three volume generators.

    Tone generator A is controlled by R0 and R1.  It contains a 12 bit down
    counter which is set to the value of R1R0 (most significant bits are in
    R1) every time it reaches zero, and is counted down at a frequency of
    221660 Hz (which is the driving frequency of the chip divided by 8).
    Loading R0 or R1 takes effect only when the down counter reaches zero.
    Every time it does so, the tone generator changes it output from 0 to 1
    or vice versa, so the frequency of the tone generated is 110830/R1R0 Hz
    (one period consists of two transitions). If R1R0 contains 0, the
    counter behaves as if R1R0 contained 1.

    The noise generator contains a 5 bit down counter, which is reset to
    whatever R6 contains every time it reaches zero.  It is counted down at
    a frequency of 221660 Hz [1].  Every time it reaches zero, it randomly
    chooses 0 or 1 as its new output [2].  When R6 is zero, the noise
    generated is the same as when R6 is 1.  Changes to R6 take effect only
    when the internal counter reaches 0.


       Bit      7    6    5    4    3    2    1    0
             
       R7     D2  D1  Nc  Nb  Na  Tc  Tb  Ta 
             


    If D1 is 1, R14 acts as output register (RS232 output: bit 2 is CTS,
    bit 3 is data output); when it is 0 R14 acts as input register (bit 6
    is DTR [3]).  D2 is ignored as the AY chip has only one I/O register;
    the bit and its corresponding register are present however.  Reading
    R15 in input mode always yields 255.  Changes made to R7 take effect
    immediately.

    The noise and tone output of a channel is combined in the mixer in the
    following way:

        Output_A = (Tone_A OR Ta) AND (Noise OR Na)

    Here Tone_A is the binary output of tone generator A, and Noise is the
    binary output of the noise generator.  Note that setting both Ta and Na
    to 1 produces a constant 1 as output.  Also note that setting both Ta
    and Na to 0 produces bursts of noise and half-periods of constant
    output 0.

    Each binary tone channel output is fed to a separate volume generator.
    Each volume generator is controlled by its amplitude register (R8 for
    channel A) and the 4-bit output of the envelope controller.


       Bit      7    6    5    4    3    2    1    0
             
       R8                 Ev  V3  V2  V1  V0 
             


    If Ev=0, the current volume is given by V3V2V1V0.  If Ev=1, the current
    volume is given by the output of the envelope generator.  The volume
    controller produces an output voltage proportional to its channel's
    binary output value times the current volume.  These analogue outputs
    are then added together to give the final output [4].  Note that even
    when a channel is disabled (say Ta = Na = 1), changing the volume level
    changes the final output, as the binary tone channel output is constant
    and equal to 1, not 0.  Changes to the amplitude registers take effect
    immediately.

    The envelope generator is controlled by R11, R12 and R13.


       Bit     7  6  5  4      3         2         1        0
             
       R13            Continue  Attack  Alternate  Hold 
             


    The envelope generator contains a 16-bit down counter, operated at a
    frequency of 110830 Hz.  The lowest frequency attainable by the
    envelope clock is therefore 1.7 Hz.  If R12R11 contains 0, the clock
    runs at 110830 Hz; otherwise it runs at 110830/R12R11 Hz.  The envelope
    generator is reset by writing to R13 (but not by writing to R11 or
    R12).

    A 'period' is the time taken by 16 clock ticks.  The output of the
    envelope generator during the first period is as follows.  If Attack =
    1, the output starts off at 0 and at each clock tick is increased by 1
    until it reaches 15.  If Attack = 0, the output starts off at 15 and is
    falls to 0.

    The output in the subsequent periods is 0 if Continue = 0.  Otherwise,
    first the (internal) 'Attack' bit is toggled if Alternate is set,
    otherwise it doesn't change.  How if Hold = 1, the output is a constant
    15 in this and subsequent periods if Attack = 1, otherwise it is a
    constant 0.  If Hold = 0, the envelope generator behaves just as in the
    first period (except that Attack has possibly changed).  To sum it up:


        0,1,2,3  \__________     single decay then off

        4,5,6,7  /|_________     single attack then off

        8        \|\|\|\|\|\     repeated decay

        9        \__________     single decay then off

        10       \/\/\/\/\/\     repeated decay-attack
                   _________
        11       \|              single decay then hold

        12       /|/|/|/|/|/     repeated attack
                  __________
        13       /               single attack then hold

        14       /\/\/\/\/\/     repeated attack-decay

        15       /|_________     single attack then off


    If the envelope generator is used to generate a tone, its frequency is
    either 110830/(16*R12R11) Hz (R13 = 8 or 12) or 110830/(32*R12R11) Hz
    (R13 = 10 or 14).


    [1] This is just a guess.  From R6=1 to R6=6 the noise seemed not to
        change in 'color', but only to get louder, so the noise generator
        frequency seems to be approximately 2 * F_top_of_hearing * 6, which
        is not in disagreement with above guess.  Could easily be a factor
        2 off, though.
    [2] The algorithm used for the pseudo random output is not known.  It
        seems not to be too good, as sounds vaguely similar to tape loading
        sounds are audible if you set R6 to 31.
    [3] I don't know which bit is data input; it is probably not bit 3.
    [4] It is more likely that the volume controller's outputs are added
        together binary before being converted to an analogue signal.



----

Xref: vanilla comp.sys.sinclair:4212
Path: vanilla!asbach!noris.net!blackbush.xlink.net!tank.news.pipex.net!pipex!oleane!jussieu.fr!math.ohio-state.edu!uwm.edu!news-res.gsl.net!news.gsl.net!nntp.coast.net!news.kei.com!newsfeed.internetmci.com!usenet.eel.ufl.edu!warwick!lyra.csx.cam.ac.uk!mgr11
From: mgr11@cus.cam.ac.uk (M.G. Rison)
Newsgroups: comp.sys.amstrad.8bit,comp.sys.sinclair
Subject: Re: AY-3-819x PSG sound generation
Date: 18 Jun 1996 11:58:11 GMT
Organization: University of Cambridge, England
Lines: 41
Sender: rison@hep.phy.cam.ac.uk
Message-ID: <4q65kj$bl6@lyra.csx.cam.ac.uk>
References: <4p12ck$hqo@lyra.csx.cam.ac.uk> <8556.imc@comlab.ox.ac.uk> <4q47d5$9g1@news.interlog.com> <4q4lfr$nk1@info.service.rug.nl>
Reply-To: rison@hep.phy.cam.ac.uk
NNTP-Posting-Host: ursa.cus.cam.ac.uk

En la artikolo <4q4lfr$nk1@info.service.rug.nl>,
 <gerton@PROBLEM_WITH_INEWS_GATEWAY_FILE> skribis:
         ~~~~~~~~~~~~~~~
How about fixing this?

> Ulrich Doewich (cyrel@interlog.com) wrote:
> > To settle the questions about what happens if the period of a tone channel is 
> > set to 0: experiments with an oscilloscope have shown me that a value of 0 
> > produces _exactly_ the same as if you program a period of 1. With a 1MHz clock 
> > (CPC) you get 62.5kHz - which is inaudible. Same applies to R6 (noise): a 
> > value of 0 produces the same as a value of 1, only the random fluctuations 
> > make it audible this time.
> Great, someone with an oscilloscope!
> I think the only question yet to be settled is: what is the base frequency
> of the noise generator?  That is, if R6 is set to 0 (or 1), what is the
> smallest amount of time between edges?
> My guess would be 1/221660 sec, because the tone generators are also driven
> by a clock of 221660 Hz: a complete period of the top frequency 110830 Hz
> consists of two edges 1/221660 seconds apart.

I think we should work in PSG clock cycles here, otherwise there'll
be confusion/errors due to the differing CPC/Speccy clock rates.

I initially guessed that the smallest noise period would be 8 cycles.
This was based on the idea that the way the PSG did tone/noise was to
decrement the period counter every 8 cycles and then toggle/randomly
set the sample sign for the next bit.

Pierre Guerrier, Pierre.Guerrier@masi.ibp.fr , however, has done some
tests (with a scope) which show (IIUC!) that the smallest noise period
is 16 cycles.  [Pierre can read this newsgroup but has trouble posting.]
I'm not sure how the PSG's algorithms would work in this case, but
who cares as long as it's right?

Mark, whose PSG emulation seems pretty close now (gloat, gloat...)

======================================================================
|   rison@hep.phy.cam.ac.uk       |  Esperanto - lingvo inter-nacia  |
|   rison@vxcern.cern.ch          |       * Mi estas riisto *        |
======================================================================


----

Xref: vanilla comp.sys.sinclair:4215
Path: vanilla!asbach!noris.net!blackbush.xlink.net!tank.news.pipex.net!pipex!oleane!jussieu.fr!math.ohio-state.edu!uwm.edu!lll-winken.llnl.gov!nntp.coast.net!news.kei.com!newsfeed.internetmci.com!usenet.eel.ufl.edu!warwick!lyra.csx.cam.ac.uk!news.ox.ac.uk!news
From: imc@ecs.ox.ac.uk (Ian Collier)
Newsgroups: comp.sys.amstrad.8bit,comp.sys.sinclair
Subject: Re: AY-3-819x PSG sound generation
Date: 18 Jun 1996 12:06:19 GMT
Organization: Oxford University Computing Laboratory
Lines: 12
Message-ID: <8561.imc@comlab.ox.ac.uk>
References: <4p12ck$hqo@lyra.csx.cam.ac.uk> <4ps0cr$qod@lyra.csx.cam.ac.uk> <8556.imc@comlab.ox.ac.uk> <4q4lj5$lq3@nntp.interaccess.com>
NNTP-Posting-Host: boothp2.ecs.ox.ac.uk
X-Local-Date: Tuesday, 18th June 1996 at 1:05pm BST

In article <4q4lj5$lq3@nntp.interaccess.com>, arturj@interaccess.com wrote:
>I just uploaded to ftp.nvg.unit.no/pub/sinclair/incoming/ a file called 
>ay.tzf It contains scans of pages from GI's data book of AY family. Hope 
>this helps :)

That would be useful, but what is the file format?  From the name it looks
like a CP/M format, which wouldn't be of use to many people.  Of course, I
could be wrong since it's not possible to grab things from incoming until
Blood has moved them...

Ian Collier - imc@comlab.ox.ac.uk - WWW Home Page (including Spectrum section):
http://www.comlab.ox.ac.uk/oucl/users/ian.collier/index.html


----

Xref: vanilla comp.sys.sinclair:4213
Path: vanilla!asbach!noris.net!blackbush.xlink.net!tank.news.pipex.net!pipex!oleane!jussieu.fr!math.ohio-state.edu!howland.reston.ans.net!surfnet.nl!rug.nl!gerton
From: gerton@PROBLEM_WITH_INEWS_GATEWAY_FILE ()
Newsgroups: comp.sys.amstrad.8bit,comp.sys.sinclair
Subject: Re: AY-3-819x PSG sound generation
Date: 18 Jun 1996 12:08:25 GMT
Organization: Rijksuniversiteit Groningen
Lines: 198
Message-ID: <4q667p$a07@info.service.rug.nl>
References: <4p12ck$hqo@lyra.csx.cam.ac.uk> <8530.imc@comlab.ox.ac.uk> <8541.imc@comlab.ox.ac.uk> <4ps0cr$qod@lyra.csx.cam.ac.uk> <8556.imc@comlab.ox.ac.uk> <4q4lj5$lq3@nntp.interaccess.com>
NNTP-Posting-Host: ciwi2.math.rug.nl
X-Newsreader: TIN [version 1.2 PL2]

I've been collecting the things said in this thread for a section in the
docs of Z80 v3.04.  Here is what I've cooked up.  I did a little
experimenting to clarify a few of the problems left open.  Except for
the driving frequency of the noise generator, and the layout of the
RS232 in/out byte (the latter should be easy to find out), I think
the story is complete now.  Comments?


Here it is:



5.3  The AY-3-8912 sound chip.


    This chip is used in for instance the Sinclair ZX Spectrum 128/+2/+3,
    Amstrad CPC 464/664/6128, Mattel Intellivision, BBC Micro, Atari ST,
    Sega Master System.

    The AY has 16 internal registers.  A register is selected by OUTing the
    register number in bits 0-3 to port #FFFD (only A15, A14 and A1 are
    decoded).  Then write to a register by OUTing to #BFFD, read it by
    INning from #FFFD.  When reading from a register, unused bits are
    always 0.  Reading always yields the value last written to the
    register, except for R14 and R15 when bit 6 or 7 of R7 are reset (R14 /
    R15 used for input).  On the AY-3-8912, when R7 bit 7 is reset, R15
    always reads 255.  Writing to R14 or R15 when they are selected for
    input does load the output register.

    Here are the names of the AY registers:

        Register        Name                                Bits used:

        R0              Fine tone control (FTC) channel A      0-7
        R1              Coarse tone control (CTC) channel A    0-3
        R2              FTC channel B                          0-7
        R3              CTC channel B                          0-3
        R4              FTC channel C                          0-7
        R5              CTC channel C                          0-3
        R6              Noise generator pitch control          0-4
        R7              Mixer and I/O control                  0-7
        R8              Amplitude channel A                    0-4
        R9              Amplitude channel B                    0-4
        R10             Amplitude channel C                    0-4
        R11             Envelope fine period control           0-7
        R12             Envelope coarse period control         0-7
        R13             Envelope control                       0-3
        R14             RS232 i/o                              0-7
        R15             I/O port 2                             0-7

    The AY chip consists of three tone generators, one noise generator, an
    envelope generator, three mixers, and three volume generators.

    Tone generator A is controlled by R0 and R1.  It contains a 12 bit down
    counter which is set to the value of R1R0 (most significant bits are in
    R1) every time it reaches zero, and is counted down at a frequency of
    221660 Hz (which is the driving frequency of the chip divided by 8).
    Loading R0 or R1 takes effect only when the down counter reaches zero.
    Every time it does so, the tone generator changes it output from 0 to 1
    or vice versa, so the frequency of the tone generated is 110830/R1R0 Hz
    (one period consists of two transitions). If R1R0 contains 0, the
    counter behaves as if R1R0 contained 1.

    The noise generator contains a 5 bit down counter, which is reset to
    whatever R6 contains every time it reaches zero.  It is counted down at
    a frequency of 221660 Hz [1].  Every time it reaches zero, it randomly
    chooses 0 or 1 as its new output [2].  When R6 is zero, the noise
    generated is the same as when R6 is 1.  Changes to R6 take effect only
    when the internal counter reaches 0.


       Bit      7    6    5    4    3    2    1    0
             
       R7       D2   D1   Nc   Nb   Na   Tc   Tb   Ta 
             


    If D1 is 1, R14 acts as output register (RS232 output: bit 2 is CTS,
    bit 3 is data output); when it is 0 R14 acts as input register (bit 6
    is DTR [3]).  D2 is ignored as the AY chip has only one I/O register;
    the bit and its corresponding register are present however.  Reading
    R15 in input mode always yields 255.  Changes made to R7 take effect
    immediately.

    The noise and tone output of a channel is combined in the mixer in the
    following way:

        Output_A = (Tone_A OR Ta) AND (Noise OR Na)

    Here Tone_A is the binary output of tone generator A, and Noise is the
    binary output of the noise generator.  Note that setting both Ta and Na
    to 1 produces a constant 1 as output.  Also note that setting both Ta
    and Na to 0 produces bursts of noise and half-periods of constant
    output 0.

    Each binary tone channel output is fed to a separate volume generator.
    Each volume generator is controlled by its amplitude register (R8 for
    channel A) and the 4-bit output of the envelope controller.


       Bit      7    6    5    4    3    2    1    0
             
       R8                      Ev   V3   V2   V1   V0 
             


    If Ev=0, the current volume is given by V3V2V1V0.  If Ev=1, the current
    volume is given by the output of the envelope generator.  The volume
    controller produces an output voltage proportional to its channel's
    binary output value times the current volume.  These analogue outputs
    are then added together to give the final output [4].  Note that even
    when a channel is disabled (say Ta = Na = 1), changing the volume level
    changes the final output, as the binary tone channel output is constant
    and equal to 1, not 0.  Changes to the amplitude registers take effect
    immediately.

    The envelope generator is controlled by R11, R12 and R13.


       Bit     7  6  5  4      3         2         1         0
             
       R13                 Continue    Attack    Alternate  Hold 
             


    The envelope generator contains a 16-bit down counter, operated at a
    frequency of 110830 Hz.  The lowest frequency attainable by the
    envelope clock is therefore 1.7 Hz.  If R12R11 contains 0, the clock
    runs at 110830 Hz; otherwise it runs at 110830/R12R11 Hz.  The envelope
    generator is reset by writing to R13 (but not by writing to R11 or
    R12).

    A 'period' is the time taken by 16 clock ticks.  The output of the
    envelope generator during the first period is as follows.  If Attack =
    1, the output starts off at 0 and at each clock tick is increased by 1
    until it reaches 15.  If Attack = 0, the output starts off at 15 and is
    falls to 0.

    The output in the subsequent periods is 0 if Continue = 0.  Otherwise,
    first the (internal) 'Attack' bit is toggled if Alternate is set,
    otherwise it doesn't change.  How if Hold = 1, the output is a constant
    15 in this and subsequent periods if Attack = 1, otherwise it is a
    constant 0.  If Hold = 0, the envelope generator behaves just as in the
    first period (except that Attack has possibly changed).  To sum it up:


        0,1,2,3  \__________     single decay then off

        4,5,6,7  /|_________     single attack then off

        8        \|\|\|\|\|\     repeated decay

        9        \__________     single decay then off

        10       \/\/\/\/\/\     repeated decay-attack
                   _________
        11       \|              single decay then hold

        12       /|/|/|/|/|/     repeated attack
                  __________
        13       /               single attack then hold

        14       /\/\/\/\/\/     repeated attack-decay

        15       /|_________     single attack then off


    If the envelope generator is used to generate a tone, its frequency is
    either 110830/(16*R12R11) Hz (R13 = 8 or 12) or 110830/(32*R12R11) Hz
    (R13 = 10 or 14).


    [1] This is just a guess.  From R6=1 to R6=6 the noise seemed not to
        change in 'color', but only to get louder, so the noise generator
        frequency seems to be approximately 2 * F_top_of_hearing * 6, which
        is not in disagreement with above guess.  Could easily be a factor
        2 off, though.
    [2] The algorithm used for the pseudo random output is not known.  It
        seems not to be too good, as sounds vaguely similar to tape loading
        sounds are audible if you set R6 to 31.
    [3] I don't know which bit is data input; it is probably not bit 3.
    [4] It is more likely that the volume controller's outputs are added
        together binary before being converted to an analogue signal.

















----

Xref: vanilla comp.sys.sinclair:4225
Path: vanilla!asbach!noris.net!blackbush.xlink.net!rz.uni-karlsruhe.de!news.uni-ulm.de!news.belwue.de!fu-berlin.de!news.mathworks.com!newsfeed.internetmci.com!hunter.premier.net!netnews.worldnet.att.net!ix.netcom.com!netcom.net.uk!dispatch.news.demon.net!demon!sunsite.doc.ic.ac.uk!lyra.csx.cam.ac.uk!news.ox.ac.uk!news
From: imc@ecs.ox.ac.uk (Ian Collier)
Newsgroups: comp.sys.amstrad.8bit,comp.sys.sinclair
Subject: Re: AY-3-819x PSG sound generation
Date: 18 Jun 1996 12:40:54 GMT
Organization: Oxford University Computing Laboratory
Lines: 88
Message-ID: <8563.imc@comlab.ox.ac.uk>
References: <4p12ck$hqo@lyra.csx.cam.ac.uk> <8530.imc@comlab.ox.ac.uk> <8541.imc@comlab.ox.ac.uk> <8562.imc@comlab.ox.ac.uk>
NNTP-Posting-Host: boothp2.ecs.ox.ac.uk
X-Local-Date: Tuesday, 18th June 1996 at 1:40pm BST

In article <8562.imc@comlab.ox.ac.uk>, G.A.Lunter@math.rug.nl (Gerton Lunter) wrote:
>In article <8556.imc@comlab.ox.ac.uk> you wrote:
>> Anyway, now I have checked it turns out that both R14 and R15 return 255
>> only if the appropriate direction bit equals 0.

>I think direction bit = 1 means lines are used for output, and = 0 means used
>for input.

Something like that.  But I wasn't too sure whether it would be used on
the 8912 because half of register 14 is used for inputs and half for
outputs.  In addition, I don't think the +3's RS232 and MIDI routines
alter register 7 at all.

>            R14 changes when selected for output because the interrupt
>routine of the '128 writes to it.

I did the test in 48KDB, which just has the normal 48K interrupt routine,
so that can't be the reason.  Also, the results of the test (the one that
didn't return 255) depended on whether I had the MIDI connection plugged
in or not.

>I have come to the conclusion that the envelope generator is reset by
>writing to R13, but not by writing to R12 or R11.  If R12R11 is set to
>'very fast' halfway into an envelope, the envelope becomes very fast
>apparently immediately.  However, during a whole envelope period the
>envelope counter wraps 16 times, so actually you have to listen whether
>the 1/16th slow part is finished slowly before the enveloper starts to
>get fast, or whether it starts running fast directly.

It is the latter.  If you set the envelope on its slowest value then you
can clearly hear the volume being changed every 0.6 seconds.  If you set
it to very fast then it doesn't wait for the next change before the volume
disappears.

>5.3  The AY-3-8912 sound chip.

>    The AY has 16 internal registers.  A register is selected by OUTing the
>    register number in bits 0-3 to port #FFFD (only A15, A14 and A1 are
>    decoded).

Ho hum, more checking for me to do this evening. :-)  This may or may not be
different on the +3 than on the 128K.  (I wish the +3 was in the office!)

>                          On the AY-3-8912, when R7 bit 7 is reset, R15
>    always reads 255.  Writing to R14 or R15 when they are selected for
>    input does load the output register.

Another thing for me to check.  I didn't check what happens if you write R14
then change R7 and read it back.

>        R15             I/O port 2                             0-7

This port is not present on the 8912, even though the register still
exists; it is used on the 8910 (out of curiosity - what does the 8911
do, if it exists?).  Oh, I see you mentioned that later.  :-)

>    Every time it does so, the tone generator changes it output from 0 to 1
                                                       its

>       Bit      7    6    5    4    3    2    1    0

>       R7     D2  D1  Nc  Nb  Na  Tc  Tb  Ta 

The alignment seems to hae gone wrong here. :-)

>                                                              The volume
>    controller produces an output voltage proportional to its channel's
>    binary output value times the current volume.  These analogue outputs
>    are then added together to give the final output [4].

>    [4] It is more likely that the volume controller's outputs are added
>        together binary before being converted to an analogue signal.

Actually I believe the three outputs are produced on three pins of the chip,
and it is the application circuit that adds them together (usually by just
soldering them together).  We can verify this if we can look at the data
sheets that someone has just put up on ftp.nvg.unit.no.

>    A 'period' is the time taken by 16 clock ticks.  The output of the
>    envelope generator during the first period is as follows.  If Attack =
>    1, the output starts off at 0 and at each clock tick is increased by 1
>    until it reaches 15.  If Attack = 0, the output starts off at 15 and is
>    falls to 0.

There is an extra "is" in that last sentence.

Ian Collier - imc@comlab.ox.ac.uk - WWW Home Page (including Spectrum section):
http://www.comlab.ox.ac.uk/oucl/users/ian.collier/index.html


----

Xref: vanilla comp.sys.sinclair:4204
Path: vanilla!asbach!noris.net!blackbush.xlink.net!howland.reston.ans.net!nntp.coast.net!news.kei.com!newsfeed.internetmci.com!usenet.eel.ufl.edu!warwick!lyra.csx.cam.ac.uk!mgr11
From: mgr11@cus.cam.ac.uk (M.G. Rison)
Newsgroups: comp.sys.amstrad.8bit,comp.sys.sinclair
Subject: Re: AY-3-819x PSG sound generation
Date: 18 Jun 1996 12:58:04 GMT
Organization: University of Cambridge, England
Lines: 23
Sender: rison@hep.phy.cam.ac.uk
Message-ID: <4q694s$ebl@lyra.csx.cam.ac.uk>
References: <4p12ck$hqo@lyra.csx.cam.ac.uk> <8556.imc@comlab.ox.ac.uk> <4q4lj5$lq3@nntp.interaccess.com> <8561.imc@comlab.ox.ac.uk>
Reply-To: rison@hep.phy.cam.ac.uk
NNTP-Posting-Host: ursa.cus.cam.ac.uk

En la artikolo <8561.imc@comlab.ox.ac.uk>,
Ian Collier <imc@ecs.ox.ac.uk> skribis:

> In article <4q4lj5$lq3@nntp.interaccess.com>, arturj@interaccess.com wrote:
> >I just uploaded to ftp.nvg.unit.no/pub/sinclair/incoming/ a file called 
> >ay.tzf It contains scans of pages from GI's data book of AY family. Hope 
> >this helps :)
> That would be useful, but what is the file format?  From the name it looks
> like a CP/M format, which wouldn't be of use to many people.  Of course, I
> could be wrong since it's not possible to grab things from incoming until
> Blood has moved them...

I think it's time to reveal that something similar (identical?) is
available from the Unofficial Amstrad WWW resource at:

   http://andercheran.aiind.upv.es/~amstrad/CPC_Guide/ChipSpecs/ay-3-8912/ .

Mark

======================================================================
|   rison@hep.phy.cam.ac.uk       |  Esperanto - lingvo inter-nacia  |
|   rison@vxcern.cern.ch          |       * Mi estas riisto *        |
======================================================================


----

Xref: vanilla comp.sys.sinclair:4207
Path: vanilla!asbach!noris.net!blackbush.xlink.net!rz.uni-karlsruhe.de!news.uni-ulm.de!news.belwue.de!fu-berlin.de!zrz.TU-Berlin.DE!cs.tu-berlin.de!newscaster-1.mcast.net!news.mathworks.com!newsfeed.internetmci.com!usenet.eel.ufl.edu!warwick!lyra.csx.cam.ac.uk!mgr11
From: mgr11@cus.cam.ac.uk (M.G. Rison)
Newsgroups: comp.sys.amstrad.8bit,comp.sys.sinclair
Subject: Re: AY-3-819x PSG sound generation
Date: 18 Jun 1996 13:06:13 GMT
Organization: University of Cambridge, England
Lines: 87
Sender: rison@hep.phy.cam.ac.uk
Message-ID: <4q69k5$es5@lyra.csx.cam.ac.uk>
References: <4p12ck$hqo@lyra.csx.cam.ac.uk> <8541.imc@comlab.ox.ac.uk> <4ps0cr$qod@lyra.csx.cam.ac.uk> <8556.imc@comlab.ox.ac.uk>
Reply-To: rison@hep.phy.cam.ac.uk
NNTP-Posting-Host: ursa.cus.cam.ac.uk

En la artikolo <8556.imc@comlab.ox.ac.uk>,
Ian Collier <imc@ecs.ox.ac.uk> skribis:

> In article <4ps0cr$qod@lyra.csx.cam.ac.uk>, rison@hep.phy.cam.ac.uk wrote:
> >> Also, if you try to read register 15 you just get 255.
> >Is that so even if you've previously written something else to it,
> >and irrespective of the direction bit in R7?
> Ah, I forgot to check the direction bit (actually I don't know whether
> the direction bit is used in the same sense on the 8912 as I had got the
> impression that the upper four bits were always inputs and the lower four
> were always outputs, but maybe that's wrong).

Well that may be how Speccies use them, but as far as the PSG is
concerned, they're either all in or all out.

> Anyway, now I have checked it turns out that both R14 and R15 return 255
> only if the appropriate direction bit equals 0. If the direction bit is 1
> then R15 returns whatever you last stored whereas R14 returns whatever you
> last stored possibly modified by the current inputs.

Ah.

> >Funky!  This also explains why some technical manual I've got says
> >that to stop sound on a channel requires not only the enables to be
> >set to off, but the volume to be set to zero.
> Any number other than 16 would be OK though, as long as you don't keep
> changing it.  :-)

(Other than havingbit4set, you mean.)

I think I will gracefully give up this aspect of the PSG (sampled sounds).

> >> Doing the above experiment and varying the value of R12R11 reveals that
> >> changing R12R11 affects the waveform immediately, rather than when the
> >> current counter reaches zero. 
> >Ahaa!  This disagrees with the thinking to date.  Can you tell whether
> >the phase is reset, or whether the steps in the ramp just change in
> >duration (the latter would make more sense if we're still thinking
> >changes to R0-R6 only take effect at the end of the current cycle)?
> I don't understand the question. 

Basically, the period in R12R11 is the period for each of the 16 steps
in a hwenv ramp.  Presumably the PSG keeps a counter of which step it is
in the ramp (4-bit counter).

My question is whether writing R12R11 resets the phase within the ramp
element, or the ramp counter, or both, or what!

> However, further experiment shows
> something weird happening.  If you set the envelope on slow and then
> suddenly put it to very fast, it speeds up immediately.  On the other
> hand, if you repeatedly set it to the same value then the envelope continues
> normally.  It seems like the internal counter is being set to the minimum
> of whatever it is at the moment and the new value of R12R11.  Whatever is
> happening, the volume does not suddenly go back to its starting value.

Very strange, this.  This would be far less trivial to siliconify, I'd guess.

Are you _sure_ that it speeds up immediately?  Even on the longest hwenv
period, each step in the ramp is only going to last something like 0.5 s;
does it always speed up _immediately_, or sometimes only after a few
tenths of a second?

> [Now we have to ask: does this minumum thing apply to the tone generators
> also?  I don't know a good way to find out, unfortunately.]

Hm.

> >Hm, so 0 behaves as 1 for all the counters.  The interesting question
> >is whether the traditional formula f=1/p is wrong and should be f=1/(p+1)
> >or whether 0=1 is just an implementation accident.
> The "f(p)=1/(p+1)" conjecture is certainly not true for the envelope
> counter [because for small values of p the frequency of the envelope
> is always within audible range and it is easy to tell that f(0) is the
> same as f(1) and also that f(5) is 2*f(10)] and probably not true for
> the noise counter [because I can't hear a difference between 0 and 1],
> so I infer that it is probably not true for any of the counters.  The
> answer must thus be "implementation accident".

OK.  So 0=1 is our working guess.  Good!

Mark

======================================================================
|   rison@hep.phy.cam.ac.uk       |  Esperanto - lingvo inter-nacia  |
|   rison@vxcern.cern.ch          |       * Mi estas riisto *        |
======================================================================


----

Xref: vanilla comp.sys.sinclair:4224
Path: vanilla!asbach!noris.net!blackbush.xlink.net!rz.uni-karlsruhe.de!news.uni-kl.de!news.belwue.de!fu-berlin.de!news.mathworks.com!newsfeed.internetmci.com!hunter.premier.net!netnews.worldnet.att.net!ix.netcom.com!netcom.net.uk!dispatch.news.demon.net!demon!sunsite.doc.ic.ac.uk!lyra.csx.cam.ac.uk!news.ox.ac.uk!news
From: imc@ecs.ox.ac.uk (Ian Collier)
Newsgroups: comp.sys.amstrad.8bit,comp.sys.sinclair
Subject: Re: AY-3-819x PSG sound generation
Date: 18 Jun 1996 14:40:44 GMT
Organization: Oxford University Computing Laboratory
Lines: 54
Message-ID: <8566.imc@comlab.ox.ac.uk>
References: <4p12ck$hqo@lyra.csx.cam.ac.uk> <4ps0cr$qod@lyra.csx.cam.ac.uk> <8556.imc@comlab.ox.ac.uk> <4q69k5$es5@lyra.csx.cam.ac.uk>
NNTP-Posting-Host: boothp2.ecs.ox.ac.uk
X-Modified-on: Tuesday, 18th June 1996 at 3:40pm BST
X-Local-Date: Tuesday, 18th June 1996 at 3:39pm BST

In article <4q69k5$es5@lyra.csx.cam.ac.uk>, rison@hep.phy.cam.ac.uk wrote:
>Well that may be how Speccies use them, but as far as the PSG is
>concerned, they're either all in or all out.

Which is odd, because as I mentioned the speccy seems to use them as both
inputs and outputs without fiddling with R7.

It's rather awkward to emulate RS232 using "all-in-or-all-out" I/O ports,
because you want to output the CTS signal at the same time as inputting the
data.  It's all very strange and I don't know how it works...

>> Any number other than 16 would be OK though, as long as you don't keep
>> changing it.  :-)

>(Other than havingbit4set, you mean.)

OK, pedant.  Setting it to any value more than 16 would be silly, so I
assumed you wouldn't do that.  :-)

>>            It seems like the internal counter is being set to the minimum
>> of whatever it is at the moment and the new value of R12R11.  Whatever is
>> happening, the volume does not suddenly go back to its starting value.
>
>Very strange, this.  This would be far less trivial to siliconify, I'd guess.
>
>Are you _sure_ that it speeds up immediately?  Even on the longest hwenv
>period, each step in the ramp is only going to last something like 0.5 s;
>does it always speed up _immediately_, or sometimes only after a few
>tenths of a second?

I can distinguish between "0.7 seconds" and "immediately", thanks :-) and
I'm afraid it is the latter.

Here's something wacky!  What if the internal counters counted up instead of
down and on each step compared themselves with the target value?  It would
require more silicon, but it takes care of two of our problems:

 1. If you repeatedly set the period to the same value then nothing unusual
    happens, but if you set it to a smaller value you might cause an instant
    change due to the counter being higher than the period value.  Or the
    change might not be instant if the counter isn't that high.  This is
    precisely what I observe.

 2. If you set the period to 1 then the counter reaches 1 on each step and
    is reset.  If you set the period to 0 then the counter still reaches 1
    on each step and is reset because 1>0.  So setting it to 0 equals
    setting it to 1.

Ian Collier - imc@comlab.ox.ac.uk - WWW Home Page (including Spectrum section):
http://www.comlab.ox.ac.uk/oucl/users/ian.collier/index.html

PS I've read those scans of the AY data sheet (they are rather difficult to
   read, btw) and they didn't help...



----

Xref: vanilla comp.sys.sinclair:4218
Path: vanilla!asbach!noris.net!blackbush.xlink.net!howland.reston.ans.net!nntp.coast.net!zombie.ncsc.mil!news.mathworks.com!newsfeed.internetmci.com!usenet.eel.ufl.edu!warwick!lyra.csx.cam.ac.uk!mgr11
From: mgr11@cus.cam.ac.uk (M.G. Rison)
Newsgroups: comp.sys.amstrad.8bit,comp.sys.sinclair,comp.sys.acorn.hardware
Subject: Re: AY-3-819x PSG sound generation
Date: 18 Jun 1996 17:53:18 GMT
Organization: University of Cambridge, England
Lines: 21
Sender: rison@hep.phy.cam.ac.uk
Message-ID: <4q6qee$skp@lyra.csx.cam.ac.uk>
References: <4p12ck$hqo@lyra.csx.cam.ac.uk> <8556.imc@comlab.ox.ac.uk> <4q4lj5$lq3@nntp.interaccess.com> <4q667p$a07@info.service.rug.nl>
Reply-To: rison@hep.phy.cam.ac.uk
NNTP-Posting-Host: ursa.cus.cam.ac.uk

[Note cross-post.]

En la artikolo <4q667p$a07@info.service.rug.nl>,
 <gerton@PROBLEM_WITH_INEWS_GATEWAY_FILE> skribis:

> 5.3  The AY-3-8912 sound chip.
>     This chip is used in for instance the Sinclair ZX Spectrum 128/+2/+3,
>     Amstrad CPC 464/664/6128, Mattel Intellivision, BBC Micro, Atari ST,
>     Sega Master System.

AFAIK, the BBC didn't use an AY-3-891x.  It used a chip with similar
capabilities (perhaps a relation of the AY-3-891x), which, for example,
only allowed for one noise channel -- but the noise could be `white'
or `pulsed', or something like that.

Mark "ah, nostalgia"

======================================================================
|   rison@hep.phy.cam.ac.uk       |  Esperanto - lingvo inter-nacia  |
|   rison@vxcern.cern.ch          |       * Mi estas riisto *        |
======================================================================


----

Xref: vanilla comp.sys.sinclair:4232
Path: vanilla!asbach!noris.net!blackbush.xlink.net!unlisys!CNB.CompuNet.DE!zrz.TU-Berlin.DE!fu-berlin.de!news.mathworks.com!tank.news.pipex.net!pipex!usenet1.news.uk.psi.net!uknet!dispatch.news.demon.net!demon!fbs1.demon.co.uk!RFahey
From: Robert Fahey <RFahey@fbs1.demon.co.uk>
Newsgroups: comp.sys.amstrad.8bit,comp.sys.sinclair
Subject: Re: AY-3-819x PSG sound generation
Date: Tue, 18 Jun 1996 19:18:31 +0100
Organization: Symbiosys Ireland
Lines: 25
Distribution: world
Message-ID: <As+1tEA3LvxxEwnU@fbs1.demon.co.uk>
References: <4p12ck$hqo@lyra.csx.cam.ac.uk> <8530.imc@comlab.ox.ac.uk>
 <8541.imc@comlab.ox.ac.uk> <4ps0cr$qod@lyra.csx.cam.ac.uk>
 <8556.imc@comlab.ox.ac.uk> <4q4lj5$lq3@nntp.interaccess.com>
 <4q667p$a07@info.service.rug.nl>
NNTP-Posting-Host: fbs1.demon.co.uk
X-NNTP-Posting-Host: fbs1.demon.co.uk
MIME-Version: 1.0
X-Newsreader: Turnpike (evaluation) Version 1.12 <lhnqm4twwjlfKgGG9Mw5gwJZ07>

In article <4q667p$a07@info.service.rug.nl>, gerton@PROBLEM_WITH_INEWS_G
ATEWAY_FILE.? writes
>I've been collecting the things said in this thread for a section in the
>docs of Z80 v3.04.  Here is what I've cooked up.  I did a little
>experimenting to clarify a few of the problems left open.  Except for
>the driving frequency of the noise generator, and the layout of the
>RS232 in/out byte (the latter should be easy to find out), I think
>the story is complete now.  Comments?

I will post the full details of the AY chip as described in the Amstrad
CPC anvanced hardware programming guide as soon as I can find my copy.
This guide is fairly complete but I may need to consult a friend on some
register details :-( , so give me a while.

Robert 'Spooky' Fahey


=======================================================================
# Robert Fahey               |    Drop your carrier, we have you      #
# rfahey@fbs1.demon.co.uk    |    surrounded!                         #
# --------------------------------------------------------------------#
# Website soon on http://www.symbiosys.ie/   !!!!!!!!!!!!!!!!!!!!     #
=======================================================================

Turnpike evaluation. For Turnpike information, mailto:info@turnpike.com


----

Path: vanilla!asbach!noris.net!blackbush.xlink.net!tank.news.pipex.net!pipex!usenet.eel.ufl.edu!newsfeed.internetmci.com!howland.reston.ans.net!nntp.coast.net!dispatch.news.demon.net!demon!mail2news.demon.co.uk!getafix.oasis.icl.co.uk
From: l.d.tonks.bra0202@oasis.icl.co.uk
Newsgroups: comp.sys.sinclair
Subject: Re: AY-3-819x PSG sound generation
Date: Wed, 19 Jun 1996 09:57:03 +0100
Lines: 26
Message-ID: <199606190857.29630.0@getafix.oasis.icl.co.uk>
Reply-To: l.d.tonks.bra0202@oasis.icl.co.uk
X-NNTP-Posting-Host: getafix.oasis.icl.co.uk
X-Mail2News-Path: duct.mail.pipex.net!Q.icl.co.uk!relay1.pipex.net!getafix.oasis.icl.co.uk







:Ooops! I created this archive (ay.tzf) late at night. I guess I was a bit
:sleepy and used wrong extension. It is a unix tar gzipped archive        
: (tar czf .... command) and therefore should be named ay.tgz and not     
:ay.tzf. I have already sent a note to ftp@nvg, but if the file name      
:doesn't get corrected, just use tar xzf ay.tzf to extract images. The    
:scans are in 1 bit(black-and-white) TIFF format.                         


Consider the file moved and renamed! ;-)
ftp://ftp.nvg.unit.no/pub/sinclair/pics/misc/ay-info.tgz


Blood.

*============[ l.d.tonks@bra0202.wins.icl.co.uk ]=============*
|                    The Infamous BLOOD!                      |
|         The Speccy's not dead - it was just resting!        |
| Who needs 500Mb of rendered intro when Jetpac fits in 16k?! |
*===========[ http://spodbox.linux.org.uk/~blood/ ]===========*


----

Xref: vanilla comp.sys.sinclair:4227
Path: vanilla!asbach!noris.net!blackbush.xlink.net!tank.news.pipex.net!pipex!oleane!jussieu.fr!math.ohio-state.edu!howland.reston.ans.net!newsfeed.internetmci.com!in1.uu.net!EU.net!sun4nl!surfnet.nl!rug.nl!gerton
From: gerton@PROBLEM_WITH_INEWS_GATEWAY_FILE ()
Newsgroups: comp.sys.amstrad.8bit,comp.sys.sinclair
Subject: Re: AY-3-819x PSG sound generation
Followup-To: comp.sys.amstrad.8bit,comp.sys.sinclair
Date: 19 Jun 1996 11:47:16 GMT
Organization: Rijksuniversiteit Groningen
Lines: 38
Message-ID: <4q8pc4$64a@info.service.rug.nl>
References: <4p12ck$hqo@lyra.csx.cam.ac.uk> <4ps0cr$qod@lyra.csx.cam.ac.uk> <8556.imc@comlab.ox.ac.uk> <4q69k5$es5@lyra.csx.cam.ac.uk> <8566.imc@comlab.ox.ac.uk>
NNTP-Posting-Host: ciwi1.math.rug.nl
X-Newsreader: TIN [version 1.2 PL2]

Ian Collier (imc@ecs.ox.ac.uk) wrote:

> Here's something wacky!  What if the internal counters counted up instead of
> down and on each step compared themselves with the target value?  It would
> require more silicon, but it takes care of two of our problems:

>  1. If you repeatedly set the period to the same value then nothing unusual
>     happens, but if you set it to a smaller value you might cause an instant
>     change due to the counter being higher than the period value.  Or the
>     change might not be instant if the counter isn't that high.  This is
>     precisely what I observe.

>  2. If you set the period to 1 then the counter reaches 1 on each step and
>     is reset.  If you set the period to 0 then the counter still reaches 1
>     on each step and is reset because 1>0.  So setting it to 0 equals
>     setting it to 1.

This must be it.  (I like jumping to conclusions).  I also see a way of testing
it.

Set R0 to 0.  Then in machine code set R1 to 1, then to 15, then wait a
while, say twenty times longer than the time between setting R1 to 1 and
setting it to 255, and then repeat the process.

If we had a down counter, we have a 95% chance of the counter being reset
to 3840 = #f00, and a 5% chance of it being reset to 255, and we'll hear
a tone of 29 Hz with a few clicks here and there.

If we have an up counter, then the counter will never make it far beyond
255, and we'll hear a tone of something below 434 Hz, together with some
hissing, noise, or whatever.

I haven't done the experiment; I cannot handle the 128K keyboard, and
I haven't got my audio equipment connected up to the 128K to be able to
write it in Z80 and tape it to the real thing.  But it isn't difficult, so..


Gerton.


----

Xref: vanilla comp.sys.sinclair:4282
Path: vanilla!asbach!noris.net!blackbush.xlink.net!rz.uni-karlsruhe.de!news.uni-kl.de!news.belwue.de!fu-berlin.de!cs.tu-berlin.de!newscaster-1.mcast.net!news.mathworks.com!news.kei.com!nntp.coast.net!dispatch.news.demon.net!demon!sunsite.doc.ic.ac.uk!yama.mcc.ac.uk!zippy.dct.ac.uk!str-ccsun!strath-cs!ftel.co.uk!bham!bhamcs!news.ox.ac.uk!news
Newsgroups: comp.sys.amstrad.8bit,comp.sys.sinclair,comp.sys.acorn.hardware
Subject: Re: AY-3-819x PSG sound generation
Message-ID: <8578.imc@comlab.ox.ac.uk>
From: imc@ecs.ox.ac.uk (Ian Collier)
Date: 19 Jun 1996 13:44:48 GMT
References: <4p12ck$hqo@lyra.csx.cam.ac.uk> <4q4lj5$lq3@nntp.interaccess.com>
 <4q667p$a07@info.service.rug.nl> <4q6qee$skp@lyra.csx.cam.ac.uk>
Organization: Oxford University Computing Laboratory
NNTP-Posting-Host: boothp2.ecs.ox.ac.uk
X-Local-Date: Wednesday, 19th June 1996 at 2:44pm BST
Lines: 29

In article <4q6qee$skp@lyra.csx.cam.ac.uk>, rison@hep.phy.cam.ac.uk wrote:
>AFAIK, the BBC didn't use an AY-3-891x.  It used a chip with similar
>capabilities (perhaps a relation of the AY-3-891x), which, for example,
>only allowed for one noise channel -- but the noise could be `white'
>or `pulsed', or something like that.

True (it may also be an distant relation of the Sam's sound chip).  Instead
of there being a noise generator which could be mixed in with any of the
channels, the noise generator was a separate channel of its own.  It had
eight settings.

 - noise of high frequency             - periodic of high frequency
 - noise of medium frequency           - periodic of medium frequency
 - noise of low frequency              - periodic of low frequency
 - noise of frequency given by chan 1  - periodic of frequency given by chan 1

Don't ask me what "periodic" means.  But I remember that you could do
envelopes on this channel just as well as on any other, and that if you
set the envelope period to about 0.3 seconds and the pitch step to 1
or -1 it went something like "Eee Aah Aaw p p PSSHH Psshh psshh p p"
repeatedly.

The Beeb did have an advantage with its envelope command, but that could be
done in software on the 128K speccy (see some file or other on nvg :-) )
and explosions are easier on the AY because you can vary the noise quality
without having to mess with a tone channel.

Ian Collier - imc@comlab.ox.ac.uk - WWW Home Page (including Spectrum section):
http://www.comlab.ox.ac.uk/oucl/users/ian.collier/index.html


----

Xref: vanilla comp.sys.sinclair:4249
Path: vanilla!asbach!noris.net!blackbush.xlink.net!sol.ctr.columbia.edu!news.columbia.edu!lamont.ldeo.columbia.edu!zombie.ncsc.mil!news.mathworks.com!newsfeed.internetmci.com!usenet.eel.ufl.edu!warwick!lyra.csx.cam.ac.uk!news.ox.ac.uk!news
From: imc@ecs.ox.ac.uk (Ian Collier)
Newsgroups: comp.sys.amstrad.8bit,comp.sys.sinclair
Subject: Re: AY-3-819x PSG sound generation
Date: 19 Jun 1996 13:52:47 GMT
Organization: Oxford University Computing Laboratory
Lines: 25
Message-ID: <8580.imc@comlab.ox.ac.uk>
References: <4p12ck$hqo@lyra.csx.cam.ac.uk> <8541.imc@comlab.ox.ac.uk> <8562.imc@comlab.ox.ac.uk> <8563.imc@comlab.ox.ac.uk>
NNTP-Posting-Host: boothp2.ecs.ox.ac.uk
X-Local-Date: Wednesday, 19th June 1996 at 2:52pm BST

In article <8563.imc@comlab.ox.ac.uk>, imc@ecs.ox.ac.uk (that's me) wrote:
>>    The AY has 16 internal registers.  A register is selected by OUTing the
>>    register number in bits 0-3 to port #FFFD (only A15, A14 and A1 are
>>    decoded).

>Ho hum, more checking for me to do this evening. :-)  This may or may not be
>different on the +3 than on the 128K.

It's the same.  Only A15, A14 and A1 count.

>>                          On the AY-3-8912, when R7 bit 7 is reset, R15
>>    always reads 255.  Writing to R14 or R15 when they are selected for
>>    input does load the output register.

>Another thing for me to check.  I didn't check what happens if you write R14
>then change R7 and read it back.

The deal is: if you write a value to the register, it is stored.  If you
read it back when R7=255 then you get the same value back, modified by the
inputs in the top four bits; if R7=63 then you get 255.  Apart from that it
doesn't matter what the value of R7 is at the time, nor does it matter if
you flip it back and forth between writing and reading the value.

>Ian Collier - imc@comlab.ox.ac.uk - WWW Home Page (including Spectrum section):
>http://www.comlab.ox.ac.uk/oucl/users/ian.collier/index.html


----

Xref: vanilla comp.sys.sinclair:4281
Path: vanilla!asbach!noris.net!blackbush.xlink.net!sol.ctr.columbia.edu!news.uoregon.edu!vixen.cso.uiuc.edu!newsfeed.internetmci.com!news.ac.net!news.cais.net!xara.net!agate.xara.net!usenet2.news.uk.psi.net!uknet!usenet1.news.uk.psi.net!uknet!uknet!lyra.csx.cam.ac.uk!news.ox.ac.uk!news
From: imc@ecs.ox.ac.uk (Ian Collier)
Newsgroups: comp.sys.amstrad.8bit,comp.sys.sinclair
Subject: Re: AY-3-819x PSG sound generation
Date: 20 Jun 1996 14:30:40 GMT
Organization: Oxford University Computing Laboratory
Lines: 61
Message-ID: <8587.imc@comlab.ox.ac.uk>
References: <4p12ck$hqo@lyra.csx.cam.ac.uk> <4q69k5$es5@lyra.csx.cam.ac.uk> <8566.imc@comlab.ox.ac.uk> <4q8pc4$64a@info.service.rug.nl>
NNTP-Posting-Host: boothp2.ecs.ox.ac.uk
X-Local-Date: Thursday, 20th June 1996 at 3:30pm BST

In article <4q8pc4$64a@info.service.rug.nl>, gerton@PROBLEM_WITH_INEWS_GATEWAY_FILE () wrote:
>Set R0 to 0.  Then in machine code set R1 to 1, then to 15, then wait a
>while, say twenty times longer than the time between setting R1 to 1 and
>setting it to 255, and then repeat the process.

>If we had a down counter ... we'll hear a tone of 29 Hz with a few clicks
>here and there.

>If we have an up counter ... we'll hear a tone of something below 434 Hz,
>together with some hissing, noise, or whatever.

I ran this loop:

        di
  lp:   ld a,1:out (c),a
        ld e,5:dec e:jr nz,-3
        ld a,15:out (c),a
        ld e,99:dec e:jr nz,-3
        xor a:in a,(254)
        cpl:and 31:jr z,lp

(after setting the appropriate registers, selecting register 1 and setting
bc to $fffd) and the output was a steady tone of frequency fairly close to
340 Hz.

This indicates an up-counter but it doesn't prove it beyond doubt because
it might still have a down-counter which gets set to the minimum of the
new value and whatever the counter is now whenever you change R1/R0.  The
up-counter probably uses less silicon though, in which case we can assume
it is true by Occam's razor.  Odd that they did this when they could have
used a much more simple down-counter.

Analysis

Actually I don't know why I put 99 there; it should have been higher for
a ratio of 20:1.  The two parts of the loop take 101 and 1643 Tstates.
Anyway, if we have an up-counter then the tone generator will change phase
during the time that R1 is 1; the chances are that this will be as soon
as R1 changes to 1 given the above 16:1 ratio.

The above loop has a period of 1744 Tstates.  It takes 4096 Tstates for the
up-counter to get to 256 [the sound chip is fed one clock every two Tstates
and the up-counter is incremented every eight clocks], by which time the
loop has gone round twice and is now in the long delay of the third loop
after setting R1 to 15.  So the up-counter continues until R1 is set back
to 1. This whole thing takes three loop periods, or 5232 Tstates.  Thus,
since two transitions makes a full cycle, the period of the tone produced
will be 10464 Tstates, and the frequency of the tone should be: 338.96 Hz.
And I didn't calculate that before stating my result above, honest!

Now, what if we have a "minimum" down-counter?  The counter will be set
to 256 as soon as R1 is set to 1 and it will count down in 4096 Tstates.
Two and a bit loops of the program later, it reaches zero.  R1 now equals
15 and the counter will be set to 4095.  The next time R1 is set to 1 the
counter will be set to 256.  The time elapsed between the two times when
the counter is set to 256 will be three loops of the program.  The result
is exactly the same as for an up-counter except that the transitions are
delayed by 4096 Tstates.

Ian Collier - imc@comlab.ox.ac.uk - WWW Home Page (including Spectrum section):
http://www.comlab.ox.ac.uk/oucl/users/ian.collier/index.html


----

Xref: vanilla comp.sys.sinclair:4277
Path: vanilla!asbach!noris.net!blackbush.xlink.net!sol.ctr.columbia.edu!news.uoregon.edu!vixen.cso.uiuc.edu!howland.reston.ans.net!surfnet.nl!rug.nl!gerton
From: gerton@PROBLEM_WITH_INEWS_GATEWAY_FILE ()
Newsgroups: comp.sys.amstrad.8bit,comp.sys.sinclair
Subject: Re: AY-3-819x PSG sound generation
Followup-To: comp.sys.amstrad.8bit,comp.sys.sinclair
Date: 20 Jun 1996 16:41:31 GMT
Organization: Rijksuniversiteit Groningen
Lines: 79
Message-ID: <4qbuvr$96v@info.service.rug.nl>
References: <4p12ck$hqo@lyra.csx.cam.ac.uk> <4q69k5$es5@lyra.csx.cam.ac.uk> <8566.imc@comlab.ox.ac.uk> <4q8pc4$64a@info.service.rug.nl> <8587.imc@comlab.ox.ac.uk>
NNTP-Posting-Host: ciwi3.math.rug.nl
X-Newsreader: TIN [version 1.2 PL2]

Ian Collier (imc@ecs.ox.ac.uk) wrote:

> I ran this loop:

>         di
>   lp:   ld a,1:out (c),a
>         ld e,5:dec e:jr nz,-3
>         ld a,15:out (c),a
>         ld e,99:dec e:jr nz,-3
>         xor a:in a,(254)
>         cpl:and 31:jr z,lp

> (after setting the appropriate registers, selecting register 1 and setting
> bc to $fffd) and the output was a steady tone of frequency fairly close to
> 340 Hz.

> This indicates an up-counter but it doesn't prove it beyond doubt because
> it might still have a down-counter which gets set to the minimum of the
> new value and whatever the counter is now whenever you change R1/R0.  The
> up-counter probably uses less silicon though, in which case we can assume
> it is true by Occam's razor.  Odd that they did this when they could have
> used a much more simple down-counter.

This is the true setting of Occam's razor.  There is no real satisfactory
argument why Nature would not be uneconomic sometimes; it's just that bad
theories produce more rubbish to account for on top of what Nature has
produced itself.  But for man-made things, usually one tries to get
functionality against as little cost as possible, so Occam's razor applies
directly, if we assume reasonable intelligence at the other side.

Okay, end-of-useless-philosophical-blabla.

There is also a way to distinguish up-counting + bound checking and
down-counting + reset to minimum when R1R0 gets changed.

	Set R0 to 255
label:	Set R1 to 15
	Wait for 256 AY-clocks to have passed
	Set R1 to 14
	Wait for the same period
	...
	Set R1 to 0
	Wait again, and go to label

Down-counting gives a steady tone of, what is it, 27 Hz, while up-counting
gives pulses of 8*256, 4*256, 2*256, 256, 256 clocks, which should sound
like a tone of, whatisit, 27*16 Hz, together with some components a few
octaves lower.  Have to do some careful thinking what happens if the
period between OUTs is not exactly right, but things will not change
spectacularly.

(Erm.  Another spurious thought.  I bought a CD a couple of days ago,
with an old recording, made in Moscow, of Glenn Gould, famous Canadese
pianist.  When he played loud, he sounded distorted, but when he played
softly, it was okay (except for continual hissing sound, but that was not
too annoying).  I thought that as I now have a very good and long CD 
recording of a distorted wave form, maybe I can find out what the functional
dependence of the output is given the input.  Probably the 'distortion 
function' is fixed in time.  It may well depend however not only on the
'value' of the input, but also on a few derivatives.  It will be very 
nonlinear too, for sure.

But how to find it?  I'm looking for a mapping f -> g such that g is
my CD waveform, -> is some nonlinear mapping, and f is a waveform such
that **most of the energy is in the lower freqency bands**.  A nonlinear
distortion always moves energy to higher harmonics, if you average over
time.  The -> for which f has most energy in lowest bands is the
undistorted sound.

So that's the link between Occam's razor.  The mapping is the theory,
g is what we observe, and f is the explanation in simplest terms.

Admittedly a bit far-fetched, but still nice I think...

Sorry to bother you with this... :-)  )



gerton@math.rug.nl


----

Xref: vanilla comp.sys.sinclair:4290
Path: vanilla!asbach!noris.net!blackbush.xlink.net!tank.news.pipex.net!pipex!oleane!jussieu.fr!math.ohio-state.edu!howland.reston.ans.net!nntp.coast.net!news.kei.com!newsfeed.internetmci.com!in2.uu.net!newsflash.concordia.ca!newsfeed.pitt.edu!dsinc!netnews.upenn.edu!news.voicenet.com!news2.noc.netcom.net!noc.netcom.net!netcom.net.uk!dispatch.news.demon.net!demon!sunsite.doc.ic.ac.uk!yama.mcc.ac.uk!daresbury!lyra.csx.cam.ac.uk!news.ox.ac.uk!news
From: imc@ecs.ox.ac.uk (Ian Collier)
Newsgroups: comp.sys.amstrad.8bit,comp.sys.sinclair
Subject: Re: AY-3-819x PSG sound generation
Date: 21 Jun 1996 13:47:23 GMT
Organization: Oxford University Computing Laboratory
Lines: 20
Message-ID: <8595.imc@comlab.ox.ac.uk>
References: <4p12ck$hqo@lyra.csx.cam.ac.uk> <4q8pc4$64a@info.service.rug.nl> <8587.imc@comlab.ox.ac.uk> <4qbuvr$96v@info.service.rug.nl>
NNTP-Posting-Host: boothp2.ecs.ox.ac.uk
X-Local-Date: Friday, 21th June 1996 at 2:47pm BST

In article <4qbuvr$96v@info.service.rug.nl>, gerton@PROBLEM_WITH_INEWS_GATEWAY_FILE () wrote:
>There is also a way to distinguish up-counting + bound checking and
>down-counting + reset to minimum when R1R0 gets changed.

>	Set R0 to 255
>label:	Set R1 to 15
>	Wait for 256 AY-clocks to have passed
>	Set R1 to 14
>	Wait for the same period
>	...
>	Set R1 to 0
>	Wait again, and go to label

I did this, except I started from 7 instead of 15.  The result was a steady
but rather harsh tone at about 108 Hz, so it must be up-counting.

I didn't understand the bit about the CD, by the way...

Ian Collier - imc@comlab.ox.ac.uk - WWW Home Page (including Spectrum section):
http://www.comlab.ox.ac.uk/oucl/users/ian.collier/index.html