Jump to content
TROGDOR

The HMOVE artifacts

Recommended Posts

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)

Share this post


Link to post
Share on other sites
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 [url="http://www.biglist.com/lists/stella/archives/199804/msg00198.html"]http://www.biglist.com/lists/stella/archiv...4/msg00198.html[/url]

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.

Share this post


Link to post
Share on other sites
Thanks Tom. I found a ton of information here:

[url="http://www.atarihq.com/danb/files/TIA_HW_Notes.txt"]http://www.atarihq.com/danb/files/TIA_HW_Notes.txt[/url]

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.

Share this post


Link to post
Share on other sites
[quote name='Tom' date='Tue Feb 7, 2006 11:46 PM']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 [url="http://www.biglist.com/lists/stella/archives/199804/msg00198.html"]http://www.biglist.com/lists/stella/archiv...4/msg00198.html[/url]

Does this work reliable on any 2600, btw ?[/quote]
:!:
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. ;)

Share this post


Link to post
Share on other sites
[quote name='vdub_bobby' date='Wed Feb 8, 2006 12:22 PM']:!:
No, it doesn't.  On late-model Jrs the HMOVE lines cannot be hidden.  There is info about this in the [stella] archives.[/quote]
I wasn't aware of this :sad:

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

Share this post


Link to post
Share on other sites
[quote name='DEBRO' date='Wed Feb 8, 2006 9:15 AM'][quote name='vdub_bobby' date='Wed Feb 8, 2006 12:22 PM']:!:
No, it doesn't.  On late-model Jrs the HMOVE lines cannot be hidden.  There is info about this in the [stella] archives.[/quote]
I wasn't aware of this :sad:

I guess I'll go fish through the archives to find the message.
[right][snapback]1015124[/snapback][/right]
[/quote]
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: [url="http://www.atariage.com/forums/index.php?showtopic=80246&view=findpost&p=1001486"]http://www.atariage.com/forums/index.php?s...dpost&p=1001486[/url]

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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

[quote name='Thomas Jentzsch' date='Wed Feb 8, 2006 12:45 PM']At least those consoles can be autodetected
[/quote]

How so ?

Share this post


Link to post
Share on other sites
[quote name='Tom' date='Wed Feb 8, 2006 7:51 PM'][quote name='Thomas Jentzsch' date='Wed Feb 8, 2006 12:45 PM']At least those consoles can be autodetected
[/quote]
How so ?
[right][snapback]1015164[/snapback][/right][/quote]
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
[quote name='DEBRO' date='Wed Feb 8, 2006 5:15 PM'][quote name='vdub_bobby' date='Wed Feb 8, 2006 12:22 PM']:!:
No, it doesn't.  On late-model Jrs the HMOVE lines cannot be hidden.  There is info about this in the [stella] archives.[/quote]
I wasn't aware of this :sad:

I guess I'll go fish through the archives to find the message.[/quote]

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?

Share this post


Link to post
Share on other sites
[quote name='vdub_bobby' date='Wed Feb 8, 2006 5:33 PM']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?
[right][snapback]1015134[/snapback][/right]
[/quote]

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 [url="http://www.atariage.com/forums/index.php?showtopic=72308&st=50&p=903045&#entry903045"]developing Hunchy 2[/url]. I think it is possible to hide the HMOVE bars, only that the behaviour is different on the Jr for some complex reasons.

Chris

Share this post


