> OK, lets define the situation:
Depending on how detailed you want to go on about vdel, the description
that was assembled in a previous email by Erik may be enough. It is
technically accurate, and explains the original intended use for vdel.
It simply does not touch on the expanded possibilities of the hardware
implementation of vdel. Here is the quotes I'm talking about:
<start quote>
> Also, how I'm going to explain VDEL is that it has the net effect of
> shifting sprites down a single scanline. So if you want to move a sprite
> up a single scanline, you move it up a full scanline (since it's a 2 line
> kernel) and enable VDEL, the next frame you don't enable VDEL so it has the
> effect of moving it another single scanline, and so on.
That's correct - if you're using VDEL in the manner that the designers
intended. For it to work that way, the kernel _must_ work so that on each
pair of scanlines, you write GRP0 on the first scanline and GRP1 on the
second. VDEL doesn't work as advertised if you write to GRP0 in ways
other than that.
<end quote>
> >I would like to expand on this diagram to show how the TIA drives the
> >speaker with this type of counter, and how it performs sprite positioning
> >(via coarse and fine registers) in combination with the binary/decimal ->
> >poly value code.
> Sorry, I can't help you here. Did anyone here ever figure out how the
> poly counters relate to the TIA register?
Here's what I can contribute on poly counters.
A polynomial counter is another name for a type of LFSR(linear feedback
shift register). This jist of the hardware behind it is a shift register
with a few XOR gates in the mix, but I'm sure you know that if you have a
shockwave demo of it...
As to sprite positioning, I am not sure what you are talking about by
coarse and fine registers, unless you are refering to coarse positioning
as the RESxx and fine as the adjustments made by HMOVE.
Programmers view:
For positioning sprites across the screen, the programmer can simply look
at is as there being a normal binary counter that counts how many color
clocks across the screen it is. The counter is setup to roll over once
every line(look at it as if it rolls over at 227). There is one of these
counters for every sprite that can be positioned. The TIA continuously
checks if this number is zero, if it is zero, it knows that it should
start drawing the sprite(the sprite who's register is zero). When you do
a RESxx it resets this counter to zero(or more likely all ones, but that
is irrelevant here). HMOVE can be looked at as adding and subtracting
values from this register.
Hardware/implementation:
This is completely invisable to the programmer, and it is only the insides
of the TIA that actually make a difference. Knowing that it is
implemented in a LFSR is unnessicary for programming a game. You could
remake the TIA using a binary counter, but as the designers noted, that
would have taken more space in the Si. These counters are actually LFSR.
the LFSR has a neat feature in that it is easy to implement, and does the
work of a binary counter, it just looks a little different in that it does
not count in a normal fashion. To see what I mean, take a look at an
excel sheet I made to predict the values coming out of the 'random' number
generator in the DPC.
You can download it at :
http://www.upl.cs.wisc.edu/de-smet/DPCLFSR.xls
I put it on the web because I know that attachments sometimes get held up
when posted to this list, and you said you were on a deadline.
Put a binary number in the yellow boxes to see the next 255 combinations.
You will note that after 255 the number has repeated. Note that This is
one implementation of it. LFSR's can be implemented with the XOR's at the
end like I did in the sheet, or with he XOR's in the middle of the
register bits. In this second format the numbers will look more random
that in the sheet because they will not appear simply shifted as they do.
The fact that it doesn't count in a binary order is irrelevant as you are
only checking if it is zero. Further, because it always counts in a
predetermined order, you can simply determine which value will be in the
register after so many clocks. As a side note, the most that a n bit LFSR
can count is n^2 -1. This is because it cannot ever be all zeros(or ones
in the case of the one I programmed into the excel sheet). If it ever is,
it cannot get out of that value. Try putting 11111111 into my spredsheet
to see what I mean.
When it comes to HMOVE, you can't really add or subtract from a LFSR
because you would have to create an added/subracter that does math in the
strange numbering scheme represented by the LFSR. They actually do it by
adding or subtracting that many clock pulses to that LFSR. They do this
during the horizontal blank, which is why a HMOVE has to be done right
after a WSYNC, and why you should not do anything to the registers for
those 24 clock cycles. I don't think that it actually does it during
thehorizontal blank by default, but simply does it whenever you do the
HMOVE, but they tell you to do the HMOVE then so that it will be done
before there is any problems during screen draw.
In case you are curious, the reason it is called a polynomial counter is
that if you configure it right, you have a shift in and a shift out, and
you can use it to do polynomial division etc...
As to sound generation, I don't know. Best guess is that it simply takes
the output for the sound, and changing the mode changes the format of the
shift register(different combination of XOR's).
Need any more elaboration?
Mark
--
Archives (includes files) at http://www.biglist.com/lists/stella/archives/
Unsub & more at http://www.biglist.com/lists/stella/
