Lonetech, thanks a zillion... though I can only make out a slight outline in the fog of my ignorance meaning that you have cracked a way to get some close relative of the original SDK (software developer kit?) up and ranning.
So trying to understand a bit, do I get it right that you have reproduced on a "virtual" machine (QEMU) a software that adds to the SDK of other models the additional things (libraries) that are specific to the 903? And that this would now allow other programmes to run on the PB903 (both old ones and new developments)?
By the way, when you say "the new models ... do not accept programs built for earlier models" which programmes running on the other pb do you have in mind (sorry, I am a total newby!)?
For other users who are absolute beginenrs like me, here is what I found:
"QEMU is a generic and open source machine emulator and virtualizer.
When used as a machine emulator, QEMU can run OSes and programs made for one machine (e.g. an ARM board) on a different machine (e.g. your own PC). By using dynamic translation, it achieves very good performance.
But for those tech-unsavy of us, what does this mean in practice?
Poterm is PoTerm is serial terminal shell talks to serial ports and it is capable of sending AT commands to modems. A serial communication library is also available. Works on Windows and Linux also
and for ABI/EABI
In computer software, an application binary interface (ABI) describes the low-level interface between an application (or any type of) program and the operating system or another application.
ABIs cover details such as data type, size, and alignment; the calling convention, which controls how functions' arguments are passed and return values retrieved; the system call numbers and how an application should make system calls to the operating system; and in the case of a complete operating system ABI, the binary format of object files, program libraries and so on. A complete ABI, such as the Intel Binary Compatibility Standard (iBCS), allows a program from one operating system supporting that ABI to run without modifications on any other such system, provided that necessary shared libraries are present, and similar prerequisites are fulfilled.
Other ABIs standardize details such as the C++ name mangling, exception propagation, and calling convention between compilers on the same platform, but do not require cross-platform compatibility.
An ABI should not be confused with an application programming interface (API) which defines a library of routines to call, data structures to manipulate, and/or object classes to use in the construction of an application using that particular (often language specific) API.
An embedded-application binary interface (EABI) specifies standard conventions for file formats, data types, register usage, stack frame organization, and function parameter passing of an embedded software program.
Compilers that support the EABI create object code that is compatible with code generated by other such compilers, thus allowing developers to link libraries generated with one compiler with object code generated with a different compiler. Developers writing their own assembly language code may also use the EABI to interface with assembly generated by a compliant compiler.
The main differences of an EABI with respect to an ABI for general purpose operating systems are that privileged instructions are allowed in application code, dynamic linking is not required (sometimes it is completely disallowed), and a more compact stack frame organization is used to save memory.