jhs@MITRE-BEDFORD.ARPA (02/18/86)
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? (I dunno why I care - I haven't bought my ST yet!!!) -John Sangster jhs at mitre-bedford.arpa
lbl@druhi.UUCP (LocklearLB) (02/20/86)
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? > > -John Sangster > jhs at mitre-bedford.arpa If COMPUTE! said that the 520ST uses CPM/68K, then they are just plain wrong. The underlying operating system for the ST is GEMDOS, which has functionality similar to MSDOS. Access to GEMDOS is done by merely doing gemdos() calls with the appropriate parameters. Thats all it takes. Of course, the compiler or interpreter that you are using must provide the bindings for these calls, but that is another matter. By the way, you never "get rid" of GEM in the sense that the code for it becomes non-resident (especially since it is now in the ROMs!), you can only by-pass it. Barry Locklear AT&T Information Systems Labs Denver, CO (303) 538-4954 ihnp4!druhi!lbl
holloway@drivax.UUCP (Bruce Holloway) (02/20/86)
>>====> 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.)
rb@ccivax.UUCP (rex ballard) (02/24/86)
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?