Jump to content
  • entries
    62
  • comments
    464
  • views
    86,898

HMOVE magic


supercat

809 views

The Atari 2600's HMOVE circuitry is, to put it mildly, interesting. I was just examining the schematics for it earlier today and figured out a trick that might be useful for some applications, most notably kernels in the style of Homestar Runner or Ruby Runner which move some sprites left and right by eight pixels on alternate scan lines.

 

The "classic" approach, invented by David Crane almost 30 years ago, was to only move sprites by seven pixels instead of eight and then shift the data bytes for alternate scan lines by a bit. This approach works, but it requires having blank columns since the sprites can't reach everywhere. A more modern approach is to use cycle 74 HMOVEs to push sprites eight pixels left and normal HMOVEs to push them right. This can be a little annoying, however, because it requires rewriting on every scan line the HMxx registers for any sprite whose motion is of interest.

 

There's another way, at least for "normal" Ataris (as distinct from "funny" Juniors).

 

Perform a "STA HMOVE" that starts at cycle 60. Perform another that starts on or before cycle 72.

 

Sprites with HMxx values of $00-$70 will behave normally. Sprites with an HMxx value of $80 will move left 8 pixels. Depending upon the amount of time between the HMOVEs, other values may cause sprites to become "confused". Note that $90 will always cause a sprite to become confused, and values $A0-$F0 that do not cause sprites to become confused will simply result in them not moving.

 

If it's desired to have some sprites move left and right by 8 pixels on alternate scan lines while other sprites stay put, the HMxx values for all the sprites may be set up beforehand: $80 for sprites that move and $00 for those that don't. Before a scan line where the $80 sprites are supposed to move right, do a "normal" HMOVE. On the line before those sprites are supposed to move left, do the funny double HMOVE described above. In this way, all the sprite motions can be handled without having to write HMxx or HMCLR during the kernel--just three HMOVEs every two lines.

4 Comments


Recommended Comments

That is a nice trick to save some cycles. It is a pity that it won't work on the PAL Jr, but I guess there are not too many of these around.

 

Chris

Link to comment
Have you tested this on hardware? And what do you mean by "confused"? This is very interesting, to say the least!

 

It does work on my 7800. I'll test it on my Heavy Sixer and "normal" Junior sometime.

 

If a sprite becomes "confused", it will move leftward 17 pixels per scan line, but on some scan lines it will appear distorted and on others it may be missing entirely, until the next HMOVE (note that even a RESxx will not unconfuse a sprite). Cosmic Ark uses this behavior to generate the starfield, and Journey Escape uses it to generate the background clutter.

 

That reminds me of something I need to test: whether sprites near the right edge of the screen may become distorted. Ruby Runner doesn't put sprites near the edge of the screen, but other games that use this trick might want to do so.

Link to comment

You're so quiet lately... already preparing for the next 10 year break?

 

Or secretly working on a surprise 1K entry? :)

Link to comment
Guest
Add a comment...

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