Some time ago I released the P900 Zx Spectrum emulator (full source
included).
The main source has to #include a "p900.h" header file: if the
compiler is targeted to ARM processor, then it will include a
"p900base.h" header, else it will include "p900x11.h" (with same
functions but targeted to X11 and Linux).
Also, the functions contained in the p900base.h will give you a "full
CPU" environment instead of the common "event driven" structure. As
you may already know, in every windowed environment programming
library (Mac OS X, Windows, QT, Symbian/UIQ, etc) your program has
only to answer to events: the system, not your program, has the
control of all resources.
For example, given a button, you define an event "button clicked",
and your procedure will be called only when the button is actually
clicked: you have then to quickly execute your (short) code and then
release control to the system (because other events may be waiting:
keypresses, timing, etc).
The most notable exception is bare X11 programming, where you must
initialize all windows and stuff, and then create a for-loop to ask
for events and then respond to them. You have the control, not the
windowing management library of the system: you can write programs
that can use all available CPU power and which still appear in
"windowed" mode.
To write the Zx Spectrum emulator I needed full control, not "event
style" control. So I had to split the main P900 .APP program in two
threads soon after initialization phase: the first is a classic event-
driven program, which keeps a linked-list (big, circular) filled with
the events that it got from the system; the second thread simply runs
at full speed, reading from the shared list the events (keyboard,
touchscreen) when needed, and can use all available CPU power without
interfering with the rest of Symbian applications already running.
This said, I was finally able to create the P900 Zx Spectrum emulator
which:
1) uses all available CPU power, thus getting a realistic screen
refresh (25 fps: 25 times per second the 320x208 screen gets a full
redraw) without freezing the P900 (alarms, messaging, etc won't
stop); a commercial Spectrum emulator, using the standard event/
timers driven version, can barely get more than 12-15 frames per second.
2) same P900-Spectrum source is cross-compilable to the Linux+X11
platform (have a look at the Makefile: "make x11" will compile it for
your Linux box), where it will perform in the same mode but a little
slower (due to X11 calls: in the P900 to set a pixel you simply need
to write two bytes in memory; in X11 you need to call a library
function which will perform window controls, color depth control,
visibility controls, etc, before actually telling the X11 engine to
recolor it: a dramatic speed-up was obtained by keeping an fake
screen matrix, in order to call the set pixel color function only
when the color was changed)
3) I had to stop development for a number of reasons, and didn't
explore the sound section (which, in event-driven mode, could still
use the 5-8% of CPU power left from the P900 Spectrum emulator and
still be in sync with everything).
This entire introduction means that:
a) you can build and develop on X11 and do minimal tests on a real P900;
alf
