home Asteroids | Donkey Kong | Duck Hunt | Frogger | Moon Patrol | Pacman | Pong | Simon | Space Invaders | StarCastle | Tertis

1986
                   
1987
1988
1989
2000
2001
2002
2003
2004
2006
   

Home

Asteroids | Donkey Kong | Duck Hunt | Frogger | Moon Patrol | Pacman | Pong | Simon | Space Invaders | StarCastle | Tertis

Date: 1987-11 atari800xl.org comp.sys.atari.8bit
cc8 documentation  
 
1.  Jim Saulnier X7097  
 More options Nov 3 1987, 3:25 am
Newsgroups: comp.sys.atari.8bit
From: sauln@cg-atla.UUCP (Jim Saulnier X7097) -
Date: Mon, 2-Nov-87 13:25:02 EST
Local: Tues, Nov 3 1987 3:25 am
Subject: cc8 documentation
| | | | | | |
Could the author/distributor of the "cc8" C compiler please repost
the documentation of same? I have searched my entire account and it
seems to be gone. (Our system does that sometimes....takes things with
it when it crashes, which is often, unfortunately.)

Many thanx.
--
Jim Saulnier

...!{decvax,ima,ism780c,ulowell,cgeuro,cg-f}!cg-atla!saulnier
"Wow, it never did THAT before."


 
Several things  
 
1.  John R. Dunning  
 More options Nov 3 1987, 6:35 am
Newsgroups: comp.sys.atari.8bit
From: j@STONY-BROOK.SCRC.SYMBOLICS.COM (John R. Dunning) -
Date: Mon, 2-Nov-87 16:35:00 EST
Subject: Several things
| | | | | | |
A while ago, I posted an upgraded, bug-fixed etc version of Kermit-65.
I haven't seen it appear in the archives, nor have I seen any mail about
it.  Does anyone know what happened?  Did it disappear into hyperspace?
I'll repost it if so.

Second thing:  I'm whipping up a new assembler for use in the C compiler
project, and was wondering what sort of macro syntax anyone prefers?
In particular, what does MAC/65 do?  I gather from reading mail that a
number of folk like that one.  Any other favorites?  Any particular
kinds of macro capabilities in demand?  

Finally, in digging back thru old mail, I discovered a rumor that
someone was going to come up with a relocatable object format.  I
haven't seen anything about it since; does anyone have any info about
such a thing?  If not, I'll finish my own design and use that.

Thanks for any feedback.


 
Turbo BASIC runtime and compiler compatibility with SpartaDOS.  
 
1.  jhs  
 More options Nov 3 1987, 8:19 am
Newsgroups: comp.sys.atari.8bit
From: j@MITRE-BEDFORD.ARPA -
Date: Mon, 2-Nov-87 18:19:00 EST
Subject: Turbo BASIC runtime and compiler compatibility with SpartaDOS.
| | | | | | |
Thanks to John DiMarco for supplying the following information.
-John Sangster, j@mitre-bedford.arpa
------- Forwarded Message
From: "John D. DiMarco" <jdd%csri.toronto.@RELAY.CS.NET>
Message-Id: <8711022059.AA24394@csri.toronto.edu>
To: jhs
Subject: Re: FROST and Turbo BASIC questions...
-------
The Turbo basic runtime and compiler systems do NOT work on an XL running
spartados.

John DiMarco              Disclaimer:   I take complete responsibility for
                                        anything I have written above.
j@csri.toronto.edu                    The University of Toronto can in no
ihnp4!utzoo!utcsri!jdd                  way be responsible for anything I say.
-------------------------end-of-forwarded-message-----------------------------


 
FROST and Turbo BASIC questions...  
 
1.  O.ALEXANDER  
 More options Nov 3 1987, 10:56 pm
Newsgroups: comp.sys.atari.8bit
From: o@houxl.UUCP (O.ALEXANDER) -
Date: Tue, 3-Nov-87 08:56:01 EST
Local: Tues, Nov 3 1987 10:56 pm
Subject: Re: FROST and Turbo BASIC questions...
| | | | | | |

