🚀 go-pugleaf

>>====>

In article <8602181908.AA07989@mitre-bedford.ARPA> jhs@MITRE-BEDFORD.ARPA writes
>Have any of you hackers out there figured out how to access CPM/68K without
>buying the $300 "developers' kit"?  According to COMPUTE! Magazine, the
>GEM desktop is "really" built on top of CPM and can be "peeled away" if you
>know how.  It seems that getting rid of GEM should cost negative, not positive
>dollars!  Has anybody figured out how to do this?

Agh, what does COMPUTE! magazine know about anything? The GEM Desktop (and
GEM in general) is NOT built on CP/M-68K. CP/M-68K doesn't support sub-
directories (aka folders), so we wrote a new operating system called GEMDOS
(renamed by Atari to TOS) that supported subdirectories and an MS-DOS
compatible file system.

You can peel GEM away if you really want; you won't have any means of
talking to GEMDOS then. What you want is the command line interpreter,
which uses that familiar old {A} prompt. And that comes with the developer's
kit. However, Dr. Dobbs has been publishing a command line interpreter for
the PC; somebody could merely adapt this for the ST and make it public domain.


-- 


Bruce Holloway
Digital Research, Inc.
60 Garden Court
Monterey, CA  93942

....!ucbvax!hplabs!amdahl!drivax!holloway
(I'm not THAT Bruce Holloway, I'm the other one.)

In article <285@drivax.UUCP> holloway@drivax.UUCP (Bruce Holloway) writes:
>Agh, what does COMPUTE! magazine know about anything? The GEM Desktop (and
>GEM in general) is NOT built on CP/M-68K. CP/M-68K doesn't support sub-
>directories (aka folders), so we wrote a new operating system called GEMDOS
>(renamed by Atari to TOS) that supported subdirectories and an MS-DOS
>compatible file system.
>Bruce Holloway
>Digital Research, Inc.
>60 Garden Court
>Monterey, CA  93942
>....!ucbvax!hplabs!amdahl!drivax!holloway

From the horses mouth yet!!

Since he's to modest to point it out, GEMDOS has many other nice
characteristics that CP/M didn't, like direct interface to high level
languages like C (especially C).  This eliminates the need for the
time consuming "glue", of interface routines that stuff things from
the stack into registers, and back.  The calling technique is not
much different from UNIX calling proceedure.  Push arguments, trap,
pop or "drop" arguments, you're done.

To answer the original question (interfaces to OS calls), you may
find "ST Internals" and "Gem Programmers Guide" from ABACUS to be
quite useful.  These books are about $20 each.  The developers kit
is a good investment if you want to do some heavy programming.

Important note if you use the DRI C compiler, it uses 16 bit "Ints".
Assignment of ints to pointers, even with casting, is non-portable.
Using 16 bit Ints make things run lots faster too.

There are several good "shells", ranging from the command.prg, to
one that has most of the features of csh.

Since DRI is on the net, maybe they can tell us more about TOS/GEMDOS
re-entrancy and multitasking capabilities.  Assuming we know about
the 6 desk accessories plus various drivers, is it possible to add
a real-time clock interupt handler that can do the AES calls automatically?
(AES "Application Environment Services" is like the "system scheduler"
in UNIX, but currently has to be "called" periodically to give other
processes a chance to execute.)

Any plans for multiple forground tasks?

Any plans for multiple background tasks?

Pre-emptive multitasking?

Assuming there were some tradoffs to make the forground application
run faster, is it possible to alter these tradoffs?  If it is trivial,
could you give us some hints?