[comp.sys.atari.st] versions

to_stdnet@stag.UUCP (06/09/89)

From: stag!thelake!steve@bungia.mn.org (Steve Yelvington)

 kbad@atari.UUCP (Ken Badertscher) writes ...
 
> In article <801@orbit.UUCP> steve@pnet51.cts.com (Steve Yelvington) writes:
> | The Sversion() Gemdos function allegedly provides this information, but on my
> | STFM it returns a value of 0.19. Does anybody know whether Sversion() really
> | works?
> 
> Hmm, Sversion is returning a float value?  Hmmm... ;-)

No, I'm not *that* silly. What I did was:

#include <stdio.h>
#include <osbind.h>
main()
   {
   int vsn;
   vsn = Sversion();
   printf("Version %d.%d\n", vsn & 0xFF, (vsn >> 8) & 0xFF);
   }

... basing the above on the Sversion() documentation in Pollack & Weber's
"Atari ST Application Programming," which says in part:
    "The high byte contains the minor version number and the low byte
     the major version number."
> 
> Sversion() returns the GEMDOS version number, not the TOS version.  The
> GEMDOS version number for your machine should be 0x1300 (our version
> numbers are all WORD values); I'm not sure how you get 0.19 from that,
> but...   

Well, 19 decimal == 13 hex. 

(stuff omitted)

> Versions
> ==============
>  ROM TOS  Mega TOS  
>  -------  --------  -------
>   $0100    $0102     $0104      TOS version (from the OS header)
>   $1300    $1300     $1500      GEMDOS version (from the Sversion call)
>   $0100    $0120     $0140      AES version (from global[0] after appl_init)
> 

Heh... what IS the new version of TOS going to be called, Ken? 
Besides late, I mean. :-)

> Can you now see why we don't like to give OS releases specific version
> numbers? ;-)
 
This reminds me of when I worked at the (late, lamented) St. Louis
Globe-Democrat and had to converse with the platemakers regarding editions
of the paper. The edition we in the newsroom called "Early Metro"
was the one they called "The run that goes down after Charlie goes to
dinner." And our business was communications....

At any rate, I'll alter my version-reading program to deliver values for
all three magic numbers. Thanks for the info.



#define steve@thelake.UUCP      pwcs!stag!thelake!steve
#define steve@thelake.citadel   the_land!class68!thelake!steve

kbad@atari.UUCP (Ken Badertscher) (06/13/89)

In article <865@stag.UUCP> to_stdnet@stag.UUCP writes:
|  kbad@atari.UUCP (Ken Badertscher) writes ...
|
| > Hmm, Sversion is returning a float value?  Hmmm... ;-)
|
| No, I'm not *that* silly.  [source code omitted...]

Of *course* you aren't.  *I* was being silly (note the smiley above... ;-).

| ... basing the above on the Sversion() documentation in Pollack & Weber's
| "Atari ST Application Programming," which says in part:
|     "The high byte contains the minor version number and the low byte
|      the major version number."

Oh my, I stand corrected.  That documentation is corroborated by the
GEMDOS documentation, which says that Sversion returns the GEMDOS
version number "in byte-reversed format."  Don't ask me why it's like
that...  In fact, the Pexec Cookbook is incorrect in this regard, it
states that the high byte is the major version number.  According to
the GEMDOS bible, the high byte is the MINOR version number.  So
byteswap it before doing any version dependancy tests.

| Heh... what IS the new version of TOS going to be called, Ken? 
| Besides late, I mean. :-)

My lips are sealed until the general ROM release.  WhoKnowsWhen.


-- 
   |||   Ken Badertscher  (ames!atari!kbad)
   |||   Atari R&D System Software Engine
  / | \  #include <disclaimer>

leo@philmds.UUCP (Leo de Wit) (06/14/89)

In article <1555@atari.UUCP> kbad@atari.UUCP (Ken Badertscher) writes:
|In article <865@stag.UUCP> to_stdnet@stag.UUCP writes:
   []
|| Heh... what IS the new version of TOS going to be called, Ken? 
|| Besides late, I mean. :-)
|
|My lips are sealed until the general ROM release.  WhoKnowsWhen.

Sounds like a good name to me, Ken; you have my vote ;-)

    Leo.