Date   : Tue, 17 Oct 1989 17:06:15 GMT
From   : zephyr.ens.tek.com!wrgate!nobody@uunet.uu.net (Unpriveleged user)
Subject: Z80 algorithms

>Someone mailed to me the following memory fill algorithm:
>
>>
>>       ld      hl,buffer               ; point at buffer
>>       ld      de,buffer + 1           ; point at next byte
>>       ld      bc,count - 1            ; number of bytes minus one
>>       ld      (hl),xxx                ; save the first byte
>>       ldir                            ; replicate through rest of buffer
>>
>>is the fastest buffer fill I know on the Z80.
>
>There exists a much faster faster algorithm for that. Let's see:
>
>The central statement in your solution is `ldir'. It takes 21 T states per
>byte. For 16 bytes this is 336 T states.
>
>Using the push statement is much faster:
>   Set D = E = the byte to be filled in;
>   let SP point 1 byte after the end of the area to be filled;
>   B contains the number of 16 byte blocks to be filled.
>Then use "push DE"s, and you're finished very quickly.
>
>   DI                      ; CP/M must not interrupt, because SP will be
>                           ; misused
       {rest of clever PUSHing algorithm deleted}
From: michaelk@copper.WR.TEK.COM (Michael D. Kersenbrock)
Path: copper!michaelk


The push-algorithm is good for memory fill patterns when the pattern itself
is of a particular variety and is of a fixed length.

The LDIR algorithm works for any pattern of length.  You load the pattern
once, with:

        hl-> beginning of memory area
        de-> beginning of memory area + pattern_length
        bc ==  fill_length - pattern length

You then load your pattern starting at (HL) ONCE with a sequence that gets
it from the source (wherever it comes from).

Then you LDIR it.

If the fill length is less than pattern length, this can be tested when
being loaded manually the "first (and only) time".

This generalization of the 1-byte case (presented at the top of this
article) is a fast way of loading variable-length patterns, AND it can be
interrupted.  Byte count is small too.

Just depends on your needs :-).

Mike Kersenbrock
Tektronix Microprocessor Development Products
michaelk@copper.WR.TEK.COM
Aloha, Oregon