[A83] Re: variable horizontal line routine?

[Prev][Next][Index][Thread]

[A83] Re: variable horizontal line routine?


There's nothing inherently bad about it being in the loop if it saves bytes.
I assume that when the person asked for a fast routine, they meant as
opposed to _iline. Using a generic line routine for a horizontal line is
slow in the first place, but TI's implementation of _iline has lots of extra
features that you wouldn't need. Here's a modified routine, one byte bigger
to include the OR (although it might not be necessary depending on the
application):

horizline:
  ;43 bytes
  ;c = x, l = y
  ld h,0
  add hl,hl      ; * 2
  add hl,hl      ; * 4
  ld d,h
  ld e,l
  add hl,hl      ; * 8
  add hl,de      ; * 12
  ld a,c
  rra
  rra
  rra
  and %00011111  ; x / 8
  ld e,a
  ld a,12
  sub e          ;get number of bytes left in row
  push af        ;save it
  add hl,de      ;add x component
  ld de,graphbuf ;whatever that address is ;-)
  add hl,de
  ld a,c
  cpl
  and %00000111
  inc a            ;shift 1-8 times depending on x value
  ld b,a
  xor a
getbitmask:
  sl1 a            ;undocumented opcode ;-)
  djnz getbitmask
  pop bc           ;number of bytes left in row
  or (hl)
copybytes:
  ld (hl),a
  inc hl
  ld a,$ff         ;write $ff to all the other bytes
  djnz copybytes
  ret

-----Original Message-----
From: assembly-83-bounce@lists.ticalc.org
[mailto:assembly-83-bounce@lists.ticalc.org]On Behalf Of Olle Hedman
Sent: Friday, June 01, 2001 9:39 AM
To: assembly-83@lists.ticalc.org
Subject: [A83] Re: variable horizontal line routine?



At 17:30 2001-06-01, you wrote:
>The point of using ld a,$FF is obviously that A does not equal $FF the
first
>time, but it equals something different.

ofcourse. but it's bad to have it in the loop anyway. and thad mod to his
routine is a small increase.
and the first contents of a should anyway not be ld:n into the graphbuf,
but or:ed, as stated before.

>For the record, Jonah's takes 261 tstates average, plus 33 * n where n is
>the number of extra bytes in the line. Yours takes 220 tstates constant,
>plus 29 * n. I really don't think that the speed difference here is worth
>the 43% size increase.

maybe. but 15% is at least some speed increase. but sure, if you don't need
it use the smaller.
I just answered the request for a "_fast_" routine.

///Olle
Follow-Ups: References: