I need a tutorial, I can't find one.

Gameboy Color Programming (GBDK)

Posted 22 January 2006 - 10:06 AM

I have already programmed for the Gameboy Advance.

Now I want to go old-school style and program for the Gameboy Color using the GBDK compiler I already have.

What I need is a good tutorial to get myself started. I would also like to know where a good memory map (Every hardware address and what bits to set or read) is. (Where ROM/RAM is located and such). And if anybody can find a tutorial that shows you how to program for the battery-back up save file thing it would be cool.

Re: Gameboy Color Programming (GBDK)

Posted 23 January 2006 - 09:57 PM

Sorry, none of the links there for the good tutorials work.

Actually, a map of every hardware register and a quick info guide on how to program for the battery backup save system is all I need. A memory map of RAM and ROM will be useful. I've already got a sound register tutorial.

I can piece it together from there if ANYBODY can get me links to those things.

And a sound programming FAQ, the URL doesn't work anymore so I have to post it:
[code]
<div class="moz-text-flowed" style="font-family: -moz-fixed">Nintendo(TM) Gameboy sound system (PAPU) guide, v0.99.20 (1/01/2004)
Written by Jonathan Gevaryahu, with help from many, many others.
lord_nightmare at users d0t sourceforge d0t net
I can also be found on Freenode #gnuboy or EFnet #gameboy and #gbdev
(This document is written in the same style/context as Brad Taylor's very
useful NESSOUND.txt; If you found NESSOUND.txt useful for NES work, I hope
you
find this just as useful for Gameboy work)

The latest version of this document can (hopefully) always be obtained from:
http://www.netaxs.com/~gevaryah/GBSOUND.txt
and from Joshua's mirror at:
http://www.joshuawise.com/~nightmare/GBSOUND.txt
and sometime soon, from the devrs.com mirror at:
http://www.devrs.com/gb/files/GBSOUND.txt

All results were obtained by studying prior information available, mainly
the
(in)famous Pan Docs, additional info added to the pan docs by Martin Korth
of
NO$GMB fame, info from some of Jeff Frohwein's various tests, and from
information derived from my own experimentation.
Anything UNVERIFIED is an educated guess based on prior knowledge.

also, as Brad Taylor said so well:
"A special thanks goes out to Matthew Conte, for his expertise on
pseudo-random number generation (amoung other things), which allowed for the
full reverse engineering of the NES's noise channel to take place. Without
his help, I would still be trying to find a needle in a haystack, as far as
the noise's method of pseudo-random number generation goes..."
This applies here as well, since the Gameboy's PRNG is very similar to the
NES'

ANYHOW...

/------------------\
< **Introduction** >
\------------------/

The DMG-CPU/GBC-CPU/SGB-CPU (sometimes referred to as the GB-Z80 due to it's
similarity with the Z80 microprocessor) has, internally, 4 semi-analog sound
channels. These can be output in a conditional (on or off) fashion to one or
both of the Gameboy's output terminals, achieving a pseudo-stereo effect.
The sound sometimes referred to as a PAPU, or Pseudo-Audio-Processing-Unit,
Pseudo because it isn't actually a separate unit. However, from a
programming
standpoint, for all intents and purposes it is a separate circuit from the
main
processor.
I'll go into as deep detail as I can when explaining the inner workings of
this
PAPU.

/---------------------\
< **Channel Details** >
\---------------------/
Each one of the four channels is different in it's own way:

The addresses through which the sound channels can be accessed are:
$Addresses: (Description), (Register shorthand)
$FF10 -- $FF14: Channel 1, Referred to as NR10-NR14
$FF15 is unused, was probably going to be a sweep reg for channel 2
originally
$FF16 -- $FF19: Channel 2, Referred to as NR21-NR24
$FF1A -- $FF1E: Channel 3, Referred to as NR30-NR34
$FF1F is unused, was probably going to be a sweep reg for channel 4
originally
$FF20 -- $FF23: Channel 4, Referred to as NR41-NR44
$FF24 controls the Vin status and volume, Referred to as NR50
$FF25 selects which output each channel goes to, Referred to as NR51
$FF26 is the status register, and also controls the sound circuit's power.
Referred to as NR52
$FF27 -- $FF2F are unused.
$FF30 -- $FF3F is the load register space for the 4-bit samples for channel
3

