5 replies to this topic

[grafixbmp]

For a long time now I thought I had this figured out but not sure anymore. I want to run throught/ ask questions about horizontal positioning to make sure I got it.

Any RES for the 5 objects set at the apropriate time triggers that objects drawing imediatelyon screen. At exactly what colour clock when that write occurs does the begining of the object start? That is taking into account double and quad size players one CC delay.

HM 's individualy sets a positive or negative value for P0 P1 M0 M1 and BL but doesn't become an offset until HMOVE register is triggered? And a single HMOVE triggering applies to every HM's setting?

Atleast 24 colour clocks are needed for an HMOVE to respond in each object.

This last one I may have conjored up myself but I also undestood that multiple triggers to HMOVE applied the fine tuning offset multiple times. For example, if HMP0 is +2 and HMP1 is +1 then if HMOVE is triggered 3 times with atleast 24 cycles before displaying, does that mean that P0 shifts 6 colour clocks right and P1 shifts 3 as well?

Edited by grafixbmp, Tue Oct 20, 2009 12:45 AM.

[Mord]

I will pretend I know the answers!

grafixbmp, on Tue Oct 20, 2009 12:45 AM, said:

For a long time now I thought I had this figured out but not sure anymore. I want to run throught/ ask questions about horizontal positioning to make sure I got it.

Any RES for the 5 objects set at the apropriate time triggers that objects drawing imediatelyon screen. At exactly what colour clock when that write occurs does the begining of the object start? That is taking into account double and quad size players one CC delay.

I keep getting mixed up on this myself. I end up writing or using a prepackaged sprite placement routine that does all the brain numbing math for me. After it's written I end up never having to think about it again since it would convert the desired pixel value to the proper RES and HMOVE value.

Quote

HM 's individualy sets a positive or negative value for P0 P1 M0 M1 and BL but doesn't become an offset until HMOVE register is triggered? And a single HMOVE triggering applies to every HM's setting?

Atleast 24 colour clocks are needed for an HMOVE to respond in each object.

