[comp.sys.amiga.tech] Larry's ghost fix works....why?

addison@pollux.usc.edu (Richard Addison) (10/21/89)

In article <4202@abaa.UUCP> esker@abaa.UUCP (Lawrence Esker) writes:
>This brings an interesting question.  From the above desription, the Amiga
>preloads the sprite data and then multiplexes the preload data with the
>bitmap data being read on the fly.  When the time comes to display the sprite,
>the multiplexer ignores the bitmap data and uses the preloaded sprite data.
>
>Assuming the above to be true, why didn't the design multiplex the bitmap
>current address with a sprite address generator?  When the time for the sprite
>arrives, the chip ram address would just change.  This would avoid the use
>of preload data buffers, indirectly allowing sprites to be any width.  Would
>also free the time slots allocated to the sprites.

The multiplexer does not ignore the bitmap data.  Look at your mouse pointer,
is it a 16 bit wide opaque block aligned on a 16 bit boundary?  

The flexibility of the sprite engine comes from that fact that it has
transparency.  The dual-playfield mode is sort of an extension of that.
But, as you probably know, all of these accesses need to share the same
pool of memory.

I understand the decision to have the sync signals fixed while allowing the
data fetch and display to be programmable.  (Compare this to how the video
controller works on the old Color Graphics Adapter on the IBM PC's.  Did
you ever seen one of those change display modes?  It would upset the sync
on the monitor!  On the Amiga, you can change modes in mid-display!  It
all stays rock steady.)

However, would it not have been possible to design the custom chips to fetch
the sprite data for line n after fetching the bitmap data for line n-1 when
the Display Fetch Data Start occurs too soon to allow the sprite data to be
fetched at the beginning of line n?  Yes, I know it's more complicated, but
I think these "vertical bar" sprite problems occur quite frequently for
typical users who don't know that it doesn't mean their machine is broken.

(Parse that!)

Oh, by the way, since this is getting somewhat more technical, I've set the
"Followup-To:" line appropriately.

Richard Addison
"But officer, I didn't see that motorcycle 'cause of Preferences!"