PARTIALLY VERIFIED: All registers are read/writable except for the
initialize
flags for each channel, and $FF30-$FF3F, which is read/writable, but is
scrambled slightly once channel 3 is played with new data written there.
The low 4 bits of $FF26 have no effect whatsoever if written to, as they are
status flags.

Writing a 0 to bit position 7 in register $FF26(NR52) disables the power to
the
audio processing unit, which can give a 15-20% increase in battery life if
used
properly. see note on power consumption for details.

PARTIALLY VERIFIED: Any writes to any register while the audio processing
unit
is OFF have NO EFFECT WHATSOEVER, with the exception of the $FF30-$FF3F
range.

PARTIALLY VERIFIED: Any writes to any unused bits in any register are
RETAINED
as long as the APU isn't powered off, so they can be theoretically used for
temporary storage by programs. I have yet to see a program which DOES this,
but
it is quite doable!

My writing a test ROM to dump the entire audio range's initial state to SRAM
memory revealed a few mistakes in versions prior to 99.20 of this document,
so
CHECK EVERYTHING AGAIN CAREFULLY!

Each channel has 5 registers associated with it, and, like the NES, they are
in
sets:

IMPORTANT NOTE ON POWER CONSUMPTION!!!
Writing a 0 to bit position 7 in register $FF26(NR52) disables the power to
the
audio processing unit, which can give a 15-20% increase in battery life if
used
properly. When the PAPU is disabled, all registers in the range $FF10-$FF2F
are
unreadable and unwritable except for register $FF26(NR52). When the power is
disabled, all register values, hidden or accessible, are lost, except for
both
the hidden internal and regular $FF30-FF3F wave pattern memory area. Reading
from $FF26(NR52) while the audio processing unit is disabled will yield the
values last written into the unused bits (0x70), all other bits are 0.
A good way to use this in your game is to disable the audio unit during any
time where there will be no sound playing for an extended period (when
paused
for instance), or where there will be long gaps between any sounds played.
Note that turning on or off the audio unit results in an audible CLICK noise
over the SOx output lines (AKA the stereo channels). The volume of the click
can be reduced considerably by turning both of the output master volume
controls to zero before turning off the sound core, but practically all
games
don't bother doing this, as the click is almost unnoticable among other
sounds.

VERIFIED on DMG, SGB, and CGB: Values marked 'No Change' are reset to 0xFF
upon
a system reset or power-cycle.

On the DMG/GBP/CGB, the value of $FF26(NR52) is 0xF_1_ due to the fact that
channel 1 is on-but-faded-out, due to the two-toned 'Gameboy startup sound'.
On the SGB/SGB2, however, there IS no internally-created startup noise, and
so
the initial value is 0xF_0_, and channel 1 is off.

/--------------------------\
< **Channel Architecture** >
\--------------------------/
Here, I will try to describe the inner workings of the channels in as much
detail as I can manage. Please note that a few of the points are not
completely
tested and/or understood (particularly the zombie state increment stuff, see
'volume/envelope control unit')

IMPORTANT NOTE!: Lacking an oscilloscope, I'm making a LOT of guesses about
the
specifics (counters, etc), somewhat based on the fact that the NES and
Gameboy
sound units are very very similar, and somewhat by experimental results.
I can pretty much promise that by version 1.0 of this doc, if I ever get
that
far, I will have 100% completely verified info.

/--------------------\
< Programmable timer >
\--------------------/
The programmable timer is an 11-bit presettable down counter, with
reloading-
upon-0. It is found in the two squarewave channels and the voluntary wave
channel. Some permutation of it may exist on the noise channel also, but for
all intents and purposes it doesn't exist there.

The 11-bit frequency value, upon either part being written, is
binary-inverted
(NOT), and the resulting number plus one is placed into the 11-bit counter.
Another possibility is that the 11-bit frequency is subtracted from 2048,
the
result being written into the counter. (either way, the result is the same)

