[GEM Development] [GEM-DEV] GEM 32

Sat Nov 7 07:33:03 PST 2009

Hi Thomas,

I owe you an apology as well - I didn't mean to go off on rant like that.

There seems to be a little confusion (mainly because of my name I guess) - I
am NOT the same Shane that is responsible for ShaneLand OpenGEM. My net
contribution to GEM (both commercial and open source) is limited to the
posts I have made on this list. I have a handful of sample code I've written
to test various ideas but none of it has ever been made public. So as you
originally said all of this is in my minds eye - I just wanted to point out
that I did not indicate anything else (the coincidence of my name and that
of a major GEM contributor being the same has only just clicked).

In terms of project I was not thinking of creating a new OS - my idea was to
make a version of GEM that ran on a different OS (it already runs on two -
DOS for IBM style machines and TOS for Atari's). The UI is not really tied
to the underlying OS services (even Windows has a limited level of
separation that can be replaced - that's how some 'skins' are implemented).
Linux (or Unix based systems in general) are more flexible in that regard
(and being open source - a lot easier to figure out how to do it). I did
some research into the MMURTL stuff you mentioned (and it does look good -
for anyone interested in implementing their own OS it would be a great
start). The Linux kernel makes sense to me because there is hardware support
for most of the devices I need as well as the underlying OS type stuff
(threads, filesystems, networking, etc) so I can just concentrate on the UI
stuff.

The 'objectifying' stage was an idea to modernise GEM applications and ease
porting. Basically if I could take existing code for a current application,
convert it to use an OO framework and still have it work under 'classic' GEM
then it should be a lot easier to convert that to a 32 bit version of GEM.
There are a lot of assumptions in the GEM programs I have read through
though - GEM Paint for example will crash if the active video mode is more
thank 64K (in terms of width * height * bytes per pixel) - it assumes that
64K is the biggest chunk of memory that can be dealt with.

A downside to many experienced GEM developers is that I would like to change
the names of many functions (for example: The VDI function for 'Open
Workstation' - op code #1 - would become vdiOpenWorkstation() as opposed to
the recommended v_opnwk() - a lot easier to read and understand what it's
doing).Most modern compilers (even the freebie ones available for DOS) are
no longer limited to 8 character unique identifiers so there is no longer
any need to truncate or abbreviate as much. As I am converting the function
names I am also working on an automated translation script (using awk
mostly) to help in the process if converting existing code.

So - to progress on more realistic terms I've decided on the following:

1/ Develop a library (including header and implementation) for VDI using
Turbo C++ 1.01 (available as a legal free download from
http://edn.embarcadero.com/museum - was Borland, now sold off as a separate
company).
2/ This library will use the 'modernised' function names.
3/ Develop a set of test applications that exercise all known functions in
the VDI.

The code and documentation for this library shall be available on the
SourceForge site for the 'gemapi' project. Help at this stage will probably
be best given as discussions and criticisms. If you would like to become
part of the project please create a SourceForge account and contact me via
that method. I have not set any time period for the project so please don't
start holding your breath :) Once this is basically working I'll start work
on the AES functions. After that - well, it depends on what everyone says.

Regards,
Shane

On Sat, Nov 7, 2009 at 7:15 PM, Thomas Clayton <topcatdrc at yahoo.com> wrote:

> Shane,
>
> First and FOREMOST: I, in NO way meant ANY criticism of you. I hadn't
> noticed / realized Bro. Henry had mentioned you. If I had, I'd have written
> more for clarifications sake. You have made many good contributions. GEM
> development isn't  - and shouldn't be - ALL on your shoulders.
>
> Second, I was thinking about US as a group. Yeah. There is 32-bit processor
> (an 80386? ;-)  ) available (quite a few others, in fact, now  :-)  )
>  and
> wouldn't it be "neato" for GEM to run in a manner that took "full
> advantage" of it (those).
>
> As a starting point for the 32-bit dream, I'd recommend everyone look up
> "MMURTL". An individual, named Richard Burgess, wrote his own 32-bit OpSys
> back in the '90s. It - and its source code! - is (are) now available as
> 'public domain' Sw.
>
> In the early "00"'s, I went looking for the book I'd seen (he wrote about
> HOW he made his design decisions) and couldn't find it till HE re-published
> it, himself. ***If you find "copies" of the book (in PDF); they are NOT
> "Public Domain" but (quite correctly) copyrighted by Richard Burgess. He
> DESERVES the compensation / remuneration _for the book_. ***
> Paper-bound copies ARE available FROM him (last I knew). (I own one.)
>
>
> Still, in more practical matters, I like(d) your idea of "objectifying"(?)
> GEM 16-bit code.
>
>
> Sincerely,
>
> Thomas Clayton
>
>
> --- On Thu, 11/5/09, Shane Gough <goughsw at gmail.com> wrote:
>
> > From: Shane Gough <goughsw at gmail.com>
> > Subject: Re: [GEM Development] [GEM-DEV] GEM 32
> > To: "GEM Development" <gem-dev at simpits.org>
> > Date: Thursday, November 5, 2009, 4:20 AM
> > Hi Tom,
> >
> > Pretty much - although I have some code snippets to prove
> > (or disprove) various ideas. Certainly nothing that could be
> > publicly released that would contribute anything.
> >
> > In my defence I will argue that many systems started out
> > this way - the Linux kernel is a good example :P
> >
> >
> > I am certainly not promising anything - if you read that
> > from my emails I apologise. I'm simply interested in the
> > idea, believe I have the skills to implement it and (it
> > seems) others are interested as well. To me this is an
> > interesting intellectual problem (and I'd rather be
> > writing code than watching TV) - I don't get paid for
> > this, it's never going to make me any money and it's
> > a choice I make about how I choose to spend my spare time.
> >
> >
> > Sorry to seem like I'm ranting but this is the only
> > forum I get to discuss my ideas about this particular topic.
> > It doesn't really matter if I do something about them or
> > another reader does (or someone scanning the archives in a
> > couple of years time). At this stage it is little more than
> > an idea (in my minds eye as you say) and I've not
> > presented it in any other way.
> >
> >
> > Regards,
> > Shane
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.simpits.org/pipermail/gem-dev/attachments/20091108/4323ebd9/attachment.html 