In article <8710292249.AA12@mitre-bedford.ARPA>, j@MITRE-BEDFORD.ARPA writes:
> Does anybody know if the Turbo BASIC compiler and runtime system work

>     (a) on an 800 or upgraded 400?

FROST BASIC will work on a 800 or 400 as well as an XL/XE computer.

Turbo BASIC will only work on an XL/XE and gives about 12K more RAM.

>     (b) on an XL/XE under SpartaDOS or DOS-XL or any other
>    DOS that uses portions of the RAM under ROM?

Turbo BASIC will not work with any DOS that uses the RAM under the
ROM.

FROST BASIC will only work with the DOS that is supplied on it's disk.
The compiler and DOS are very closely tied (I tried unsuccessfully to
de-couple them), if fact they are appended together as one binary file,
and the compiler uses hard coded vectors to interface with the DOS.

============================================================================
Owen Alexander          | For the wages of sin is death; but the gift of
AT&T Communications     | God is eternal life through Jesus Christ our Lord.
UUCP: ihnp4!houxl!oaa   |                              - Romans 6:23 -
============================================================================


 
 
2.  PATRICK  
 More options Nov 5 1987, 2:31 am
Newsgroups: comp.sys.atari.8bit
From: P@PSUVMA.BITNET (PATRICK) -
Date: Wed, 4-Nov-87 12:31:53 EST
Local: Thurs, Nov 5 1987 2:31 am
Subject: Re: FROST and Turbo BASIC questions...
| | | | | | |
As far as I know,Turbo Basic wont work very well with Dos Xl,
I dint try it will Sparta Dos,I think My Dos 4.3B (With Ramdisk)
will work,for the 800XL at least!!!

 
1050 disk format  
 
1.  Jeff Makey  
 More options Nov 4 1987, 3:41 am
Newsgroups: comp.sys.atari.8bit
From: M@LOGICON.ARPA (Jeff Makey) -
Date: Tue, 3-Nov-87 13:41:00 EST
Subject: 1050 disk format
| | | | | | |
I am writing an exerciser for my (unmodified) Atari 1050 disk drive,
and I would like to know what the "worst cast" pattern is that I should
write to the disk to test for bad media.

For the uninitiated, the worst case pattern is like alternating ones
and zeroes, except that the particular method of encoding the ones and
zeroes on the disk may mean that a different pattern is actually the
"worst" case.  Thus, even if you don't know which pattern is worst you
could help me if you could tell me how ones and zeroes are physically
stored on the disk.  Thanks in advance.

                       :: Jeff Makey
                          M@LOGICON.ARPA


 
 
2.  Terry Conklin  
 More options Nov 4 1987, 5:34 pm
Newsgroups: comp.sys.atari.8bit
From: conk@eecae.UUCP (Terry Conklin) -
Date: Wed, 4-Nov-87 03:34:42 EST
Local: Wed, Nov 4 1987 5:34 pm
Subject: Re: 1050 disk format
| | | | | | |

Since the format itself is untouchable on a stock 1050, your
only option would be to use worst case data.

The TRS-80 always used the Hex byte E5 to fill all the unused
sectors on a track. This was the worst case data you could
get, and helped verify flaky disks. Since the TRS, Atari,
IBM and ST all use (cough) the same disk format (well, I us
the TRS to copy disks for all of the above!) it would seem
a safe assumption that this would prove close if not it.

Terry Conklin
ihnp4!msudoc!cs the


 
 
3.  Jim Saulnier X7097  
 More options Nov 8 1987, 2:17 pm
Newsgroups: comp.sys.atari.8bit
From: sauln@cg-atla.UUCP (Jim Saulnier X7097) -
Date: Sun, 8-Nov-87 00:17:26 EST
Local: Sun, Nov 8 1987 2:17 pm
Subject: Re: 1050 disk format
| | | | | | |

        Here in diagnostic land, we have always used a worst case
