Path: utzoo!mnetor!uunet!husc6!hao!ames!ucsd!sdcsvax!ucsdhub!hp-sdd!hplabs!well!ewhac
From: ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab)
Newsgroups: comp.sys.amiga
Subject: Re: Simple sprite question
Message-ID: <5163@well.UUCP>
Date: 6 Feb 88 01:38:26 GMT
References: <880@isrnix.UUCP>
Reply-To: ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab)
Organization: Speak Before You Think Enterprises
Lines: 135
Keywords: joke
Summary: If Mike Smithwick can write amusing stuff, so can I.
Warning: Believing the following posting may be hazardous to your sanity.


In article <880@isrnix.UUCP> greg@isrnix.UUCP (Gregory Travis) writes:
>If the system is limited to 8 sprites in any given horizontal
>plane and if the CLI cursor is itself a sprite (which I read
>somewhere) howcome I can open more than 10 cli windows on my
>1000?  Note that I make the windows very small and stack them
>horizontally:
>
>	[][][][][][][][][][]
>
>So that their cursors are all on the same scan lines.
>
	You have just accidentally stumbled upon one of the best kept
secrets in the Amiga, as well as one of the finest hacks ever perpetrated.

	I noted the same behavior you did many many moons ago, and decided
that I was going to get to the bottom of it once and for all.  Thus ensued
my three-week-long foray into the innards of the Amiga.

	I disassembled.  I PEEKed.  I POKEed.  I dereferenced pointers.  I
disassembled COPPER lists.  I fiddled with the Blitter.  I had the COPPER
stuff the Blitter registers.  I had the Blitter write into FAST RAM.  I
read the DOS manuals over and over and over and over and over and over....
I had the sprite DMA channel connected to the audio DMA channel, and tied it
to the memory refresh and disk DMA channels, patched it into LIVE!, and had
the video fetch DMA getting its pixel colors from the parallel port.  After
three long weeks, I was ready to give up....

	When SUDDENLY!  I figured it out!

	Intuition, Graphics, Exec, and the console.device are all much more
tightly integrated than anyone ever suspected before.  You see, the
graphics.library has a complete Copper list assembler/editor with AI
heuristics, which, by what I can divine, was originally written in SNOBOL.
This AI subsystem is closely connected to Intuition's window manager, and
the console.device.

	When the console.device moves its cursor, it tells Intuition about
it (using message ports running a variant of the InterNet protocol).
Intuition then maps the window's cursor to display coordinates, and then
issues a complex stream of string-based requests to the Copper AI software.
Using a piece of software I'm beta-testing for ASDG (MetaRomScopeGrandDBWack),
I managed to watch this transaction in action.  It goes something like this:

Intuition: "Yo!  Dale!  I need a favor..."
Copper AI: "Sure, -=RJ=-, whatcha need?"
I:	"Well, I have this cursor here which needs to be moved."
CAI:	"No problem.  Have a beer and we'll talk about it."
	[ At this point, an enormous chemical formula flies through which I
	utterly failed to understand. ]
I:	"Mmmmm.  Very good.  Well, about my cursor..."
CAI:	"Right.  Where do you need it?"
I:	[ Specifies coordinates in hex ]
CAI:	"Hmmmm.  Tricky.  You realize that it'll be off by one pixel; does
	that cause problems?"
I:	"No, I corrected for that already."
CAI:	"Ah.  Yeah, I can do that.  Lemme think about it for a bit and I'll
	have it ready for you."
	[ 75 microseconds pass, during which, there's a lot of CPU
	stomping on undocumented custom chip registers. ]
CAI:	"Okay, it'll be taken care of during the next vblank."
I:	"Very cool!"
CAI:	"No problem.  See you."
I:	"See you.  Thanks for the beer."

	After seeing this transaction, I decided to inspect the copper
lists.  They looked completely normal and unremarkable.  This didn't seem
right to me, yet the cursor sprites remained on the screen just fine.

	So I bit the bullet, and decided to simulate the CPU stomping on the
undocumented custom chip registers.  Nothing happened.  So I fiddled a bit
with the data that was being written, and...... ONE OF THE CURSORS MOVED!

	After some hours of hacking, I discovered how to move any cursor to
any position, and how to add and delete them.  But, it seemed, there was
more here that was meeting the eye.  So I went to work studying the data I
was writing to the chip registers.

	"Strange," I thought, "It looks like 68000 object code."  So I
disassmebled the code by hand, and I got a short little machine program.  It
appeared to refer to known custom chip registers, as well as memory space at
a very high address.

	So I thought, what the hell, and wrote a small 68000 program that
spun in a tight loop for 65536 iterations, and continued.  I sent this to
the custom chips, and gave the correct protocol to run it.  The screen
jumped briefly!

	I knew I was close.  I rewrote the program to make the loop iterate
2^32 times so I could see what was going on.  I sent the program and had it
execute.  My jaw dropped as I looked at the screen....

	THE VIDEO BEAM HAD STOPPED MOVING!  It was just a spot, off to one
side, colored blue.  Suddenly, it started moving again, and the system
behaved normally.

	I ran the program again, and timed the duration of the video beam
halt.  I then ran a few calculations (using HaiTex's 3D scientific
calculator), and discovered that the delay was exactly as long as it would
take a 68000 to count to 2^32 if it were running at eight times the hi-res
dot clock rate.

	After some more exploring, I discovered that the custom chips house
a totally seperate 68000 running at a high rate, but with only 8K of RAM,
and 1K of ROM.  It also doesn't have access to the outside system; it is its
own private world.  It is this 68000 that manages the custom chip
operations, and literally drives the video beam.  This is why the program I
wrote stopped the video beam.  The tight loop I put it in stopped all its
operations, and it couldn't drive the beam anymore, so it stopped.

	Getting back to sprites:  As far as outside programs are concerned,
there are only eight sprites available per video line.  However, the
graphics software seems to know about the "other" 68000 inside the custom
silicon.  It sends a small program which alters the behavior of the main
video driving program.  Since the "other" 68000 runs blindingly fast, and
since its responsible for painting the screen, it briefly re-allocates one
of the sprite channels, and paints it in the right place, even in hi-res.

	So in fact, what you're seeing is not ten sprites, or eight sprites
with judicious re-use, it's *ONE* sprite that's being flipped around the
screen.  The video driver program knows where all the user's sprites are,
and if there is a collision, it sorts the priority on a pixel-by-pixel
basis, and flips between images as needed.

	I was going to write an incredibly neat display hack using this
technology, but every time I tried to write something, the system would Guru
with the code 4E594148.4E594148.  So I gave up.

	After my discovery, I've come to the conclusion that -=RJ=-, Dale,
and Jay are Gods.  Be nice to them next time you meet them...

_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
Leo L. Schwab -- The Guy in The Cape	ihnp4!ptsfa -\
 \_ -_		Recumbent Bikes:	      dual ---> !{well,unicom}!ewhac
O----^o	      The Only Way To Fly.	      hplabs / (pronounced "AE-wack")
"Work FOR?  I don't work FOR anybody!  I'm just having fun."  -- The Doctor