Re: [stella] Games that do bad things to HMOVE...

Subject: Re: [stella] Games that do bad things to HMOVE...
From: Erik Mooney <emooney@xxxxxxxxxxxxxxxx>
Date: Thu, 23 Apr 1998 09:36:15 -0400 (EDT)
> PC=f622 IR=85 <$nn        2  STA> A= 7 X= 0 Y=ff PS=20 SP=fd Cyc=8284  0
> PC=f624 IR=ea <implied    0  NOP> A= 7 X= 0 Y=ff PS=20 SP=fd Cyc=8286  2
> PC=f625 IR=a8 <implied    0  TAY> A= 7 X= 0 Y= 7 PS=20 SP=fd Cyc=8288  4

Just out of curiosity, what debugger is generating that? (I really hope
you aren't typing it... :) )

> So they waste 71 cycles and hit HMOVE ending on cycle 74.  Thus they 
> are hitting HMOVE two cycles before HBLANK begins.
> Now, the best I can figure is that by hitting HMOVE at this time it
> reduces the amount of motion applied to the objects by 6 clocks.
> So that instead of moving P0 by 8 pixels and P1 by 7 pixels it
> moves them by 2 and 1 pixels.
> So we have that because HMOVE occurs at cycle 74 we loose 6 color clocks
> and the pixel locations are:
>   128 + 2 = 130   130 - 68 = 62
>   137 + 1 = 138   138 - 68 = 70
> Using these pixel locations the drawing works out and the text is displayed 
> as it should be.

Innnteresting.  Do you always lose 6 pixels that way, in the same
direction?  That is, could you  set HMP0 and HMP1 to move , say, seven
pixels left each, and then do the early HMOVE, moving 13 pixels in a
single HMOVE?
> What do you all think?  Is this what happens when you hit HMOVE near
> the end of a scanline?  
> Does this mean that if you hit HMOVE during let's say the middle of a 
> scanline it would have no effect?

Or it might move the objects 30 or 40 pixels one direction. :)  experiment
> Finally, do you have any idea why they decided to do it this way?  
> I'm guessing that it somehow avoids the HMOVE BLANK lines and they
> wanted this because they have a border around the title screen.

Who says they knew what they were doing?   It could've been just trial and
error and it happened to work... I certainly did enough of that in the INV
kernel :)  If it does avoid the HMOVE lines, though, it might be worth
keeping and looking into.  (unfortunately, I can't think of a way to
position a sprite variably and then do the HMOVE on cycle 74 that same
scanline... anyone?)

Archives (includes files) at
Unsub & more at

Current Thread