data pattern of ->  6D, B6, DB when testing floppy subsystems.  I'm not
sure why this pattern came into being, but I do know that we have been
using this as a standard for many years, and this company is usually
more conscious of it's diagnostics than most other companies.

--
Jim Saulnier

...!{decvax,ima,ism780c,ulowell,cgeuro,cg-f}!cg-atla!saulnier
"Wow, it never did THAT before."


 
 
4.  Hans Breitenlohner  
 More options Nov 12 1987, 2:15 am
Newsgroups: comp.sys.atari.8bit
From: h@umd5.umd.edu (Hans Breitenlohner) -
Date: Wed, 11-Nov-87 12:15:41 EST
Local: Thurs, Nov 12 1987 2:15 am
Subject: Re: 1050 disk format
| | | | | | |
The 1050 disk drive (as all Atari drives) uses industry standard (or is it
IBM standard) Floppy disk format (except that the index hole is not used).
In single density FM encoding is used, in double (or enhanced) density
MFM encoding is used.  

FM encoding records a transition in the middle of each bit cell, and an
additional transition between equal bits.
MFM encoding records a transition in the middle of bit cells containing
a one bit, and additional transitions between bit cells which both contain
zero bits.
Thus transitions are one-half or one bit cell apart in FM mode; and one,
one-and-a-half, or two bit cells apart in MFM mode.  Note: Since the bit
density is twice as high in MFM mode, the actual minimum and maximum spacing
between transitions is the same in both modes.

The lowest density of recorded transitions in either mode happens for
alternating 0 and 1 bits.
The highest density of transitions in either mode occurs for sequences of
all zero bits or all one bits.
The intermediate transition density in MFM mode occurs for sequences of
the form 001001001 etc.

A good test pattern probably should contain some of all
recording densities.  IBM uses data bytes of E5 to fill empty sectors
in FM mode, which qualifies on that count.  Similarly the pattern 6D B6 DB
which was suggested alternates between high and low density transitions in
MFM mode.  I would think, however, that a good MFM test pattern should also
contain a good supply of medium-density signals, to verify that the three
spacings can be distinguished reliably.

An additional complication you need to know about is the fact that all data
bytes are inverted before they are written to disk, and after reading.


 
Repost: CC8 documentation  
 
1.  Stephen Kennedy  
 More options Nov 4 1987, 12:38 pm
Newsgroups: comp.sys.atari.8bit
From: s@cbterra.ATT.COM (Stephen Kennedy) -
Date: Tue, 3-Nov-87 22:38:59 EST
Local: Wed, Nov 4 1987 12:38 pm
Subject: Repost: CC8 documentation
| | | | | | |

[ This is a repost of the V2.3 CC8 documentation.  I've fixed some
  grammatical and spelling errors and appended the notes for V2.3b,
  the last posted version of the compiler. - Steve ]

CC8 DOCUMENTATION

This compiler is an upgraded version of the Deep Blue C (DBC) compiler
which supports more features of standard C and is much faster.  It
generates the same kind of pseudo code as DBC and ACE C and can
be used with either's linker and runtime engine.  I recommend using ACE
C for its speed and expanded features.  This document gives a brief
overview of the extended features of the compiler along with its
limitations.

This document is not intended as a C tutorial, nor is it intended
as a tutorial for DBC or ACE C.  Features such as assembly language
protocol, built-in routines, and floating point depend solely upon the
type of linker and runtime system you are using, and NOT upon this compiler.

PREPROCESSING

CC8 supports all preprocessor functions except for #line.  This
includes macro functions, #ifdef, #ifndef, #if, and #undef.  In addition,

    o #include files may be nested (currently only 2 deep)

    o no restriction on placement of comments

    o the TAB character may be used as white space.

    o predefined symbols __LINE__ (replaced by current line number) and
      __FILE__ (replaced by current file name).

    o #ifdef, #ifndef, and #if may be nested (5 deep maximum).

Caveats:

    - "bizarre" usage of #define macros may not work as expected (or
      at all)

    - in the "skipped" section of an #ifdef-#else-#endif group, comments
      are not processed.  Thus it is not a good idea to "comment out"
      #else's or #endif's.

