accessing CPM/68K on the 520ST
j...@mitre-bedford.arpa
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?
(I dunno why I care - I haven't bought my ST yet!!!)
-John Sangster
jhs at mitre-bedford.arpa
Bruce Holloway
In article <8602181908.AA07989@mitre-bedford.ARPA> j...@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.)
rex ballard
>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.
>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?
m5@megamax
About using GEM from C:
Sorry, rb@ccivax, but there really are glue routines to get from C to
GEMDOS. The parameters to the routines have to be moved from the
stack to the "intin", "intout", "control", etc. arrays.
Mike McNally
convex!ctvax!megamax!m5
jmi...@uokvax.uucp
The RGB monitor is no problem since any medium resolution negative sync monitor can be used, however, the monochrome monitor requires a 31.5 KHz
horizontal sweep rate and a vertical sweep rate that can be tweeked
to 71 Hz. The 71 Hz Vertical sweep was chosen to reduce the
harringbone and barber polling that occurrs because of the internal
frequencies present in the computer required to generate the color
burst sync. Several monochrome monitors will fit this description
if you are sure that the vertical freq. can be tweeked far enough.
The monochrome monitor should have a high persistence phosphor
so that flickering will be kept to a minimum. In monochrome mode,
the video is output in interlaced mode and must scan two complete
frames to complete one picture in the same amount of time that one
frame is scanned in color mode. Thus the 400 line resolution in
monochrome mode. There are rgb monitors that can scan at the 35 Khz
rate and have a high persistence phosphor but their cost is around
800.00 plus dollars and that was evidently not considered a
viable option. This would also require twice as much of aa graphics
frame buffer also causing larger than needed overhead. The capability
exists within the hardware to do this at a later date whenever the
monitor technology get's to a more economical position. This would
require different initialization of the graphics crt scan control
registers as well as all the application software routines.
David N. Horn
use interlace, i.e. all 400 lines are scanned in one frame (vertical scan)
period. Thus a long persistance phosphor is not needed.
Dave Horn, AT&T Bell Labs, Holmdel, NJ, vax135!dh