D.C.Halliday@newcastle.ac.uk (John Robert Reed) (02/13/91)
I notice that alot of people have been clammering for information on the
STe recently. Some time ago a Mathew Lodge of ST world (UK mag) wrote
the following. This information has appeared here before in 3 parts and
has been published by various people in various magazines.
It should be noted that you should not hold this information to be
gosble and if you wan't to be sure of correct information get the
Developers kit. So if there are any errors don't blame Atari or Mathew
lodge but yourself.
Now there is no excuse for not writing STe specific SW so how about some
nice Demos.
Dave Halliday
(D.C.Halliday@newcastle.ac.uk)
---------------- Mathew Lodge's Original Posts Follow -------------
OK, here is the documentation for STE DMA sound output. More documentation
when I've typed it in. Screen blanker postings when I've got a copy of uuencode
... please be patient
----------------------- cut here ----------------------------------
Information from "Atari STE Developer Information Addendum"
STE DMA Sound registers
Register Access Description
FF8900 R/W 00 - sound disabled (reset state)
01 - sound enabled, disable at end of frame
11 - sound enabled, repeat forever
FF8902 R/W Frame base address (high)
FF8904 R/W Frame base address (middle)
FF8906 R/W Frame base address (low)
FF8908 RO Frame address counter (high)
FF890A RO Frame address counter (middle)
FF890C RO Frame address counter (low)
FF890E R/W Frame end address (high)
FF8910 R/W Frame end address (middle)
FF8912 R/W Frame end address (low)
FF8920 R/W Sound mode control:
xxxx xxxx m000 00rr
Where for m:
0 Stereo mode
1 Monophonic mode
Where for rr:
00 6258 Hz sample rate (reset state)
01 12517 Hz sample rate
10 25033 Hz sample rate
11 50066 Hz sample rate
FF8922 R/W MICROWIRE data register
FF8924 R/W MICROWIRE mask register
Volume/controller commands (device address is always 10)
--------------------------------------------------------
011 DDD DDD Set master volume
000 000 -80 dB
010 100 -40 dB
101 XXX 0 dB
101 xDD DDD Set left channel volume
00 000 -40 dB
01 010 -20 dB
10 1xx 0 dB
100 xDD DDD Set right channel volume
00 000 -40 dB
01 010 -20 dB
10 1xx 0 dB
010 xxD DDD Set treble
0 000 -12 dB
0 110 0 dB
1 100 +12 dB
001 xxD DDD Set bass
0 000 -12 dB
0 110 0 dB
1 100 +12 dB
000 xxx xDD Set mix
00 -12 dB
01 Mix GI sound output (ST sound chip)
10 Do not mix GI sound output
11 Reserved
----------------------------------------------------------
Sampled sound data is stored in memory as a series of bytes, which
represent a speaker displacement from -128 to +127. Zero represents the
neutral or middle speaker position. Playback is programmable at one of
four rates : 50kHz, 25kHz, 12.5kHz or 6.25kHz.
During the horizontal blanking phase, samples are fetched from memory by
the DMA sound chip, and fed into a Digital to Analogue Converter (DAC).
The output of the DAC is then filtered by a four-pole low pass filter to
a frequency equal to around 40% of the sample frequency. The signal then
passes through a two pole 16kHz low-pass filter, and fed into the
National Semiconductor Volume/Tone controller (LMC1992). The final
output is available from the RCA jacks on the back of the STE, which can
be fed into an amplifier and hence to speakers, headphones etc.
Both stereo and mono sample replay is provided, but both stereo channels
are mixed along with the ST's sound chip output for monitor speaker
output. Sound chip output can also be sent to the stereo output jacks as
well.
In stereo playback mode, the same data is regarded as words, with the
high byte of the word being the sample for the left channel, and the low
byte the right channel sample. In mono mode, each byte is output to both
left and right stereo channels, but data is still fetched one word at a
time. This means that mono sample data must always be an even number of
bytes.
Samples are grouped together in frames. Each frame can be played once,
or repeated automatically forever (until stopped). Two registers are
loaded with the frame start and end address - the end address is
actually the first byte beyond the end of the sample. Thus a 512 byte
sample with a frame start address of 101024 would have a frame end
address of 101536. Table One gives the location and description of each
DMA sound register.
Actually playing a sample is really quite straightforward. Simply
assemble the data in memory, load the start and end addresses, set
stereo or mono mode and the playback frequency. Finally, write a one to
the sound control register, and the sample will play once.
Producing continuous sound and linking frames together are the next
steps, and hardware support is provided for these processes. The DMA
sound chip produces a 'DMA sound active' signal which is connected to
the external input of MFP Timer A. This signal is a one when samples are
being played, and zero otherwise. At the end of a repeated frame, this
line goes from one to zero, and then back to one again. Thus setting
Timer A into event countdown mode allows you to generate an interrupt
when a frame has been played a set number of times.
Frame repetition is seamless - there is no time delay between the end of
a sample, and the start of it's replay, because the frame start and end
registers are double buffered. Writing to these registers actually
places the data into a holding area, and the contents of the holding
area actually go into the true registers when the chip is idle (at the
end of the frame, if one is currently being played).
Thus, if you wanted to play two consecutive frames, you would write the
start and end addresses, and set the control register to three. The
first frame will start playing, and you can immediately write the start
and end addresses of the next frame, without waiting for the first frame
to finish. There will still be an interrupt from Timer A at the end of
the first frame, and you could use that to load the address of a further
frame, and so on.
One further thing to note is that the 'DMA sound active' signal is also
exclusive-ORed with the 'monochrome monitor detect' signal, and fed into
the GPIP I7 input of the MFP. This was provided to enable interrupt
driven sound without using the last free timer of the MFP. It is a
little more difficult to use, since you will get a different signal edge
depending on whether a mono or colour monitor is attached, as well as an
interrupt at the end of every frame.
Monochrome monitors ground the 'mono detect' line, resulting in a zero
when the bit is read from the MFP. Colour monitors don't ground the line
(it is left floating), and the bit reads one. When DMA sound is active,
this situation is inverted (because of the XOR with the 'DMA sound
active line'). TOS actually looks at this bit during vertical blank
time, to see if the monitor has been changed, but TOS on any machine
with the DMA sound chip has been appropriately modified to avoid
problems.
Finally, the 'DMA sound active' line goes from active to idle (one to
zero) after the last sample has been fetched. There is a four-word FIFO
(First In, First Out) buffer inside the chip, so it will be eight sample
times (in stereo mode) before the sound actually finishes. If you do not
reload the frame registers in this time, then the join between samples
will not be seamless.
The volume and tone controller of the STE is connected via a MICROWIRE
bus interface. The idea behind this is that further devices can be added
to the bus in the future. The MICROWIRE bus is a simple three wire
serial connection, with a protocol to allow multiple devices to be
controlled individually.
In the general case, the data stream consists of N address bits,
followed by zero or more don't care bits, and then M bits of data. The
actual hardware interface in the STE consists of two 16 bit read/write
registers, one for the data to be shifted out, and a mask indicating
which bits are valid.
A one in any bit of the mask indicates that the corresponding bit in the
data register is valid. Data transmission starts as soon as the data
register has been written to, so the mask register must be loaded first.
Sending takes approximately sixteen micro-seconds, and if the data
register is read during this time, a 'snap-shot' of the data being
shifted out will be obtained. This means that if you wait for either
register to return to its original state, you can be sure that sending
has been completed.
The volume/tone controller is addressed by a two bit address field of
%10 (binary) and a nine bit data field. Table One details the commands
that can be sent to the device, and the addresses of the MICROWIRE
registers in the STEs memory map. Actually sending these commands is
easier than it looks. Simply set the mask register to $07FF, and place
the data in the lower nine bits with %10 in the upper two bits.
For example, setting the mask to $07FF and the data register to $04C4
will set the master volume to $14. That's all there is to it!
Regards,
Mathew Lodge
***********************************************************************
* c/o Dept. Computer Science * "Baldrick, fetch me a turkey _so *
* University of York * big_, you'd have thought its mother *
* Heslington * had been rodgered by an Omnibus" *
* York, UK * *
* YO1 5DD * JANET : SOCS18@uk.ac.york.vaxa *
***********************************************************************
Video Harware Modifications
===========================
Addr Access Size Use
====== ====== ==== =================================================
FF8204 R/W 6 Video address counter (high)
FF8206 R/W 8 Video address counter (middle)
FF8208 R/W 8 Video address counter (low)
The change here is that these registers are now
read and write, allowing the programmer to
update the video refresh address to any word
boundary _at any time_.
FF820C R/W 8 Video base address (low) (VBASELO) This register
didn't exist on the ST, but on the STE it allows
the positioning of the screen base address on
any _WORD_ boundary
FF820E ?? 8 Line offset (LINEWID) - the number of extra words
added to the address counter at the end of each
line, _MINUS ONE DATA FETCH_. This allows for
virtual screens that are wider than the actual
screen display. Clearing this register means the
STE acts like an ordinary ST.
FF8240 to FF825E Colour palette
There are now four bits for each of the red,
green and blue components. To give backward
compatibility with the ST, the least significant
bit is above the most significant bit. Thus the
register layout is as follows:
xxxx 0321 0321 0321; x=don't care
RED GRN BLUE
FF8264 ?? 4 Horizontal bit-wise scroll (HSCROLL). Allows the
start of each line to be delayed by 0-15 bits,
thus giving instant horizontal scrolling.
Horizontal fine scrolling isn't quite as trivial as it looks. The pixel offset
is loaded into HSCROLL, and the documentation then says the following about
the LINEWID register :
"If you are actively scrolling (HSCROLL<>0), this register should
contain the additional width of the display line _minus one data fetch_
(in low resolution one data fetch would be four words, one word for
monchrome etc.)"
The reason for the extra data fetch becomes clearer if you think about
what is actually happening. If you fine scroll by n bits, then n bits
are effectively missed off the left hand edge of the screen. But to get
a complete line of pixels, n bits must be added to the right hand side
of the screen. This constitues one extra data fetch for the display
processor beyond the usual requirement.
For example, if you had three low resolution pictures side by side in
memory, and you wanted to scroll across them, you would set LINEWID to
160 when HSCROLL=0 (no extra data fetch). When HSCROLL<>0, LINEWID would
be set to 156 (four less due to the extra data fetch done automatically
by the display processor).
Vertical scrolling is trivial - simply set the video address base to the
required address at horizontal blanking time.
That's all folks - for now - more info on the new controller ports soon.
Regards,
Mathew Lodge
***********************************************************************
* c/o Dept. Computer Science * "Baldrick, fetch me a turkey _so *
* University of York * big_, you'd have thought its mother *
* Heslington * had been rodgered by an Omnibus" *
* York, UK * *
* YO1 5DD * JANET : SOCS18@uk.ac.york.vaxa *
***********************************************************************
STE CONTROLLER PORTS
Address Usage Description
=================================================
FF9200 xxxx xxxx xxxx 3210 Fire buttons
FF9202 UDLR UDLR UDLR UDLR Joystick directions
Joy3 Joy2 Joy1 Joy0
FF9210 xxxx xxxx NNNN NNNN Paddle 0 X
FF9212 xxxx xxxx NNNN NNNN Paddle 0 Y
FF9214 xxxx xxxx NNNN NNNN Paddle 1 X
FF9216 xxxx xxxx NNNN NNNN Paddle 1 Y
FF9220 xxxx xxNN NNNN NNNN Light pen/gun X
FF9222 xxxx xxNN NNNN NNNN Light pen/gun Y
Four new joystick ports were added, directly interfaced to the 68000
bus, rather than using another IKBD controller. The table above gives the
locations of the hardware registers for the joysticks, paddles and light
gun/pen inputs. Note that the joystick registers are bidirectional, and
can therefore be written as well as read. If the registers are written,
then the outputs are driven until the registers are read again.
Two paddle controllers can be connected with eight bit resolution on
each axis, and the current position of each of the four paddles are
reported in the registers shown in the table. No information is given in
the data sheets as to the voltage range that the A/D converters function
in, but I would guess that it is 0-5V. The triggers on the paddles are
bits zero and one of $FF9202 (Joystick 0 left and right.)
The light gun/pen position is reported in $FF9220 and $FF9222. The
x-axis accuracy is four pixels in low resolution, eight pixels in medium
res., and sixteen pixels in high resolution. The y-axis position is
accurate to within one pixel in all modes. The x position only ranges
from 0 to 319, and therefore must be left shifted for other screen
modes. Again, no electrical information is provided on how to
implement a light gun/pen.
Regards,
Mathew Lodge
***********************************************************************
* c/o Dept. Computer Science * "Baldrick, fetch me a turkey _so *
* University of York * big_, you'd have thought its mother *
* Heslington * had been rodgered by an Omnibus" *
* York, UK * *
* YO1 5DD * JANET : SOCS18@uk.ac.york.vaxa *
***********************************************************************