Attempting to read the contents of these registers will yield a null result
(either all 0's or all 1's, I haven't checked yet)

The counter has 'syncronous reloading upon terminal count', meaning that it
will count for N clock cycles before arriving at 0 (the 'terminal count', at
which the counter's TC line is raised), and then be reloaded, taking an
additional cycle, and resume counting). This counter is clocked by the
output
of a 5-bit count-0-to-31-and-loop timer/divider, which itself is clocked by
the
gameboy's standard CPU clock input, 4.194304mhz.
[the pitch doesn't double when in the CGB's doublespeed mode, because
doublespeed mode only makes the *processor* clock on both the rising and
falling edges of the clock signal, which stays constant at 4.194304mhz.]

This makes the output frequency work like this as compared to the 11-bit
freq:

The Terminal Count line is also connected to either the duty cycle
generator,
the wave pattern playback unit, or the pseudorandom number generator's
trigger,
depending on the channel.

NOTE: Channel 1's sweep unit will scramble its counter's contents during a
sweep, and will necessitate a fresh write of the frequency values. (see
sweep
unit)

/--------------------\
< Configurable Timer >
\--------------------/
The configurable timer is the noise channel (channel 4)'s equivalent of a
programmable frequency timer. It is controlled by register $FF22(NR43), and
consists of a customized 3-bit down counter, a 16-bit long down counter with
reload-on-0 and only 1 initially-settable bit. The 3-bit down counter's
initial/reload setting is determined by the setting of the frequency divide
ratio.

The down counter is clocked at 2097152 hz, divided from the processor's
4.194304Mhz frequency. The counter counts down until 0, and spends 1 clock
cycle reloading the initial value from the freq divide ratio. When it
reloads,
it inverts the status of its output line.

The terminal count/output of the counter is the clock input to the shift
clock.

The shift clock is a 16-bit long down counter which can have any single bit
in
it set as the initial/reload value, the position of that bit being read from
the shift clock frequency register.
UNVERIFIED: Reloading of the value is instantaneous.

/----------------\
< Length Counter >
\----------------/
The Gameboy's audio channels each feature a length counter, a conditionally
clocked down counter. There are two types of length counters used in the
Gameboy's PAPU: the 5-bit ones used on channels 1, 2, and 4, and the 8-bit
one
used on channel 3. The clock source for each counter is described below.

Values can be loaded into the length counters for each channel using the
following registers:

The 5-bit value is binary-inverted (NOT) upon a register write, 1 is added
to
the result, and the resulting value is written to the counter. Another
possibility is that the 5-bit length value is subtracted from 64, the result
being written to the counter. (either way, the result is the same)

These length counters are clocked at a rate of 1 count every 1/256th of a
second, taken directly from the unified length clock (256hz, see below).
Therefore: length in seconds = (64 - [length]) * (1/256)

NOTE: In versions of this document prior to 99.18, I had the length counter
clock for channels 1,2,4 being clocked once every 1/64th of a second.
Subsequent testing proved that this was incorrect. Thanks to beware for
asking
me to check it.

The 8-bit value is binary-inverted (NOT) upon a register write, 1 is added
to
the result, and the resulting value is written to the counter. Another
possibility is that the 8-bit length value is subtracted from 256, the
result
being written to the counter. (either way, the result is the same)

This length counter is also clocked at a rate of 1 count every 1/256th of a
second, taken directly from the unified length clock (256hz, see below).
Therefore: length in seconds = (256 - [length]) * (1/256)

Writing a value to a length counter will IMMEDIATELY start the counter
counting
down, regardless of the channel's current on/off state! This will happen ANY
time that the length counter enable bit is on during a write. Several games,
notably 'Mega Man 2' and 'Balloon Kid' prove this.

NOTE: The length counters are NEVER reloaded to their last written value!
They
must be reloaded by hand EVERY TIME, as the values written are destroyed
during
the countdown itself! However, Initializing the channel (setting bit 7 of
$FF14, $FF19, $FF1E, $FF23) when the counter is already at zero will cause a
maximum-length-possible-for-the-channel playback! Be careful!

VERIFIED: If the counter is written to while the length counter enable bit
(see
below) is OFF, the value will remain intact until the enable bit is turned
on.
This is regardless of whether the channel is INITed then, although I'm
fairly
sure it was intended that one would start the counter and the channel during
the same PAPU write.

The clocking of the counter is enabled or disabled depending on the status
of
the 'length counter enable register' (AKA the 'consecutive' bit) in register
set 5, a 1 enabling the counter, a 0 disabling it.

The real-time status for the length counter of a given channel can be
attained
by reading register $FF26(NR52). a 1 indicates that the length counter is
non-0, or that the consecutive/length counter enable bit is 0; 0 indicates
that
the length counter is 0, and subsequently that channel is off.

/----------------------\
< Unified Length Clock >
\----------------------/
This is a recent discovery, pointed out to me by beware(of bgb fame). It is
a
single clock, running at 256hz, probably divided directly from the GB
processor's clock (4.194304Mhz). It is used to clock the length counters of
each channel, when the length counter enable bit (see above) for that
particular channel is on. It is common to all channels, so when it clocks
for
one channel it clocks all of them.

UNVERIFIED: It may also be used, after being divided by 2, to clock the
128hz
sweep clock. The last test I did was inconclusive, probably due to some
mistake
I made during testing.

/-----------\
< 4-bit DAC >
\-----------/
This is a plain-old vanilla linear 4-bit DAC, 16 steps of output voltage.
All
of the sound channels use them for output.

The Volume/Envelope control unit is a simple volume control which can also
do
fade-ins and fade-outs at a configurable rate. The channel volume level is
controlled by a 4-bit delta counter (which can be incremented or decremented
by
1) with an overflow/underflow line. The 1-bit input from the duty cycle
generator or PRNG is multiplied by 15, and binary AND'ed against the volume
control (effectively multiplied by the volume control). Modifications to the
volume control take effect upon the next channel INIT, and if the channel
was
on (length counter status was non-0, and master volume control switch was
on;
see below), then it will trigger a 'zombie mode' volume change (see below).

The volume sweep section consists of a 3-bit down counter(hereafter referred
to
as the 'step length counter') with switchable reload-upon-0, whose initial
value is loaded from the sweep rate value on channel INIT.

The terminal count (value=0) line of this counter is output to a 1-of-2
selector. This 1-of-2 selector is used to select an upward or downward
volume
sweep, getting the direction from the Volume/envelope register on channel
INIT.

if the direction is 0, the counter outputs its signal through the selector
into
the decrease (-) delta terminal of the volume counter. If the direction is
1,
the counter outputs its signal through the selector into the increase (+)
delta
terminal of the volume counter.

SPECULATION: The volume counter itself has an overflow/underflow line, which
is
connected to a switch that prevents the step length counter from reloading
its
original value when it reaches 0. When this occurs, the terminal count line
of
the step length counter is ON steadily, and unless the channel's length
counter
is enabled (and will shut the channel off), the channel enters 'zombie
mode'.

ZOMBIE MODE: UNDEAD CHANNELS!
The channel's volume is now whatever it was set to, or 0/15 if a sweep
occured,
and will sustain that volume indefinitely unless the length counter halts
the
channel. If any envelope register bits are now changed, the volume of the
channel will increase by 1 or 2, looping around to 0 if necessary. (1 if the
channel was INIT-ed with the sweep step number set to 0, 2 if otherwise;
also 2 if the step number has been changed to a non-zero value since the
INIT,
even if it currently is 0)

If the volume sweep direction bit is changed, however, the volume of the
channel will increase by 4 instead of 2, for that write only. Direction of
the
change(1->0 or 0->1) is apparently irrelevant. While in zombie mode, if the
step length register is set to 0, it will have no immediate effect other
than
increasing the volume by 2 (or 4 if the direction was also changed). (but it
WILL change the step size to 1 if the channel is then re-INITed, see above)
Setting the (Initial) Volume to 0 will disable the channel's master channel
control switch, and silence the channel (see below, 'master channel control
switch').

Re-INITing the channel will pull it out of zombie mode: it will turn
envelope
sweeping back on, unless the volume is 0, in which case the master volume
control switch will be off.

/-------------------------------\
< Master Channel Control Switch >
\-------------------------------/
The master channel control switch, which appears at first glance to be
unique
to channel 3, is actually not exclusive to that channel. It is present in
all
of the channels, but is embedded within the Initial Volume control, on the
channels which have an Envelope Control unit (channels 1, 2, and 4).

As mentioned above in the 'Volume/Envelope Control Unit' section, when a
downward envelope sweep occurs, the channel is NOT shut off when the volume
reaches 0. HOWEVER, writing a 0 to the (Initial) Volume section of the
envelope
register will cause that channel's 'hidden' master channel control switch to
be
turned off. This ONLY occurs if 0 is *WRITTEN* to the register, and only if
the
master channel control switch is not already off(it can't be turned off
twice!)
If the switch is off, it can be turned back on by writing any non-0 value to
the (Initial) Volume section of the register.

UNVERIFIED, PLEASE TAKE WITH A GRAIN OF SALT: When the switch for a channel
is
off, it's length counter status flag will be 0. In fact, this may very well
be
the switch turned off by the length counter too.

The switch causes a slight residual DC voltage to be output to the SOx
switches, even if the channel's DAC output is at 0. It makes an audible
click
noise on the speaker/headphones when switched.

At system startup, channel 1's switch is on (turned on by the bootstrap
rom),
all other channels are off.

/----------------------\
< Frequency Sweep Unit >
\----------------------/
The sweep unit is exclusive to channel 1. The controlling register for the
sweep unit is $FF10(NR10). The sweep unit, on channel INIT, grabs the the 11
bits of channel 1's frequency register, and stores them into a hidden,
internal
register. any writes to the frequency registers during the sweep, will take
effect until the sweep unit makes its next write to those registers,
continuing
the original sweep. IT WILL NOT SWEEP FROM THE NEW FREQUENCY! The sweep unit
has the aforementioned hidden frequency register (an 11-bit accumulator), an
adder, a 3-bit down counter with reload-on-0, a selector switch, and an
up-to-3-bit rightshifter.

The 3-bit down counter controls the frequency of sweep updates. It's initial
(and reload) value is taken from the sweep time register. The value-reload
takes 1 clock cycle.

NOTE: Writing 0 to the Sweep RtShift amount disables sweeping. While the
RtShift amount is 0, the sweep time register becomes sort of a length
counter,
and the channel will automatically terminate on it clocking.

NOTE2: When set to sweep upward, the channel will do absolutely nothing on
INIT
unless the current frequency is below the 'sweep threshhold' for that
particular rightshift amount.

The reason for this is because otherwise the channel's NEXT step would
IMMEDIATELY overflow the 11-bit frequency counter.
(frequencies immediately below the threshholds will only play one note,
since
the second step wouldn't overflow, but the third step would, and so only the
first step is played. The sweep unit always works one step ahead of the
current
output, and on the next step outputs that result and calculates the next,
etc.)

The above table is actually unnecessary, I'm just leaving it in as a
reference.

The game 'Metroid 2' runs into this issue in a few places, apparently the
programmers didn't know about the above info. Also, the knife-throwing
monsters
in 'Wario Land: Super Mario Land 3' run into the issue, but there it is
intentionally used to prevent their 'voices' from going too high.

Upon reaching the terminal count (value=0), the counter sends a signal to a
selector, which controls what direction the sweep will be by controlling the
sign bit of the accumulator.

The adder then takes the accumulator, and adds that value to the 11-bit
frequency value stored in registers $FF13 and $FF14. Therefore, because the
registers are modified, the frequency must be rewritten in-between sweeps.

/----------------------\
< Duty Cycle Generator >
\----------------------/
The duty cycle generator is a 3-bit (down?) counter which produces output
depending on the result of some binary operations against the bits of the
counter, the operations selectable by changing the duty cycle bits in
register.

Note that 75% is just a binary NOT against 25%, and that the two are almost
indistinguishable to the human ear.

The duty cycle generator is clocked by the output of the frequency counter
for
channels 1 and 2.

Upon the channel INIT trigger bit being set for either channel 1
or 2, the wave position's incrementing will be delayed by 1/12 of a full
cycle.
IT WILL *NOT* BE RESET TO 0 BY A CHANNEL INIT. 'Gauntlet II' does a very
slick
job of timing? itself around this fact.

Upon system reset, channel 1 will be set to the 50% duty cycle wave, channel
2
to the 12.5% duty cycle wave. (see initial register values)

COMPLETELY UNVERIFIED: In a recent update to NESSOUND.txt, Brad Taylor
demonstrated that the way to reset the position of the two squarewave
channels
on the NES to position 0 is by resetting the timer register. The equivalent
register on the gameboy is PROBABLY the $FF04 (DIV) register, though it
could
also be $FF05 - $FF07 (Timer stuff). This may turn out to be the mysterious
'slick' way that Gauntlet II can 'reset' the position of the squarewave
channels.

PARTIALLY VERIFIED:
The CGB has channels 1 and 2 output in such a way (normal phase reversed on
channel 2 from channel 1) that the two squarewave channels can cancel each
other out completely instead of adding to each other, as on the DMG, MGB,
and
SGB.
I think that one of the reasons Nintendo did this on the CGB was to mess up
the
startup theme of the Galoob 'Game Genie', which is practically inaudible on
the
CGB for this reason! Another, more likely reason could be that they used
some
silicon-saving technique on the duty cycle generators which necessitated
opposite phase on the two squarewave channels.
This is noticible in quite a few official Nintendo-approved games, but the
game
which demonstrates it particularly vividly is "Lock n' Chase". It sounds
absoluetly HORRIBLE on a CGB!

/-------------------------------\
< PseudoRandom Number Generator >
\-------------------------------/
The noise channel has a 1-bit pseudo-random number generator, or PRNG. This
particular type of PRNG is called an LFSR, a Linear Feedback Shift Register.
It's based on a 15 or 7-bit shift register, and an exclusive OR gate (XOR).
The
mode is selectable by the Shift register width selector.

X- N/A
%- output and XOR tap
*- XOR tap
R- result of XOR, to be shifted in

The current result of the XOR will be transferred into bit position 0 of the
shift register upon the next shift cycle. The 1-bit 'random' output is taken
from the output, is inverted, then is sent to the volume/envelope hardware
for
the noise channel.

VERIFIED: Upon the channel INIT trigger bit being set for this channel (4),
the PRNG will be reloaded with a value of 0xFF. (Kirby 2)
NOTE: There will be a 16-clock delay before the PRNG outputs any non-0 data
after an INIT. This means the value loaded on channel INIT isn't 0x01 as
previously written here, but is 0xFF. this will cause the channel to have a
value of 0x01 16 clocks later. Again, thanks to beware for pointing this
out.

On system reset, this shift register is loaded with a value of 1.

/---------------------\
< Wave Pattern Memory >
\---------------------/
This is the 16-byte long 'hidden' internal memory area (hereafter referred
to
as 'wave pattern memory'), containing the 32 4-bit samples for channel 3. It
can be written to by writing the 16-byte sample data into the wave pattern
load
register.

Setting the 'init' bit [bit 7] in $FF1E to 1 will slightly scramble the
contents at location $FF30-$FF3F, but the wave pattern memory will retain
the
proper values.
This area cannot be written to while channel 3's master control switch is
on.
UNVERIFIED: If it IS written to when the control is on, the written values
will
be ignored.
Sample playback is possible using this register, by turning off the switch
and
writing the next 16 4-bit samples, and turning it back on. However, doing
this
will create some click-distortion from the switch itself (especially on
DMGs),
and the first sample immediately after the switch is turned back on will be
replaced (due to capacitance somewhere or possibly a pointer pointing
somewhere
unexpected) by the last COMPLETELY played back (partially played doesn't
count)
sample before the switch was shut off. (Thanks Jeff Frohwein for a nice
image
demonstrating this)

UNVERIFIED: The 1-sample error is carried over to successive loops of the
wave pattern data.

On system power-on of the DMG (and MGB???), the internal area isn't loaded
with any particular value, however due to some unusual properties of the
memory
in question, the values present will almost always be roughly the same.
The game "R-Type", due to a programming error, doesn't load this area with
anything, and therefore the initial value is played. When "R-Type" was
re-released for the GBC in "R-Type DX", Irem made a very good approximation
of
the DMG's initial Wave pattern memory values. Those values are:
0xac, 0xdd, 0xda, 0x48, 0x36, 0x02, 0xcf, 0x16,
0x2c, 0x04, 0xe5, 0x2c, 0xac, 0xdd, 0xda, 0x48

However on actual DMG hardware, the values are pretty much completely
random,
in a pattern unique to each Gameboy unit. By this I mean that, on a
particular
Gameboy, bits which start as 1 almost always start as 1, and bits which
start
as 0 almost always start as 0. There IS some variation, but the values are
roughly the same every time. It is sort of a 'Gameboy fingerprint'.

One can easily see that though no two dumps are the same, they follow a
general
pattern, which seems to be unique to each Gameboy unit.

/--------------------------------------\
< Wave Pattern Playback / Shifter Unit >
\--------------------------------------/
This is effectively a 5-bit counter, which acts as a pointer to the current
4-bit sample in the 16-byte, 32-sample wave pattern memory. Every clock from
the programmable timer will cause a 4-bit sample (the wavepattern's
[high-4-bits-of-counter]st byte's high or low 4 bits [depending on whether
the
counter's low bit is 0 or 1, respectively]) to be sent to the volume shifter
unit. The volume shifter unit, depending on it's register, will output
either
0, the 4-bit sample, or the sample rightshifted by 1 or 2. This 4-bit result
is
then sent to the DAC.