VARIABLE DECLARATIONS

CC8 supports more complex type constructions than DBC or ACE C, e.g.,
pointers to pointers.  In addition, the types struct, union, and enum
have been added and variables can be declared static.

    o multidimensional arrays may be declared.

    o functions may be declared as returning char, int, or pointer
      to anything.  Pointers to functions, arrays of pointers to
      functions, etc, may be declared.  Note:  a pointer to a
      function must now be used correctly:

        (*pf)();

        not

        (pf)();

    o variables declared as type "enum x" are really declared as
      type "int"; the name "x" is ignored.  Note that user
      assignment of numbering scheme is implemented, e.g.,

        enum colors $( red = 2, white = 0, blue $);

      assigns red = 2, white = 0 and blue = 1.

    o external array declarations of the form

        extern int array_name[];

      are now valid.

    o in expressions, the sizeof and type cast operators may be
      used.

Caveats:

    - no float/double declarations (but a limited floating point is
      available when ACE C's linker and runtime engine are used)

    - all struct/unions must have a tag name

    - all global symbols, struct/union tags and components are drawn
      from the same name pool.

    - no bit fields

    - identical declarations of a variable neither cause an error
      nor do they work reasonably.  For example,

      int a; int a;

      will silently declare "a" twice and confuse the linker.

COMPILE TIME EVALUATION OF CONSTANT EXPRESSIONS

CC8 supports a limited form of compile time evaluation of
constant expressions.  A constant expression is defined as
any expression containing integer constants, character constants,
sizeof, or a constant expression separated by one or more operators
in one of the following groups, "|", "^", "&", "==", "!=", ">> <<",
"+ -", "* / %", or prefixed by one of the unary operators, "-",
"!", "$-".  Evaluation follows normal rules of operator precedence
and can be overridden by parentheses.  Examples:

    x = 12*24 + 13;     =>   x = 301;

    x = 12 + 13 + y;    =>   x = 25 + y;

    x = y + 12 + 13;    =>   x = y + 12 + 13; (1)

    x = y + 12*13;      =>   x = y + 156; (2)

    x = y + (12 + 13)   =>   x = y + 15; (3)

    1. compiler "gives up" after finding non-constant 'y'.

    2. '*' is in a different precedence group than '+' and thus "12*13"
       appears to the compiler as a separate expression.

    3. Parentheses force compiler to treat "12 + 13" as a subexpression.

Constant expressions may be used in array declarations, initializers,
and #if.

INITIALIZERS

CC8 supports initialization of global variables of type char, int,
pointer, array, struct/union, and enum.  The syntax is a subset of that
allowed by standard C.

Rules:

    1.  Simple types (char, int, pointer) can be initialized by
        a constant expression.  The constant expression must not
        be enclosed inside $( $).  Absolutely no type checking is
        done.  The definition of constant expression is extended
        to include:

            o address of static variable
            o static array names
            o function names
            o "character string"

    2.  Aggregate types can be initialized by the following
        construct:

        $( init-element-1, init-element-2, ..., init-element-m $)

        a. if fewer initializers than elements appear, the rest of
           the aggregate is initialized to zero.

        b. if the number of elements of an array is not specified,
           then it will be set to the number of initializers.

        c.  a character array may be initialized by a string.

    Examples:

    int x = 23*22;

    char *p = "hello";
    char q[10] = "hello";     /* q[6] ... q[9] are set to '\0' */

    int f();
    int (*pf)() = f;

                                /* array bound set to 5 */
    char *weekdays[] = $( "Mon", "Tues", "Wed", "Thu", "Fri" $);

    struct x $(
        char *symbol;
        int  value;
        $);
    struct x tab[] = $(
        $( "word1", 4 $),
        $( "word2", 8 $),
        $( "word3", 13 $)
        $);

Caveats:

    - local variables cannot be initialized (bad programming practice
      anyway)

    - unions cannot be initialized (properly, that is)

GOTOS AND LABELS

CC8 supports the dreaded goto statement and labels.  Note:  the compiler
cannot distinguish between labels and local variables.

ERROR HANDLING

Error messages are printed in the typical Unix C fashion:

    file-name, line #: error message

In addition, the line causing the error is printed.  Note:  if the error
occurs near the end of a line, the compiler will usually flag the next line.

This compiler, like DBC and ACE C, does not know how to intelligently
recover from syntax errors.  For this reason, the compiler will halt
compilation after 8 errors.

The compiler no longer exits directly to DOS on fatal errors (e.g., too
many errors) so that the user may jump directly to an editor using
the command line feature described below.

I would appreciate knowing if the compiler hangs after finding an error
or a certain sequence of errors.

INTERNAL LIMITS AND TABLE SIZES

Lest we forget this is not a 48K 8 bit implementation of C, here are
some of the more important limits:

1.  7000 bytes of "global space" -- shared by:

    - macro definitions
    - each unique non-macro symbol name (15 bytes + length of symbol)
    - global symbol type info

2.  256 bytes of "local space"

    - local symbol type info
    - only 128 local symbols may be declared.

3.  A source line may not be longer than 254 characters after macro
    expansion.  WARNING:  this limit is not checked!

4.  An expression cannot generate more than 512 bytes of p-code
    instructions.  An expression violating this limit would be
    ridiculously huge.  WARNING:  this limit is not checked!

5.  512 bytes of "string space"

    - This table was 3000 bytes in DBC and probably ACE C too.
    - A way around the size constraint is to use initializers:

        char dummy1[] = " ... ";
        char dummy2[] = " ... ";
             ...

6.  2300 bytes of stack space

    The compiler has been written to conserve stack space, so stack
    overflows should be a rarity.  This is fortunate because --
    WARNING:  this limit is not checked!  Stack overflow will overwrite
    screen memory (but it's possible compilation will complete normally).

7.  #define macros may have up to 128 arguments.

CC8 uses memory from MEMLO to MEMTOP and locations $480 to $6FF.  MEMLO
must not exceed $2BFF.

SPEED

CC8 is much faster than DBC and slightly faster than ACE C (15% -
30% depending on type of program).  Compilation time is affected
most by the presence of #defines.  You should expect compilation
times of 15 to 30 seconds for small programs, and up to 2:00 for large
programs with many #defines.  Larger source files are possible, but run
the risk of running out of internal table space.  Some sample times:

    Program Description         SC      ACEC    DBC
    -------------------         --      -----   ---
    238 lines, no #defines      58      80 (1)  551
    same, one #define           66 (2)  77 (1)  -

    482 lines + 222 #include'd
    many #defines + comments    107     -       -

Note:  these timings were made on an 800xl with a 1050 running DOS 2.5
       with write verify on.

(1) I can't explain this anomaly.

(2) The reason one #define makes so much difference is that the compiler
    takes advantage of the zero #defines to skip part of the pre-
    processing phase.

COMMAND LINE FEATURES

For users of DOS' that take a long time to reload (such as DOS 2.X), a
way to load and run files directly from the command line has been
provided.

    o ^L<RETURN>           runs file called "D1:LINK.COM"
    o ^Lfilename<RETURN>   runs file called "filename"
                           ("D1:" and ".COM" default)
    o ^E<RETURN>           runs file called "D1:EDIT.COM"

Note this feature is in its infancy.

    1. The control characters print as their equivalent graphic characters.

    2. ^L runs the ACE C and DBC linkers, and ^E runs SpeedScript.  Nothing
       else has been tested.

    3. "Theoretically" the load routine understands INIT addresses.

MISCELLANEOUS

Switch statement handling has been reworked.  The last clause need not
end in "break", "continue", or "return".  In addition, the "default"
clause need not be the last (this was a bug in DBC).  On the down side,
you are limited to 100 "case"s per switch statement, and switch statements
may be safely nested only four or five deep.  I'll wait
...

 


 

- - - -
End