Jump to content

Photo

The HMOVE artifacts


36 replies to this topic

#1 TROGDOR OFFLINE  

TROGDOR

    Chopper Commander

  • 161 posts
  • Why Yes, I Have Played Atari Today.
  • Location:Strongbadia

Posted Wed Feb 8, 2006 1:30 AM

Can someone point me to a post or document that describes how HMOVE affects background display? I've been experimenting with moving sprites around in the kernel, and I'm seeing those nasty black lines on the left side of the screen that were so common in Atari games. I'm getting the feeling that these lines are unavoidable if HMOVE is called during on-screen scanlines, but I want to get the details so I can figure out how this will affect my game.

TIA (Thanks in advance, not Television Interface Adaptor)

#2 Tom OFFLINE  

Tom

    Moonsweeper

  • 455 posts
  • Location:Switzerland

Posted Wed Feb 8, 2006 1:46 AM

You get the HMOVE lines if you follow the stella manual and trigger HMOVE right at the start of a scanline. There are certain cycles (74 ?) where you can trigger HMOVE and get exact the same behaviour (same amount of movement for same HMxx value) without the HMOVE lines.

See http://www.biglist.c...4/msg00198.html

Does this work reliable on any 2600, btw ?

There are also games that trigger HMOVE on every scanline, which results in a black border over the whole left of the screen. Still better than garbage moving around to the left of the screen, imo.

#3 TROGDOR OFFLINE  

TROGDOR

    Chopper Commander

  • Topic Starter
  • 161 posts
  • Why Yes, I Have Played Atari Today.
  • Location:Strongbadia

Posted Wed Feb 8, 2006 2:03 AM

Thanks Tom. I found a ton of information here:

http://www.atarihq.c...IA_HW_Notes.txt

The section "Playing with the HMOVE registers" describes this problem in detail. Here's an excerpt from it:

The extra HBlank time shifts everything except the Playfield
right by 8 pixels, because the position counters will now
resume counting 8 CLK later than they would have without the
HMOVE. This is also the source of the HMOVE 'comb' effect;
the extended HBlank hides the normal playfield output for the
first 8 pixels of the line.

#4 vdub_bobby OFFLINE  

vdub_bobby

    Quadrunner

  • 5,832 posts
  • Boom bam.
  • Location:Seattle, WA

Posted Wed Feb 8, 2006 10:22 AM

You get the HMOVE lines if you follow the stella manual and trigger HMOVE right at the start of a scanline. There are certain cycles (74 ?) where you can trigger HMOVE and get exact the same behaviour (same amount of movement for same HMxx value) without the HMOVE lines.

See http://www.biglist.c...4/msg00198.html

Does this work reliable on any 2600, btw ?

:!:
No, it doesn't. On late-model Jrs the HMOVE lines cannot be hidden. There is info about this in the [stella] archives.

And, by the way, Reindeer Rescue hits HMOVE early to hide all HMOVE blank lines. ;)

#5 DEBRO OFFLINE  

DEBRO

    Stargunner

  • 1,946 posts
  • Location:Atlanta, GA

Posted Wed Feb 8, 2006 11:15 AM

:!:
No, it doesn't.  On late-model Jrs the HMOVE lines cannot be hidden.  There is info about this in the [stella] archives.

I wasn't aware of this :sad:

I guess I'll go fish through the archives to find the message.

#6 vdub_bobby OFFLINE  

vdub_bobby

    Quadrunner

  • 5,832 posts
  • Boom bam.
  • Location:Seattle, WA

Posted Wed Feb 8, 2006 11:33 AM

:!:
No, it doesn't.  On late-model Jrs the HMOVE lines cannot be hidden.  There is info about this in the [stella] archives.

I wasn't aware of this :sad:

I guess I'll go fish through the archives to find the message.

 

It might only be PAL Jrs; not sure. Also check the RR/Holiday Sale thread in the 2600 forum, Chris (cd-w) has one of those Jrs (his is PAL) and posted a pic of what it looks like, I believe.

EDIT: Linky: http://www.atariage....dpost&p=1001486

Though, looking at that pic, it looks more like the PF color is off somehow - which is...weird.