Link to post
Share on other sites
[quote name='cd-w' date='Thu Feb 9, 2006 5:56 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 [url="http://www.atariage.com/forums/index.php?showtopic=72308&st=50&p=903045&#entry903045"]developing Hunchy 2[/url].  I think it is possible to hide the HMOVE bars, only that the behaviour is different on the Jr for some complex reasons.  [/quote]
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.

Share this post


Link to post
Share on other sites
[quote name='Cybergoth' date='Thu Feb 9, 2006 5:16 AM'][quote name='DEBRO' date='Wed Feb 8, 2006 5:15 PM'][quote name='vdub_bobby' date='Wed Feb 8, 2006 12:22 PM']:!:
No, it doesn't.  On late-model Jrs the HMOVE lines cannot be hidden.  There is info about this in the [stella] archives.[/quote]
I wasn't aware of this :sad:

I guess I'll go fish through the archives to find the message.[/quote]

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?
[right][snapback]1015587[/snapback][/right]
[/quote]
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.

Share this post


Link to post
Share on other sites
[quote name='vdub_bobby' post='1015681' date='Thu Feb 9, 2006 12:54 PM']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.[/quote]
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
[quote name='DEBRO' post='1048968' date='Mon Apr 10, 2006 7:51 AM'][quote name='vdub_bobby' post='1015681' date='Thu Feb 9, 2006 12:54 PM']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.[/quote]
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.
[/quote]
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: [url="http://atari2600.org/pipermail/stella/2004-October/017423.html"]http://atari2600.org/pipermail/stella/2004...ber/017423.html[/url]
[quote]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.[/quote]Next, Andrew Towers: [url="http://www.whimsey.com/atari_docs/TIA_HW_Notes.txt"]http://www.whimsey.com/atari_docs/TIA_HW_Notes.txt[/url]
[quote]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.[/quote]
Next, Eckhard again: [url="http://atari2600.org/pipermail/stella/2005-November/019419.html"]http://atari2600.org/pipermail/stella/2005...ber/019419.html[/url]
[quote]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.[/quote]Now Andrew Towers again: [url="http://atari2600.org/pipermail/stella/2005-March/017950.html"]http://atari2600.org/pipermail/stella/2005-March/017950.html[/url]
[quote]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.[/quote]
Eckhard again: [url="http://atari2600.org/pipermail/stella/2005-March/017948.html"]http://atari2600.org/pipermail/stella/2005-March/017948.html[/url]
[quote]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.[/quote]

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?

Share this post


Link to post
Share on other sites
[quote name='Cybergoth' post='1048983' date='Mon Apr 10, 2006 8: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.[/quote]
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.net/minidig/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

Share this post


Link to post
Share on other sites
Man, you really pulled some info from [stella]. Thanks for the links and all.
[quote name='vdub_bobby' post='1049000' date='Mon Apr 10, 2006 12:16 PM']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:[/quote]
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.

Share this post


Link to post
Share on other sites
[quote name='vdub_bobby' post='1049000' date='Mon Apr 10, 2006 4:16 PM']I would assume that for a 73/74 HMOVE all HMOVE pulses are coming during the HBLANK period. :ponder:

So...???[/quote]

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.

Share this post


Link to post
Share on other sites
[quote name='TROGDOR' post='1015015' date='Wed Feb 8, 2006 2:03 AM']Thanks Tom. I found a ton of information here:

[url="http://www.atarihq.com/danb/files/TIA_HW_Notes.txt"]http://www.atarihq.com/danb/files/TIA_HW_Notes.txt[/url]

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

The extra HBlank time shifts everything [b]except the Playfield[/b]
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.[/quote]

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.

Share this post


Link to post
Share on other sites
[quote name='Robert M' post='1049083' date='Mon Apr 10, 2006 9:45 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.[/quote]
Yes, that would have been great.

But did scrolling games even exist at all in 1977? Edited by Thomas Jentzsch

Share this post


Link to post
Share on other sites
[quote name='Thomas Jentzsch' post='1049093' date='Mon Apr 10, 2006 3:02 PM'][quote name='Robert M' post='1049083' date='Mon Apr 10, 2006 9:45 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.[/quote]
Yes, that would have been great.

But did scrolling games even exist at all in 1977?
[/quote]
[url="http://www.klov.com/game_detail.php?letter=&game_id=9875"]Yup.[/url]

Share this post


Link to post
Share on other sites
[quote name='batari' post='1049098' date='Mon Apr 10, 2006 10:10 PM'][url="http://www.klov.com/game_detail.php?letter=&game_id=9875"]Yup.[/url][/quote]
:)

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...