This is correct. The offset is applied to all 5 objects when you hit a HMOVE, and only then. Keep in mind that timing is important when hitting the HMOVE. The positive and negative values given in stella.txt, etc generally assume a standard HMOVE. IE: When the HMOVE is the first thing done in the scanline. (So it ends on cpu clock 2. (takes 3 clocks to do a sta HMOVE, and clock 0 is counted as one.)

I'm not entirely sure about the 24 color clocks however. I do know you have to wait a while after hitting sta HMOVE before you can go updating the offset values or you get funny results.

Quote

This last one I may have conjored up myself but I also undestood that multiple triggers to HMOVE applied the fine tuning offset multiple times. For example, if HMP0 is +2 and HMP1 is +1 then if HMOVE is triggered 3 times with atleast 24 cycles before displaying, does that mean that P0 shifts 6 colour clocks right and P1 shifts 3 as well?

This is correct as well. However like I said above the timing on the HMOVE is VERY important. The offset values change depending on when you do the sta HMOVE, and you can't just do sta HMOVE, sta HMOVE, etc one after the other.

Doing a standard HMOVE also produces the little black bars on the left side of the screen if you're updating things during the visible display. To do a HMOVE without generating those you'd have to attempt triggering the HMOVE on cycle 73-74 instead - but this completely changes the meanings of the offsets and creates it's own headaches.

But otherwise, doing a proper HMOVE twice (each on a different scanline) would cause it to apply the offsets twice.

[grafixbmp]

OK then. well what happens in this situation because it feels like the old Chicken and the egg scenario:
You want to position so far into a scanline so you count loops into the scanline as to set the specific RES at the right time. However, this isn't exact enough for your current placement so you need to set a value for that HM setting. But this isn't enough either as the offset value doesn't get applied until HMOVE is triggered and then it turns out every HM's current values gets applied all at once which won't do either if being done at mid-kernel. SO then if one value needs to be set imediately without the others being affected, then it would be best to do an HMCLR strobing thereby clearing all HM values and then load the specific one you need at that time before teh HMOVE.

I guess depending on if you position the majority of objects prior to the start of the kermnel and/or if you position a specific object mid kernel, you turn out treating each scenario diffrently.


Well, how does this go for mid kernel changes?
For in my mind, I guess you need to set the RES and somewhere along the way have other HM registers cleared so that any HMOVE only affects the one you set immediately for current use. But does this mean that the RES needs to be done first before HM can affect it? Cause if done backwards, then the RES seems like it would naturaly reset any offset applied to it given it is stated that a RES places that object at the time and place the RES happens.

Clarity pleae?

Edited by grafixbmp, Tue Oct 20, 2009 5:51 AM.

[Mord]

grafixbmp, on Tue Oct 20, 2009 5:47 AM, said:

OK then. well what happens in this situation because it feels like the old Chicken and the egg scenario:
You want to position so far into a scanline so you count loops into the scanline as to set the specific RES at the right time. However, this isn't exact enough for your current placement so you need to set a value for that HM setting. But this isn't enough either as the offset value doesn't get applied until HMOVE is triggered and then it turns out every HM's current values gets applied all at once which won't do either if being done at mid-kernel. SO then if one value needs to be set imediately without the others being affected, then it would be best to do an HMCLR strobing thereby clearing all HM values and then load the specific one you need at that time before teh HMOVE.

I guess depending on if you position the majority of objects prior to the start of the kermnel and/or if you position a specific object mid kernel, you turn out treating each scenario diffrently.


Well, how does this go for mid kernel changes?
For in my mind, I guess you need to set the RES and somewhere along the way have other HM registers cleared so that any HMOVE only affects the one you set immediately for current use. But does this mean that the RES needs to be done first before HM can affect it? Cause if done backwards, then the RES seems like it would naturaly reset any offset applied to it given it is stated that a RES places that object at the time and place the RES happens.

Clarity pleae?

Yes, the RES will need to be done first since it positions the sprite to exactly where/when it was triggered during the scanline. Doing an HM/HMOVE prior to it is a waste of time. Position as many objects as you can prior to the start of the visible screen and clear out the HM registers asap. That way you only need to set and clear the specific HM needed during the actual screen display as needed.

[supercat]

Each sprite (player/missile/ball) has a circuit which will trigger a horizontal start signal whenever its horizontal counter hits 160. The players and missiles can also be triggered by count values of 16, 32, or 64, and the ball can also be triggered by a reset signal. The horizontal counters will be reset by RESxx, or whenever they reach 160. The logic to display players adds additional delay after the start signal is triggered.

Each sprite's horizontal counter is hit with one pulse per pixel during the visible part of the scan line, and has an associated "supplemental pulse" circuit which can hit it once every four pixels. Normally supplemental pulses are only added during horizontal blank; pulses generated during the displayed portion of the line will not bump the counter, but will cause objects to be displayed oddly.

The TIA has one four-bit HMOVE counter which is shared among all five sprites. Normally it sits at a value of 8. It is incremented once every four pixels if its value is not 8, or on the cycle following a write to HMOVE. A write to HMOVE has three effects:

-1- It allows the HMOVE counter to advance once even if its value is 8.

-2- It turns on all five sprites' pulser circuits.

-3- If it occurs within the horizontal blanking interval, it will delay the end of the blanking interval by 8 pixels, thus depriving all five sprites of eight clock pulses they would otherwise have received (and generating an "HMOVE bar")

Each sprite's pulser circuit will switch off as soon as its HMxx register matches the HMOVE counter. Note that if the HMxx register is not $80, it's possible that this may never occur.

There are 68 non-displayed pixels per line, so the maximum number of supplemental pulses that can be generated is 17 for a line without an HMOVE bar, or 19 for a line with the bar (note that the bar itself will effectively subtract eight motion pulses, so the net effect in that case would be 11 pixels' worth of motion).

The HMOVE circuitry is tricky, but if one understands it one can do some tricks which would otherwise not be possible.

[grafixbmp]

supercat, on Mon Oct 26, 2009 5:14 PM, said:

Each sprite (player/missile/ball) has a circuit which will trigger a horizontal start signal whenever its horizontal counter hits 160. The players and missiles can also be triggered by count values of 16, 32, or 64, and the ball can also be triggered by a reset signal. The horizontal counters will be reset by RESxx, or whenever they reach 160. The logic to display players adds additional delay after the start signal is triggered.

Each sprite's horizontal counter is hit with one pulse per pixel during the visible part of the scan line, and has an associated "supplemental pulse" circuit which can hit it once every four pixels. Normally supplemental pulses are only added during horizontal blank; pulses generated during the displayed portion of the line will not bump the counter, but will cause objects to be displayed oddly.

The TIA has one four-bit HMOVE counter which is shared among all five sprites. Normally it sits at a value of 8. It is incremented once every four pixels if its value is not 8, or on the cycle following a write to HMOVE. A write to HMOVE has three effects:

-1- It allows the HMOVE counter to advance once even if its value is 8.

-2- It turns on all five sprites' pulser circuits.

-3- If it occurs within the horizontal blanking interval, it will delay the end of the blanking interval by 8 pixels, thus depriving all five sprites of eight clock pulses they would otherwise have received (and generating an "HMOVE bar")

Each sprite's pulser circuit will switch off as soon as its HMxx register matches the HMOVE counter. Note that if the HMxx register is not $80, it's possible that this may never occur.

There are 68 non-displayed pixels per line, so the maximum number of supplemental pulses that can be generated is 17 for a line without an HMOVE bar, or 19 for a line with the bar (note that the bar itself will effectively subtract eight motion pulses, so the net effect in that case would be 11 pixels' worth of motion).

The HMOVE circuitry is tricky, but if one understands it one can do some tricks which would otherwise not be possible.

This has got to be the one most to-the-point explination of 2600 hardware I have ever seen. It's deep! Deep like how one would constantly reread a passage in the Bible to try and understand it. I feel I should treat this like a passage from the bible. kudos!

Edited by grafixbmp, Tue Oct 27, 2009 10:05 PM.