EDIT II: Chris, if you're reading this, could you possibly describe any of the ways in which RR runs different, from an emulator, on your PAL Jr?

Edited by vdub_bobby, Wed Feb 8, 2006 11:39 AM.


#7 Thomas Jentzsch OFFLINE  

Thomas Jentzsch

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

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

Posted Wed Feb 8, 2006 11:45 AM

I have one of those late PAL Jrs too. I'll check if the blanks can be hidden.

At least those consoles can be autodetected, so you may be able to adjust your code.

#8 Tom OFFLINE  

Tom

    Moonsweeper

  • 455 posts
  • Location:Switzerland

Posted Wed Feb 8, 2006 12:51 PM

I have two PAL juniors. Looks like I have to dig them out. What I know is what works on at least one of them is achieving an 8 pixel left shift by triggering HMOVE out of specs. I think that was an experiment with a 12/24 char kernel that moved the sprites left/right per scanline.

At least those consoles can be autodetected


How so ?

#9 Thomas Jentzsch OFFLINE  

Thomas Jentzsch

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

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

Posted Wed Feb 8, 2006 1:48 PM

At least those consoles can be autodetected

How so ?

 

HMOVE behaves different. So you position a sprite against a playfield pixel. If it is at the correct position it will trigger a collision, else not. I just this in my 11 invaders demo, which should work on both types of consoles.

#10 DEBRO OFFLINE  

DEBRO

    Stargunner

  • 1,946 posts
  • Location:Atlanta, GA

Posted Thu Feb 9, 2006 5:48 AM

What about PF timing writes on these 2600s? Are they consistent with the other 2600s? I know there are some cases where the 7800 might not time these writes correctly.

I ran into an issue where I was doing a write to PF2 at cycle 38. This works fine on the 2600 (or the models I have) but that was too late sometimes for the 7800. I found I had to do the write ~5 cycles earlier for the 7800 display to be consistent.

#11 Cybergoth OFFLINE  

Cybergoth

    Quadrunner

  • 8,876 posts
  • This is Sparta!
  • Location:Bavaria

Posted Thu Feb 9, 2006 7:16 AM

:!:
No, it doesn't.  On late-model Jrs the HMOVE lines cannot be hidden.  There is info about this in the [stella] archives.

I wasn't aware of this :sad:

I guess I'll go fish through the archives to find the message.


You're sure? That's the first time I hear that. Of course, maybe you got that confused with master programmer "belial" not getting it done for "Bobby needs Food" or so?

#12 cd-w OFFLINE  

cd-w

    Stargunner

  • 1,612 posts
  • Juno First!
  • Location:Glasgow, UK

Posted Thu Feb 9, 2006 7:56 AM

EDIT II:  Chris, if you're reading this, could you possibly describe any of the ways in which RR runs different, from an emulator, on your PAL Jr?

 


My PAL Jr is in storage at the moment, but the effects that I remember seeing were slighly garbled sprites in places, and the wierd colour blobs on either side of the screen. I ran into a similar problem when developing Hunchy 2. I think it is possible to hide the HMOVE bars, only that the behaviour is different on the Jr for some complex reasons.

Chris

#13 vdub_bobby OFFLINE  

vdub_bobby

    Quadrunner

  • 5,832 posts
  • Boom bam.
  • Location:Seattle, WA

Posted Thu Feb 9, 2006 10:23 AM

My PAL Jr is in storage at the moment, but the effects that I remember seeing were slighly garbled sprites in places, and the wierd colour blobs on either side of the screen.  I ran into a similar problem when developing Hunchy 2.  I think it is possible to hide the HMOVE bars, only that the behaviour is different on the Jr for some complex reasons. 

Looking closer at that pic you posted, those green blobs are the PF, which should be the same color as the background. That is really weird.

#14 vdub_bobby OFFLINE  

vdub_bobby

    Quadrunner

  • 5,832 posts
  • Boom bam.
  • Location:Seattle, WA

Posted Thu Feb 9, 2006 10:54 AM

:!:
No, it doesn't.  On late-model Jrs the HMOVE lines cannot be hidden.  There is info about this in the [stella] archives.

I wasn't aware of this :sad:

I guess I'll go fish through the archives to find the message.


