View Single Post
Old 09 January 2017, 21:58   #5
dissident
Registered User

 
Join Date: Sep 2015
Location: Germany
Posts: 224
Lightbulb

Quote:
Originally Posted by Toni Wilen View Post
I am sure your theory #2 is correct. Sprite is not horizontally armed when horizontal comparison matches = sprite's shift register won't get loaded or only SPRxDATA gets loaded (and DATB gets previous line's data, I guess) if match position is after sprite's DATA DMA but before sprite's DATB DMA slot.

SPRxDATA write does the horizontal arming.

It can't be #1, copper, blitter or cpu can't steal sprite cycles. (Only bitplanes can steal sprite cycles).
Okay, thank you for your quick reply, Toni. So I was not totally wrong with my theories. Fine.

Quote:
Originally Posted by Toni Wilen View Post
Do you have some example code that shows this (and does nothing else)? Because I am so lazy to test it myself.. You can email if you prefer to keep it secret. Executable only is fine, I don't need sources.
I've sent you an e-mail with the exe-file(s).

Quote:
Originally Posted by Toni Wilen View Post
My first guess can't be right, it has nothing to do with armed status. (It is always good idea to check HRM and current emulation code before guessing anything too weird..)

It is most likely really simple reason: horizontal comparison matches after DATA has been loaded but before DATB: DATB still has previous line's data.
I guess I will change my routine that way, dropping the use of SPR6/7 to avoid the obvious display error in the overscan region. The error with SPR4/5 is not so obvious, because there, it's only at the beginning of the overscan region.
dissident is offline  
 
Page generated in 0.04172 seconds with 11 queries