> "Since the TIA latches all instructions until altered by another write
> operation it could be updated every 2 or 3 lines".
Note for the hardware knowledgeable, they are not 'instructions' per-se,
but instead simply register writes. The registers can be considered
memory, so latched, yes.(NOTE, that because of the way the TIA was
implemented to reduce hardware, the memory is write ONLY, or read ONLY
depending on the direction of the register.)
> I'm assuming this means that whenever you want the same scanline to show up
> for multiple scanlines, you simply execute a WSYNC on the successive
> lines? But for any kernel that does register hits in mid-scanline, you
> must re-execute those hits on every scanline, right?
Yes, if you don't do anything, the line will be repeated, hence the
vertical bars which you sometimes see when you pull a cartridge with the
power still on. The exception to this, as you have noted, is when you do
resets(resp0, respm0...) more than once per line, or update graphics
mid-line. If you do a reset once, like the TIA was originally designed
for(2 sprites, 2 missles, 1 ball, playfield on the entire screen), then
you do not have to do the 're-execution' every line. The reset object
will repeat if you don't change it. The other note is with horizontal
motion, but if you don't strobe hmove, then the above is correct. As you
say, the line will not repeat if you are setting the playfield(for
example) twice in a line(once at the beginning, and once in the middle)
> So if you just wanted to draw a stripe, you could have one line in the
> kernel and all others would be WSYNCs? Could the programmer also use this
> screentime to perform number crunching and other non-visible stuff? This
> is how the paddles are typically read, correct?
Big time yes! This is why early games did graphics that have a large
vertical resolution. The intent was to allow more programmer time. I
suspect it wasn't that the early games needed the program time, but that
they didn't have the experience yet to realise what all could be done.
Yes, paddle reads must be done during the screen.
> "when a 1 is written to D1 of the CTRLPF register, the left half of the
> playfield takes on the color of player 0 and the right half takes on the
> color of player 1."
>
> Does this mean it actually does a color shift automatically in
> hardware? Also, this feature does not prevent sprites from being used on
> those scanlines, does it?
It is done in hardware. I don't see why this would prevent sprites, and
it should have no effect on those colors.
I had always wondered about that 'score' bit. I mean it is theoretically
great for doing scores at the top of the screen like in airsea
battle. The thing I don't understand is because I think this is why it
was designed this way when they designed the TIA, but that would imply
that when they designed the TIA, they knew that they could do playfield
updates mid line. I had thought that this was a later revalation...
> That's one feature I never knew about. I thought Combat was doing the
> color shift manually.
It could be done either way, but it would be easier using the 'score' bit.
> Also, has anyone thought of trying to wire something into the unused bits
> (D5 D4 and D2) of PortB/SWCHB?
Never heard anything of it. It is 100% doable. the 6532 is a stock part,
and those pins are simply not connected.
> Also, anyone know the reason why the trigger buttons connect to the TIA
> instead of PIA?
Not sure, best guess is because the designers wanted the latch feature.
The PIA(6532) basically provides no latching(except for that edge trigger
I talked about before, which I don't think anyone uses) By putting it
through the TIA, they could add that latch which would allow for better
grabbing of fast button presses. If your program only reads the inputs
once per screen(and you have the latches off), then a person has to have
the button pressed fully for 1/60 of a second, which although is a short
period of time, is actually long when you talk about bouncing, which you
may want to catch. With the latch, you can catch all presses, no matter
how fast(I lie, the speed is limited to the transistor speed, but that is
pretty darn fast).
Mark
--
Archives (includes files) at http://www.biglist.com/lists/stella/archives/
Unsub & more at http://www.biglist.com/lists/stella/
