RDROYA01@ULKYVX.BITNET (04/12/86)
Date: Sat, 12 Apr 86 09:12 EST
From: (1) <RDROYA01@ULKYVX.BITNET>
Organization: University of Louisville
Subject: How close to ALCYON C is TOS?
To: info-atari16@su-score.stanford.edu
X-Original-To: info-atari16@su-score.stanford.edu
Quote of the week: "What do you do when the people you knew were the plastic
that melted and the chromium too? / Who are the brain
police?"
-frank zappa
I have received a lot of buzzing about an entry I had on the net.
RUMORS was the name. In it I asked if TOS was really cp/m68k. No
it is not everyone said. But I'll bet it's written in ALCYON C
because the file header format and the exception format are too close
for coincidence. I didn't say why I asked at first, but perhaps I should
have. I write a lot of cpm-68k programs, and simply wondered whether the
object format (output from as68) was compatible. DRI claims rights to all
of the cpm-68k development tools, but they are actually third party
products -- i'll bet the same third party products that made cpm-68k, Tos,
and that are distributed in the developer's kit.
THE FOLLOWING IS HEARSAY FROM A TRUSTED SOURCE
David Betz writes about developing xlisp for the Atari using MicroEmacs
under CP/M-68K. This was said to be in the _BYTE_ section of *Compuserve*.
So, has anyone used the crippled cp/m-68k *and* TOS who can explain why
header format is the same and so forth and yet TOS was to have been designed
from the ground up?
RDROYA01@ULKYVX.BITNETdyer@atari.UUcp (Landon Dyer) (04/15/86)
How far is up? Why change a perfectly good object code format? You think reinventing the wheel is fun, maybe? Executable file loaders are not hard to write. The GEMDOS C compiler is the Alcyon C compiler (a couple of centuries old -- ask DRI why they haven't released any new versions in the last couple years) -- the SAME compiler that also runs on CP/M-68K. Only the changes needed to make it run on the ST were made. The only differences between CP/M-68K and GEMDOS binary files are: o The relocation information is compressed (say, to about 5% of the total file size, on the average) under GEMDOS. (Those of you familiar with CP/M-68K are nodding your heads right now). o There are no "absolute" files under GEMDOS (thank God). You could do ST development under CP/M-68K, if you wanted to. In fact, that's what Atari did in the early days of the project. -Landon "If business is war, then I'm a prisoner of business!"
braun@drivax.UUCP (Karl Braun) (04/17/86)
In article <8604121902.AA24030@ucbvax.berkeley.edu> RDROYA01%ULKYVX.BITNET@SU-Forsythe.ARPA writes: > >I have received a lot of buzzing about an entry I had on the net. >RUMORS was the name. In it I asked if TOS was really cp/m68k. No >it is not everyone said. But I'll bet it's written in ALCYON C >because the file header format and the exception format are too close >for coincidence... ... > >David Betz writes about developing xlisp for the Atari using MicroEmacs >under CP/M-68K. This was said to be in the _BYTE_ section of *Compuserve*. >So, has anyone used the crippled cp/m-68k *and* TOS who can explain why >header format is the same and so forth and yet TOS was to have been designed >from the ground up? > >RDROYA01@ULKYVX.BITNET I don't quite follow your line of questioning, so I will just throw this out and see if it helps: GEM was written for the PC. Atari had this new machine (the 520) and liked the GEM environment, and asked us to provide such an environment on the 68k. Original plans were for some sort of crude DOS emulator on top of CPM/68K. But one of our (former) engineers, Jason (born to code) Loveman had a "Dos Jr." prototype running (this is the infamous JasonDos written about in Inforworld (I think)). It was a better alternative to bring this prototype to production than coerce CPM/68K to do the same, so GEMDOS was born. It was developed under CPM/68K, and so the Alcyon compiler was used. So: GEMDOS uses the Alcyon compiler, and I presume Atari does too (we hand code over to them for their mods); thus the familiar object format. It is not, nor has it ever been CPM/68K. -- kral ihnp4!-------- \ mot! ---------- \ > drivax!braun ucscc!--------- / amdahl!------- / -- -- kral ihnp4!-------- \ mot! ---------- \ > drivax!braun ucscc!--------- / amdahl!------- / ----- The opinions expressed here are my own, and do not necessarily reflect the opinions of my employers, my country, the minor deities from the Halls of Asgaard, or the great Prophet Zarquon. ----
holloway@drivax.UUCP (Bruce Holloway) (04/17/86)
In article <8604121902.AA24030@ucbvax.berkeley.edu> RDROYA01%ULKYVX.BITNET@SU-Forsythe.ARPA writes: > >THE FOLLOWING IS HEARSAY FROM A TRUSTED SOURCE > >David Betz writes about developing xlisp for the Atari using MicroEmacs >under CP/M-68K. This was said to be in the _BYTE_ section of *Compuserve*. >So, has anyone used the crippled cp/m-68k *and* TOS who can explain why >header format is the same and so forth and yet TOS was to have been designed >from the ground up? Why do you think? The load file format for TOS programs is identical to that for CP/M-68K programs, except that the relocation information has been compressed. The header at the beginning is the same because the load files are at least that similar. -- "Pitiful Earthlings.... who will save you now?" ....!ucbvax!hplabs!amdahl!drivax!holloway (I'm not THAT Bruce Holloway, I'm the other one.)
holloway@drivax.UUCP (Bruce Holloway) (04/17/86)
In article <434@drivax.UUCP> braun@drivax.UUCP (Karl Braun) writes: > >I don't quite follow your line of questioning, so I will just throw this out >and see if it helps: > >GEMDOS uses the Alcyon compiler, and I presume Atari does too (we hand code >over to them for their mods); thus the familiar object format. It is not, nor >has it ever been CPM/68K. Let's get our stories straight, Karl. I think he was referring to the load format, which is essentially the same. > >The opinions expressed here are my own, and do not necessarily reflect the >opinions of my employers, my country, the minor deities from the Halls of >Asgaard, or the great Prophet Zarquon. However, mine do. -- "Pitiful Earthlings.... who will save you now?" ....!ucbvax!hplabs!amdahl!drivax!holloway (I'm not THAT Bruce Holloway, I'm the other one.)