Re: A89: TIGCCLIB 2.0 released!


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

Re: A89: TIGCCLIB 2.0 released!




> Maybe you see that __gmax is 2 on HW2 and 3 on HW1. Look at the
> instruction move.l %d1,__gcnt. It also sets __gmax...

ahhh, now I see - so the reason it doesn't flicker is because HW2 is calling
the routine 4/3 as often as HW1.  I missed that teeny little fact =)

However, that seems to me to make the most obvious speed difference of all -
it's calling the grayscale routine approximately 117 times per second rather
than 87.5 times per second.  Can we slap together a quick test program that
just moves a sprite around the screen with grayscale on and see how long it
takes on HW1 vs HW2?

> > a higher number could be used to intentionally flip between two
> > images), then it's understandable - but you don't do that.
>
> I am sorry, but I can't understand what do you talking about in this
> sentence...

For example, if I wanted to make it, say, blink really fast, I could set
plane 0 to all black and plane 1 to all white and use a __gmax of 5 or 6.
This wouldn't appear to be gray, but instead it would flip back and forth.
I can't imagine that anyone would really use that, but it could be done.

> Because it is not a constant. Btw, when it WAS a simple constant 3, it
> flickered enormously on real HW2 calc (but not on HW2-VTI). I concluded
> that it MUST be 2 on HW2 and 3 on HW1. Julien Muchembled tells this to
> me the same thing. I don't know why.

Because the HW2 routine is slower, it must be called more often to avoid
flicker.  The lower __gmax is, the less it flickers.  I'm just wondering if
that makes any major speed difference?

> 10 clock cucles loss 87.5 times per second is degradation of
> only 0.0087% which is really not too much...

Well, you're gonna have to change those numbers now =)

> Universal OS and DoorsOS do not perform loop unrolling too!

Well, it was unrolled when I modified graphlib for Xavier; he just didn't
like it that way =)  It's still somewhat unrolled in Olivier's TEOS routine,
though, which still flickers occasionally but doesn't cause slowdown by
calling the routine more often.

> This is not bug but a feature: this is noted in the documentation. Cite:
> "In a grayscale mode, don't assume that any plane is on LCD_MEM due to
> HW2 support..."

Well, seeing as people are STILL writing progs that only work on HW1 using
the new graphlib because they ignore the documentation that comes with the
kernels, I've stopped trusting documentation alone =)

> Good idea. Btw, you can see that PortRestore is called on turning off.

Correct, I only looked for it on turning it on.

> I accept your idea. Btw, the common rule is: "if really nothing else
helps,
> then read the documentation" :-)

The problem is, how many people test their progs?  Not too many. . . but
it's very hard to find good beta testers =(  I'd expect that sending a
request to this list would help, but since I'm the only person with a HW2
that cares to respond to anything. . .

> asm("lea "_str_(LCD_MEM)",%a0")
> will expand to
> asm("lea 0x4C00,%a0")

Ahh, that's right.  Just curious, is it the same in C++?  The Codewarrior we
run in my Computer Science class (an old Mac version) doesn't seem to be
able to handle string concatenation like that, among some other odd bugs. .
.

> I hope that this is what you want to ask.

Yup, thanks!

> The assembler will not screw up any ASM code which is defined out of
> any function. Only code which is embedded into functions will be
> eventually optimized.

hmmm, I never even realized that wasn't in a function - I never thought
about the fact that inline ASM doesn't need to be in a fuction.

> Have you really tried it on your real calc or only on HW2-VTI? As I
> said, HW2-VTI behaves wrongly!!!

Only VTI.  Just got my HW2 this week, so I haven't gotten to fool with it
much =(  If anyone else would like anything tested on HW2, let me know.

Zeljko, could you slap together a quick grayscale GCC prog that runs for
maybe a minute or so, time it on a HW1, then send it to me so I can time it
on a HW2?  I need to see the timing differences. . .

    -Scott




References: