Re: A83:STILL NEED HELP!

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

Re: A83:STILL NEED HELP!


 dWait:  in a,(10h) ; 11 T
         rla           ; 4 T
         jr c,dWait   ; 12/7
         ret             ; 10 T

call dWait ; 17T

So the port is read after 17+11 T states. Since it takes at least 30 before
it is finished the port will be read again after:
17+11+4+12+11 = 55 T. So you will return from the subroutine after
55T+4+7+10= 76T states. This is more than twice the amount needed, and thus
very inefficient.

This is the routine TI uses:
push af ; 11
inc hl ; 6 T
dec hl ; 6
pop af ; 10
ret ; 10 T

Total delay 11+6+6+10+10+17 = 60 T. This is too long a delay, but it is
better than the routine that you are using. In most routines you should not
use a delay like this, use the time between writes to do something useful !
If you look at some of the fast display routines you will see that most of
the time they are doing something which needed to be dones anyway, only app
10 T are spend waiting.

Dines


----- Original Message -----
From: Daniel M Church <dchurch@mbhs.edu>
To: <assembly-83@lists.ticalc.org>
Sent: 25. oktober 1999 02:28
Subject: Re: A83:STILL NEED HELP!


>
> On Sun, 24 Oct 1999, Laurens Holst wrote:
>
> >
> >
> > > Dines Justesen wrote:
> > > > BTW Are you sure it is 53 T-states ?
> > >
> > > When I fiddled with this, a long time ago, I think I landed on about
30..
> > > (I dont even have a ti83 anylonger)
> > > The tricky thing is that the exact number changes, depending on
> > temperature and
> > > how good your batteries are.
> >
> > Yep, indeed. Lotus doesn't function right when the batteries are new
because
> > it waits not long enough. By the way, does Lotus use the fastCopy
routine???
> > I think so because it requires ZGFXL which has no real other useful
> > functions, but at the other hand, I had no problems with other games
which
> > used it... I remember Sqrxz having the same problems too (long ago...).
> >
> > Oh, and I heard the 83+ required even more waiting (the processor is
> > probably running a little faster or so).
>
> Why not just keep reading the port until it's ready?  My wait routine
> looks like this:
>
> dWait:  in a,(10h)
>         rla
>         jr c,dWait
>         ret
>
> Is that inefficient?
>
> > > Another trick to speed up the update, is to set the screen in
> > "column-mode" and
> > > write colums to it, instead of rows. If you do that, you will save
quite a
> > few
> > > writes to the controller, and that is good, because writes to the
> > controller is
> > > _slow_.
> >
> > the fastCopy routine of SOS (and ION) has the auto-increment mode set to
> > columns. A shame that it doesn't increase the row when it reaches the
end by
> > the way.
> >
> >
> > ~Grauw
> >
> >
> > --
> > >>>>>>>>>>>>>>>>>>>>>>>>><<<<<<<<<<<<<<<<<<<<<<<<<
> >           email me: laurensh@geocities.com or ICQ: 10196372
> >              visit the Datax homepage at http://datax.cjb.net/
> > MSX fair Bussum / MSX Marathon homepage: http://msxfair.cjb.net/
> > >>>>>>>>>>>>>>>>>>>>>>>>><<<<<<<<<<<<<<<<<<<<<<<<<
> >
> >
> >
>
>      Daniel Church      |  "War doesn't determine who is right-
>      ___---^---___      |   only who is left."
>     dchurch@mbhs.edu    |  -anonymous
>
> -----BEGIN GEEK CODE BLOCK-----
> Version: 3.1
> GCS/M/S/MU>AT d-(+)(x) s++:- a16@ C++(+++)>++++$ UL++++ P+ L+++(++)>++++
> E W+>++ N+ o? K? w(---) !O !M(--) V? PS+(++) PE(--) Y? !PGP>+ t+ 5 X()+
> R>+ tv+() b+(++)>+++ DI++>++++ D++ G+>++ e-(*)>++ h!>>-(---) r+>++ y>+
> ------END GEEK CODE BLOCK------
>
>
Follow-Ups: References: