ShuriZma
/
BizHawk
mirror of https://github.com/TASEmulators/BizHawk.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
BizHawk/BizHawk.Emulation/Consoles/Atari/docs/TIA_HW_Notes.txt

1118 lines
44 KiB
Plaintext
Raw Blame History

===================================================================
Atari 2600 TIA Hardware Notes
===================================================================
v1.0 6-March-2003
by Andrew Towers
mariofrog@bigpond.com
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+++ TIA Hardware Notes (a Small Opus on the TIA)
Following is a whole bunch of notes on the TIA I made while I
was trying to work out how the whole thing is put together.
You'll need a copy of the TIA schematics to understand the more
complicated bits of this since I was looking at them when I
wrote it. According to my copy they were scanned in by Mark De
Smet. They are now available for download from AtariAge at:
http://www.atariage.com/2600/archives/schematics_tia/index.html
I started out searching through the stella archives for any info
on triggering the players more than once per scanline (at the
time I wanted to draw more than the 12 copies possible by flicker
and 3-repeat) - and I came across Eckhard Stolberg's 'grid2' demo
from Oct 1998, followed by a long series of threads over several
months discussing how the technique actually manages to work =)
From all the articles it looked like a complete black art and
no-one had a theory that would explain it fully.
Then I came across the TIA-1A schematics, and proceeded to spend
the next 3-4 days solid drinking copious amounts of coffee and
taking very little sleep while I tried to figure the whole mess
out from the gate level up. (hey, the 2600 is a new hobby, I can
splurge ;) In the end I found that as usual writing a 'few quick
notes' turned into 'writing a tutorial' or, 'a small opus on the
TIA'. So, here we go.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+++ Polynomial Counters, what the heck is this?
Almost all of the timing and counting within the TIA is implemented
in the form of "polynomial counters", so this seems a good place to
start. If you've never come across these before (I hadn't) they
seem a really obscure way to go about counting things, but they're
very small and simple to implement and therefore cheap on silicon.
They also have the useful property that 'adding 1' takes linear
time (unlike a ripple-carry adder/counter) - as long as you don't
want to know where you're up to in traditional binary numeric form,
they're perfect ;)
Actually, as the TIA designers pointed out, you can use a small
lookup table to convert from one to the other, and you can compare
two counter states to see if you're up to the same count without
knowing the numeric values. But this is getting off track and
hand-wavery. If you want to know the maths behind polynomial
counters I suggest you look elsewhere, I'm no mathematician ;)
These things seem to be used as pseudo-random number generators or
noise generators (see the TIA sound generator, ditto for the GBA)
more than anything else.
A polynomial counter (actually a form of "Linear Feedback Shift
Register") consists of a shift register, as the name suggests,
with some sort of feedback logic - in this case a single two-
input XNOR gate obfuscated in NOR logic. They have the property
that they will step through up to (2^n)-1 unique states when
optimally wired up, from any starting state except for the illegal
state (and of course it's possible to power-up in the illegal
state =) so for a 6-bit shift register there can be at most 63
valid states.
The TIA uses the same polynomial counter circuit for all of its
horizontal counters - there is a HSync counter, two Player
Position and two Missile Position counters, and the Ball Position
counter. The sound generator has a more complex design involving
another polynomial counter or two - I haven't delved into the
workings of this one yet.
Beside each counter there is a two-phase clock generator. This
takes the incoming 3.58 MHz colour clock (CLK) and divides by
4 using a couple of flip-flops. Two AND gates are then used to
generate two independent clock signals thusly:
__ __ __
_| |_________| |_________| |_________ PHASE-1 (H@1)
__ __ __
_______| |_________| |_________| |___ PHASE-2 (H@2)
You'll need a thingo, fixed-spacing font, to make sense of that.
The two clock lines are used to perform a two-step increment
of the counter, as well as being used independently to move
data through the supporting clocked logic.
This concept seems to come up a -lot- in the TIA, I think it's
some sort of Zen NMOS thing, it seems to go hand and hand with
storing data in back of inverters all over the place (a * is used
in the TIA schematics to denote this), and building bit-shifting
chains into your data storage so you don't need addressing ;p
If you've ever wondered why the Playfield bit order is so obscure,
now you know.
Each counter has a wired-AND counter state decode matrix (woo..)
connected in parallel with the shift register. In every case,
the top line of the decoder on the schematics checks for '111111'
and forces a Reset if it is encountered. This is to prevent the
counter getting stuck in the illegal state when it powers up as
mentioned earlier.
Also in every case, the next decoder line is the 'wrap-around'
value - when this state comes up, the counter does a self-reset
to 000000 on the next phase-2 clock, and usually does something
useful like generating a START signal for graphics output.
The rest of the counter decodes depend entirely on which counter
we're looking at, set let's get into 'em.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+++ Horizontal Sync Counter
The HSync counter counts from 0 to 56 once for every TV scan-line
before wrapping around, a period of 57 counts at 1/4 CLK (57*4=228
CLK). The counter decodes shown below provide all the horizontal
timing for the control lines used to construct a valid TV signal.
This table shows the elapsed number of CLK, CPU cycles, Playfield
(PF) bits and Playfield pixels at the start of each counter state
(ie when the counter changes to this state on the rising edge of
the H@2 clock). The decoded control lines are usually clocked into
other logic blocks during the next H@1-H@2 cycle (within 4 CLK).
Value HCount CLK CPU PF Pixel Control
000000 0 0 0
100000 1 4 1.3
110000 2 8 2.6
111000 3 12 4
111100 4 16 5.3 Set H-SYNC [SHS]
111110 5 20 6.6
011111 6 24 8
101111 7 28 9.3
110111 8 32 10.6 Reset H-SYNC [RHS]
111011 9 36 12
111101 10 40 13.3
011110 11 44 14.6
001111 12 48 16 ColourBurst [RCB]
100111 13 52 17.3
110011 14 56 18.6
111001 15 60 20
011100 16 64 21.3 Reset H-BLANK [RHB]
101110 17 68 22.6 0 0
010111 18 72 24 1 4 Late RHB [LRHB]
101011 19 76 25.3 2 8
110101 20 80 26.6 3 12
011010 21 84 28 4 16
001101 22 88 29.3 5 20
000110 23 92 30.6 6 24
000011 24 96 32 7 28
100001 25 100 33.3 8 32
010000 26 104 34.6 9 36
101000 27 108 36 10 40
110100 28 112 37.3 11 44
111010 29 116 38.6 12 48
011101 30 120 40 13 52
001110 31 124 41.3 14 56
000111 32 128 42.6 15 60
100011 33 132 44 16 64
110001 34 136 45.3 17 68
011000 35 140 46.6 18 72
101100 36 144 48 19 76 Center [CNT]
110110 37 148 49.3 20 80
011011 38 152 50.6 21 84
101101 39 156 52 22 88
010110 40 160 53.3 23 92
001011 41 164 54.6 24 96
100101 42 168 56 25 100
010010 43 172 57.3 26 104
001001 44 176 58.6 27 108
000100 45 180 60 28 112
100010 46 184 61.3 29 116
010001 47 188 62.6 30 120
001000 48 192 64 31 124
100100 49 196 65.3 32 128
110010 50 200 66.6 33 132
011001 51 204 68 34 136
001100 52 208 69.3 35 140
100110 53 212 70.6 36 144
010011 54 216 72 37 148
101001 55 220 73.3 38 152
010100 56 224 74.6 39 156 RESET, HBLANK [SHB]
101010 57 (228) (76) (40) (160) (already at 000000)
010101 58 232 - - -
001010 59 236 - - -
000101 60 240 - - -
000010 61 244 - - -
000001 62 248 - - -
000000 0 0 - - - (cycle)
111111 - - - - - ERROR (Reset to 000000)
Key:
SHS Turn on the TV HSYNC signal to start Horizontal flyback.
RHS Turn off the HSYNC signal, delayed 4 CLK.
RCB Reset Colour Burst, delayed 4 CLK latching [CB].
RHB Reset HBlank (enable output), delayed 4 CLK latching [HB].
LRHB Late RHB, used instead of RHB when [HMOVE] latch is set.
CNT Center screen, start copy/reflect PF, delayed 4 CLK for [CNTD].
SHB Start HBlank (disable output), Reset HCount to 000000.
The HSync counter resets itself after 57 counts; the decode on
HCount=56 performs a reset to 000000 delayed by 4 CLK, so
HCount=57 becomes HCount=0. This gives a period of 57 counts
or 228 CLK.
Playfield pixels start on the [RHB] control line at CLK=64, but
the first visible pixel won't appear until CLK=68 due to the
clocking on its output. The [CNT] control line either starts the
Playfield again as normal, or starts a reverse-shifted copy when
reflect-playfield [REF] is enabled.
RSYNC resets the two-phase clock for the HSync counter to the
H@1 rising edge when strobed. It looks like this could be used
to move the HSync counter into phase with the CPU on any cycle
(although there is some auto-synchronisation between the two-phase
clock and the div-by-3 counter for the CPU clock, I haven't looked
into this yet.) A full H@1-H@2 cycle after RSYNC is strobed, the
HSync counter is also reset to 000000 and HBlank is turned on.
This one requires more investigation.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+++ Player 0 and Player 1 Horizontal Position Counters
There are two independent Player Horizontal Position Counters, one
each for player 0 and player 1. The counters are identical; only
one is drawn in the schematics. This section describes only the
player 0 counter.
The player position counter controls the position of the player
graphics object (P0) on each scanline. The player counter counts
from 0 to 39 and then wraps around, giving a period of 40 counts
at 1/4 CLK (160 CLK) - also the number of visible pixels on a
scanline.
This table shows the elapsed number of CLK and CPU cycles at the
beginning of each counter state (the CPU column isn't particularly
relevant). Each START decode is delayed by 4 CLK in decoding, plus
a further 1 CLK to latch the STARTat the graphics scan counter.
The START decodes are ANDed with flags from the NUSIZ register
before being latched, to determine whether to draw that copy.
Actual graphics output is shown in parentheses for non-stretched
copies of the player.
Value PCount CPU CLK Event
000000 0 0 0 (draw -012)
100000 1 1.3 4 (draw 3456)
110000 2 2.6 8 (draw 7---)
111000 3 4 12 START DRAWING (NUSIZ=001,011)
111100 4 5.3 16 (draw -012)
111110 5 6.6 20 (draw 3456)
011111 6 8 24 (draw 7---)
101111 7 9.3 28 START DRAWING (NUSIZ=011,010,110)
110111 8 10.6 32 (draw -012)
111011 9 12 36 (draw 3456)
111101 10 13.3 40 (draw 7---)
011110 11 14.6 44
001111 12 16 48
100111 13 17.3 52
110011 14 18.6 56
111001 15 20 60 START DRAWING (NUSIZ=100,110)
011100 16 21.3 64 (draw -012)
101110 17 22.6 68 (draw 3456)
010111 18 24 72 (draw 7---)
101011 19 25.3 76
110101 20 26.6 80
011010 21 28 84
001101 22 29.3 88
000110 23 30.6 92
000011 24 32 96
100001 25 33.3 100
010000 26 34.6 104
101000 27 36 108
110100 28 37.3 112
111010 29 38.6 116
011101 30 40 120
001110 31 41.3 124
000111 32 42.6 128
100011 33 44 132
110001 34 45.3 136
011000 35 46.6 140
101100 36 48 144
110110 37 49.3 148
011011 38 50.6 152
101101 39 52 156 RESET, START DRAWING (always)
010110 40 53.3 160 (already at 000000)
001011 41 54.6
100101 42 56
010010 43 57.3
001001 44 58.6
000100 45 60
100010 46 61.3
010001 47 62.6
001000 48 64
100100 49 65.3
110010 50 66.6
011001 51 68
001100 52 69.3
100110 53 70.6
010011 54 72
101001 55 73.3
010100 56 74.6
101010 57 76
010101 58 -
001010 59 -
000101 60 -
000010 61 -
000001 62 -
000000 0 - (cycle)
111111 - - ERROR (Reset to 000000)
The graphics output for players contains some extra clocking
logic not present for the Playfield or other screen objects.
It takes 1 additional CLK to latch the player START signal.
The rest of the clocking logic is in common with the other
grahpics objects; therefore we can say that player grahpics
are delayed by 1 CLK (this is why the leftmost possible start
position for a RESP0 is pixel 1, not pixel 0. You can HMOVE
the player further left though, if necessary.)
The most important thing to note about the player counter is
that it only receives CLK signals during the visible part of
each scanline, when HBlank is off; exactly 160 CLK per scanline
(except during HMOVE). During the other 68 CLK per line, the
counter lies dormant on the exact 1/4 phase it was up to.
The [MOTCK] (motion clock?) line supplies the CLK signals
for all movable graphics objects during the visible part of
the scanline. It is an inverted (out of phase) CLK signal.
This arrangement means that resetting the player counter on any
visible pixel will cause the main copy of the player to appear
at that same pixel position on the next and subsequent scanlines.
There are 5 CLK worth of clocking/latching to take into account,
so the actual position ends up 5 pixels to the right of the
reset pixel (approx. 9 pixels after the start of STA RESP0).
For better or worse, the manual 'reset' signal (RESP0) does not
generate a START signal for graphics output. This means that
you must always do a 'reset' then wait for the counter to
wrap around (160 CLK later) before the main copy of the player
will appear. However, if you have any of the 'close', 'medium'
or 'far' copies of the player enabled in NUSIZ, these will be
drawn on the current and subsequent scanlines as the appropriate
decodes are reached and generate their START signals.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+++ Player 0 and Player 1 Graphics Scan Counters
The Player Graphics Scan Counters are 3-bit binary ripple counters
attached to the player objects, used to determine which pixel
of the player is currently being drawn by generating a 3-bit
source pixel address. These are the only binary ripple counters
in the TIA.
The Scan Counters are never reset, so once the counter receives
the Start signal it will count fully from 0 to 7. Counting is
only performed during the visible part of the scanline since
it is driven by the [MOTCK] line used to advance the Player
Position Counter. This gives rise to "sprite wrapping" whereby
a player positioned so it ends past the righthand side of the
screen will finish drawing at the beginning of the next scanline.
Note that a HMOVE can gobble up the wrapped player graphics -
see below.
The count frequency is determined by the NUSIZ register for that
player; this is used to selectively mask off the clock signals to
the Graphics Scan Counter. Depending on the player stretch mode,
one clock signal is allowed through every 1, 2 or 4 graphics CLK.
The stretched modes are derived from the two-phase clock; the H@2
phase allows 1 in 4 CLK through (4x stretch), both phases ORed
together allow 1 in 2 CLK through (2x stretch).
The NUSIZ register can be changed at any time in order to alter
the counting frequency, since it is read every graphics CLK.
This should allow possible player graphics warp effects etc.
Player Reflect bit - this is read every time a pixel is generated,
and used to conditionally invert the bits of the source pixel
address. This has the effect of flipping the player image drawn.
This flag could potentially be changed during the rendering of
the player, for example this might be used to draw bits 01233210.
Player graphics registers - there are four 8-bit registers in the
TIA for storing Player graphics, two for each player. Only two
of these are ever directly accessible; these are labelled the
"new" player graphics registers on the schematics. Unless the
Player Vertical Delay (VDELPn) is set, the "new" registers are
always drawn.
Writes to GRP0 always modify the "new" P0 value, and the
contents of the "new" P0 are copied into "old" P0 whenever
GRP1 is written. (Likewise, writes to GRP1 always modify the
"new" P1 value, and the contents of the "new" P1 are copied
into "old" P1 whenever GRP0 is written). It is safe to modify
GRPn at any time, with immediate effect.
Vertical Delay bit - this is also read every time a pixel is
generated and used to select which of the "new" (0) or "old" (1)
Player Graphics registers is used to generate the pixel. (ie
the pixel is retrieved from both registers in parallel, and
this flag used to choose between them at the graphics output).
It is safe to modify VDELPn at any time, with immediate effect.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+++ Missile 0 and Missile 1 Horizontal Position Counters
There are also two individual Horizontal Position Counters for
missile 0 and missile 1. The counters are independent and identical.
These counters use exactly the same counter decodes as the players,
but without the extra 1 CLK delay to start writing out graphics.
Missiles use the same control lines as the player from the NUISZ
register to determine the number of copies drawn, although they
ignore the player scaling options (you'll just get a single copy
for the scaled player modes).
Missile width is implemented in the same way as the ball width; it
appears to be exactly the same gate arrangement (see below).
The Missile-to-player reset is implemented by resetting the M0
counter when the P0 graphics scan counter is at %100 (in the middle
of drawing the player graphics) AND the main copy of P0 is being
drawn (ie the missile counter will not be reset when a subsequent
copy is drawn, if any). This second condition is generated from a
latch outputting [FSTOB] that is reset when the P0 counter wraps
around, and set when the START signal is decoded for a 'close',
'medium' or 'far' copy of P0.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+++ Ball Horizontal Position Counter
The ball position counter controls the position of the ball
graphics object (BL) on each scanline. The ball counter counts
from 0 to 39 and then wraps around, giving a period of 40 counts
at 1/4 CLK (160 CLK).
Ball width is given by combining clock signals of different widths
based on the state of the two size bits (the gates form an AND ->
OR -> AND -> OR -> out arrangement, with a hanger-on AND gate).
See notes later for all the messy details ;p
It seems a shame to have a whole polynomial counter for the ball, and
no special effects aside from its size - except for one small detail.
If you look closely at the START signal for the ball, unlike all
the other position counters - the ball reset RESBL does send a START
signal for graphics output! This makes the ball incredibly useful
since you can trigger it as many times as you like across the same
scanline and it will start drawing immediately each time :)
So it's good for cutting holes in things, drawing background details,
clipping the edges off things, etc. It can even be used to draw simple
sprites, or used as the background colour (because it's behind
everything else) for a two-colour sprite.
Actually on my 2600jr (long rainbow), setting the ball size to 8
pixels results in solid colour when it's reset every 9 pixels
(this might just be colour bleeding, I'm not sure).
Value BCount CPU CLK Event
000000 0 0 0 (draw 0123)
100000 1 1.3 4 (draw 4567)
110000 2 2.6 8
111000 3 4 12
111100 4 5.3 16
111110 5 6.6 20
011111 6 8 24
101111 7 9.3 28
110111 8 10.6 32
111011 9 12 36
111101 10 13.3 40
011110 11 14.6 44
001111 12 16 48
100111 13 17.3 52
110011 14 18.6 56
111001 15 20 60
011100 16 21.3 64
101110 17 22.6 68
010111 18 24 72
101011 19 25.3 76
110101 20 26.6 80
011010 21 28 84
001101 22 29.3 88
000110 23 30.6 92
000011 24 32 96
100001 25 33.3 100
010000 26 34.6 104
101000 27 36 108
110100 28 37.3 112
111010 29 38.6 116
011101 30 40 120
001110 31 41.3 124
000111 32 42.6 128
100011 33 44 132
110001 34 45.3 136
011000 35 46.6 140
101100 36 48 144
110110 37 49.3 148
011011 38 50.6 152
101101 39 52 156 RESET, START DRAWING
010110 40 53.3
001011 41 54.6
100101 42 56
010010 43 57.3
001001 44 58.6
000100 45 60
100010 46 61.3
010001 47 62.6
001000 48 64
100100 49 65.3
110010 50 66.6
011001 51 68
001100 52 69.3
100110 53 70.6
010011 54 72
101001 55 73.3
010100 56 74.6
101010 57 76
010101 58 -
001010 59 -
000101 60 -
000010 61 -
000001 62 -
000000 0 - (cycle)
111111 - - ERROR (Reset to 000000)
Vertical Delay bit - the VDELBL control bit works in the same
manner as the player VDEL bits; the state of VDELBL is used
every CLK to determine which of the "new" (0) or "old" (1)
ENABL values to use at the graphics output. Writes to ENABL
always modify the "new" value, and whenever GRP1 is written
the "new" value is copied into the "old". It is safe to
modify VDELBL and ENABL at any time, with immediate effects.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+++ Using the Horizontal Position Counters
The documented way to use a player position counter is to reset
it with RESPn on any CPU cycle divisible by 5 during the visible
scanline (5 is a convenient number for DEX-BNE loops), set up
HMPn to adjust the position by +7 (left) to -8 (right) pixels,
and hit HMOVE immediately after the next WSYNC. Then configure
NUSIZn for the number and spacing of copies required, and let
the hardware go about its business. Once this is set up, you
can just change the grpahics in GRPn every scanline to get one,
two or three copies at fixed spacing.
In fact the hardware has hard-wired requirements for almost none
of the above =) The fixed spacing between copies is hard-wired
and HMOVE is largely not negotiable, but the rest is complete
tosh.
The TIA renders each movable graphics object according to
independent position counters running at 1/4 CLK with a period
of 40 increments, and synchronised to the last RESPn/RESMn/RESBL
strobe. Each and every time a counter wraps around, the 'main'
copy of the object starts to draw. Since it takes 4 CLK to reset
the counter to zero and 4 CLK to increment the counter, the image
can be expected to appear after exactly 40 full counts, or 160 CLK.
The counters are normally only running during the 'visible' part
of a scanline, unless you're doing a HMOVE. Since the scanline
has 160 visible pixels, this yields the documented behavior that
a RESPn/etc sets the position for the next scanline. It's out
by 5 pixels when you set it, but who's counting?
Due to extra clocking logic for Player graphics output, the first
player pixel won't appear until 1 CLK later than for any other
grahpics object once rendering 'starts'. See the HSync/Player
Counter info above for an explanation of this.
During the horizontal blank (see the Horizontal Counter info
above) the Player, Missile and Ball counters stop receiving
CLK signals, so they pause on the exact 1/4 CLK they're up to
and resume where they left off at the first visible pixel on
the next scanline. This gives rise to the 'wrap around' effect,
to the point of splitting a copy of the player image in half
because it happened to start too near the right edge of the
screen ;)
The object counters are running at the same 1/4 CLK rate as the
HSync counter, but you can set them out of phase with the HSync
counter (and therefore the Playfield) by resetting any of them
on a CPU cycle that isn't divisible by 4. (If this were not the
case, there would only be 40 possible positions along the
scanline and we could all go home early). You can also use the
HMOVE command, which is described below.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+++ Playing with the HMOVE registers
In principle the operation of HMOVE is quite straight-forward;
if a HMOVE is initiated immediately after HBlank starts, which
is the case when HMOVE is used as documented, the [HMOVE] signal
is latched and used to delay the end of the HBlank by exactly
8 CLK, or two counts of the HSync Counter. This is achieved in
the TIA by resetting the HB (HBlank) latch on the [LRHB] (Late
Reset H-Blank) counter decode rather than the normal [RHB] (Reset
H-Blank) decode.
The extra HBlank time shifts everything except the Playfield
right by 8 pixels, because the position counters will now
resume counting 8 CLK later than they would have without the
HMOVE. This is also the source of the HMOVE 'comb' effect;
the extended HBlank hides the normal playfield output for the
first 8 pixels of the line.
In order to move less than 8 pixels right the TIA performs
'clock stuffing' on the Player, Missile and Ball position
counters, whereby a number of clock pulses between 0 and 15
are sent to the counters during HMOVE. Each extra clock pulse
eats up 1/4 count in the object's horizontal position counter,
and thereby moves the object left one pixel. This must be done
during HBlank because it is sending these extra clock pulses
down the same clock lines that usually receive [MOTCK] pulses
during the visible part of the scanline.
The Stella Programmer's Guide states that "the motion registers
should not be modified for at least 24 machine cycles after an
HMOVE command". This is indeed for internal hardware
considerations, although perhaps not entirely mysterious.
After several attempts, I finally got my head around the
heavily obfuscated logic in the schematics. It turns out to
be fairly simple, and quite elegant :)
The HMOVE values set by the programmer are stored in a matrix
of 4-bit data latches with built-in comparators - each latch
effectively contains a wired-XOR gate, and the 4 latches for
a given HMxx register are arranged in a wired-NOR formation
to give a 4-bit comparator.
Beside the matrix of HMxx latches is a 4-bit binary ripple
counter. It begins at 15 and decrements down to zero during
the HMOVE at a rate of 1 decrement every 4 CLK (it's built
from 2-phase clocked logic). The counter is wired in parallel
to the comparators in all 5 HMxx registers.
At the beginning of the HMOVE, a latch is set for each movable
object to indicate that it requires more motion to the left.
When the comparator for a given object detects that none of
the 4 bits match the bits in the counter state, it clears this
latch (a clever exercise in reverse logic!) Until this time,
the output of the latch is sent through to the movable object
once every 4 CLK (on every H@1 signal from the HSync two-phase
clock) as an extra "stuffed" clock signal.
Since one extra CLK pulse is sent every 4 CLK, this takes at
most 4*16=64 CLK (including counter reset at the end), or
64/3=21 CPU cycles. It takes 3 CLK after the HMOVE command
is received to decode the [SEC] signal (at most 6 CLK depending
on the timing of STA HMOVE) and a further 4 CLK to set the
"more movement required" latches. So we need to wait at least
71/3=23.66 CPU cycles before the HMOVE operation is complete.
For a normal HMOVE after WSYNC, it might be safe by cycle 23
(this has not been tested).
The first compare (against 15) will be sampled 15 CLK after STA
HMOVE begins and every 4 CLK thereafter. The first counter
decrement will happen at CLK 17, and every 4 CLK thereafter.
You may have noticed that the above discussion ignores the
fact that HMxx values are specified in the range +7 to -8.
In an odd twist, this was done purely for the convenience
of the programmer! The comparator for D7 in each HMxx latch
is wired up in reverse, costing nothing in silicon and
effectively inverting this bit so that the value can be
treated as a simple 0-15 count for movement left. It might
be easier to think of this as having D7 inverted when it
is stored in the first place.
In theory then the side effects of modifying the HMxx registers
during HMOVE should be quite straight-forward. If the internal
counter has not yet reached the value in HMxx, a new value greater
than this (in 0-15 terms) will work normally. Conversely, if
the counter has already reached the value in HMxx, new values
will have no effect because the latch will have been cleared.
Much more interesting is this: if the counter has not yet
reached the value in HMxx (or has reached it but not yet
commited the comparison) and a value with at least one bit
in common with all remaining internal counter states is
written (zeros or ones), the stopping condition will never be
reached and the object will be moved a full 15 pixels left.
In addition to this, the HMOVE will complete without clearing
the "more movement required" latch, and so will continue to send
an additional clock signal every 4 CLK (during visible and
non-visible parts of the scanline) until another HMOVE operation
clears the latch. The HMCLR command does not reset these latches.
The Cosmic Ark stars effect achieved this by writing the value
$60 to HMM0, 21 cycles after HMOVE starts. See this message in
the archives:
http://www.biglist.com/lists/stella/archives/199705/msg00024.html
Following is how I believe it works: at 21 cycles in, the internal
counter has just decremented to %0000 and is about to test this
against the HMxx registers (2 CLK from now, if my timings are
correct). If we flip the top bit of $60 as described above,
we have the binary pattern %1110. This pattern has at least one
bit in common with the final remaining state (the bottom zero
bit), and also has bits in common with the default counter state
%1111 which will arise when the counter resets. This means the
compare will pass now and forever more :) For this to work, I
expect that they must have set HMM0 to $70 before using the trick
(binary %0111, or %1111 with the bit flipped), but after a cursory
glance at Thomas' commented Cosmic Ark code I haven't found this.
Looking at the archives relating to Cosmic Arc and Rabbit Transit
tricks, I also notice that a HMCLR 20 cycles in has the same effect.
In this case it will be resetting HMxx to %1000 (bit-flipped)
which also obeys the rules for bypassing the stopping condition.
Also of note, the HMOVE latch used to extend the HBlank time
is cleared when the HSync Counter wraps around. This fact is
exploited by the trick that invloves hitting HMOVE on the 74th
CPU cycle of the scanline; the CLK stuffing will still take
place during the HBlank and the HSYNC latch will be set just
before the counter wraps around. It will then be cleared again
immediately (and therefore ignored) when the counter wraps,
preventing the HMOVE comb effect. Since the extended HBlank
is needed to move all objects right 8 pixels, this has the
limitation that objects can only be moved left, and the normal
HMOVE numbering no longer applies. Instead the HMOVE value is
interpreted as (8 + value) pixels to the left, ie:
-8 = 0 -4 = 4 0 = 8 4 = 12
-7 = 1 -3 = 5 1 = 9 5 = 13
-6 = 2 -2 = 6 2 = 10 6 = 14
-5 = 3 -1 = 7 3 = 11 7 = 15
This means that all objects will be moved 8 pixels left unless
you set their HMxx value to -8 for zero movement.
I've recently found a post in the Stella mailing list archives
that gave these results by exhaustive testing, posted by Brad Mott:
http://www.biglist.com/lists/stella/archives/199804/msg00198.html
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+++ Graphics Scan Counters during HMOVE
Since the Graphics Scan Counters are never reset, player
graphics output can wrap around as mentioned above.
A HMOVE 8 pixels right (-8 << 4), has no effect on the scan
counter since it will perform no "clock stuffing" of the
player counters for that player (the extended HBlank time
moves everything right 8 pixels).
Any other HMOVE value will gobble up at least one pixel,
or more proportional to the HMOVE value. Since a HMOVE
value really represents a count from 0 (for -8) to 15
(for +7) with the top bit inverted, this is the number
of player pixels that will be gobbled up by the HMOVE.
This means that a HMOVE of 0 will gobble up all remaining
wrapped output for the non-stretched player modes, since it
sends 8 extra clocks to the player. (Note that this is only
true if HMOVE was actually strobed for the scanline,
otherwise the configured HMxx registers never have any
effect). For the stretched player modes there could be some
output left - it takes 16 stuffed clocks to eat up a full
2X player, and 32 clocks to eat up a full 4X player.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+++ HMOVE during the visible scanline.
I mentioned above that HMOVE sends extra clock pulses down
the same clock lines that are usually used during the visible
part of the scanline. In theory this means that performing a
HMOVE during the visible part of the scanline should have no
effect. However, looking at how the various clock signals
interact, I suspect it is possible. I did some preliminary
experiments (on a 2600 Jr) at some point, and I seem to
remember having some success.
In this case the extra HMOVE clock pulses act to perform
'plugging' instead of the normal 'stuffing'; by this I mean
that the extra pulses plug up the gaps in the normal [MOTCK]
pulses, preventing them from counting as clock pulses. This
only works because the extra HMOVE pulses are derived from
the two-phase clock on the HSync counter, which is itself
derived from CLK (the TIA colour clock input), whereas
[MOTCK] is an inverted CLK signal - so they are more or less
precisely out of phase :)
I'm not sure how universal (or reliable!) this might turn out
to be, but I haven't seen it mentioned before. Also of note,
this technique can only be used to effect a move to the right,
at a rate of 1 pixel every 4 CLK (since this is the rate that
HMOVE generates the extra clock pulses).
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+++ The Re-trigger Trick, and all that jazz
I've read some theories suggesting that re-triggering is a
hack, possibly dependent on chip revision, where you trick
the TIA into rendering more than three copies by hitting
RESP0/RESP1 during the rendering of a 'legitimate' copy, or
some other method to confuse the poor chip. Through extensive
coffee consumption, I have determined that this is not the
case. Perhaps peering at the TIA schematics for countless
hours on end, until I fell asleep (two days in a row), may
have helped also.
The behaviour of the TIA positioning registers is quite
predictable and completely independent from its graphics
output logic, as documented above. What remains are issues
involving the timing of RESPn commands, given that the TIA
counts things at 1/4 clock and the CPU runs at 1/3 CLK =)
Following is a table of the cycle decodes for the Player
counters, starting from CLK=0 when the counter resets. This
is an excerpt from the Player Counter table listed elsewhere
in the document (I recomment you go have a look, the spacing
between events should look oddly familiar ;)
Value PCount CPU CLK Event
111000 3 4 12 START DRAWING (NUSIZ=001,011) Close
101111 7 9.3 28 START DRAWING (011,010,110) Medium
111001 15 20 60 START DRAWING (100,110) Far
101101 39 52 156 RESET, START DRAWING (always) Main
The columns from the left are: the polynomial counter state,
(see notes above), the decimal value that the player counter
is up to, the number of CPU cycles since the counter reset,
and the number of CLKs elapsed since the counter reset.
You'll notice I'm now talking about everything relative to
RESPn on the current scanline, rather than the beginning of
the scanline. This is because this is all that matters.
You should understand the following point:
If you hit RESPn at least twice on every scanline,
you will never see the 'main' copy of that player,
ever, on any scanline.
This is because the counter will always be reset before it
manages to complete a full 40 counts (160 CLK), and so the
'main' copy will never start drawing.
This is tricky to test, especially if you don't reset a few
things when you stop (eg, for VSync) - whenever you stop
hiting RESPn, you will start to get the normal output on the
next and subsequent scanlines, including the 'main' copy.
The very top visible scanline is a perfectly valid
'subsequent scanline' after the very bottom visible scanline,
once you get past the first frame ;)
If you've set up NUSIZn for 3 copies close (011), you'll be
getting four copies on every scanline on which you hit RESPn
twice, as long as they are far enough apart. This works because
it doesn't take a counter wrap-around to get to the 'close' and
'medium' copies as shown in the table above. They will appear
4+12+1=17 and 4+28+1=33 pixels after each RESPn CLK arrives
in the TIA (it takes 4 extra CLK to reset the counter, and 1
extra CLK to start the graphics output).
It's important to note, that as long as the second RESPn on
the line causes a reset after the 'start' signal has been
generated for the 'medium' copy of the first RESPn, you will
get four copies regardless of how far apart the RESPn hits
are. If you do the second RESPn too soon you'll end up with
only three copies - the 'close' from the first RESPn, followed
by the the 'close' and the 'medium' from the second RESPn.
If you do the second RESPn before the first 'close' copy,
you'll only end up with the 'close' and 'medium' from the
second RESPn.
From this it follows that if you set NUSIZ0 to 011, hit RESPn
and wait until the 'medium' copy has started, then change NUSIZ0
to 100 or 110, you will get all of 'close', 'medium' and 'far'.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+++ Re-triggering after exactly 18, 33, 66 or 162 cycles
These are special cases only because resetting a Position Counter
(RSPn, RESMn, RESBL) also resets the two-phase clock attached
to it, and this in turn affects the clocked logic on the output
of the counter decodes.
For the player counters, this affects the four decodes that
produce the Start signal for copies of the player graphics.
These are generated 12, 28, 60, and 160 CLK after the Position
Counter has been reset, in order to trigger the 'close', 'medium',
'far' and 'main' copies.
These decodes pass through a block of logic that requires a full
cycle of the two-phase clock (hence the normal 4 CLK delay before
graphics output common to all movable graphics objects). If the
Position Counter and therefore the two-phase clock are reset
during this decoding process, the Start signal will either be
lost or delayed up to 3 CLK depending on exact timing.
This effect is most evident when attempting to re-trigger the
player graphics over and over again. For example, examine this
retriggering technique:
STA RESP0 ;3 reset P0, call this 0 CLK.
CMP $EA ;3 nop
STA RESP0 ;3 reset P0 again, after 18 CLK.
CMP $EA ;3 nop
STA RESP0 ;3 reset P0 again, after 18 CLK.
The visible result of this will be a 'close' copy of P0 shifted
right by two pixels from the expected position, followed by a
second 'close' copy shifted right by two pixels, and finally a
third 'close' copy, not shifted right. There will be an 18 pixel
gap between the first two copies of P0, and only a 16 pixel gap
before the third copy.
In order to fix up the spacing of the final copy, it is necessary
to trigger P0 yet again exactly 18 CLK later, but clear GRP0 in
the mean time so nothing is drawn.
If the retriggering will be continuing onto the next line there is
no need to do this; just ensure that the first re-trigger on the
next line happens 18 visible pixels after the last RESP0 on the
previous line (ie 18 CLK later, minus HBlank time).
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+++ Notes on the Ball/Missile width enclockifier
Just to reiterate, ball width is given by combining clock signals
of different widths based on the state of the two size bits (the
gates form an AND -> OR -> AND -> OR -> out arrangement, with a
hanger-on AND gate).
The Enable (output) signal is built in two halves, arranged back-
to-back at the final OR gate.
The first half comes from one of three sources combined through
the earlier OR gate and then AND-ed with the Start signal:
(1) If D4 and D5 are both clear, one of the two-phase clock signals
(active 1 in 4 colour CLK) yields a single pixel of output.
(2) If D4 is set, a line active 2 in every 4 colour CLK is borrowed
from the two-phase clock generator (this yields 2 pixels).
(3) Finally D5 itself is used directly - the Start signal is active
for 4 CLK so this generates 4 pixels.
The second half is added if both D4 and D5 are set; a delayed copy
of the Start signal (4 colour CLK wide again) is OR-ed into the
Enable signal at the final OR gate.
I hope someone had as much fun building this little circuit as I
had pulling it apart again ;p
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+++ CPU Clock to Player Pixel Table
The Player Position Counter can be reset to zero (with RESP0/1) on
any CPU cycle as shown below, and copies will appear at the pixel
positions listed for 'close', 'medium' and/or 'far' depending on
the flags in NUSIZ; 1, 2, 3 or (if you change NUSIZ at the right
time) 4 copies at hard-wired positions after the reset. If the
counter is allowed to wrap around, the 'main' copy will appear
on the next line.
Resetting the counter takes 4 CLK, decoding the 'start drawing' signal
takes 4 CLK, latching the 'start' takes a further 1 CLK giving a
total 9 CLK delay after a RESP0/1. Since the playfield takes 4 CLK
to start drawing the player is visibly delayed by exactly 5 CLK -
hence the magic '5' :)
NOTE: The player counter can be safely reset 18 CLK after the previous
reset and the previous copy will still be drawn. BUT the 'start' signal
for the previous copy will be delayed a further 2 CLK due to the 2-
phase clock being reset before the 'start' signal has been clocked
through to the 'start' latch.
CPU CLK Pixel Main Close Medium Far PF
0 0 - 1 17 33 65 -
...
22 66 - 1 17 33 65 -
22.6 --------------------------------------------------------
23 69 1 6 22 38 70 0.25
24 72 4 9 25 41 73 1
25 75 7 12 28 44 76 1.75
26 78 10 15 31 47 79 2.5
27 81 13 18 34 50 82 3.25
28 84 16 21 37 53 85 3
29 87 19 24 40 56 88
30 90 22 27 43 59 91
31 93 25 30 46 62 94
32 96 28 33 49 65 97
33 99 31 36 52 68 100
34 102 34 39 55 71 103
35 105 37 42 58 74 106
36 108 40 45 61 77 109
37 111 43 48 64 80 112
38 114 46 51 67 83 115
39 117 49 54 70 86 118
40 120 52 57 73 89 121
41 123 55 60 76 92 124
42 126 58 63 79 95 127
43 129 61 66 82 98 130
44 132 64 69 85 101 133
45 135 67 72 88 104 136
46 138 70 75 91 107 139
47 141 73 78 94 110 142
48 144 76 81 97 113 145
49 147 79 84 100 116 148
50 150 82 87 103 119 151
51 153 85 90 106 122 154
52 156 88 93 109 125 157
53 159 91 96 112 128 0
54 162 94 99 115 131 3
55 165 97 102 118 134 6
56 168 100 105 121 137 9
57 171 103 108 124 140 12
58 174 106 111 127 143 15
59 177 109 114 130 146 18
60 180 112 117 133 149 21
61 183 115 120 136 152 24
62 186 118 123 139 155 27
63 189 121 126 142 158 30
64 192 124 129 145 1 33
65 195 127 132 148 4 36
66 198 130 135 151 7 39
67 201 133 138 154 10 42
68 204 136 141 157 13 45
69 207 139 144 0 16 48
70 210 142 147 3 19 51
71 213 145 150 6 22 54
72 216 148 153 9 25 57
73 219 151 156 12 28 60
74 222 154 159 15 31 63
75 225 157 2 18 34 66
76 228 0 5 21 37 69
----------------------------------------------------- Start HBLANK
Also note that hitting RESP0 before HBLANK has finished will reset
the counter immediately, but it will only start counting again when
HBLANK goes off. Due to output clocking, this will produce player
graphics at playfield pixel 1.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+++ The Venerable 6-digit Score Trick
The 6-digit score trick involves putting both players into 3-repeat
mode (011 or 110 in NUSIZ0/1) and resetting them such that all the
player 2 images are positioned exactly between all the player 1
images, ergo:
P1 P2
v v
1 2 1 2 1 2
Then you need to set the graphics up (GRP0/1) for the first two
digits, and write some very precise timing code to wait until the
scan-line is just about to start drawing the first copy of P1.
While you're waiting, get the rest of the graphics loaded into
the registers (A, X, and Y).
At this point you need to start storing all the graphics you've
loaded into GRP0 and GRP1 as fast as you can - it will look like
this because there's only one way to do it fast enough:
STA GRP0 ; 3
STX GRP1 ; 3
STY GRP0 ; 3
ST? GRP1 ; 3 we've run out of registers!
Notice that each one takes 3 cycles to execute (which is 9 pixels)
and makes the change on the -end- of the 3rd cycle. We could use
the stack pointer register (S) for the last one and do a TSX, but
that would take 5 cycles (that's 15 pixels) which is too long.
To get it working you need to turn on VDELP0/1 (vertical delay)
which allows you to set up the first 3 digits in the TIA's
graphics registers before the beginning of the scanline, and
requires only the 3 remaining registers to hold the last 3 digits.
I've found a post in the Stellar archives that explains this
technique in great detail, so I'll stop here.
http://www.biglist.com/lists/stella/archives/199704/msg00137.html
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+++ Fine Print
Please note that these notes are my own, and are made available
without any warranties of any kind. They may include errors,
omissions and much that is apocryphal; use at your own risk.
Please let me know if you spot anything that is blatantly wrong
and I'll update the document. I'm also happy to answer any
questions about this stuff.
Copyright (C) Andrew Towers 2003
Reference in New Issue View Git Blame Copy Permalink