You're sure? That's the first time I hear that. Of course, maybe you got that confused with master programmer "belial" not getting it done for "Bobby needs Food" or so?

 

Maybe my memory is faulty here. I remember something...

I think I read, somewhere, that hitting HMOVE early on the late-model (made in China?) Jrs will indeed hide the HMOVE line but it won't move the sprites properly. I'll see if I can figure out where I read this.

#15 DEBRO OFFLINE  

DEBRO

    Stargunner

  • 1,946 posts
  • Location:Atlanta, GA

Posted Mon Apr 10, 2006 8:51 AM

Maybe my memory is faulty here. I remember something...

I think I read, somewhere, that hitting HMOVE early on the late-model (made in China?) Jrs will indeed hide the HMOVE line but it won't move the sprites properly. I'll see if I can figure out where I read this.

Is there anymore development on this? I'd like to hide the HMOVE lines but if it affects sprite movement I might have to forget about it.

#16 Cybergoth OFFLINE  

Cybergoth

    Quadrunner

  • 8,876 posts
  • This is Sparta!
  • Location:Bavaria

Posted Mon Apr 10, 2006 9:42 AM

I still think it's a safe technique. Really no clue were this "doubtfull" atmosphere is coming from lately. If it wouldn't work or affect sprite movement, someone would've complained by now, since I use it in Gunfight since 2001.

#17 vdub_bobby OFFLINE  

vdub_bobby

    Quadrunner

  • 5,832 posts
  • Boom bam.
  • Location:Seattle, WA

Posted Mon Apr 10, 2006 10:10 AM

Maybe my memory is faulty here. I remember something...

I think I read, somewhere, that hitting HMOVE early on the late-model (made in China?) Jrs will indeed hide the HMOVE line but it won't move the sprites properly. I'll see if I can figure out where I read this.

Is there anymore development on this? I'd like to hide the HMOVE lines but if it affects sprite movement I might have to forget about it.

Okay, I did some serious looking just now, and this is what I found. Mostly from the [stella] archives. I had to read (and reread) about five different documents before I kind of got my head wrapped around what is going on, so I'm just going to link/paste a bunch of quotes and then try to explain what I *think* is going on at the end. :)

First, Eckhard: http://atari2600.org...ber/017423.html

IIRC the problem is that some of the clock lines are used for
different purposes during the visible part of the screen and
during the horizontal blank. The HMOVE positioning clock pulses
are supposed to happen only during the horizontal blank. But
you can also generate them during the visible part of the screen
either by triggering the HMOVE register there or by triggering
the Cosmic Ark starfield effect during HBLANK.

On a normal TIA the extra HMOVE clock pulses don't have any effect,
but on the China-TIA they seem to be delayed enough to overlap
with the pixel counter pulses in a line in such a way that the
gap between two pulses will be bridged when it's time to compare
the pixel counter with the player position counters. The result of
this is that the two pulses will only be seen as one, and that
therefore the players will be shifted to the right by one pixel,
because the pixel counter matches the player position counters
one clock cycle later. AFAIK only the player graphics are affected
by this. The missiles and the ball are positioned the same on
all TIAs.

Next, Andrew Towers: http://www.whimsey.c...IA_HW_Notes.txt

I mentioned above that HMOVE sends extra clock pulses down
the same clock lines that are usually used during the visible
part of the scanline. In theory this means that performing a
HMOVE during the visible part of the scanline should have no
effect. However, looking at how the various clock signals
interact, I suspect it is possible. I did some preliminary
experiments (on a 2600 Jr) at some point, and I seem to
remember having some success.

Next, Eckhard again: http://atari2600.org...ber/019419.html

HMOVE only stuffs pulses through the position counters during the
horizontal blank period. During the visible part of the line the
pulses are ignored. The pulses can only create leftward motion.

You can hit HMOVE at any time in the scanline and it will go through
it's full 15-pulses cycle. But only pulses that happen during the
horizontal blank period will have any effect. It doesn't matter
which of these pulses happen during the horizontal blank.

Now Andrew Towers again: http://atari2600.org...rch/017950.html

I haven't been able to find anything specific in the schematics
either for this one; all I can tell you is the doubling/missing
missile pixels must be due to interactions between the normal
movable object clock (MOTCK) and the extra pulses sent by HMOVE
during the visible part of the scanline.

In particular, I have reasoned thus: the effect repeats itself
every four lines which is interesting because it corresponds
to the starting phase of the two-phase clocked logic for the
missile position counter. There are 68 clocks of HBLANK time,
and each HMOVE moves the missile 17 pixels left. If I were to
do this four times, I would have used up 68 clocks (17*4=68)
so I'm back where I started. The position counter counts once
for every four clocks, and each line I add 17 -- so I actually
add 4 and 1/4 counts to the position counter each line. This
puts the position counter 1/4 out of phase with the previous
line each time.

This does not explain the doubling/missing effect, but it lays
the groundwork. The 17 pixel left shift is due to extra HMOVE
clocks during the non-visible part of the scanline; this is
quite straight-forward. I belive the strange pixel behavour
is due to "undefined" interactions between the normal MOTCK
and the extra HMOVE pulses during the *visible* part of the
scanline only.

I call these "undefined" because the interactions depend entirely
on the precise phase between the two clock signals (the HMOVE
pulses are twice as wide as the MOTCK pulses, and only come once
every 4th MOTCK). The phase depends on the gate delays introduced
on the HMOVE signal (approx. 4 gates worth), which in turn depends
on the exact transistor layout of the gates and the manufacturing
process used!

With this in mind, it can be seen that the HMOVE clock might
simply extend a normal MOTCK pulse, causing a double-wide pulse.
This might coincide nicely with two pixel clocks, causing a
double-pixel to be displayed, but only if it falls on the correct
1/4 cycle of the position counter.

Alternatively, with different transistor sizes in a later revision
(the TIA-1A schematics mention sizes changing for that revision),
the behaviour might be completely different, with the extra HMOVE
pulses plugging up MOTCK pulses instead of widening them.

Eckhard again: http://atari2600.org...rch/017948.html

But during the visible part of the screen the clock line for
the HMOVE shifting pulses is used for different things, like
advancing the pixel counter for the line. So on most VCSs
the extra HMOVE pulses have no effect during the visible part
of the screen.


Okay, after all that mish-mash, here's what I've got:
On the late-model, china TIAs, HMOVE pulses sent during the visible scanline *do* have an effect on object positions, unlike other TIAs - which means that hitting HMOVE during the visible scanline will move objects differently than on other TIAs. This is why Kool-Aid Man has issues on certain 2600s. AFAIK the HMOVE-blank is still hidden, though. I think TJ has mentioned a couple of times that you can detect which model TIA is being used; if this is possible then you could probably use different HMxx values depending on which TIA is being used and correct for the problem.

Does this make sense? Spot any errors?

#18 vdub_bobby OFFLINE  

vdub_bobby

    Quadrunner

  • 5,832 posts
  • Boom bam.
  • Location:Seattle, WA

Posted Mon Apr 10, 2006 10:16 AM

I still think it's a safe technique. Really no clue were this "doubtfull" atmosphere is coming from lately. If it wouldn't work or affect sprite movement, someone would've complained by now, since I use it in Gunfight since 2001.

1. How many late-model, China-made TIAs are out there, and how many people that have one have Gunfight? AFAIK, differences *have* been seen in other games (Kool-Aid Man, at least).
2. Maybe there is no effect for HMOVE hit at cycles 73-76, since the issue seems to be HMOVE pulses sent during the visible part of the scanline, and maybe HMOVE hit at cycle 73/74 is late enough that it doesn't matter. Since HMOVE pulses only have an effect if sent during the visible scanline and yet HMOVE hit at 73/74 still gives the full range of motion* (0-15 pixels), I would assume that for a 73/74 HMOVE all HMOVE pulses are coming during the HBLANK period. :ponder:

So...???

