[A83] Re: im 2

To: assembly-83@lists.ticalc.org
Subject: [A83] Re: im 2
From: Tijl Coosemans <tijl.coosemans@mail.be>
Date: Fri, 7 Sep 2001 10:43:54 +0200
Reply-To: assembly-83@lists.ticalc.org

> From: David Phillips <david@acz.org>

> > I know, but I brought up the issue again, because my routine really needs
> > to be as fast as possible. Every tstate counts. So I thought, by splitting
> > it up into several routines, which are randomly called, each routine could
> > be faster than when I had to put them together and built in a counter.

> What are you doing that is so time critical?

Can't really tell yet :)

> Your logic doesn't make any sense.  Having less control over your program
> doesn't make it faster.

Now I actually have three routines. Each interrupt another one is called and the order in which that happens doesn't really matter. I do that by implementing a counter which counts from 1 to 3. If I could make an interrupt vector table with 3 pointers instead of one, I wouldn't have to implement that counter, which could safe me a few clock cycles. Not much, but as I said, every tstate counts.

> > As far as I know now, the lower bit seems to be more 1 than 0. Also, when
> > I use a _getcsc/halt loop in the main program, the lowest bit seems to be
> > always 1, resulting in aligned addresses. Don't ask me why that is.

> How are you reading the value?  I don't have any proof, but reading the
> register might always return the same value, or a different one than the
> calc uses when an interrupt occurs.  The only way to really test it is to
> put in different interrupt routines at different addresses, and see what
> happens.  Or put garbage in half the bytes, and see if it crashes.

I used two routines. One at 8587h and one at 8785h. Then I made a vector table at 8600h-8700h. One time I let it start with 85h(,87h,85h,87h,...) and the other time with 87h(,85h,...) and saw what happent.
-----------------------------------------------------
Mail.be, Free WebMail and Virtual Office
http://www.mail.be