Jump to content
rbairos

8 pixel back-n-forth sprite shift

Recommended Posts

Hello, doing some work shifting sprite back and forth each line, 
but am I correct in thinking the maximum back-n-forth shift is 7 pixels?

That is, I do quite a bit of rendering throughout the line, and near the end I need to shift things forward or backward 8 pixels for the next line.
I realize HMP0,1 only allow +8 through -7,  so am I out of luck?

Thanks,
Rob.
 

Share this post


Link to post
Share on other sites

You need to do a late HMOVE: if you strobe HMOVE at the correct cycle at the end of the line, all extra cycles sent by the TIA will fall into HBLANK (causing a reliable movement to the left) but the latch that triggers the extended HBLANK will be reset --- this gives you between 0 and 15 clocks of movement to the left. From the top of my head, doing a "STA HMOVE" during cycle 71 or 72 should work fine. The left shift achieved this way is determined by the high nibble of HMx with the highest bit inverted --- i.e. HMP0 = $00 will give you 8 pixels movement to the left, and HMP0 = $70 will give you 15 pixels movement to the left.

Edited by DirtyHairy
  • Like 1

Share this post


Link to post
Share on other sites

So cycle 71 (HMPx == 0) does the trick to shift back 8 pixels.

Funnily enough, if its at 72,  the counter does tick left 8 pixels, but then shifts back to original position.
 

Share this post


Link to post
Share on other sites

I wonder... I think this is a one-off error ;) My counting starts with cycle 1, but maybe your counting starts with cycle 0. If you are one cycle too late, the extended hmove latch will not be cleared, and you end up with an ordinary HMOVE --- you get eight pulses together with eight pixels movement to the right from the extended hblank, which amounts to zero pixels movement.

 

If you strobe HMOVE too early, you will get extra pulses during the visible part of the scanline where they either coincide with or fill the gap between regular pulses, depending on the generation of the TIA. This is the main reason for the differences between different console generations.

Share this post


Link to post
Share on other sites

I'll have to verify, but was using stella to note the cycle clock.
But in the case where it does work (72, or 71 base 0), should I expect it to work on most systems then?
Aiming for heavy-sixer, and FB2 mod.

Thanks,
Rob.
 

Share this post


Link to post
Share on other sites

Stella starts counting with cycle 0. It seems that using the earlier cycle (71 if you start counting with 1) is unstable on some Jr. machines: 

Afaik, using the latest possible cycle (72) should be fine. While this trick is not part of the standard repertoire of VCS development, it is not that exotic either; there are many ROMs out there that use it. In particular, it is required to create a 96 pixel flickerblinds bitmap.

Share this post


Link to post
Share on other sites
28 minutes ago, SpiceWare said:

When using HMOVE this way I use cycle 73 or 74 based on research by Bradford Mott. If hit on cycle 72 the movement would only be -7.

I am talking about the cycle where STA HMOVE starts, not about the actual access, that‘s the reason for the discrepancy 😏

Share this post


Link to post
Share on other sites

So I got a kernel working with this method.
Works on stella emulator, light sixer, even the Flashback 2.
I should be able to try out Colecovision adapter soonish.
 

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