Jump to content

Photo

HMOVE variations


12 replies to this topic

#1 ZackAttack OFFLINE  

ZackAttack

    Dragonstomper

  • 754 posts
  • Location:Orlando, FL US

Posted Thu Jul 12, 2018 7:37 AM

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.



#2 alex_79 OFFLINE  

alex_79

    Stargunner

  • 1,184 posts
  • Location:Italy

Posted Thu Jul 12, 2018 8:57 AM

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

 
https://www.biglist....4/msg00198.html

 

Attached File  hmove.zip   4.46KB   47 downloads


Edited by alex_79, Thu Jul 12, 2018 9:00 AM.


#3 Dionoid OFFLINE  

Dionoid

    Chopper Commander

  • 101 posts
  • Location:Leiden, Netherlands

Posted Fri Jul 13, 2018 2:33 PM

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.

#4 Omegamatrix OFFLINE  

Omegamatrix

    Quadrunner

  • 6,215 posts
  • Location:Canada

Posted Fri Jul 13, 2018 3:00 PM

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

 

Attached File  DHmoveValues(rev2).zip   18.96KB   43 downloads

 

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/...hy-ii/?p=903045

 

http://atariage.com/...hy-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.

 

 



#5 ZackAttack OFFLINE  

ZackAttack

    Dragonstomper

  • Topic Starter
  • 754 posts
  • Location:Orlando, FL US

Posted Fri Jul 13, 2018 8:17 PM

https://www.biglist....4/msg00198.html
 
attachicon.gifhmove.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.:
 
attachicon.gifDHmoveValues(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.



#6 SeaGtGruff OFFLINE  

SeaGtGruff

    Quadrunner

  • 5,566 posts
  • Location:South Carolina, USA

Posted Sat Jul 14, 2018 9:53 AM

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.



#7 Thomas Jentzsch OFFLINE  

Thomas Jentzsch

    Thrust, Jammed, SWOOPS!, Boulder Dash, THREE·S, Star Castle

  • 23,647 posts
  • Always left from right here!
  • Location:Düsseldorf, Germany, Europe, Earth

Posted Sat Jul 14, 2018 10:04 AM

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.



#8 SeaGtGruff OFFLINE  

SeaGtGruff

    Quadrunner

  • 5,566 posts
  • Location:South Carolina, USA

Posted Sat Jul 14, 2018 10:16 AM

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. :)



#9 Omegamatrix OFFLINE  

Omegamatrix

    Quadrunner

  • 6,215 posts
  • Location:Canada

Posted Sat Jul 14, 2018 11:31 AM

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. icon_wink.gif


Ciao, Eckhard Stolberg



#10 DirtyHairy OFFLINE  

DirtyHairy

    Moonsweeper

  • 476 posts
  • Location:Germany

Posted Sat Jul 14, 2018 1:20 PM

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 by DirtyHairy, Sat Jul 14, 2018 1:20 PM.


#11 RevEng OFFLINE  

RevEng

    River Patroller

  • 4,994 posts
  • Bitnik
  • Location:bottom of the stack

Posted Sat Jul 14, 2018 2:02 PM

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.

#12 alex_79 OFFLINE  

alex_79

    Stargunner

  • 1,184 posts
  • Location:Italy

Posted Sun Jul 15, 2018 7:32 AM

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/...m/#entry1820187



#13 ZackAttack OFFLINE  

ZackAttack

    Dragonstomper

  • Topic Starter
  • 754 posts
  • Location:Orlando, FL US

Posted Mon Jul 16, 2018 10:56 AM

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).






0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users