# Re: A83: Re: modules operator

```
> What's Olle's sprite routine?? Could someone send it to me.
>
> Nat Sith
> smithrh@esper.com

Well, here's the routine, and the tutorial to go with it :)
------------------------------------------------------------
Introduction.
Olle Hedman recently came out with an amazing pixel-plotting routine.  This tutorial will just introduce you to it, and even
explain it!

Pixel Code Explanation.
Thanks to Olle for explaining this to me.

PIX:
;	push	af		; Uncomment these to save regs..
;	push	de

ld	d,0		; Do y*12
sla	e
sla	e
ld	hl,0

Now, why does he do y*12?  Ok, this routine plots to PLOTSSSCREEN, which is an area 768 bytes big, right?  Now, to plot the
pixel we have to find the byte its in.  Why?  Because we can only set bytes (or words) at a time, not bits.  Ok, so why
multiply by 12.  Well, what's 96/8?…12!  Thus, by multiplying by 12, we essentially skip as many as many bytes as we want to go
down.

The instructions behind this are simple enough.  First, Olle initializes d, then multiples e by 4 with two SLA statements
(check Tutorial 28 for bit-level instructions).  Initializes hl, and in essence multiples de by 3, by adding it three times
over to HL which is keeping the running total.

ld      d,0             ; Do x/8

ld      e,a

srl     e

srl     e

srl     e

Ok, now we have to find the horizontal byte we're in.  This is done by dividing x by 8, because there's 8 bits in a byte!  For
example, if a = 5, 5/8 truncated is 0, so it would be in the first byte of our horizontal line that HL is already pointing to.
So, we would add 0 to hl…it would still point to the first byte in our horizontal line.  If a=53, it would point to the 6th
byte, thus, we would add 6 to HL.  We now know the exact BYTE that our pixel resides in.

ld      de,8e29h

We have the byte number, but we need to add it to PLOTSSCREEN so that it points to the right place, don't we!

ld      de,0007h     	; Get the remainder of x/8
and     e

Ok, check this out!  This is really neat, IMO.  Note that a still contains the original x address.  Now, we want the bit on our
byte, so that we can then mask the byte and update PLOTSSCREEN appropriately.  So get the bit, get back the three bits we
shifted (thus, destroyed) when we divided.  We do this by using a bit-mask (see Tutorial 13).  07h is equivalent to 00000111d.
So we AND a and e.  And bingo, we have the bit!  Don't believe?…let's look.  Assume you want 12 as the x-coordinate:

12 			= 00001100  AND
---------
00000100 = 4

And that is correct!  We'd want the fourth bit (in the second byte)!  Pretty neat, huh?

ld 	e,a
ld	IX,pixtable  	; Look up in table which pixel to be set
ld	a,(IX+0)  	; and load this

Ok, now that we have the bit number, we need to set the byte.  First of all, we load the bit position into e, then a look-up
tables of the bytes into IX (an index register).  We then add IX and de, now IX points to the correct byte in the lookup table
(if a = 3, then IX points to 00100000b).  We then load this into a again.

or	(HL)		; 'xor' to toggle pixel, 'and' cpl to clear.
ld	(HL),a

Ok, now…We don't want to clear all the bits (remember, we're using Bytes here), so we OR it to keep everything, and our new
bit.  For example, using our 4 example and a made-up byte from Plotscreen:

Lookup (using 4)		= 00010000   OR
Example of Plotscreen	= 01001001
--------
01011001

Notice, that both our bit, and the original plotsscreen contents are there!  Finally, you put the byte into (HL), and bingo,

;	pop	de
;	pop	af

ret

pixtable:
.db	10000000b
.db	01000000b
.db	00100000b
.db	00010000b
.db	00001000b
.db	00000100b
.db	00000010b
.db	00000001b

Phew, there you have it!  Amazing piece of coding from Olle!!

New Commands.
pix		- Yep, you guessed it…calls his routine!

Code.

Tiny program, not worth putting in, but if you want to quickly test it…

ld	b,96
loop1:
ld	a,b
push	bc
ld	b,64
loop2:
ld	e,b
call	pix
djnz	loop2
pop	bc
djnz	loop1
call	_grbufcpy_v
ret

;Put Olle's code here!;

Note that Olle's code is available here.

Conclusion.

This is a GREAT exercise in bit-level ASM, and looking and understand real source code.  Hopefully, soon I'll get on Movax's
case, and see if I can explain his sprite routines.

Thanks to Olle!

```

Follow-Ups: