[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Second Sight again...
- Subject: Re: Second Sight again...
- From: toddpw@beat.ugcs.caltech.edu (Todd P. Whitesel)
- Date: 1995/07/13
- Newsgroups: comp.sys.apple2
- Organization: California Institute of Technology, Pasadena
- References: <3taljo$rgq@nuscc.nus.sg> <3ti1qf$be0@news.mel.aone.net.au> <3tj7gm$duq@gap.cco.caltech.edu> <3tudbm$p4g@news-2a.csn.net> <3u03ct$bbd@gap.cco.caltech.edu> <3u0sl0$6g1@paris.ics.uci.edu>
jlee@ics.uci.edu (Orion Pax) writes:
>: Decrement-and-branch-if-non-zero instructions. gotta love em.
>Which is no loss of speed if scanned the other way and checked to some
>explicit number. What are we talking about here, 0.001 MHz for the dec/beq
>to be a speed factor?
More than that. If Jawaid's loop is tight enough, it's going to be very
significant. One reprieve is that different code can be used for filled
vs. non-filled scanlines.
I think the real question is how much extra code does it take to propagate
the fill value. At the very least it would add a pair of BIT/BNE instructions
to isolate the 320-mode pixels, on top of the loop order reversal.
Remember that the SS is not using a 65816 but a 64180 which is Z80-like
in its wastage of cycles. The CPU power of the SS is more on par with a
stock GS.
I agree that it should be investigated further though. Having the option to
get slower but accurate fill mode would be nice.
Todd Whitesel
toddpw @ ugcs.caltech.edu