HMOVE variations

[ZackAttack]

While working on a 12 sprite kernel I noticed that my 2600jr doesn't behave as described in the HMOVE document on the minidig. Specifically the cycle 73 HMOVE seems to be off by one.

 

Was there a test program used to generate this chart and if so does anyone know where to obtain it?

 

If not I'd like to write one that displays the move values for 0-15 for cycle 73, 74 and 3 HMOVEs. Any ideas on how to extract the actual HMOVE values from the TIA? I. E. setting HMP0 to 0 and strobing HMOVE on cycle 73 moves P0 n pixels. Programmatically find n.

[alex_79]

Was there a test program used to generate this chart and if so does anyone know where to obtain it?

 

https://www.biglist.com/lists/stella/archives/199804/msg00198.html

 

hmove.zip

Edited July 12, 2018 by alex_79

[Dionoid]

Just to be sure: a cycle 73 HMOVE means that it should end on cycle 73 (not start on cycle 73). That might cause the issue you are seeing.

[Omegamatrix]

Here try this test rom built around cycle 74 HMOVE's.:

 

DHmoveValues(rev2).zip

 

Use the joystick left & right to slow/speed up the cycling.

 

 

 

While looking more at early HMOVE's several months ago (for my new game) I found 2 very important posts:

 

http://atariage.com/forums/topic/72308-hunchy-ii/?p=903045

 

http://atariage.com/forums/topic/72308-hunchy-ii/?p=903928

 

 

It does not appear viable to get correct the HMxx values for every system, because even if you get the position correct there will be shifting that can corrupt the graphics. This will be true on late model Atari Jr's and all PAL 7800's for any HMOVE's during the visible portion of the screen.

 

 

That being said I am still using early HMOVE's myself.

 

 

[ZackAttack]

https://www.biglist.com/lists/stella/archives/199804/msg00198.html

 

hmove.zip

Thanks, if I'm reading it correctly the jr is
-7  -8  -9 -10 -11 -12 -13 -14   0   0  -1  -2  -3  -4  -5  -6
instead of
-8  -9 -10 -11 -12 -13 -14 -15   0  -1  -2  -3  -4  -5  -6  -7
for both 73 and 74 hmoves

Just to be sure: a cycle 73 HMOVE means that it should end on cycle 73 (not start on cycle 73). That might cause the issue you are seeing.

Correct, ends on 73. The issue only appears on my jr. On my ntsc 7800 and in stella the position matches the doc.

 

Here try this test rom built around cycle 74 HMOVE's.:

 

DHmoveValues(rev2).zip

 

Use the joystick left & right to slow/speed up the cycling.

 

That rom only works on my 7800. It completely crashes on the jr. Probably the harmony firmware though, both the harmony and uno cart hate this system.

 

It does not appear viable to get correct the HMxx values for every system, because even if you get the position correct there will be shifting that can corrupt the graphics. This will be true on late model Atari Jr's and all PAL 7800's for any HMOVE's during the visible portion of the screen.

If I understand this correctly the 73/74 hmove should be fine for the 12 sprite kernel because all 3 copies of P0 and P1 will remain in the middle of the screen and should never overlap with the hmove clock pulses.

 

So based on everything covered above, the detection only needs to differentiate between those two possibilities. And using a normal hmove after wsync will be correct regardless of which system it is.

[SeaGtGruff]

As far as I remember, there are indeed some variations between specific models and clones of the VCS 2600 with regard to things like the timing of HMOVEs and the windows for when it's safe to write to the playfield registers. You might be able to find more information about the differences by searching the 2600 programming subforums for something like "2600jr HMOVE," "2600jr starfield effect," "2600jr playfield pixels," etc.

[Thomas Jentzsch]

I just remembered at this when I was watching Zeropage Homebrew playing the latest version of Aaardvark. When the aardvark leaves the scene, I was writing to PF2 at cycle 38. This worked flawlessly in Stella and on my console. But in the stream, there was a glitch which went away after I corrected to 37.

[SeaGtGruff]

I remember that I made and posted a chart showing when you could write to the PF registers, breaking it down to each playfield pixel (based on some calculations), and I think you (@Thomas Jentzsch) gave me feedback about timing variations for certain models/clones, which I added to the chart. I think I posted two versions, one showing the calculations and another that just gave the results. It should be here in one of the 2600 programming subforums. But I'm a little off-topic, since this thread is actually about HMOVE.

[Omegamatrix]

That rom only works on my 7800. It completely crashes on the jr. Probably the harmony firmware though, both the harmony and uno cart hate this system.

Maybe, but maybe not. Is this Jr made in China? Does it have a date on it?

 

 

 

If I understand this correctly the 73/74 hmove should be fine for the 12 sprite kernel because all 3 copies of P0 and P1 will remain in the middle of the screen and should never overlap with the hmove clock pulses.

 

So based on everything covered above, the detection only needs to differentiate between those two possibilities. And using a normal hmove after wsync will be correct regardless of which system it is.

The real problem with these oddball consoles is that HMOVE's in the visible portion of the screen (including cycle73/74) will corrupt the graphics. If the position of the players on the previous line is always the same that is good as it does seem a HMPx value can be found that works. However there is still a chance that the graphics get corrupted so that becomes difficulty to deal with.

 

I'm going off of what I understood from Eckhard, quoted below.

 

From my experience, only consoles made in China in 1989 or later are affected by the different HMOVE behaviour. Unfortunately this includes all PAL 7800s. Older 2600 Jrs. should work just like the 6- and 4-switch models. At least it is like this with all my PAL consoles.

 

The difference is in HMOVE pulses that happen during the visible part of the scanline. As you might know, the TIA will generate a left-shift pulse every 4 pixels when you trigger a HMOVE. It will continue to do so until the motion counters for all movable objects have been matched with the HMOVE counter. When you trigger HMOVE at the start of VBLANK, all counters will usually have been matched by the end of VBLANK.

 

The only exceptions are when you trigger the Cosmic Ark starfield effect or when you trigger HMOVE during the visible part of the screen. The clock lines for the HMOVE pulses are used for different things during the visible part of the scanline, so the shifting pulses will be ignored on a normal VCS. This is why you get different shifting distances when you trigger HMOVE on different cycles. It depends on how many of the HMOVE pulses happen during VBLANK.

 

On the China-VCS the HMOVE pulses during the visible part of the scanline unfortunately overlap with the display clocks for the player graphics in such a way that those will be canceled out. As a result it will appear that the player graphics get shifted to the right by one pixel for every HMOVE clock. Since HMOVE pulses happen every 4 pixels, they can generate such a shift even in the middle of a player display.

 

So, if you want to keep your game compatible with both types of consoles, you need to avoid moving player graphics with HMOVEs that happen during the visible part of the scanline. But AFAIK only the players are affected by this. So Manuel's worm demo should work fine, since it only uses missiles and the ball.

 

 

Ciao, Eckhard Stolberg

[DirtyHairy]

The issue with cycle 73 and 74 HMOVEs is interesting. From my understanding of the chip, both variants do not send pulses during the visible part of the scanline as there is a six clock delay after the register is strobed (this is also reflected in the 8 pixels shift measured by bwmott in the test program: all 8 clock pulses generated by the HMOVE logic count, none are gobbled). The way HMOVE is modeled in my TIA core, both have the same effect, as extra pulses are potentially only triggered on color clocks 1, 4, 8, .... A cycle 73 HMOVE takes effect at color clock 225, which will generate the first movement pulse at color clock 1. A cycle 74 HMOVE takes effect at clock 1, and the first movement pulse will occur at clock 1 in my model, too.

 

However, the difference suggests that something is wrong in this picture, at least on those oddball consoles. How exactly does cycle 73 differ from cycle 74 on the affected chips?

Edited July 14, 2018 by DirtyHairy

[RevEng]

I just remembered at this when I was watching Zeropage Homebrew playing the latest version of Aaardvark. When the aardvark leaves the scene, I was writing to PF2 at cycle 38. This worked flawlessly in Stella and on my console. But in the stream, there was a glitch which went away after I corrected to 37.

This was the precisely the cause of the bB DPC+ kernel "ghost pixel" glitch, which was initially discovered by iesposta, when he was watching Zeropage's stream. Thankfully one of his consoles could reproduce it, so it was possible for us to figure it out.

 

It's a "ghost pixel" for the bB DPC+ kernel, because the cycle 38 PF2 update only happens during virtual player repositioning, and only then for certain coarse player positions.

[alex_79]

I remember that I made and posted a chart showing when you could write to the PF registers, breaking it down to each playfield pixel (based on some calculations), and I think you (@Thomas Jentzsch) gave me feedback about timing variations for certain models/clones, which I added to the chart. I think I posted two versions, one showing the calculations and another that just gave the results. It should be here in one of the 2600 programming subforums.

It's here:

http://atariage.com/forums/topic/149228-a-simple-display-timing-diagram/?do=findComment&comment=1820187

[ZackAttack]

However, the difference suggests that something is wrong in this picture, at least on those oddball consoles. How exactly does cycle 73 differ from cycle 74 on the affected chips?

 

The only difference I have observed is that the movement is one pixel less than on the normal consoles (clamped to 0).

[DirtyHairy]

I just stumbled over this topic again. I wonder: the "ordinary" TIA has a six color clock delay before strobing HMOVE actually takes effect. I wonder if the delay is one or two cycles less on the affected consoles. This would mean that a cycle 73 HMOVE generates one of the extra pulses *before* HBLANK starts, and as a result, the pulse would either coincide with an ordinary movement pulse (which means one pixel less movement) or fill in the gap between two ordinary pulses (which would mean a right shift of one pixel).

[Thomas Jentzsch]

Once we got this analysed, we should add another option to Stella which emulates these consoles.

[Dionoid]

On 7/14/2018 at 6:04 PM, Thomas Jentzsch said:

I just remembered at this when I was watching Zeropage Homebrew playing the latest version of Aaardvark. When the aardvark leaves the scene, I was writing to PF2 at cycle 38. This worked flawlessly in Stella and on my console. But in the stream, there was a glitch which went away after I corrected to 37.

Did someone eventually determine the source of this PF2 timing issue which was visible on this specific 2600 console? Or is cycle 37 just the more 'safe' way to update PF2 at the latest?

[Thomas Jentzsch]

16 hours ago, Dionoid said:

Did someone eventually determine the source of this PF2 timing issue which was visible on this specific 2600 console? Or is cycle 37 just the more 'safe' way to update PF2 at the latest?

The latter. Some TIAs are slightly slower than others. Stella can emulate this (Developer settings/TIA/Pesco glitch).

 

Also see here.