[Openpalm-devel] Re: Framebuffer Interface

[Henri Chen]

One more thing, the framebuffer base address must be dividable by 4, too;
otherwise, the graphic engine will not work.

Henri Chen
henrichen at infoshock.com
OpenPalm Project:: http://openpalm.sourceforge.net


-----Original Message-----
From: Henri Chen [mailto:henrichen at infoshock.com.tw]
Sent: Thursday, December 21, 2000 12:18 PM
To: openpalm-devel; rtems-snapshots at OARcorp.com; rtems-users at OARcorp.com;
Rosimildo da Silva
Subject: [Openpalm-devel] Framebuffer Interface


Some facts regarding the OpenPalm's framebuffer interface.

* The framebuffer interface does not cover hardware init issue.

* The most proper palce for hardware initialization is probably at or before
fbConfig(). fbConfig() is called from bmpSysInit().

* The current implementation for tvm and wince get the framebuffer base
addess in fbConfig() and store that information into SCREEN_BASEADDR (macro
defined as g_scrnBase). If your system has a fixed framebuffer base address,
you can simply define the macro to the proper unsigned value. (yes,
unsigned, not (void*))

* There is already an framebuffer graphic engine implementation in OpenPalm.
Related files are located in jedi/tvm (and copy over to jedi/rtems in the
mean time).

* Besides the 4 APIs (see jedi/include/jedi/fb.h), the framebuffer interface
use 4 predefined variables/constants to provide service to the framebuffer
graphic engine.

#define SCREEN_WIDTH	//the screen's width in pixel, which must be a number
devidable by 4.
#define SCREEN_HEIGHT	//the screen's heigth in pixel
#define SCREEN_BPP	//the supported color depth. The engine now support
1,2,4,8,16,32 (no 24!)
#define SCREEN_BASEADDR //the base address of the framebuffer

* These defined information is immutable after bmpSysInit() is called.
(check jedi/include/jedi/bmp.h)

* The format of the framebuffer for various color depth the OpenPalm graphic
engine expected is the same as what the MS Windows's DIB engine expected. We
believe that this format is also directly supported by most framebuffer
hardware chips. Note that the OpenPalm's graphic engine does not support VGA
4 plane mode.

Hope the above information is helpful.

Regards,

Henri Chen
henrichen at infoshock.com
OpenPalm Project:: http://openpalm.sourceforge.net


-----Original Message-----
From: openpalm-devel-admin at lists.sourceforge.net
[mailto:openpalm-devel-admin at lists.sourceforge.net]On Behalf Of Rosimildo da
Silva
Sent: Wednesday, December 20, 2000 10:23 PM
To: rtems-users at OARcorp.com; rtems-snapshots at OARcorp.com; Openpam-Devel
Subject: [Openpalm-devel] Re: OpenPalm port to RTEMS


From: Joel Sherrill <joel.sherrill at OARcorp.com>
To: rtems-users at OARcorp.com <rtems-users at OARcorp.com>;
rtems-snapshots at OARcorp.com <rtems-snapshots at OARcorp.com>; Openpam-Devel
<openpalm-devel at lists.sourceforge.net>
Date: Wednesday, December 20, 2000 7:14 AM
Subject: OpenPalm port to RTEMS


>
>+ The OpenPalm framebuffer interface for RTEMS is a stub.

I guess the best way here is to build something around SVGAlib.


>+ alloca() is undefined.

GCC provides alloca(). Two options:

    + drop the "-ansi" flag
    + wrapper around( __builtin_alloca() ??? ). RTEMS' lists archives have
some discussion
about this( a year or so ago ).


>+ settimeofday() needs to be implemented in RTEMS.
>+ The use of POSIX condition variables in the thread interface
>  has some tinkering left to do in regard to timeouts and
>  the use of pthread_cond_wait().
>+ no testing yet.



_______________________________________________
Openpalm-devel mailing list
Openpalm-devel at lists.sourceforge.net
http://lists.sourceforge.net/mailman/listinfo/openpalm-devel