Jump to content
IGNORED

The HMOVE artifacts


TROGDOR

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)

Link to comment
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 http://www.biglist.com/lists/stella/archiv...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.

Link to comment
Share on other sites

Thanks Tom. I found a ton of information here:

 

http://www.atarihq.com/danb/files/TIA_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.

Link to comment
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 http://www.biglist.com/lists/stella/archiv...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. ;)

Link to comment
Share on other sites

:!:

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.

1015124[/snapback]

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.com/forums/index.php?s...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
Link to comment
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.

 

At least those consoles can be autodetected

 

How so ?

Link to comment
Share on other sites

At least those consoles can be autodetected

How so ?

1015164[/snapback]

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.

Link to comment
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.

Link to comment
Share on other sites

:!:

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?

Link to comment
Share on other sites

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?

1015134[/snapback]

 

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

:!:

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?

1015587[/snapback]

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.

Link to comment
Share on other sites

  • 2 months later...
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.

Link to comment
Share on other sites

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/pipermail/stella/2004...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.com/atari_docs/TIA_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/pipermail/stella/2005...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/pipermail/stella/2005-March/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/pipermail/stella/2005-March/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?

Link to comment
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.

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

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

Thanks Tom. I found a ton of information here:

 

http://www.atarihq.com/danb/files/TIA_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.

Link to comment
Share on other sites

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

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.

Link to comment
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.
Note: Your post will require moderator approval before it will be visible.

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