ARMlet help

[Massman82]

"I have some problems with ARM code. Everything works, just a gif decoder fails.
It seems the NX can't run correctly what I compile with the gcc-arm version I have. It fails at very primitive expressions.
I can virtually debug it by placing 'return' into different places, and check whether I get 'Fatal Exception' or not. I just see that the code fails on a simple expression like this:
x=y
Where x is an unsigned short and y, too. It's a joke. It shouldn't fail on this.
I tried to compile it as cpp, but the same occurs."

I want to help this developer but I know nothing about coding. That's why I came to you!

[ayasin]

Well first don't use the gcc-arm toolchain, use the PRC tools which contain arm-palmos-xxxx tools. You'll save yourself a lot of heartache. If you still have trouble, post the offending code and maybe we can work though it.

Also virtually debuging by adding returns is highly suspect. It's probably not failing on x=y but rather its failing to restore registers that it should have preserved on function entry (r9 is a key one for PACE, step on that and your dead). Having the compiler generate the ASM and taking a look at it would probably give you a lot of insight into the problem.

[Massman82]

Thanks for that very quick response! I'll forward it to the developers and see what their answer is.

I really hope this helps them. (Their developing something exciting! :))

[ayasin]

Hey are these guys "RedShift"? I saw a nearly identical question from them in the ARMlet forum digest today.

[redshift]

Hello!

Yea, that was me :) I wasn't able to solve that problem... don't know why. That gif decompressor had a buggy c code, it seem. Doesn't matter, from that point I have made an own compression from the png lib (works).

Another question: I have several troubles running Legacy on UX/TH series. The game works on every other palm device, but on ux/th, it fails (not at start... but later). The Motorola part is stable - there can't be too much difference between Palm and Palm with Motorola code. I think I have problems with the Armlets.
The latest issue: at more testers :( Legacy on ux leads to *hard* reset. How could it be? I can't imagine. Do you know special rules with Armlets on UX/TH series? Maybe additional register which must be reserved? Or much smaller available stack?

The armlet which always fail: Capture... copies back a part of the screen from the 2nd buffer to an allocated heap memory block. It works on all other Palm devices. The code is very simple.

Stewe

[igor_n]

Stewe,

you can find sample of setting bigger stack in PNOlet forum. AFAIK arm stack is about 4-8K and it's size depends on licensee choice.

Aso you should take care with direct access to video memory. Memory caching scheme and video controller access lead your to fatal exception.

[redshift]

Stewe,
you can find sample of setting bigger stack in PNOlet forum. AFAIK arm stack is about 4-8K and it's size depends on licensee choice.

The truth is that Armlet (the Capture one) uses about 20 bytes stack, just few local variables. So this try was just a wrong idea from me. Another Armlet, which uses few kilobytes stack, works correctly on ux/th.


Aso you should take care with direct access to video memory. Memory caching scheme and video controller access lead your to fatal exception.

Hmm... I really can't imagine a game without direct screen access nowadays. Let's see Warfare, that's surely with direct screen access, and works sorrectly on ux/th. I try to compile my Armlets with Codewarrior, instead of an arm-gcc compiler.

Thanks!

Stewe

[igor_n]

Look this discussion about direct access to video memory
http://www.escribe.com/computing/poaf/m990.html

[scottlu]

Originally posted by redshift

The truth is that Armlet (the Capture one) uses about 20 bytes stack, just few local variables. So this try was just a wrong idea from me. Another Armlet, which uses few kilobytes stack, works correctly on ux/th.


Hmm... I really can't imagine a game without direct screen access nowadays. Let's see Warfare, that's surely with direct screen access, and works sorrectly on ux/th. I try to compile my Armlets with Codewarrior, instead of an arm-gcc compiler.

Thanks!

Stewe


Actually Stewe, Warfare uses direct screen access on OS 3.x and 4.x models only. It uses WinCopyRectangle on OS 5.x and above. It tracks "dirty" areas of the screen and only updates what is needed, instead of the whole screen, to speed things up. By the way, we recently completed our ARM port, I can help answer any questions if you have any.

I suggest using Codewarrior instead of arm-gcc compiler, because it has a fully-cooked model for handling globals on the ARM side that won't require much extra coding on your part to use.

Scott
Spiffcode, Inc.

[redshift]

Thank you!

Interesting, I always try to skip the operating system and do all job alone. Let's see for example Garmin Ique: I really can't reach a stable, 320x480 screen with os support. I *had* to use direct screen access, which is fast and stable.
I still don't think that the WinCopyRactangle can as fast as my flush arm code. Maybe I'm not right!

I have recompiled the Armlets with Codewarrior, and I'm going to send the game to ux/th testers. Hope the best.
But, this will remain the lifetime question: how could a buggy code reach *hard* reset on ux? Legacy did :) :( That's why I disabled the ux compatibility until Sony's answer.
The Codewarrior-compiled Armlets are my last chance.

Stewe

[scottlu]

Originally posted by redshift
Thank you!

Interesting, I always try to skip the operating system and do all job alone. Let's see for example Garmin Ique: I really can't reach a stable, 320x480 screen with os support. I *had* to use direct screen access, which is fast and stable.
I still don't think that the WinCopyRactangle can as fast as my flush arm code. Maybe I'm not right!

I have recompiled the Armlets with Codewarrior, and I'm going to send the game to ux/th testers. Hope the best.
But, this will remain the lifetime question: how could a buggy code reach *hard* reset on ux? Legacy did :) :( That's why I disabled the ux compatibility until Sony's answer.
The Codewarrior-compiled Armlets are my last chance.

Stewe


Whether WinCopyRectangle is faster depends on the device. Some devices have slow video ram access, some will have no direct video ram access, and some no api access to hardware acceleration except via WinCopyRectangle. WinCopyRectangle performs very good for us, however we go to lengths to not draw as much as possible. I can also say that using WinCopyRectangle will be more compatible than direct screen access, and require less support.

OS 6 buffers all OS 5 app output, and has a dirty rect based updater that updates from the buffer to the screen. As an OS 5 app you can skip this buffering using WinScreenLock() however that api expects that you are updating the entire screen.

About ARMlet performance. Calls from 68K to ARM usually cause an instruction cache flush, under the assumption that the code may have been recently locked down. Warfare v1.0 used an ARMlet approach for graphics tasks and hit this perf problem all the time. The good news is that callbacks from ARM to 68K don't cause cache flushing, so if you switch over to all ARM with 68K callbacks for PalmOS apis, you'll get the best of all worlds, high performance on OS 5 and OS 6. It is also debuggable on the ARM side with POD. This is what we did for Warfare v1.1.

I don't know how a bug can cause a hard reset. Some devices have protected memory addresses that can cause strange things to occur with hardware, that is probably what you hit by accident. I am guessing though that whatever Sony says won't help you find the problem. Sounds like a case for "binary search" debugging to narrow in on the cause.

Scott

[redshift]

I don't know how a bug can cause a hard reset. Some devices have protected memory addresses that can cause strange things to occur with hardware, that is probably what you hit by accident. I am guessing though that whatever Sony says won't help you find the problem. Sounds like a case for "binary search" debugging to narrow in on the cause.


Yea, I was thinking about it a lot. Our Armlets always use pre-allocated heap blocks (from 68K). So - I think - this shoudn't be a problem.
I have the Codewarrior-recompiled Armlet test result - the same. Problems on ux an on th. On ux - hard reset again. I have to think twice before asking them to test a new version :(

I have one more idea: to replace all Armlets with the same routine in 68K. Maybe I wasn't right (as always), and Armlets are working correctly on them.

Stewe