well there was one on IRC once.
I figured out as much as that.

I suspected it to be in the fact that callbacks use a Bitu and what is written in memory is a Bit16u. but according to harekiet this couldn't be the issue.

if you can compile the debugger enalbed version of dosbox you might want to see what is presetn on where
runrealint points to.
C800:0984

and c800:110
and c800:120

I have used the debugged version, what should be expected? Would you like to give me more information? I cannot follow your mean. Thanks.

So if i understood it correctly, CALLBACK_RunRealInt(0x16)
is called, the normal core executes something, but
INT16_Handler() is never called.
First of all switch to the full core, if it works ok it's
most likely a bug in the normal core, otherwise maybe
something with the callback setup as Qbix said.

For the normal core: try to add some debug output to
CPU_Core_Normal_Run(), something like replacing the

1restart_opcode:
2		switch (core.opcode_index+Fetchb()) {

by

1restart_opcode:
2		Bit8u bt=Fetchb();
3		LOG_MSG("cs:eip=%x:%x, opcode=%x",SegValue(cs),reg_eip,bt);
4		switch (core.opcode_index+bt) {

and see what output you get past the CALLBACK_RunRealInt.
Should look like
cs:eip=c800:984, opcode=cd (execute interrupt)
cs:eip=c800:110, opcode=fb (STI)
cs:eip=c800:111, opcode=fe (special callback opcode)
then the normal core should return into dosbox.cpp with
returncode something like 0x11 (issue callback).

cs:eip=c800:4084, opcode=cd
cs:eip=c800:110, opcode=fb
cs:eip=c800:111, opcode=fe
cs:eip=c800:113, opcode=11
cs:eip=c800:115, opcode=cf
Any clue?

Got the root cause and should be able to solve it. The interrupt set up code on arm is problematic. The unaligned word access would cause problem. I changed to byte access in callback.c's line 155:
phys_writew(CB_BASE+(callback<<4)+3,callback);

One solution is to change the writew/readw/writed/readd implementation. I have used that one.

But it's slow than expected. 🙁

hmm dosbox has allready a switch for unalligned memory acces.
maybe it's not properly used in the phys_writew or something like that.

oh, I found in current dosbox 0.63's source, the mem.h still has the unaligned implementation. After modified the implementation, it can run successfully. 😀

does this mean it runs using the cvs ?
Could you confirm that ?

http://pcnwstage.phys.rug.nl/dosboxcvs.tgz

No, I haven't used the cvs version, just the released dosbox-0.63.tar.gz, now it works great. After removed the code wd suggested, it runs faster. 😀

Thansk Qbix and WD, without you two, I couldn't find the problem. 😀

If you didn't use the CVS sources: could you try them (the link
Qbix provided) and see if it runs without modifications?
If it needs modifications, could you please post them?

Yes, it's best to try the CVS source, as many fixes and improvements have been added since 0.63. It's quite stable as many people are testing it all the time (on Win32 and Linux at least).

No lucky for me. I hacked the Config to Config_ to avoid the class confliction to Qtopia. After it run, it will stuck in somewhere. Don't have chance to see whether the aligned/unaligned problem has been solved or not. I will update if I have time to figure out the problem inside.
Thanks.