*Judging from this chart (http://www.qotile.ne.../code/hmove.txt), the only cycles at which you can hit HMOVE and still have the full range of motion are cycles 73-3, where STA HMOVE ending at cycles 75, 76, 1, 2, and 3 will cause normal behavior and a STA HMOVE ending at cycles 73 or 74 will suppress the horizontal blank and will therefore shift the range of motion left by 8 pixels (-15 to 0 vs. -8 to 7).

Edited by vdub_bobby, Mon Apr 10, 2006 10:20 AM.


#19 DEBRO OFFLINE  

DEBRO

    Stargunner

  • 1,946 posts
  • Location:Atlanta, GA

Posted Mon Apr 10, 2006 10:48 AM

Man, you really pulled some info from [stella]. Thanks for the links and all.

2. Maybe there is no effect for HMOVE hit at cycles 73-76, since the issue seems to be HMOVE pulses sent during the visible part of the scanline, and maybe HMOVE hit at cycle 73/74 is late enough that it doesn't matter. Since HMOVE pulses only have an effect if sent during the visible scanline and yet HMOVE hit at 73/74 still gives the full range of motion* (0-15 pixels), I would assume that for a 73/74 HMOVE all HMOVE pulses are coming during the HBLANK period. :ponder:

If this is the case then I think we're all okay. I'd still like to hear some results on one of these 2600 models with hitting HMOVE at cycle 71 or 72.

#20 Cybergoth OFFLINE  

Cybergoth

    Quadrunner

  • 8,876 posts
  • This is Sparta!
  • Location:Bavaria

Posted Mon Apr 10, 2006 12:09 PM

I would assume that for a 73/74 HMOVE all HMOVE pulses are coming during the HBLANK period. :ponder:

So...???


Well, not the slightest clue about all the hardware rhabarber - but unless someone can prove that this trick doesn't work on his Jr. - it does work on all :)

And - even if it doesn't - it's their TIA that's broken, not the software.

#21 Robert M OFFLINE  

Robert M

    Stargunner

  • 1,488 posts
  • Rootbeer!
  • Location:Western NY state

Posted Mon Apr 10, 2006 1:45 PM

Thanks Tom. I found a ton of information here:

http://www.atarihq.c...IA_HW_Notes.txt

The section "Playing with the HMOVE registers" describes this problem in detail. Here's an excerpt from it:

The extra HBlank time shifts everything except the Playfield
right by 8 pixels, because the position counters will now
resume counting 8 CLK later than they would have without the
HMOVE. This is also the source of the HMOVE 'comb' effect;
the extended HBlank hides the normal playfield output for the
first 8 pixels of the line.


Day dreaming here. :ponder: If they had considered adding a HMOVE register for the playfield that would shift the display -8 to +7 pixels on every line. Smooth horizontal scrolling would have been doable, and the vertical HMOVE bar on the left would hide data being scrolled on or off the screen. :love: Ah the possibilities.

#22 Thomas Jentzsch OFFLINE  

Thomas Jentzsch

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

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

Posted Mon Apr 10, 2006 2:02 PM

Day dreaming here. :ponder: If they had considered adding a HMOVE register for the playfield that would shift the display -8 to +7 pixels on every line. Smooth horizontal scrolling would have been doable, and the vertical HMOVE bar on the left would hide data being scrolled on or off the screen. :love: Ah the possibilities.

Yes, that would have been great.

But did scrolling games even exist at all in 1977?

Edited by Thomas Jentzsch, Mon Apr 10, 2006 2:02 PM.


#23 batari OFFLINE  

batari

    )66]U('=I;B$*

  • 6,673 posts
  • begin 644 contest

Posted Mon Apr 10, 2006 2:10 PM

Day dreaming here. :ponder: If they had considered adding a HMOVE register for the playfield that would shift the display -8 to +7 pixels on every line. Smooth horizontal scrolling would have been doable, and the vertical HMOVE bar on the left would hide data being scrolled on or off the screen. :love: Ah the possibilities.

Yes, that would have been great.

But did scrolling games even exist at all in 1977?

Yup.

#24 Cybergoth OFFLINE  

Cybergoth

    Quadrunner

  • 8,876 posts
  • This is Sparta!
  • Location:Bavaria

Posted Mon Apr 10, 2006 2:23 PM

I thought there once was some bit in [Stella] about shifting the whole playfield or so, but I can't find it. Maybe something using RSYNC?

#25 Thomas Jentzsch OFFLINE  

Thomas Jentzsch

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

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

Posted Mon Apr 10, 2006 2:40 PM

Yup.

:)




0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users