Ken Krugler <[EMAIL PROTECTED]> wrote:
> I'm not sure of the status of the GCC-based development environment,
> though, so perhaps somebody else (John?) could better understand and
> answer your questions. I know there were some issues with getting an
> appropriate version of the Palm OS Glue library released for
> PRC-tools.
Interesting that you mention this. Just today I've been working on
getting TxtGlue incorporated into my app, using prc-tools 2.0 and SDK
3.5, and have run into trouble. I get a bus error in TxtGlueCharAttr(),
running in POSE using either the 2.0 or 3.0 ROM (haven't tried it with
any others, don't think it will matter). Apparently TxtGlueCharAttr()
is attempting to use the character value to index into a table of 16-
bit character attributes. When I display memory at the calculated
address of this table (using Debuffer, a wonderful tool), I see all
ones (0xFFFF).
Here's the assembler code:
link.l a6, #$0
move.w $8(a6), d0 ;chr in d0 now
cmp.w #$00ff, d0
bhi.s #$a
and.l #$0000ffff, d0
bra #$14
cmp.w #$ff7f, d0
bhi.s #$6
clr.w d0
bra #$12
and.l #$000000ff, d0
lea.l $4efc(a5), a0 ;base of table must be a5 + $4efc
add.l d0, d0
move.w $0(a0, d0.l), d0 ;this instruction is trouble
unlk.l a6
rts
The instruction noted as "trouble" is where things go haywire. In my
environment, at least, a0 is 0x122a0, and d0 is 0xc2 (chr was 'a'), so
that means an attempt to read a word from 0x12362.
After that instruction executes, one of two things is apparently
happening:
1. Debuffer is getting out of sync with POSE
2. Program memory just got seriously trounced
because the memory containing the routine listed above has been filled
with all zeros. I can reset POSE and run my app again without re-
installing it, so my hunch is it's #1.
Anybody have any insight into this? Thanks.
--
Roger Chaplin
<[EMAIL PROTECTED]>
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palm.com/devzone/mailinglists.html
