[GEM Development] [GEM-DEV] GEM 32

[Shane Gough]

Well, this has certainly got discussion going at least :)

@All

Apologies for any confusion, I didn't get a choice in my name (in fact, it
was very nearly Michael so I may have been confused with you Brother Michael
rather than Shane of GEM fame :P). If it helps refer to me as ShaneG or
ShaneNotGEM :)

@David

For portability support GCC/GAS is almost a must. Between them they cover
almost all available OS's and platforms. DJGPP comes with a DOS extender (is
it GO32 or something similar? I don't recall off the top of my head). In any
case, support for DJGPP will restrict the PC processor to a 386 or better -
maintaining support for previous processors (at the VDI/AES level at least)
would be difficult. This would mean a new implementation of VDI and AES that
is fully 32 bit and protected mode aware. You could use 'thunking' (the way
WIN32 was supported on Win31) but it would add a lot of complexity which
would be better to avoid. How would existing (binary only) GEM applications
run on top of this?

As for video support - on DOS the VESA interface would probably be easiest
(there are third party TSR's that provide additional support for Non-VESA or
Minimal-VESA cards). On Linux the standard Framebuffer interface would work
reasonably well. As I mentioned in an earlier email - 2D accelleration would
be up to the VESA implementation and 3D accelleration would be non-existant.

@Ben

I was wondering about the Atari GEM implementation as well. Ideally it
should be supported as part of any standard API (from the documents I have
read there is little functional difference between the TOS/DOS
implementations of the GEM API). I don't know enough about it to say how
easy it would be to port applications from Atari GEM to other GEM - from
what I gather the TOS API is not exactly POSIX like (neither is DOS for that
matter). Is there the equivelant of GCC (and it's standard C library) for
TOS? If that's the case it should simplify things (excluding those
applications that make explicit use of Atari only hardware functions). I
haven't found a reasonable Atari emulator and development tools to do any
testing on yet (I haven't looked that hard either though). I do have an
Atari 520ST stashed away in the cupboard though - apart from playing a
couple of games on it I haven't done much else.

@Peter

GEM (specifically OpenGEM) as it stands is great on legacy PC hardware
(which is becoming more difficult to find). It's fun for those who are
interested in nostalgia when running on DosBOX or something similar. But as
a day to day platform for any purpose it is not really much use (yes, I know
there are web browsers, news readers etc available - a lot of people have
done a lot of work). But is GEM of any use in the long run on non-PC (or
non-Atari) hardware? I work with embedded hardware (both commercially and
for fun) and there are times when I would like a nice simple UI to plug in
which doesn't have a large memory or disk footprint, is simple to program
and provides a reasonably pretty interface - I think GEM would fulfill that
goal.

@All

Anyway - as I have stated previously I have created the 'gemapi' and 'gemix'
projects on SourceForge. I'm happy to hand over control of the 'gemapi'
project to those with more of a history (and more experience) with GEM. I
intend to continue with the 'gemix' project as a 'GEM like' (at the very
least) implementation of the GEM API for the Linux kernel (initially,
ideally it should work on any POSIX compliant system that someone can
provide a VDI implementation for). SourceForge does provide for webspace as
well so maybe the 'gemapi' project would be a reasonable place for a
documentation Wiki and other developer style information?

What does everyone think?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.simpits.org/pipermail/gem-dev/attachments/20091109/34030e46/attachment-0001.html