=========================================================================
(C) 1994 by Atari Corporation, GEnie, and the Atari Roundtables. May
be reprinted only with this notice intact.  The Atari Roundtables on
GEnie are *official* information services of Atari Corporation. To sign
up for GEnie service, call (with modem) 800-638-8369.  Upon connection
type HHH (RETURN after that). Wait for the U#= prompt.Type XTX99437,GENIE
and press [RETURN]. The system will prompt you for your information.
==========================================================================
 ************
Topic 6         Sun Oct 25, 1992
ORA.TECH                     at 20:15 EST
Sub: Lattice C

Professional ANSI C development system
203 message(s) total.
 ************
 ------------
Category 33,  Topic 6
Message 1         Wed Feb 17, 1993
J.SIEBEN [Mike]              at 23:14 EST

I got Lattice this past xmas and have been going through the C-manship book,
now in chapter 12.  I have had some confusion about the docs and long and
short ints.  I guess I am lucky I dabbled with assembly long enough to figure
out I wanted somthing to dot the i's and cross the t's for me <grin>.  Anyway
working through the VDI stuff I needed to reference Volume III (Atari
Libraries).  In the "Synopsis" section it describes variables as "int" and
"short".  So my assumption was to treat the size of int as long (the default).
With my previous dabbling in assembly I soon realized that for the most part
int in the VDI "Synopsis" should be short.

My question is can I assume (ya I know)<grin> that "int" in the library
manuals is always short?

Mike

 ------------
Category 33,  Topic 6
Message 2         Thu Feb 18, 1993
CBARRON                      at 03:00 EST

What LC actually provides is a binding to the rom code.  The parameters to the
actual ROM code are passed through static arrays of 16 bit integers and 32 bit
addresses.  What the C binding does is take the data from C's  parameter
passing method and stuff these arrays with appropriate data.  With this
background of what is really happening, it is proper for all valued integer
parameters to be of type int. and all addresses to integers to be of type
short *. Why,
 because all the bindings do is take the data and move it someplace, they then
trap to the aes/vdi.  So if the arguments are int and you are using 32 bit int
bindings they are smart enough to move only the lower 16 bits of the 32 bit
int you passed to the 16 bit int array the rom wants.   They should be int and
not short because ALL arithmetic on shorts is done with int size arithmetic.
Mere access to a short in 32 bit int mode causes an ext.l to be preformed
before doing anything.  When writing GEM programs in LC I recommend
sizeof(int)=2 mode.  Unless there is a reason to use 32 bit integers, such as
some of the code requires 32 bit ints.   Mixing sizeof(int) options with
different modules of a program is sure to cause problems...,
 ------------
Category 33,  Topic 6
Message 3         Sat Feb 20, 1993
J.SIEBEN [Mike]              at 00:48 EST

Carl,

I seem to remember having trouble with taking the default for int (4?) and
passing it in VDI calls.  When I changed it to short it worked fine.  If I
understand you correctly your are saying LC is smart enough to know even
though it is sizeof(4) it will fix it for the VDI parameter passing to
sizeof(2).  At any rate I'll take you advise and set sizeof(2).

Is that the long and short of it? :-)

Mike

 ------------
Category 33,  Topic 6
Message 4         Sat Feb 20, 1993
CBARRON                      at 03:36 EST

   LC is smart enough to know what to stuff.  It is not smart enough to know
you mean short * when you pass an int *, although if they aren't, the
prototypes should be fixed to this problem is caught. If I understant ANSI C.
I might not.  I have been proven wrong at least once this week elsewhere...


 ------------
Category 33,  Topic 6
Message 5         Sun Feb 21, 1993
A.STUDER1 [Andrew]           at 07:24 EST

What does my program do on a TOS <1.4 machine if I use ex_fsel() for the fsel
label function?  Do I have to test for the TOS version on things like this to
see use fsel on <1.4 and ex_fsel() on >=1.4? How about other similar
functions?  I no longer have TOS <2.05!

 ------------
Category 33,  Topic 6
Message 6         Sun Feb 21, 1993
J.SIEBEN [Mike]              at 12:33 EST

Andrew,

From what I understand, and I think I tried it if you use ex_fsel() on TOS <
1.4 you will crash, illegal AES call or somthing like that. I did up a
fileselector routine in Assembly and posted it in the Devpac Cat a while ago
that will deal with it and if LGS is installed it will use its features too.
The important thing is to check the AES version number as this is what you are
calling.  You can get away from it and use TOS, but someone somewhere will
have thier TOS and AES versions loaded differently...murphies law.

Mike

 ------------
Category 33,  Topic 6
Message 7         Sun Feb 21, 1993
ORA.TECH                     at 14:17 EST

The use of fsel_exinput will work on all version of TOS.  For versions earlier
than 1.4, it puts an obect with your identification string above the File
Selector.

Best regards,

Bob@ORA
 ------------
Category 33,  Topic 6
Message 8         Sun Feb 21, 1993
MIKE-ALLEN [NM~SysOp]        at 14:39 EST

Andrew,

I used a version of Mike Sieben's routine to check for AES version in my
TO_GSND prgs to choose between AES 90 and AES 91.  I just wish there was a way
to detect the presence of LGS.  I prefer LGS to AES 91.

If you want to see my code (assembly, not C) it is included in 2_GSNDV1.ZIP,
file #27650.

        Mike Allen
        HelpDesk~SysOp


 ------------
Category 33,  Topic 6
Message 9         Sun Feb 21, 1993
ST.LOU [Lou Rocha]           at 15:07 EST

Mike, is there a sound player that will play the SMP GEMSOUND files without
having to sign them as *.12?
 ------------
Category 33,  Topic 6
Message 10        Sun Feb 21, 1993
CBARRON                      at 23:10 EST

  if you use fsel_exinput() and your the tos running is < 1.4 then it will
draw an AES object outside of the file selector with the prompt string.  I
have done this and because it becomes avaiable to all tos's this way I see no
need to avoid fsel_exinput() ,except perhaps commenting that LC bindings fix
this for all tos's in the source code, for future reference.
   Others I have not used but I would guess many would fail, as there is no
documented way to get a list of open windows for this application, for
instance.


 ------------
Category 33,  Topic 6
Message 11        Mon Feb 22, 1993
MIKE-ALLEN [NM~SysOp]        at 03:20 EST

Lou,

There are a couple of ways to play the SMP files from SoundLab.  The easiest
is to rename them as .SAM files and load them into SoundLab. Set the sample
rate at 12.5 KHz and away you go.  There will probably be a 'tick' at the
beginning which is the info that lets GEMSOUND read them.

You can also import them into SoundLab as is and then hit the high bit button.
You may have to mark out a block after this is done to get rid of large
'ticks' at the beginning and end of the file.

Of course you can always play them from the GemSound CPX <g>.

        Mike.

 ------------
Category 33,  Topic 6
Message 12        Mon Feb 22, 1993
ST.LOU [Lou Rocha]           at 17:10 EST

Mike, I can play them from GEMSOUND CPX? My goodness, you're right! Thanks.

Now, can you tell me if there is a guide to interpret what all those commands
mean? I get stuck after Window Open :-)
 ------------
Category 33,  Topic 6
Message 13        Tue Feb 23, 1993
MIKE-ALLEN [NM~SysOp]        at 03:51 EST

Lou,

There was a bunch of discussion a while back on the various events in
cat2/top16.  I'm surprized that the 'mad mover' (Brian) hasn't moved us there
already! <g>

        Mike

 ------------
Category 33,  Topic 6
Message 15        Tue Feb 23, 1993
ST.LOU [Lou Rocha]           at 20:39 EST

Thanks Mike. I'll check 2/16

 ------------
Category 33,  Topic 6
Message 16        Tue Feb 23, 1993
BRIAN.H [ST~SysOp]           at 22:07 EST

Mike/Lou

 >  I'm surprized that the 'mad mover' (Brian) hasn't moved us there
 >already! <g>


I am watching you sysops [grin]. BTW, if you guys want to know how to find cat
2 topic 16, just let me know [grin].

                                *******Brian*********
        Written on Tuesday 23 February 1993 at 10:39 p.m. AST

 ------------
Category 33,  Topic 6
Message 17        Sat Feb 27, 1993
A.STUDER1 [Andrew]           at 22:56 EST

How would I open a file to the printer or serial port?  I can only do open
files to disk right now.  I want my program to be able to print to any device.
I'm using Bconout (DEV,byte) so hopefully I can use putc(byte,device) somehow
once I get device opened to something other than a disk file.

Lattic doesn't print out line numbers for the source code from it's editor, so
I wrote a lister program that does all this for me (to the screen, printer, or
modem) but I'm using Bconout and I'd rather use something standard so the
program will work on more than just the Atari platform.

Thanks.

 ------------
Category 33,  Topic 6
Message 18        Sun Feb 28, 1993
CBARRON                      at 02:44 EST

  #include <stdio.h>
  void print_file(FILE *fp,...);

  ....
  switch(device_type)
  {
  case PRINTER:
      print_file(stdprt,...);
      break;
  case SERIAL_PORT:
      print_file(stdaux,...);
      break;
  case SCREEN:
      print_file(stdout,....);
      break;
  case REAL_FILE:
      fp=fopen(filename,"w");
      print_file(fp,...);
      fclose(fp);
      break;
  }
  Above is a synopsis and not real C<grin>. it should give the ideas away.
There are also 'device names' recognized by fopen() to do the same to a user
opened file. See fopen() (stdio library for details, I THINK!)
 ------------
Category 33,  Topic 6
Message 19        Mon Mar 01, 1993
A.STUDER1 [Andrew]           at 08:11 EST

Lattice doesn't print line numbers with your source code from the editor so I
wrote a program to do this (TOS based) as my 2nd REAL Lattice program (the
first being a stock investment utility).  I uploaded it into the Atari ST
Library under the name P10.LZH for those of you who are interested.

It allows you to print a filename header, page numbers, and line numbers to
the printer, screen, or RS232 port.

You can select the lines per page (25 screen, 66 printer, etc) as well as a
left margin so that you have room for hole punches or notes!

I plan on a GEM version next, so you don't have to answer text prompts, type
your filename, and generally make it more attractive as well as getting away
from the scanf() input.  I will also add the cutting of a line past 80
characters and indenting it on the next to the next version.

If anyone has any ideas, I'd appreciate input, thanks!

This program uses Bconout to send the text to the various devices, but I have
another one that uses stdprt, stdaux, and stdout that I plan on testing after
compiling on the Amiga and IBM.  It outputs much more slowly to the screen,
just exacly how does the data get to stdout and would it be slower to the
printer as well (if you could notice)?

 ------------
Category 33,  Topic 6
Message 20        Mon Mar 01, 1993
A.STUDER1 [Andrew]           at 10:45 EST

That's great news about fsel_exinput working under all TOS version! Thanks,
Bob!

 ------------
Category 33,  Topic 6
Message 21        Tue Mar 23, 1993
D.SCHWINN [DAVE]             at 14:09 EST

I've been using the wind_redraw(...)  function in Lattice C for some time.
The way I use it works, but every time it compiles I get an error #88.

Here is how I use it :

#include <gemlib.h>

int redraw(short h, GRECT *r);

...

        case WM_REDRAW :
        ...
        wind_redraw( msg[3], (GRECT * ) &msg[4], redraw  );
        ...
        break; ...

Would you please tell me how to write this so I wont get the error message any
more?


 ------------
Category 33,  Topic 6
Message 22        Tue Mar 23, 1993
J.TRAUTSCHOL [jtrautschold]  at 22:10 EST

Dave...

You really didn't supply enough information in your example to totally
troubleshoot your problem, however, based on the error message (88) it's
fairly easy to take a guess.

Error #88 means that an argument type is incorrect in your call to
wind_redraw().  wind_redraw()'s bindings look like this:

    wind_redraw(int handle, GRECT *rect, int (*routine)(handle,p));

Make sure that "msg[3]" is an int and not a short.

(GRECT *)&msg[4] - doesn't really make sense.  GRECT holds 4 pointers to
x,y,w,h coordinates.  msg[4] probably holds those four pointers, but you are
dereferencing the address of msg[4] to a GRECT structure. I can almost
guarantee that the proper information is not being passed there.

redraw - This is a function you should be calling.  In your example it looks
as though you are calling your own function recursively.  No matter, you
aren't doing the call right.  You show redraw(short h, GRECT *r), but you
aren't passing any parameters to "redraw" in your wind_redraw() function!

You say that everything seems to work right, but I seriously doubt that it
does.  There are just too many mistakes in your wind_redraw() call to make it
come out right.

                                                John T.
 ------------
Category 33,  Topic 6
Message 23        Wed Mar 24, 1993
CBARRON                      at 02:00 EST

 Johm ! OOPS a GRECT is a structure containing four short ints.
   (GRECT *)(msg+4) or (GRECT *)(&msg[4])  surely makes sense!  I use it.
  typedef struct
  {
        short g_x,g_y,g_w,g_h;
  }GRECT; look it up....  Pointers can be confusing, but in this case
 (GRECT *)(&msg[4]) is fine.  (GRECT *)(msg+4) is simpler and the same
thing....
 ------------
Category 33,  Topic 6
Message 24        Wed Mar 24, 1993
D.SCHWINN [DAVE]             at 13:54 EST

John,

It DOES work fine... I've used (GRECT *) in every single GEM program I've
written.  I've seen it in books, mags, and here on GEnie.  Also, the structure
GRECT does not contain four pointers it contains four ints. The program works -
I just want to get rid of the warning message.  <g>

 ------------
Category 33,  Topic 6
Message 25        Thu Apr 22, 1993
C.ROUNTREE2 [RoadKill]       at 04:59 EDT

        I just up loaded a source code example on how to Code floating
Dialogs. I coded it in Lattice C and I tried to make it a s clear as possible,
with lots of explanations.

FLTDIALG.ZIP in catagory 3.


 ------------
Category 33,  Topic 6
Message 26        Wed Apr 28, 1993
D.LIVINGST11 [ErnestBovine]  at 02:14 EDT

  re: addheap() etc

 There are situations (all ACCs and some of my programs) where it  would be
nice to use standard C malloc() and free() functions, but be sure that they
will never request any more memory from the operating system with GEMDOS
Malloc(), beyond what my program allocated once at program start.
 Unfortunately, if you request a block that the Lattice memory allocator can't
provide, it calls GEMDOS Malloc() and grabs more.
 I guess I can work around it by writing my own malloc() and free().
 Is that the only way to do it?
 ------------
Category 33,  Topic 6
Message 27        Wed Apr 28, 1993
C.ROUNTREE2 [RoadKill]       at 03:22 EDT



        Can I access Structure members from the assembler?? I need to do some
complicated structure accessing, and I'm not sure how to go about it.

 ------------
Category 33,  Topic 6
Message 28        Thu Apr 29, 1993
CBARRON                      at 02:23 EDT

   The simplest approach is to calculate the offsets, using C in a quick and
dirty calculation program using the standard C macro offsetof()  (in
stddefs.h) .  By printing the offset of each member to be referenced in the
assembler routine to a file as a file of equates the asm will be easier to
read as well.   m(an) is the easiest access mode.
       unsigned long off;
       off = offsetof(....)
       fprintf(fout,"field equ %lu\n",off);
 type of statements should be able to do the calculation for you, easily, no
matter how complicated the actual references are.

 ------------
Category 33,  Topic 6
Message 29        Thu Apr 29, 1993
C.ROUNTREE2 [RoadKill]       at 04:55 EDT

        CBARRON:  Hmmm. thanks. I'll have to try that.


 ------------
Category 33,  Topic 6
Message 30        Wed May 26, 1993
B.MCCORKLE                   at 21:17 EDT

   I am planning on buying a C compiler in the near future and would like some
information on Lattice C.  First, are the .bin files compatible with the DRI
or GST formats?
   Also, one of the reasons I have for buying a comiler is to use for some
college level C courses I plan on taking.  The college uses msdos Turbo C in
the labs.  Does anyone know if there would be a big difference in the way the
compilers work?  i.e. would proper code on one compile on the other with a
minmum of changes?

        Thanks,   Brian

 ------------
Category 33,  Topic 6
Message 31        Thu May 27, 1993
D.CHARTER                    at 20:45 EDT

Brian,

 I took a couple C programming classes and used LaserC for the first class and
Lattice C for the next two.  It works with only mimimum of changes - unless
you get into some of the fancy libraries.  I found that when I ran into
problems, the people here were more than willing to help me solve the
compatiblity problems.

Duane

 ------------
Category 33,  Topic 6
Message 32        Fri May 28, 1993
ORA.TECH                     at 01:21 EDT

Brain -

You can have the compiler produce GST object code, but it is not recommended.
As a 100% ANSI C compiler, any code that adheres to the ANSI standard will
compile without modification.

Best regards,

Bob@ORA
 ------------
Category 33,  Topic 6
Message 33        Fri May 28, 1993
HISOFT                       at 13:19 EDT

Lattice supports three flavours of object files; its own  for best
performance/flexibility, DRI (which the compiler  will generate directly) for
maxiumum disk space  usage/portability, and GST (via a convertor). DRI format
cannot represent all relocatable items which the compiler  is capable of
generating, whilst GST format has simply dire  performance.

If you are using only ANSI stuff in your class you should  have no problems.

Alex Kiernan, HiSoft.
 ------------
Category 33,  Topic 6
Message 34        Sat May 29, 1993
CBARRON                      at 03:22 EDT

   Reason to use dri format "Maximum disk space usage". Of course as in
  #include <stdio.h>
  void main(int ac,char *av[])
  {
      FILE *fp=fopen(av[1],"w");

      while(!ferror(fp))
        fprintf(fp,"Filling the drive\n");
      fclose(fp);
 }
 <grin>
 FIW - I don't miss the dri or gst linker formats!

 ------------
Category 33,  Topic 6
Message 35        Sun Jun 13, 1993
B.MCCORKLE                   at 00:06 EDT

        I made the plunge and got Lattice C.  The package looks very nice.
I've done some playing and have been able to compile some of the code from the
examples and some other listings.
        I have had errors apparently generated by the header \sys\stat.h as
follows;

H:\LC\HEADERS\sys\stat.h 18 Error 35: closing brace expected };
 ^ H:\LC\HEADERS\sys\stat.h 29 Error 64: structure contains no members
 _CXCERR(_lgscc(0x56,0, oldname , newname ))     /* rename a file */
                ^

Does anyone have any hints to correct this?

                Thanks, Brian
 ------------
Category 33,  Topic 6
Message 36        Mon Jun 14, 1993
D.LIVINGST11 [ErnestBovine]  at 03:17 EDT

  B.MCCORKLE,

 H:\LC\HEADERS\sys\stat.h 18 Error 35: closing brace expected
 means error in line #18 of stat.h

 In my stat.h this line is
    dev_t st_dev;           /* device */

 This would cause an error if dev_t were undefined at the time you #included
stat.h, since the compiler would interpret "dev_t" as a new token.  Since it
is not followed by a semicolon, the compiler (or maybe it's actually the
preprocessor) thinks it's the end of your structure definition, and therefore
expects a closing brace.

 Page 276 of the Library manual, under "stat", says that the file sys\types.h
must be included prior to sys\stat.h, which should fix it.
 ------------
Category 33,  Topic 6
Message 37        Mon Jun 14, 1993
B.MCCORKLE                   at 20:13 EDT

        I found the problem with that I was having with STAT.H.  The answer
(types.h) was in the library addendum.

        I have another problem, this one for ORA.  I am missing pages 157-188
in volume II-Library Manual.  I do have doubles for pages 189-220.  How do I
get a replacement Volume II?

                Brian
 ------------
Category 33,  Topic 6
Message 38        Tue Jun 15, 1993
ORA.TECH                     at 15:34 EDT

That is correct.  sys/type4.h must be included before sys/stat.h as it defines
amny of th data types used in sys/stat.h

Best regards,

Bob@ORA
 ------------
Category 33,  Topic 6
Message 39        Sat Jun 19, 1993
C.ROUNTREE2 [RoadKill]       at 02:54 EDT

        Are you guys going to add inline assembly to a furture version of
Lattice? I could realy use that function, and woud pay an upgrade fee for it.
        There are certain things I would like to speed up, but I don't want to
deal with the overhead of a subroutine.

 ------------
Category 33,  Topic 6
Message 40        Sun Jun 20, 1993
CBARRON                      at 03:50 EDT

  Huh...  if you use __assem directive.
  int __assem my_funct(register __d0 int, register__d5 int,register __d4 int);
it will call passing args in d0,d5,and d4 respectivly no major overhead.
  assembler text in proper csect and nothing the assem has to worry about
protocols.  args are setting in d0,d5,d4 and exit is a simple rts.
 d0-d7/a0-a3,a5 are readily available for args if that many are needed.
Personally I do not like large assembler routines inlined, too cumbersome, to
read.

 ------------
Category 33,  Topic 6
Message 41        Mon Jun 21, 1993
C.ROUNTREE2 [RoadKill]       at 04:01 EDT

        I do use the assem Directive for two routines in my current project.
Hmm. d0-d7 is available? The manual here says d0-d2 are available. For the
rest I need to make sure the regs are unchanged.

        Here is one thing I can't realy find. How are ints and shorts stored
as they are passed? I know the SHORTs are passed in the least signifigant
16bits of a word. But what about ints?

        Bug: You may know this already.....  I have a project file with about
20 different files included in it. If I alter a file then save it without
MAKEing the project, the system thinks that the file has been altered and
everytime I MAKE or DEBUG or RUN the project, it wants to recompile the file,
even if I havn't changed it from the last MAKE.
        The only way to fix this it to load the problem file, and MAKE the
project, then problem solved.

Kudos on the program over all. Nicest piece of Dev software I've used.

 ------------
Category 33,  Topic 6
Message 42        Mon Jun 21, 1993
ORA.TECH                     at 21:31 EDT

Note that you can create an link in assembly language modules into your
Lattice C projects.  ASM provided with Lattice C, although not as powerful and
fully featured as Devpac 3, is a fully capable 680x0 assembler.

Best regards,

Bob@ORA
 ------------
Category 33,  Topic 6
Message 43        Tue Jun 22, 1993
CBARRON                      at 02:05 EDT

  shorts are passed in the word portion of the register, longs in the whole
register.  Ints are passed as one of the above depending on sizeof(int).
 Alter but not really alter file.c.
    touch file.o  program.ext
 The following is a quick and dirty touch, written on the fly and not tested.
This should change filestamps so the project thinks all is well....
  /* touch.c */
  #include <stdio.h>
  int main(int ac,char *av[])
  {
     FILE *fp;
     int c;
     /* loop over all args */
     while(--ac)
     {
         /* if the file exists read and rewrite the first byte */
          if((fp=fopen(*++av,"rb+"))!=NULL)
          {
                c=getc(fp);
                fseek(fp,0L,SEEK_SET);
                putc(c,fp);
                fclose(fp);
          }
          else
          {
          /* if file does not exist create it. */
                if((fp=fopen(*av,"wb"))!=NULL)
                   fclose(fp);
          }
     }
     return 0;
  }

 ------------
Category 33,  Topic 6
Message 44        Wed Jun 23, 1993
C.ROUNTREE2 [RoadKill]       at 04:21 EDT

        CBARRON: Thanks. I'll try that out.

        OH, is there a version of Monst that runs on the Falcon? I crash the
computer so often :-}, I can't see living without it long.

 ------------
Category 33,  Topic 6
Message 45        Thu Jun 24, 1993
ORA.TECH                     at 01:12 EDT

Yes, there will be a Lattice C Falcon upgrade available very soon that
includes documentation of the new OS functions, new library support and a
Falcon version of Mon.

Best regards,

Bob@ORA
 ------------
Category 33,  Topic 6
Message 46        Fri Jun 25, 1993
R.WATSON15 [Wayne Watson]    at 18:02 EDT

Bob,
  Are you coming to the Blue Ridge Atari Fest in Ashville?

 ------------
Category 33,  Topic 6
Message 47        Wed Jun 30, 1993
ORA [Bob]                    at 00:10 EDT

We have not yet made a decision on the Blue Ridge show.  No one representing
the show has contacted us yet and we will be contacting them soon.

Best regards,

Bob@ORA
 ------------
Category 33,  Topic 6
Message 48        Sat Jul 03, 1993
T.WRATHER [Thomas]           at 22:43 EDT

In Lattice C's large assortment of library functions, is there a function that
can be used to determine the boot drive of the system?

Thanks, Thomas Wrather

 ------------
Category 33,  Topic 6
Message 49        Sun Jul 04, 1993
B.MCCORKLE                   at 11:25 EDT

        Where can I find a listing of the return codes that appear after I run
a program from the 'Project' menu item?  I'm not sure what to make of them.

        Is there any way to keep assembler files generated by the compiler?
(assuming the compiler makes .s files)  I've used a compiler in the past that
had this feature and have found it to be useful from time to time.

                Brian
 ------------
Category 33,  Topic 6
Message 50        Sun Jul 04, 1993
A.STUDER1 [Andy]             at 21:56 EDT

What is the proper way to handle the initial MU_REDRAW that is triggered when
a program is first run (assumming it is supposed to occur).

I open my workstation, create a window, then open it, and my evnt_multi() loop
grabs the redraw for the window, but the co-ordinates returned ignore the fact
that I have an info/title line in my window so my re-draw overwrites them.

Do I have to keep track of that myself?

Also, I'm using the Lattice wind_redraw function and I must not be using it
correctly.  Instead of re-drawing sending the co-ordinates of only the screen
portion that needs to be updated, it sends he co-ordinates of the other window
apparently ignoring the intersection of my window with it.  Any ideas?  I'll
put the code up here if someone needs it.

One more thing, how about a blit example with vro_cpyfm()... I take it I need
to store my complete screen somewhere in memory so that I can use this storage
to restore the screen during re-draws?  Right now, my re-draw routine just
draws a blank box corresponding to the MU_REDRAW co-ordinates. How would I
know when to store the screen, it seems in-efficient to store it every time
after I draw something new on it.

Thanks!

 ------------
Category 33,  Topic 6
Message 51        Mon Jul 05, 1993
T.WRATHER [Thomas]           at 00:38 EDT

Is there any plan to add DERCS support to Lattice's project manager? In other
words, have the project manager check the date of the .RSC file to determine
if DERCS should be executed on it.

Thomas Wrather
 ------------
Category 33,  Topic 6
Message 52        Mon Jul 05, 1993
CBARRON                      at 02:51 EDT

 B.MCCORKLE.
    are your main()'s int main(...) return value should be what the program
returns as an exit code.
    To my knowledge LC compiles 'quad's to M680x0 binary machine code with no
assembly required.  It does not generate *.s files.  There is a module
dissassembler but it will require much work to get the output back to input
form for asm.   It will tell you what was generated and is fairly easy to read
if you know asm.
   I do have a program to create hex data outof dissassembler output. Easy way
to create #pragma inlines...
   Andy:

      handle = wind_create(.....);      /* this sets up gem does no drawing */
      wind_title(handle,title);
      wind_info(handle,info);      /* static data info and title! **/
      wind_open(handle,...);      /* this generates the redraw */

     If the type data for your window (first param to wind_create) contains
the proper bits NAME|INFO or something my docs are away at the moment, the
titles are GEM's problem not yours, once they are set as above. [between
wind_create and wind_open],  I have used wind_redraw with no problem..

    short msg[8];

    e=evnt_multi(.....)

    if(e & MU_MESAG)
    {
          switch(msg[0])
          {
          case WM_REDRAW:
                 wind_redraw(msg[3],(GRECT *)(msg+4),my_redraw);
                 break;
           ....
    Re saving the screen, what are you drawing on it? prehaps saving how to
draw the screen would be more efficient, unless it is a 'painting'.
 ------------
Category 33,  Topic 6
Message 53        Mon Jul 05, 1993
A.STUDER1 [Andy]             at 06:53 EDT

CBARRON, thanks for the look-see at my problem.  I'll compare my code to your
example and see what's different.  From this cursory view of your comment, I
think I'm doing the same thing.  I'll upload my code section if I can't solve
the re-draw over my title/info bars problem.

I'm writing a terminal program (mainly for the experience) so that I can put
my BBS in a window (ST-Keep).  If you have any ideas on how to store the text
which is on the screen so that I can re-draw it when the WM_REDRAW msg comes
in, I'd appreciate it.  I'm going to end up writing an editor as well, but
that'll be more complicated so I would like to get this down pat first.




 ------------
Category 33,  Topic 6
Message 54        Mon Jul 05, 1993
A.STUDER1 [Andy]             at 07:19 EDT

Here is the chunk of code in question re-garding processing the WM_REDRAW
message:

 kind = NAME|CLOSE|FULL|MOVE|INFO;
 winhandle = wind_create( kind, scrX, scrY, scrW, scrH );
 wind_calc( WC_WORK, kind, scrX, scrY, scrW, scrH,
            &winX, &winY, &winW, &winH );
 rc = wind_title( winhandle, "PrimeTerm Version 1.0-01Jul93" );
 rc = wind_info( winhandle, "Copyright 1993 by Pandamonium Software" );
 rc = wind_open( winhandle, scrX, scrY, scrW, scrH );

 flags = MU_KEYBD|MU_MESAG|MU_TIMER;

 do
 {
   res = evnt_multi( flags, bmaxclicks, bmask, bstate,
                     m1flag, m1x, m1y, m1w, m1h,
                     m2flag, m2x, m2y, m2w, m2h,
                     mbuff,
                     locount, hicount,
                     &x, &y, &button, &kstate, &kreturn, &breturn );
 }
 if ( res & MU_MESAG )
 {
   event_handler();
 }

 void event_handler( void )
 {
   switch ( mbuff[ 0 ] )
   {
      case MN_SELECTED : wind_update( BEG_UPDATE );
                         menu_handler( mbuff[ 3 ], mbuff[ 4 ] );
                         wind_update( END_UPDATE );
                         break;

      case WM_FULLED : if ( mbuff[ 3 ] == winhandle )
                       {
                         printf( "\007" );
                       }
                       break;

      case WM_REDRAW : if ( mbuff[ 3 ] == winhandle )   // if redraw for my
window
                       {
                         rect1 = (GRECT *)&mbuff[ 4 ];
                         wind_redraw( winhandle, rect1, (void *)redraw );
                       }
                       break;

      case WM_TOPPED : // if my window moved to top, then top it now
                       if ( mbuff[ 3 ] == winhandle )
                       {
                         wind_set( winhandle, WF_TOP, scrX, scrY, scrW, scrH
);
                       }
                       break;

      case WM_CLOSED : c[ 0 ] = CTLQ;
                       break;
  } }

int redraw( void ) {
        short           pxyarray[ 4 ];

        pxyarray[ 0 ] = rect1->g_x;
        pxyarray[ 1 ] = rect1->g_y;
        pxyarray[ 2 ] = rect1->g_w + rect1->g_x;
        pxyarray[ 3 ] = rect1->g_h + rect1->g_y;

        // mouse hidden, rectangle list processed, and menus disabled
        // by wind_redraw calling function

        vswr_mode( wrkhandle, MD_REPLACE );
        vsf_color( wrkhandle, WHITE );
        vsf_interior( wrkhandle, FIS_SOLID );
        vr_recfl( wrkhandle, pxyarray );

        return 1;
 }


**********

Does anyone see any obvious error (forget that all my re-draw routine does is
draw a white box, I haven't figured out how to really re-draw what should be
on my screen).

The WM_REDRAW msg triggered by the wind_open() call is making the re-draw
routine write over the title and info lines, and only leaving the menu bar
alone.

However, when I get re-draws after this one, they give the appropriate co-
ordinates so far...

Thanks again for the help!  I hope the 4th was safe and enjoyable for all of
you.  I was sitting on my Falcon programming away while watching the fireworks
out in the street, hehe.  Not bad.

 ------------
Category 33,  Topic 6
Message 55        Mon Jul 05, 1993
ORA [Bob]                    at 15:44 EDT

Andy -

You need to call wind_get with WF_WORKXYWH to get the workin coordinates of th
interior fo th window you need to update.  This takes into account the
title/info bars etc.

Re: saving the screen - I agree with Cbarron.  Unless you have bit images that
are difficult to reproduce, it is generally better to have a routine that will
redraw an arbitrary rectangle rather than saving the screen and blitting back
portions.  Remember under MultiTOS your're not the only one who can do stuff
to the screen so if you say blit the entire screen back from memory it may not
be the "real" screen anymore.

Thomas - That's a good idea to add DERCS to the auto "rsh" a rsc file that has
been changed.  You can to that using the command line versions of Lattice in
conjunction with a traditional UNIX make.

 ------------
Category 33,  Topic 6
Message 56        Mon Jul 05, 1993
A.STUDER1 [Andy]             at 17:33 EDT

I used WF_WORKXYWH the first time I tried widn_get but it kept coming up
undefined even though it was defined in <aes.h>, so I changed to the other
define.  I'll try it again, that was a few days ago.

So I guess I'm going to have to store most of the data the comes across the
terminal in memory and somehow work out a way to re-draw protions of it for
the current screen, eek... that looks as scary as GEM programming did 4 days
ago!

Are the hierarchial menus in  the lattice editor being fixed to work under the
new AES?  I'm using a Falcon and everytime one opens, it ends up selecting
something from the main menu instead, effectively limiting my use of any of
those menus.

I can't wait for the update!

 ------------
Category 33,  Topic 6
Message 57        Mon Jul 05, 1993
A.STUDER1 [Andy]             at 19:17 EDT

Thanks for your helpful responses...

OK, here's the code with my current findings... Assuming I'm creating the
window properly, the first WM_REDRAW msg is always returning 0,19,640,480
which would be my screen minus the menu bar area.  It doesn't seem to
recognize the fact that I have a window with various components and thus
should be returning 1, 61, 638, 418.  I've added comments in the code that
show the values of the variables as the program progresses in case that might
help someone locate my error.  It might also help to note that while the
program is running, any other re-draw events react the same way... For
example, I can run CardFile or the Control panel over my window, and when I
move or exit these programs, the re-draw is sent to my program but still
ignores the window components and always returns the 19 for the Y co-ordinate.

 void prime( void )
 {
        menu_bar( menuPtr, 1 );

        wrkhandle = graf_handle( &junk, &junk, &junk, &junk );
        v_opnvwk( work_in, &wrkhandle, work_out );

        // obtain the available work area from the desktop
        wind_get( DESK, WF_WORKXYWH, &scrX, &scrY, &scrW, &scrH );
        // returns 0, 19, 640, 480 respectively

        // design my window
        kind = NAME|CLOSE|FULL|MOVE|INFO;
        winhandle = wind_create( kind, scrX, scrY, scrW, scrH );
        // obtain the actual window work area minus components
        wind_calc( WC_WORK, kind, scrX, scrY, scrW, scrH,
                                        &winX, &winY, &winW, &winH );
        // returns 1, 61, 638, 418 in win? respectively

        wind_title( winhandle, "PrimeTerm Version 1.0-01Jul93" );
        wind_info( winhandle, "Copyright 1993 by Pandamonium Software" );
        // open my window with screen co-ords, not window co-ords
        wind_open( winhandle, scrX, scrY, scrW, scrH );

        // if I do a wind_get here, it returns the correct values of
        // 1, 61, 638, and 418.

 do {   evnt_multi(...);
        ...
        evnt_handler();
 }

 void evnt_handler()
 {
        case    WM_REDRAW       :
                        if ( mbuff[ 3 ] == winhandle )
                        {

 sprintf( alertStr, "[1][x = %d, y = %d|w = %d, h = %d][OK]",
                        mbuff[ 4 ], mbuff[ 5 ], mbuff[ 6 ], mbuff[ 7 ] );
 form_alert( 1, alertStr );
 // returns 0, 19, 640, 480 rather than 1, 61, 638, 418, as if
 // the AES doesn't know I have components on my window!

                                rect1 = (GRECT *)&mbuff[ 4 ];
                                wind_redraw( winhandle, rect1, (void *)redraw
);
                        }
                        break;
 }

 int redraw( void )
 {
        short           pxy[ 4 ];

        pxy[ 0 ] = rect1->g_x;
        pxy[ 1 ] = rect1->g_y;
        pxy[ 2 ] = rect1->g_w + rect1->g_x;             // due to square co-
ords and not width
        pxy[ 3 ] = rect1->g_h + rect1->g_y;             // due to square co-
ords and not height


        sprintf( alertStr, "[1][x = %d, y = %d|w = %d, h = %d][OK]",
                                pxy[0], pxy[1], pxy[2], pxy[3] );
        form_alert( 1, alertStr );
        // returns 0, 19, 640, 480 just as it was passed (in error)

        // mouse hidden, rectangle list processed, and menus disabled
        // by wind_redraw calling function

        vswr_mode( wrkhandle, MD_REPLACE );
        vsf_color( wrkhandle, WHITE );
        vsf_interior( wrkhandle, FIS_SOLID );
        vr_recfl( wrkhandle, pxy );
                // is there any better way to solid fill an area?

        return 1;
 }

 ------------
Category 33,  Topic 6
Message 58        Tue Jul 06, 1993
CBARRON                      at 01:41 EDT

  redraw should be of the form int redraw(int,GRECT *);
   int redraw(int wh,GRECT *grect)
   {
       short pxy[4];
       pxy[0] = grect->g_x;
       pxy[1] = grect->g_y;
       pxy[2] = grect->g_x+grect->g_w -1;
       pxy[3] = grect->g_y+grect->g_h -1;
       ...
       vr_recfl(wrkhandle,pxy);return 1;
   }
   As your code is written it is not using the rectangles sent to it by
wind_redraw.
   Now text can be saved as an array of char pointers one to a line. thats
84x24 or 29 bytes!.  If you also keep the screen loc. of the beginning of the
line then it is a simple loop, to recreate the contents. Using a char * array
allows an easy scroll off the top by merely moving 24 pointers...   Using an
array of pointers will help when you add editing to this program as well.
   AES redraws the area sent... you are using the wrong infromation... See
wind_redraw() docs again...


  ORA -  NOT to mention TT screens are 153k and some falcon resolution are
'worse'!  Check docs to wind_redraw(), this is the big problem here... Not for
me I am used to doing the rectangle walk myself. <grin>...
 ------------
Category 33,  Topic 6
Message 59        Thu Jul 08, 1993
A.STUDER1 [Andy]             at 07:33 EDT

CBARRON,

Thanks for the clearification of the wind_redraw function, I just put my type
declarations in my redraw function and it worked like a charm.

Q:  The wind_redraw docs show that my redraw func should be an int, but why do
I have to call it with a (void *) type to avoid an invalid argument type
error?  The prototype for my redraw is int redraw ( short h, GRECT *rect )...
thanks again!

Now I can spend the next few weeks getting it to actually re-draw my data
instead of just clearing the rectange returned ... hehe.

 ------------
Category 33,  Topic 6
Message 60        Fri Jul 09, 1993
CBARRON                      at 01:23 EDT

 int (*f)(int,GRECT *) IS NOT the same as int (*f)(short,GRECT *);

 Since the argument is an address and void * is compatible with 'any' address,
there is no problem but  your prototype and the prototype of the expected
function are different.  use int redraw(int,GRECT *) litlle is cost in 16 bit
int mode and in default 32 bit int mode, it can be a problem causer.
 ------------
Category 33,  Topic 6
Message 61        Mon Jul 12, 1993
T.WRATHER [Thomas]           at 23:33 EDT

Using Lattice C, I produced the following code fragments which I do not
understand.

 ;  16: static void  copy_string_to_tedinfo (char *, char *, const int);

      copy_string_to_tedinfo (((TEDINFO *) PROGRAM[PROGRAM_NAME].ob_spec)-
>te_ptext,
       | 0eca  206c  01d4-XX.2                movea.l
_PROGRAM+$000001d4(a4),a0
 ; 495:                               dat_info.program[indx].prog_name,
       | 0ece  7000                           moveq     #$00,d0
       | 0ed0  1007                           move.b    d7,d0
       | 0ed2  7254                           moveq     #$54,d1
       | 0ed4  4eba  0000-XX.1                jsr       __CXM33(pc)
       | 0ed8  43ec  0010-XX.2                lea
_dat_info+$00000010(a4),a1
       | 0edc  d3c0                           adda.l    d0,a1
 ; 496:                               FNSIZE);
       | 0ede  4878 000d                      pea       $000d
       | 0ee2  2f09                           move.l    a1,-(a7)
       | 0ee4  2f10                           move.l    (a0),-(a7)
       | 0ee6  6100 fd06                      bsr.w     $0bee

Specifically, why is the second to last line:

 move.l (a0), -(a7)

instead of:

 move.l a0, -(a7)

The code seems be passing the first four characters of ((TEDINFO *)
PROGRAM[PROGRAM_NAME].ob_spec)->te_ptext instead of its address.  Both
((TEDINFO *) PROGRAM[PROGRAM_NAME].ob_spec)->te_ptext and
dat_info.program[indx].prog_name are of type "char *," so I expected them to
both be pushed on the stack in the same manner.  Does anyone have any insight
for me?

Thanks, Thomas
 ------------
Category 33,  Topic 6
Message 62        Tue Jul 13, 1993
CBARRON                      at 05:15 EDT

  It is actually sending the address of the te_ptext field. (offset 0 in the
tedinfo struct.)
  It is calculating the address of PROGRAM[PROGRAM_NAME].ob_spec, and passing
the contents of the ob_spec as the ted->te_ptext pointer.
  It further calculates data_info.progrma[index].program_name in the same
fashion but that result is a char pointer not a pointer to a character
pointer.
   (*(TEDINFO *)(PROGRAM[PROGRAM_NAME].ob_spec))->te_ptext is a char *.  It is
found in PROGRAM[PROGRAM_NAME].ob_spec hence the
 movea.l (a0),-(sp)
   datainfo.program[index].prog_name is a char * in and of itself hence
movea.l a1,-(sp)
    Sure looks like a munged dissassembly, but that is the gist. (offset of
te_ptext field is zero and needs no computation, that might be confusing to
you as well).


 ------------
Category 33,  Topic 6
Message 63        Tue Jul 13, 1993
T.WRATHER [Thomas]           at 21:51 EDT

CBARRON,

I am now unconfused!

Thanks, Thomas
 ------------
Category 33,  Topic 6
Message 64        Wed Jul 14, 1993
CBARRON                      at 01:10 EDT

  Thomas, no problem.  Only questions that are dumb, are those that aren't
asked!

 ------------
Category 33,  Topic 6
Message 65        Wed Jul 14, 1993
B.FREEMAN1 [BFREEMAN]        at 21:58 EDT

        I could use some help.  I want to change the text color and background
color that is displayed with printf() and putch().  Could someone set me on
the right path.
 ------------
Category 33,  Topic 6
Message 66        Wed Jul 14, 1993
B.MCCORKLE                   at 22:43 EDT

  In regard to the return codes, now I'm confused.  I used main as follows:

        int main(void)
        { ...
        return 0;
        }

and

        float main(void)
        { ...
        return 0;
        }

these did not give an alert with return code.  However,

        void main(void)
        { ...
        }

does give an alert with a return code and the code has been different
 for each differnt program.  Why is that?


        Brian
 ------------
Category 33,  Topic 6
Message 67        Wed Jul 14, 1993
M.HILL13 [Mike]              at 23:38 EDT

Brian,

Ill take a stab at this.  I believe that even though you declared main as a
void function calling programs can still receive a return value from it (like
Neodesk for example).

I believe that Data register D0 is used for return values.  So what will
happen is that whatever value is left in d0 when your main function exits will
be returned to the calling app.

My advice is to just declare the function as returning and int and do a return
0; at the end of the code.

Mike
 ------------
Category 33,  Topic 6
Message 68        Thu Jul 15, 1993
D.MCNAMEE [Dan @ Atari]      at 15:50 EST

Brian,

         I just use

 void main()
 {
 ...
 }

         for my programs.  I haven't had any problems with that at all.

 Dan


 ------------
Category 33,  Topic 6
Message 69        Thu Jul 15, 1993
TALISMAN                     at 19:16 EDT

  I think you use the use the escape code  /013  and follow it with whatever
vt52 codes you want.

 /013b1 should turn the text blue in med res, for example.
 /013c1 should turn the background blue in med res..

As far as VT52 colors are concerned, I think of them as b for the beer, and c
for the can; that makes it easy to remember which is inside (text) and which
is outside (background).

Talisman
 ------------
Category 33,  Topic 6
Message 70        Fri Jul 16, 1993
CBARRON                      at 02:17 EDT

 FYI esc = '\033'
 ------------
Category 33,  Topic 6
Message 71        Sat Jul 17, 1993
B.FREEMAN1 [BFREEMAN]        at 14:26 EDT

Many Thanks to you both for the help.  I have the text and background changing
colors working on my st, but on my Falcon the colors don't change. I wonder if
this is a bug in the Falcon.  Heres the test code:

printf("\033b1This is a test \n");
 printf("\033b2This is a test \n");
 printf("\033b3This is a test \n");

The text comes out red, green, and then black on my st in med rez, but on my
Falcon it only comes out black in any rez I try.



 ------------
Category 33,  Topic 6
Message 72        Sun Jul 18, 1993
STEVE-J [Steve @ NLS]        at 08:12 EDT

What's the current version of Lattice C?
 ------------
Category 33,  Topic 6
Message 73        Mon Aug 09, 1993
T.BUSHAW [Tom@Quidnunc]      at 23:55 EDT

Oregon Research: I have Lattice C Version 5.5 (via an upgrade directly from
HiSoft). What'll it take to upgrade to the most recent version?
 ------------
Category 33,  Topic 6
Message 74        Tue Aug 10, 1993
ORA [Bob]                    at 13:51 EDT

The latest version is V5.52.  Lattice C Falcon is expected to be released very
soon. Upgrade info will be posted when it is available.

Best regards,

Bob@ORA
 ------------
Category 33,  Topic 6
Message 75        Fri Aug 13, 1993
E.HAEFNER [HEFFS]            at 21:21 EDT

Hi There
 I've never had to allocate memory on a boundry before.So I guess that my
question is "how?".I have version 5.52 and am running with a Falcon.Any advice
would be greatly welcome.

 ------------
Category 33,  Topic 6
Message 76        Sun Aug 15, 1993
J.KERKHOFF [J.Kerkhoff]      at 12:09 EDT

To Oregon Research:
        I just got Lattice from a generous friend who doesn't use it any
longer.  It is ver 5.06.02.  I have all of the original disks and manuals and
would like to upgrade it to the current version.  What is the cost and
procedure?

To all:  I have two programming questions.  First, what is the easiest way to
link asm code to Lattice C?  I see some references to it in the manuals I
have, but it isn't clear to me how you do it. (Perhaps someone could upload an
annotated example)  Second, is there a way to service interrupts from C?
Specifically, I want to look for data from the MIDI port without waiting in a
loop.  Maybe someone has a MIDI sequencer fragment that shows this approach.

Thanks Jim

 ------------
Category 33,  Topic 6
Message 77        Sun Aug 15, 1993
ORA [Bob]                    at 19:24 EDT

Jim,

Return the original disks and $60 for and upgrade to V5.52 to:

Oregon Research Associates 16200 SW Pacific Hwy Suite 162 Tigard, OR 97224

Best regards,

Bob@ORA
 ------------
Category 33,  Topic 6
Message 78        Fri Aug 20, 1993
R.LUNSFORD2                  at 01:15 EDT

Is there any way to make an XBIOS call if it's not supported in the  library?
Like a direct way of calling it from within the program? Thanks, Russ
 ------------
Category 33,  Topic 6
Message 79        Fri Aug 20, 1993
R.BURROWS1 [Roger@Anodyn]    at 22:44 EDT

R.LUNSFORD2,
  I'm not sure what you mean.  If you know the xbios number and all the
parameters, you can just use the xbios() call.  Or, preferably, you can look
at how the existing xbios stuff (eg Flopfmt()) is defined in osbind.h, and
create your own.  Hope that answers your question...... Roger Burrows

 ------------
Category 33,  Topic 6
Message 80        Sat Aug 21, 1993
D.LIVINGST11 [ErnestBovine]  at 03:41 EDT

    R.LUNSFORD2,

 > Is there any way to make an XBIOS call if it's not
 > supported in the library?  Like a direct way of calling
 > it from within the program?

 Look at the file OSBIND.H to see how to do it.
 ------------
Category 33,  Topic 6
Message 81        Sat Aug 21, 1993
R.LUNSFORD2                  at 05:02 EDT

Roger,
 So what would be the format for just a "straight" xbios call? Basically just
an example would do...I'm very new to C...Just can't find the syntax in the
manual.  Looked in osbind.h already..It didn't have some of the defines to use
in the pragmas for some of the new xbios calls, and I can't quite get it to
work correctly.. Russ
 ------------
Category 33,  Topic 6
Message 82        Tue Aug 24, 1993
HISOFT                       at 13:20 EDT

R.LUNSFORD2:

sorry for the delay in replying. You can make XBIOS calls via  the xbios()
call which exists in the library, so long as you are  in default short integer
mode (-w) _and_ you cast every type so  that is passed correctly on the stack
to the function.

Its klunky, but w/o doing a proper pragma inline/define pair its  the only way
:-(

Alex Kiernan, HiSoft.
 ------------
Category 33,  Topic 6
Message 83        Sun Aug 29, 1993
T.KELLY12                    at 03:59 EDT

I recently purchased Lattice C 5.52 to continue development of a large scoring
(music notation) program.  The project began as a "what if" using GFA Basic,
and I ported it to Laser C last summer.  I have been working on a MegaSTE with
Tos 2.05 and Laser C seemed to have a few quirks with that version of Tos.
Neverthless, with some work-arounds, it produced a beta version of my program
that has been working well.  I decided to switch to Lattice because I will
soon have access to a Falcon and Laser is no longer supported, plus the Laser
shell is not compatible with GDOS and my program requires it.  With minor
tweeks to the code to accomodate Lattice's implementation, I got all of my
modules to compile correctly using the two byte integer option and absolute
addressing mode.  When I try to link the modules, however, I get the "Multiply
defined symbol" error for every function in all the modules.  The message
lists the function as RELOCATABLE and gives the position in the module it was
first found.  It then says it was redefined and gives the EXACT SAME
INFORMATION.  After searching through all the manuals I cannot discover any
compiler or linker setting that can account for this message occurring for
every function.  The code is solid and works fine in Laser C.  There be must
be something obvious going on, but I can't spot it.  Can anyone suggest a
solution?  The linker works fine on some of the example programs and some of
my code that I had in smaller test modules.  Does the linker have a problem
with large programs?
 ------------
Category 33,  Topic 6
Message 84        Mon Aug 30, 1993
ORA [Bob]                    at 01:09 EDT

No the linker does not have a problem with large programs. Do you have a
global header file that perhaps defines gobal variable/functions in every file
rather than external except in th file it is defined?

Best regards,

Bob@ORA
 ------------
Category 33,  Topic 6
Message 85        Mon Aug 30, 1993
CBARRON                      at 01:15 EDT

does setting the compiler to use ABSOLUTE addressing of EXTERnAL  functions
help. As for global data if it entirely defined in one  module there is an
option to treat globals as extern's. Using that on  all but a module will
eliminate mutiple DATA allocations. [y or  something near y, I don't have
manual handy.]
   file 1
    int i;
    ....
   file2
    int i;
    ...
  Will produce these messages unless all but one of the int i's is  extern int
i;.   Multiply defined FUnCTIOnS should have killed laser  as well, unless
they are static functions with laser and global  functions with LATTICE, due
to a difference in preprocessor macros! (user or compiler defined...)
 ------------
Category 33,  Topic 6
Message 86        Wed Sep 01, 1993
T.KELLY12                    at 00:11 EDT

Thanks for the suggestions regarding the "multiply defined objects" error.
Unfortunately, I still can't get the link to succeed.  All my global variables
are defined in the main module and are declared external in  all the other
modules.  If I am reading the error correctly, failure  to have the globals
declared external in the subordinate modules should have resulted in the error
reading "first defined in main, redefined in xxx."  My error message reads
"first defined in main at location 200,  redefined in main at 200."  This
error is occuring for both the global data items in the main module as well as
for all the function definitions in all the subordinate modules.  How can I be
redefining within the same module at the same location?  The options I have
selected on the compiler would seem to be fairly standard ones except that I
am using 32 bit  addressing for global data and all functions.  I just tried
the -cx option to make external declarations global, but that had no effect.

 ------------
Category 33,  Topic 6
Message 87        Wed Sep 01, 1993
T.BUSHAW [Tom@Quidnunc]      at 00:46 EDT

I, too, converted a large Laser C application to Lattice C (presently Version
5.51, not 5.52), but mine works fine (also using 16 bit integers). However, I
prototyped all my functions so none of them are declared  external anywhere
(they were in the Laser version).  With ~125 modules and who-knows-how-many
functions, this took a little while, but it's better code now.  Don't know
whether this would solve your problem.  Might be worth a try...
 ------------
Category 33,  Topic 6
Message 88        Thu Sep 02, 1993
T.KELLY12                    at 08:54 EDT

I thought that the lack of function prototypes might have something to do with
the problem and did prototype all my modules.  That removed a lot of the
function return warnings from the compiler but hasn't changed the link.  I am
encouraged that your application converted successfully though.  There still
must be something obvious I'm not seeing.  In my Laser version, very few of
the functions actually had to have an external declaration.  All functions are
defacto "external" i.e. available to the whole program in standard C, and only
those that return a non-integer need to be explicitly declared external in
another module and their proper return value given to satisfy the compiler.
If I read the Lattice manual correctly, the ANSI definition may have changed
the global scope of functions declared in a given module, limiting them to the
module unless the -cx compiler option is used, but the manual is hazy on this
point.  Tom, would you please post for me the actual compiler options you used
in converting your Laser C application?  Maybe that would give a clue as to
where I've gone astray.  Thanks for your help.

 ------------
Category 33,  Topic 6
Message 89        Thu Sep 02, 1993
ORA [Bob]                    at 19:43 EDT

Using ANSI prototyping can catch a great deal of problems that otherwise would
go undetected.  It is a good practive to get into. Check and see if you have
an include file that includes itself. Use the -ci option to suppress multiple
includes.

Best regards,

Bob@ORA
 ------------
Category 33,  Topic 6
Message 90        Fri Sep 03, 1993
T.BUSHAW [Tom@Quidnunc]      at 02:46 EDT

Here are the compiler options I used when converting Laser to Lattice (note,
however, that when I was doing the conversion I was using Version 5, not 5.51
or 5.52; shouldn't matter though):

LC_OPT=-b1 -C -cfsu -d0 -fam -mas -O -r1s -t -v -w -Hinclude.sym

Note that I did not use the -x or -cx option.  All my functions were
prototyped, none (int or otherwise) was declared external anywhere, and all
modules had access to all other modules' functions.  However, my global DATA
was declared external in an include file (which was included with each
module).  The last option above specifies my pre-compiled "master" include
file (a file which #includes all my "component" header files; e.g. the above
data declarations, resource header, structure header, and prototype header).

  - Tom
 ------------
Category 33,  Topic 6
Message 91        Sat Sep 04, 1993
T.KELLY12                    at 10:34 EDT

Yeah!  Thanks Tom for posting your compiler options.  They were similar to my
own and made me doubly sure I was overlooking something silly.  I was so used
to working in the Laser shell that I included the object files for my modules
in the project file as I would have in the link box in Laser.  If I were
"make" oriented I would have realized that including the source files would
have been enough.  So I was linking each module twice.  Hisoft might want to
add a little note to the manual that object files of sources listed will be
included in the link.  The addendum, p. 36, can easily be interpreted the
other way.  The only other problem I encountered was when I tried to take
advantage of the precompiled header option.  I built a dummy file of the
common headers and precompiled it as stated in the manual addendum.  I added
it to the advanced options box, but went I went to compile the first module
the compiler aborted before getting to the source.  It said "out of memory,"
but the system still had over 2 megs available.  The manual says there is no
limit to the precompiled headers, but perhaps there is a limit to the size of
an individual symbol file?  Nevertheless, my program is up and running.
Thanks again. Terry

 ------------
Category 33,  Topic 6
Message 92        Wed Sep 08, 1993
TOWNS [John]                 at 15:35 EDT

 Use this trick to make sure that headers don't get included more than
 once:

 // top of header file

 #ifndef __HEADER__
 #define __HEADER__

 // Body of header goes here

 #endif

 Make sure the symbol you define (__HEADER__) is something unique. I
 usually use the name of the file.

 Another tip: When including header files, do the following:

 #ifndef __HEADER__
 #include <Header.h>
 #endif

 This will cause the C preprocessor to only include the header file
 if it is included. This should save some time on compiles because this
 will prevent the C preprocessor from even opening the header file if it
 is already included. Big time saver on most systems.

 If you already know about this, feel free to ignore me ;-)

 -- John
 ------------
Category 33,  Topic 6
Message 93        Mon Sep 13, 1993
M.HILL13 [Mike]              at 22:58 EDT

 Hisoft,

 Couple questions on Lattice C.

 1) When can we expect the next update to Lattice (Falcon
    Compatibility? MultiTos/Geneva? Speedo GDOS?).

 2) Will the debugger be fixed in the next update? I have a Mega STE
    with Crazy Dots II card and can't run the debugger in my favorite
    rez's.

 3) Is there ever going to be a C source Level debugger?  When I
    first ordered Lattice almost two years ago this was promised but
    has never yet become a reality.  That promise was one reason I
    went ahead and bought Lattice over Pure C.  Im starting to regret
    that decision, since I have heard no mention of the C Source
    Debugger in ages.

 4) C++ would sure be great.  I know this Comeau guy has an option
    coming out, do you guys have any plans for doing your own or are
    you going to support the Comeau C++?

 5) How about the ability to do inline Assembly directly with an
    asm() routine?

 6) How about making the Editor show function names, variables,
    comments in different (setable) colors.  Borland C++ and most of
    the popular C compilers on the PC do this.  It really makes the
    code stand out.

 7) How about a online help system with function reference like
    Borland C++.  Where you can have the cursor on a function and
    click on the help system and have it pop up a description and
    example of that function.

Well thats it for now! :->

Mike

 ------------
Category 33,  Topic 6
Message 94        Tue Sep 14, 1993
CBARRON                      at 02:01 EDT

 Mike, I aint HISOFT, but this is what I hear wrt to your questions:

 3) Supposedly 'one another network', a Source level debugger is out for at
least 5.0.x.  ST Club supposedly has it. ST Club is some UK distributing
company I would guess.
 4) Supposedly Comeau is ready for an announcement after last week's unix
show.  Have not seen that announcement as of yet.

 ------------
Category 33,  Topic 6
Message 95        Tue Sep 14, 1993
STEVE-J [Steve @ NLS]        at 03:54 EDT

What's the current version of Lattice C and what does the upgrade from v5.51
cost?
 ------------
Category 33,  Topic 6
Message 96        Wed Sep 15, 1993
HISOFT                       at 13:17 EDT

>1) When can we expect the next update to Lattice (Falcon >   Compatibility?
MultiTos/Geneva? Speedo GDOS?).

MultiTOS, Speedo & Falcon compatability are all in the next release,  although
the debugger makes development under MTOS a problem (the  debugger wants to
take over the machine, MTOS doesn't want it to). The  work for the update will
hopefully be finished by the end of this  week/the beginning of next. After
that its printing, duplicating &  shipping time which I suspect puts it at the
end of October or so.

Geneva/Mag!x I've no idea; I've seen neither of them, sorry!

>2) Will the debugger be fixed in the next update? I have a Mega STE >   with
Crazy Dots II card and can't run the debugger in my favorite >   rez's.

No, nor do I know of any intention by the person responsible here for  it to
be (although I have a Crazy Dots card in my TT).

>3) Is there ever going to be a C source Level debugger?

I'm not working on it at the moment, although some work was done. At  the
present time I do not know when/if this project will be restarted;  such a
decision is a purely commercial one.

>4) C++ would sure be great.  I know this Comeau guy has an option >   coming
out, do you guys have any plans for doing your own or are >   you going to
support the Comeau C++?

AIUI Comeau C++ will only support Lattice in its first incarnation and  this
is certainly the product which we'll recommend to users. We have  no plans to
do our own C++.

>5) How about the ability to do inline Assembly directly with an >   asm()
routine?

We've looked at this before; without going to the complexity of  something
like the GCC scheme doing this in an environment where  there's a global
optimiser is all but impossible.

>6) How about making the Editor show function names, variables, >   comments
in different (setable) colors.  Borland C++ and most of >   the popular C
compilers on the PC do this.  It really makes the >   code stand out.

The editor could use a ton of new things, in practice I suspect it'll  get
none of them until we get around to a rewrite.

>7) How about a online help system with function reference like

Again not planned at the current time.

Alex Kiernan, HiSoft.

The existing debugger is designed around re-writing the entire  screen -
witout  screen switching harware (as in the TT/Falcon etc) the performance
would be appalling since it would need to blit the entire screen around the
place the whole time. On multi-monitor systems the debugger  will generally
use the Atari screen leaving your program running on your enhanced screen

The new release of the debugger will have improved source code handling
features.. Also with the new version will be a full featured Make utility,
Profiler and DRI format tools.

Dave Nutkins, HiSoft.
 ------------
Category 33,  Topic 6
Message 97        Fri Sep 17, 1993
T.WRATHER [Thomas]           at 22:46 EDT

I'm using Lattice C 5.52 to compile the MiNT 1.08 sources that were posted
here on GEnie a few days ago.  I'm having trouble creating the MINT.SYM file.
I assumed the correct way to generate the MINT.SYM file was to load MINT.H
into the Lattice C integrated environment and pre-compile it.  However, when I
select pre-compile, I get the following messages:

Precompiling E:\WORK\MINT108\MINT.H execution terminated

And MINT.SYM is not generated.  Since the above error messages are not very
helpful, I am having difficulty determining what I am doing wrong.  If pre-
compiling is explained in detail in the manuals someplace, just refer me to
the proper page.

Thanks, Thomas
 ------------
Category 33,  Topic 6
Message 98        Sat Sep 18, 1993
P-DIRECT2 [Tim @ TWP]        at 14:02 EDT

I'm having some trouble with Lattice C 5's editor.  I tried contacting Oregon
Research, but they seem to be totally oblivious to my existance.

From the drop-down menus, if I move the mouse pointer to a line that causes a
sub-menu to pop out, the menu pops out; however, when I go to select something
from that pop-out menu, clicking on it causes it to go away, but nothing
happens.  If I move the mouse pointer to a line that causes a pop-out menu to
be displayed, and then move the pointer to a line in the drop-down menu that
does not cause a pop-out menu to be displayed, it selects that option
automatically, without me having to click on it.

I'm using a Falcon 030 with TOS 4.04.  What's ironic is that Lattice C works
just fine under MultiTOS, but since I don't LIKE MultiTOS, I don't want to
have to load the beast up every time I want to do software development.

Also, when is the Falcon version of Lattice C 5 coming out, and how much is it
going to cost me to get the upgrade?
 ------------
Category 33,  Topic 6
Message 99        Wed Sep 22, 1993
R.STEGELMANN [Rolf]          at 03:21 EDT

Tim

Oregon Resarch was at the Glendale Show so you will probably not be able to
get in touch with them until they get back.

Don't know why you are having the problem. Must have somthing to do with the
Falcon. I have a TT and it works fine with or without MultiTOS.

Rolf

 ------------
Category 33,  Topic 6
Message 100       Mon Sep 27, 1993
R.LUNSFORD2                  at 23:48 EDT

I'm having trouble with a program...Looking through the code, everything looks
perfectly legal.  The problem comes when I try to link, I get this message...

Undefined symbols        First Referenced __CXA44                  File
'ASSGN4.O' __CXS44                  File 'ASSGN4.O' __CXM55
File 'ASSGN4.O' __CXV34                  File 'ASSGN4.O' __CXV35
File 'ASSGN4.O' __CXV45                  File 'ASSGN4.O' The only library I'm
linking with is stdio.h.  I don't make any calls to another library.... Russ
 ------------
Category 33,  Topic 6
Message 101       Tue Sep 28, 1993
C.ROUNTREE2 [RoadKill]       at 00:27 EDT

        You've forgotten to turn on Floating Point maths support. Go to the
options menu the go to Compilos Options--General. In there, towards the lower
left hand of the dialog if a button labled maths. Choose "Software IEEE" if
you don't have a coprocessor.

        Oh, save preferences wont save this. IT gets saved along with your
Project file. So after you mke this change, resave your project file.

'Nuf said.
 ------------
Category 33,  Topic 6
Message 102       Tue Sep 28, 1993
T.GIRSCH [TJ @ S-Mart]       at 01:20 EDT

Russ -

Look under options->compiler->general.  There should appear a dialog that
contains an option for "Maths."  If it is set to "none," change it to
something else (I recommend Auto "MC68881/2").  If that doesn't help, check
under options->executable, wherein there should be a "Build GEM Application"
option, which should be checked...

- T.J.
 ------------
Category 33,  Topic 6
Message 103       Tue Sep 28, 1993
R.LUNSFORD2                  at 02:00 EDT

Roadkill,
    Thanks *very* much...it's for an assignment in my C class...didn't expect
a reply that quick!! Russ
 ------------
Category 33,  Topic 6
Message 104       Thu Sep 30, 1993
P.LANCTOT [paul]             at 00:20 EDT

Hi, just got LC. Here's a rookie question..Why didn't InstallPrg. put disk #7
on my hard drive(co-processor Math libs) not that I'll need them before the
year 2000 but is there a reason for this?
   Actually, i wanted to ask a question _so_ basic that when it comes  time
for my beginner's questions they'll seem advanced! ;-)
   Also: Anything to keep in mind while working my way through Clayton
Walnum's Cmanship Complete?  thanks ---paul
 ------------
Category 33,  Topic 6
Message 105       Thu Sep 30, 1993
R.WATSON15 [Wayne Watson]    at 18:03 EDT

Paul,
  On the thing with Clayton's book, the biggest thing to remember is that the
C he used defaults to 2 byte INTeger while LC defaults to 4 byte INTeger.
There is a setting in the one of the drop down menus to change INTs to 2 byte
but I can't remember off hand. That threw me off when going through his book
until I called him and he explained what was happening.

 ------------
Category 33,  Topic 6
Message 106       Thu Sep 30, 1993
D.MCNAMEE [Dan @ Atari]      at 19:58 EDT

Paul,

         I can't answer your install question.  Maybe someone else
 here can answer it.

         As to Clay's book, the only thing to really be aware of is
 that his samples were written in Laser C, and there are some syntax
 differences between the two languages.

 Dan


 ------------
Category 33,  Topic 6
Message 107       Thu Sep 30, 1993
C.ROUNTREE2 [RoadKill]       at 22:33 EDT

        No prob, Russ. I know how it is.

 ------------
Category 33,  Topic 6
Message 108       Fri Oct 01, 1993
S.SWENA                      at 00:39 EDT

 I am having problems with extended command lines.  Can someone
 describe how one would implement things so that argv[0] will
 point to the file name of the program?  Or is there a pointer to
 a buffer somewhere in the system, pointing to the file most
 recently loaded from disk?  This example program works ok if run
 from the desktop but fails if run from elsewhere.

 /* if named lower.ttp converts to lower case */
 #include <stdio.h>
 #include <string.h>
 #include <ctype.h>
 #include <basepage.h>
 #include <dos.h>
 int main(int argc, char *argv[])
 {
 int c;
 char *p=(char *)0xCFC0;
 while(*p++)
    ;
 while(*--p != '\\')
    ;
 p++;
 argv[0] = p;
 printf("%s %s %s\n", argv[0], argv[1], argv[2]);
 if(strcmp(argv[0], "LOWER.TTP") == 0)
    {
    while((c = getchar()) != EOF)
       putchar(tolower(c));
    }
 else
    while((c = getchar()) != EOF)
       putchar(toupper(c));
 return 0;
 }
 Thanks, Stanley
 ------------
Category 33,  Topic 6
Message 109       Fri Oct 01, 1993
CBARRON                      at 02:53 EDT

 S.SWENA  first the extended arg convention is stored in the environment
variables, NOT A HARDWIRED LOCATION, (char *)0xcfc0 is at best at tos version
depenedent location.  If the calling program supports extended argv protocol.
It should be found if present via the startup module. c*.o.

  char *basename(char *fullname)
  {
        char *p = strrchr(fullname,'\\');
        if(p==NULL)
          p=fullname; /* no '\\' found */
        else
          ++p;  /* skip past the '\\' */
        return p;
   }

   is a better way to strip the path off a filename,

   you might note WELL not all CLI's support extended argv!!

 ------------
Category 33,  Topic 6
Message 110       Fri Oct 01, 1993
P.LANCTOT [paul]             at 18:12 EDT

Thanks for the quick rookie help...watch this space....
 ------------
Category 33,  Topic 6
Message 111       Sat Oct 02, 1993
S.SWENA                      at 16:41 EDT

 CBARRON  I was trying to devise a way to get this information
 (program filename) when run from the desktop or Pecec()ed from
 another program, independently of whether or not that program
 supports the extended command line protocol.  Are there any
 documented/undocumented system pointers that would allow a task
 to find out the most recently loaded disk file, which on start up
 would probably be "it's self"?

 Thanks Stanley
 ------------
Category 33,  Topic 6
Message 112       Sun Oct 03, 1993
CBARRON                      at 01:59 EDT

 Shell_read() 'sometimes' works, but modern tos'es return complete  path
rather than basename.   The solution I used with the 'compress'  suite
compress,uncompress,zcat was three execs.  A solution could be a program that
renames the file and forks the the real thing. Fork()  supports extended argv.
  #include <stdio.h>
  #include <stdlib.h>
  #define defalt "default.ttp"
  void main(int ac,char *av[])
  {
     switch(av[1][0])
     {
     case 'l':case 'L':
         rename(defalt,"lower.ttp"); /* renames may be backwards ! */
         av[1]="lower.ttp";
         av++;
         forkv("lower.ttp",av);
         wait();
         rename("lower.ttp",defalt);
         exit(0);
     case 'u':case 'U':
         ++av;
     default:
         rename(defalt,"upper.ttp");
         av[0]="upper.ttp"
         forkv("upper.ttp",av);
         wait();
         rename("upper.ttp",defalt);
         exit(0);
    }
 }
 usage prg [uUlL] ....
 My compress solution was three execs with a different define via cmd  line
for each. [that was MWC code...]
 ------------
Category 33,  Topic 6
Message 113       Sun Oct 03, 1993
T.GIRSCH [TJ @ S-Mart]       at 02:35 EDT

All -

Is there any map in the documentation which shows which header files depend on
which .O files?  I was unable to find one and this information would be very
helpful, since the integrated envrionment isn't smart enough to auto-link
these...

Thanks,

- T.J.
 ------------
Category 33,  Topic 6
Message 114       Fri Oct 08, 1993
T.KELLY12                    at 00:24 EDT

I'm writing a program which uses a number of recursive procedures and
occasionally I get an "out of stack space error."  I would like to increase
the stack size a bit, but I can't seem to locate how you do that in the
documentation.  Does anyone know how?

 ------------
Category 33,  Topic 6
Message 115       Fri Oct 08, 1993
CBARRON                      at 02:24 EDT

 RE: STACK SIZE SETTING....
  There is a global _STACK that sets the stack size. If you don't create this
variable it is loaded from lc.lib.
  unsigned long _STACK = 40960K; /* 40K stack */
 The 'chicken' factor for those 'stack overflow' checks is
  unsigned long _STKDELTA= 512; /* if stack left is < 512, its overflowed! */
  Should be in the 'library manual' under _STACK,_STKDELTA.

 ------------
Category 33,  Topic 6
Message 116       Thu Oct 14, 1993
T.WRATHER [Thomas]           at 21:31 EDT

I didn't get any help the last time I had questions about compiling MINT with
Lattice 5.52, but maybe I'll have better luck with my linking questions.  Now
that I have gotten the MINT sources to compile, I get the following link
errors:

Undefined symbols        First Referenced __saveD2A2               Library
'LCSNB.LIB' Module Name 'xbios' __savePC                 Library 'LCSNB.LIB'
Module Name 'xbios'

These symbols are not referenced in the MINT sources anywhere.  So, I assume
that I have some compiler or linker option set incorrectly. I'm using the .PRJ
file that was supplied with the sources.

Anyone have any ideas where I might be going wrong?

Thomas

 ------------
Category 33,  Topic 6
Message 117       Mon Oct 18, 1993
R.LUNSFORD2                  at 18:56 EDT

Is there any way to include a picture file when you compile a program so that
it can be referenced by the program? Russ
 ------------
Category 33,  Topic 6
Message 118       Tue Oct 19, 1993
CBARRON                      at 03:09 EDT

 It is possible to include binary data of any type that is really a file,
incbin pseudo op of the assembler can do it. Details left to the reader, but
the assembler code is a data segment,
      csect     what ever is needed for a data segment docs not here
      xdef      _picture
 _picture:
      incbin    filename of picture data
      end
 an extern datatype picture; in your C code will reference it...

 ------------
Category 33,  Topic 6
Message 119       Tue Oct 19, 1993
P.LANCTOT [paul]             at 03:20 EDT

to:D.WHITEHEAD3 re: Sound on the ST Drew, I am also a novice and sound on the
ST (my good old Mega4) was one of  the first things that I was interested in.
There's a great program in the Atari Roundtable Library that let's you
experiment with the ST  sound chip (with a GEM interface) and save your
results as C source code.
       It was so easy that i was able to include sound effects in my  very
first C program (the classic number guessing game) Just remeber  to change the
main() 's to something like fart_sound() and or  death_sound() and compile
them separately from the program that uses these lovely sounds. Then just call
them from within your program i.e. ... if (guess != number) fart_sound;  and
remember to link your sound functions in with the program that uses  them. The
file is called SNDBYTE.LZH (#14102) and can be found in the programming
library. It also explains what's going on with the  chip and includes values
for musical notes and is copyrighted but ok  for personal use. later----paul

 ------------
Category 33,  Topic 6
Message 120       Wed Oct 20, 1993
D.LIVINGST11 [ErnestBovine]  at 04:36 EDT

 Thomas,
 Re undefined symbols  __saveD2A2, __savePC these are defined in the startup
module C.S.
 LC includes many object files assembled from C.S.
 The linker links in one of them.  Which one gets linked depends on what you
select under "Application type" in the executable options menu.  Also there
are 2 versions for each application type depending on whether your ints are 16
bit or 32 bit.
 If you select "None" as your application type, then those symbols would be
undefined.  (Also your linked program would be missing a lot more besides
those 2 symbols; not just vars but all the startup code too.  So doubt that's
your problem.)

 The object module C.O (or CS.O or CSR.O or whatever; I guess it's CSNB.O in
your case) reserves space for those vars and exports the labels.
 The xbios calls in LCSNB.LIB use 'em.

 In any case, you could just declare and define them in one of your C source
files.
  long _savePC;
  long _saveD2A2[2];
 should do it.  But something else is probably wrong if you aren't linking in
a startup module.

 Does you .PRJ file contain the name of a startup module? It should be the 1st
.O file after the = sign.

 example:

 LOTTO.TOS
 .C   [-b4 -r6 -v -w -cf -d4 -fl -m0 -rr -fm]
 .S   [-u -m0]
 .L   [ADDSYM]
 =
 CSR.O
 LOTTO_07.C
 WATCHTV3.S
 LCMSR.LIB
 LCSR.LIB
 ------------
Category 33,  Topic 6
Message 121       Wed Oct 20, 1993
T.WRATHER [Thomas]           at 22:29 EDT

Ernest Bovine,

The .PRJ file supplied with the MINT sources does not contain the name of a
startup module.  The only non-MINT file mentioned in the .PRJ file is
LCSNB.LIB.

I assumed that whoever created the MINT .PRJ file knew what they were doing,
and a startup module was not needed.  Since MINT is part of MultiTOS and Atari
uses Lattice, there has to be a way of using Lattice to compile MINT.

Thanks for the reply.

Thomas
 ------------
Category 33,  Topic 6
Message 123       Fri Oct 22, 1993
P.LANCTOT [paul]             at 20:15 EDT

Drew,
   oops, my code fragrment should have been :

     if (guess != number) fart_sound(); /* forgot the ()'s

but you probably new that immediately! :-)

      ------paul.
 ------------
Category 33,  Topic 6
Message 124       Fri Oct 22, 1993
B.MCCORKLE                   at 22:43 EDT

     Does anyone know a way to default the tab to spaces in the LC editor?  I
need to detab my source code for a course I'm taking and I would like to
default to spaces just to make my life a little easier.
   Brian

 ------------
Category 33,  Topic 6
Message 125       Fri Oct 29, 1993
T.WRATHER [Thomas]           at 23:03 EDT

Brian,

I don't think that there is a way to change tabs to spaces with the LC editor.
I know STeno has an option for doing this (I've de-tabed many a program with
STeno).  However, if you don't have STeno, you could write a simple C program
to do the tab to space conversion.

Thomas
 ------------
Category 33,  Topic 6
Message 126       Tue Nov 09, 1993
J.TRAUTSCHOL [jtrautschold]  at 22:44 EST

Hey guys...

Although I recieved your latest advertising a week or so ago, I finally had
the chance to read through it.  I must say I was intrigued by the update
mentioned for Lattice C.  I believe it's now up to version 5.6.  What's this
about a new source level debugger included?????  Is that true?  Have the
HiSoft guys finally put that source level debugger in that we've all been
waiting for all this time?  If so, I'll be upgrading RSN!

I'm also quite interested in the new profiler, make and Falcon support.  Any
information you can provide would be greatly appreciated.

                                                John Trautschold
                                              Missionware Software


 ------------
Category 33,  Topic 6
Message 127       Wed Nov 10, 1993
M.HILL13 [Mike]              at 22:31 EST

Oregon Research and or HiSoft,

I second Johns question. I just posted not more than a month ago some features
I was hoping to see in a newer Lattice.

A C source level debugger was one of them.  HiSoft response seemed to say this
was a no-go.  The OR newsletter seems to dispute this.  Does the "source level
debugger" mentioned in the newsletter refer to the same assembly lever Mon-st
debugger we all know and love now?

If there is a C source debugger, does it run in a Gem enviroment and will it
work on cards like my Crazy Dots which don't have standard rez formats like
the St modes?

I also like the Profiler (I need a profiler bad for my current project), make,
and smaller LCC for use with make.

The newsletter says late October early November.  What kind of time frame are
we looking at now?  It looks like we can upgrade now by just faxing a
photocopy of one of our Lattice Disks?

Im ready to upgrade!  A C source level debugger and Profiler would make me a
very happy camper (or is that coder).

Mike

 ------------
Category 33,  Topic 6
Message 128       Thu Nov 11, 1993
ORA [Bob]                    at 12:42 EST

John,

Yes, LC 5.6 includes a source level debugger, Unix make, and Falcon support.
If you e-mail me your address, I can send more info ( when I can get it done
:')  ).

Robb @ ORA

 ------------
Category 33,  Topic 6
Message 129       Thu Nov 11, 1993
J.TRAUTSCHOL [jtrautschold]  at 22:43 EST

Thanks Robb.  You've got the info in your email-box right now!  :-)

                                                John T.
 ------------
Category 33,  Topic 6
Message 130       Fri Nov 12, 1993
ORA [Bob]                    at 11:59 EST

Mike,

There is a source level debugger and a profiler.  I will check the running on
non-standard resolutions, but I would expect this will not be a problem, as
5.6 is a Falcon optimised version.

Lattice C 5.6 will be available from us by the end of next week (19 November)

Robb @ ORA

 ------------
Category 33,  Topic 6
Message 131       Fri Nov 12, 1993
HISOFT                       at 13:04 EST

To avoid any confusion:

The debugger that will come with Lattice C 5.60 has the following source level
 features:

 Breakpoints to any line number
 Source windows locked to the program counter so that they show the line
currently being executed.
 Multiple source files can be loaded.
 Operator to find the source line corresponding to a different address.
 Global variables may be accessed by name

It does NOT support except via looking at the machine code generated:

 Named access to local variables
 Display of structured variables
 Display of floating point values (except in FPU registers).

Mon also has better window handling facilities and can lock windows to
arbitary expressions.

It supports all the video modes of the ST,TT and Falcon and you can have the
debuger in a different mode to your program. It doesn't support most addon
cards - if you have dual monitors (one with the ST/TT screen, one with the
addon, you get the debugger on the ST/TT and your program on the ST/TT). Mon
does work with Falcon Screen.

Dave Nutkins, HiSoft.

 ------------
Category 33,  Topic 6
Message 132       Fri Nov 19, 1993
R.STEGELMANN [Rolf]          at 05:38 EST

Dave Nutkins (HiSoft),

Nice to see that the debugger will lock the source lines to the program
counter. I will be ordering the upgrade.

I ran into a C compiler global optimization bug the other day. It drove me
crazy, because I could not find any problems with my source code. I finaly
tracked the problem down using the debugger. I have version 5.52 of lattice C.
Here is the stripped down version of code that was generated improperly: ------
------------------------------------- long int Vol() { return 1L; }

float Var() { float dr, dg, db;

/*~~~~~~~~~~~~~~~~~~~~  optimization bug here ~~~~~~~~*/
    dr = (float)Vol();
    dg = (float)Vol();
    db = (float)Vol(); /*~~~~~~~~~~~~~~~~~~~~  optimization bug here
~~~~~~~~*/
        return (dr+dg+db); }

int main() { float a;

        a = Var();
        return (int) a; } ---------------------------------

The three calls to Vol() did not generate the code to save the return value on
the stack, the result being that float 'a' was set to some rubbish when it
should have been set to 3.0

The following options where set up

General:                  Object:

default short integers    always generate stack frames processor : 68030
default 'Far data maths : line-F MC68882 debug : Full/Flush Parameters : Stack

Optimizer:

Enable global optimization Optimize for : TIME

All other options are set to their defaults (I did not change them).

If I turn OFF the global optimization the compiler generates the code to save
the result of the call to Vol on the stack.

It also generates the correct code (even with global optimization turned on)
when the return parameter of function Vol is changed to a float instead of the
long int.

Rolf






 ------------
Category 33,  Topic 6
Message 133       Mon Nov 22, 1993
HISOFT                       at 13:19 EST

Rolf,

Thanks for the report.

Alex has checked this out and you are correct - amazingly  this seems to be a
problem in the back end of the compiler  that has been there since we started
doing Lattice C - its  still there for 5.60.

Dave N.
 ------------
Category 33,  Topic 6
Message 134       Tue Nov 23, 1993
C.ROUNTREE2 [RoadKill]       at 00:58 EST

        AHHHHHHHHHHHHHHHH   I think I'll live without the optimiser. .  ..
 ------------
Category 33,  Topic 6
Message 135       Tue Nov 23, 1993
T.GIRSCH [TJ @ S-Mart]       at 01:11 EST

When will 5.60 be available?  I sent in a Credit Card order about a week ago,
and am anxious to get the upgrade.

Thanks,

- T.J.
 ------------
Category 33,  Topic 6
Message 136       Tue Nov 23, 1993
P.LANCTOT [paul]             at 20:49 EST

Hi, procrastonator that I am, I still haven't registered my copy of v. 5.52
yet but can you tell me how much the upgrade is and  what I have to do to get
it -- thanks.  I bought it a few months ago from TOAD -  I think the source-
level debugger would help me alot as I am a definate rookie to C.
         thanks-----------paul.
 ------------
Category 33,  Topic 6
Message 137       Tue Nov 23, 1993
L.HINSLEY [Stargazer]        at 21:30 EST

ORA,

I saw that in the Fall News flyer that an upgrade for Lattice C also received
the Modern Atari System software book.  Does this also apply for those
purchasing a new Lattice C package???

                                       ***** Stargazer *****
 ------------
Category 33,  Topic 6
Message 138       Thu Nov 25, 1993
HISOFT                       at 13:20 EST

Stargazer,

The Modern Atari System Software book is included in  Lattice C 5.60.

Dave Nutkins, HiSoft.

 ------------
Category 33,  Topic 6
Message 139       Fri Nov 26, 1993
R.LUNSFORD2                  at 05:26 EST

ALL,
   Is anyone else having problems with the drop down menus and their "pop up"
extensions on the Falcon?  I can't select anything from this portion of the
menu...Is this fixed in the 5.6 update? Russ
 ------------
Category 33,  Topic 6
Message 140       Fri Nov 26, 1993
STEVE-J [DrHfuhruhurr]       at 07:16 EST

How much is the upgrade from v5.51 to v5.60?
 ------------
Category 33,  Topic 6
Message 141       Fri Nov 26, 1993
HISOFT                       at 13:14 EST

Russ,

The "walking" menus work fine on the Falcon starting with the new 5.60.

Dave Nutkins, HiSoft. .
 ------------
Category 33,  Topic 6
Message 142       Sat Nov 27, 1993
T.GIRSCH [TJ @ S-Mart]       at 03:37 EST

STEVE-J

If memory serves, upgrade from 5.52 to 5.60 was $70 or $80.  From < 5.52, it
was closer to $100.  But recall, that comes with ALL NEW MANUALS (revised &
consolidated to match the new version) and the new ST programming book.

- T.J.
 ------------
Category 33,  Topic 6
Message 143       Sat Nov 27, 1993
E.BETZ [Bud]                 at 14:31 EST

Steve-J

According to the flyer from Oegon Research, upgrade from 5.5x to 5.60 is
$89.00.  This includes all new documentation and a book called "Modern Atari
System Software Book" and shipped in a seven pound (thats right, 7 lbs)
package.  Upgrades from 5.0x is $119.00.

Bud
 ------------
Category 33,  Topic 6
Message 144       Sun Nov 28, 1993
R.BURROWS1 [Roger@Anodyn]    at 13:57 EST

HISOFT:
  I have Lattice C 5.51.  I've just discovered some library stuff which you
may not have come across: 1. The stat() call accepts wildcards, and doesn't
work with '.' and
   '..' filenames.  Both of these cause some problems when porting
   from Unix code.  If you're interested, I can send you my
   replacement stat() code which fixes both (it's not real elegant
   though). 2. The localtime() call doesn't call __tzset() to set the timezone
   variables, so if no other routine is called that calls __tzset(),
   the timezone is always GMT. [I may have commented on this a long
   time ago, now I think about it].

I also ran across a strange problem in the compiler: I suddenly started to get
an "Intermediate file error" msg when trying to compile a file.  I checked the
free space, but there was lots of room (4 to 5MB).  I found that compiling
with a different .PRJ file fixed things, and eventually found that the PATH
variable in the integrated compiler had a blank first line.  When I removed
it, everything worked fine again.  At one time, I had manually edited the .PRJ
file to remove options from a specific module, but I think that I had compiled
stuff successfully after that.

Regards, Roger Burrows

 ------------
Category 33,  Topic 6
Message 145       Mon Nov 29, 1993
ORA [Bob]                    at 14:08 EST

Steve J,

Upgrade is 89 + s/h and copy of original disk.

Robb @ ORA

 ------------
Category 33,  Topic 6
Message 146       Wed Dec 01, 1993
HISOFT                       at 13:13 EST

Roger,

The stat() and localtime() stuff has been re-worked for  version 5.60 although
stat will still accept wildcards as  the GEMDOS fopen call does.

I can't really comment on your "Intermediate File Error"  funny but it sounds
most like you deleted something off  your QUAD: drive.


Dave Nutkins, HiSoft.

 ------------
Category 33,  Topic 6
Message 147       Thu Dec 02, 1993
CBARRON                      at 01:33 EST

 If the QUad: drive is full is this 'intermediate file error' the result of
reading an incomplete file, or is that fixed, to note the error occurred
during the actual write of the quad file?  Seems to me the only intermediate
file errors I have seen was due to filling of the diskspace where the quad
files are stored. Result occurs when the incomplete file is read.
 I might be way off base but that is what I recall as the only reason I have
ever seen 'intermediate file errors'.

 ------------
Category 33,  Topic 6
Message 148       Sat Dec 04, 1993
J.KRZYSZTOW [JEFFREY]        at 19:26 EST

When I originally purchased Lattice C through Toad Computers, I paid for the
Silver Support Service.  Now that Oregon Research is handling the products,
what does it get me??  I used to receive HiSoft flyers, but haven't in a long
time, is this because of ORA handling the US?

Jeffrey A. Krzysztow
 ------------
Category 33,  Topic 6
Message 149       Sun Dec 05, 1993
T.GIRSCH [TJ @ S-Mart]       at 04:29 EST

Got my Lattice 5.60 upgrade Friday (hooray!)

Two small 'nits' to pick, though:

1)  The disks still all say "Lattice C 5.5"

2)  The manuals are bound like paperbacks.  I like the spiral- or 3-ring-bound
manuals, because it is easy to leave them open to a certain page if I need to.

Other than that, much improved Install program.  Haven't used it enough to
give any more opinions, however.

- T.J.
 ------------
Category 33,  Topic 6
Message 150       Sun Dec 05, 1993
R.LUNSFORD2                  at 22:13 EST

No spiral bound books? ugh1! Oh well...that and the compendium... Russ
 ------------
Category 33,  Topic 6
Message 151       Sun Dec 05, 1993
J.TRAUTSCHOL [jtrautschold]  at 22:45 EST

T.J.

I'm interested in the updated debugger.  Any thoughts you can give on that?

Too bad about the "perfect bound" manuals.  I agree - I much prefer a binding
(such as spiral) that permits be to keep the books open.  Of course, one could
still use the old manuals, I suppose.  The binding should not have changed.

                                                John T.

 ------------
Category 33,  Topic 6
Message 152       Mon Dec 06, 1993
T.GIRSCH [TJ @ S-Mart]       at 00:32 EST

R.LUNSFORD2 -

The new "Modern Atari System Software" book that comes with _is_ spiral bound
(the only one that was).  Unfortunately, the majority of that book (I'd guess
two thirds, from my initial perusal) is Falcon030 specific.  It _does_ have a
nice "Software Guidelines" section, though (for standardizing user
interfaces).


J.TRAUTSCHOL -

Yes, the perfect binding is a pain, but these manuals are significantly
improved over the previous ones.  Mind you, in many respects these new manuals
are very much the same as the old ones, which is precisely why they are better
(huh?!?).  Let me explain. They did not change the things I liked about the
manuals (nice segmentation, etc).  They _did_, integrate the manuals (no more
addendums [addenda?!?] floating around).  And they improved the index, as
well.  They also added a (very handy) VT-52 command summary page, as well as
some other useful appendices.

One "still-active" beef, though.  I'd like a comprehensive summary of the
library files, what they are, and when I need to link them.  This seems to be
almost nonexistent.  There is only one small page that describes part of the
naming standard (e.g., a .LIB file that starts with "LCM" is a maths library.
Anything that comes after the 'M' is undocumented).

The debugger seems to be pretty nice (although still not a 'true' source-level
debugger), it has a good many features, such as breakpoints, memory dumps,
etc.;  I haven't used it, but from my initial scan I'd guess it's like a sort
of hybrid between CTRACE and SDB (if you know UNIX), only more interactive.

- T.J.

 ------------
Category 33,  Topic 6
Message 153       Mon Dec 06, 1993
R.WATSON15 [Wayne Watson]    at 03:23 EST

   Ah man, don't tell me another company has gone to paperback style
 reference books. Crap!!! Don't they all know it's EXTREAMLY hard to
 keep the book open with that type. ARGH!!! I HATE paperback binding
 on computer books.

 ------------
Category 33,  Topic 6
Message 154       Tue Dec 07, 1993
CBARRON                      at 02:04 EST

  What follows m of lcm*.lib, and g of lcg*.lib is the same ending that
follows the corresponding lc.lib and c.o file.  That is documented someplace!
[excepting a few startups like auto detect prg/acc which obviously don't need
additional libs]


 ------------
Category 33,  Topic 6
Message 155       Tue Dec 07, 1993
S.SANDERS2 [Scott @ SDS]     at 23:29 EST

I'll raise my hand in favor of paper-bound. They tend to last longer than the
spiral sort (pages are less likely to tear out and spiral binding sometimes
bends and becomes useless). I'll agree that they are easier to keep open in
front of you. The Compendium is perfect-bound because of its size mostly
though I am looking into a lay-flat style of binding (I don't want to raise
the price of the book though).

So far my only complaint about the upgrade is its lack of support for
MultiTOS. I can't launch GEM programs from within the editor concurrently or
not. Getting the debugger and especially the profiler to work under MT would
be a large undertaking I understand but the editor should be more compliant.

-Scott @ SDS

 ------------
Category 33,  Topic 6
Message 156       Wed Dec 08, 1993
HISOFT                       at 13:34 EST

We prefer ring bound manuals - but using them would  have put up the cost of
the upgrade considerably. Throwing  away the 5.5. labels would have cost a bit
too.

Dave Nutkins, HiSoft.
 ------------
Category 33,  Topic 6
Message 157       Thu Dec 09, 1993
T.GIRSCH [TJ @ S-Mart]       at 01:36 EST

Wayne -

Sorry, but it's true.  Paperback is it.

BTW, for the record, at the office we consistently buy $10,000 software
licenses for network database software, and what do you get? One set of
paperback-bound manuals.  Nice.

At least the lattice upgrade was only $80.

- T.J.
 ------------
Category 33,  Topic 6
Message 158       Thu Dec 09, 1993
R.WATSON15 [Wayne Watson]    at 22:21 EST

   Yea, I would have paid more for the upgrade is it meant getting
 spiral bound manuals.

 ------------
Category 33,  Topic 6
Message 159       Fri Dec 10, 1993
SAM-RAPP [<<Sam>>]           at 01:11 EST

You guys ever run any of those "competitive upgrade" specials?  For instance,
a REALLY attractive price to someone who sends in thier old (uh, Laser C, for
instance...) disks to switch to your product....

Just wishful thinking....



==========> Sam_030

 ------------
Category 33,  Topic 6
Message 160       Fri Dec 10, 1993
R.LUNSFORD2                  at 02:37 EST

Think I would've paid more too, but oh well, I already paid :)... Russ
 ------------
Category 33,  Topic 6
Message 161       Wed Dec 15, 1993
R.LUNSFORD2                  at 03:01 EST

So what's the turnaround time on these upgrade ordesrrs?  I sent in my order
about 2 weeks ago, so I would assume I could start expecting it now?

Russ
 ------------
Category 33,  Topic 6
Message 162       Thu Dec 16, 1993
M.HILL13 [Mike]              at 22:53 EST

Russ,

I placed my order on December 3.  Was told it would ship either that day
(Friday) or the following Tuesday at the latest.  I still hadn't gotten it
this week so I called and as I expected, they said they had too many orders
compared to what they had in stock.  Something about having two separate order
files instead of one.

Pretty much ticked me off since I asked twice about it shipping by that
following Tuesday when I ordered it and was told "absolutely no problem".  I
also had taken a couple days off work that following week since I knew I would
receive Lattice then.  I had an important project I needed to finish and the
profiler would be a great boost.  Well that plan fell through big time.  From
what I was told they were expecting more in next week, but with the Holidays
and everything I probably wont get the update till late January.

I seem to always have the worst luck with ordering things.  Ive heard lots of
good things about Oregon Research (don't own any of their own software), but
my last two dealings with them have left a bitter taste in my mouth.

Mike
 ------------
Category 33,  Topic 6
Message 163       Fri Dec 17, 1993
R.LUNSFORD2                  at 13:14 EST

Mike,
    I was hoping that wouldn't be the case, but oh well...I'm really looking
forward to getting mine as well...I ordered the assembler and Lattice
upgrades, can't wait to get a Falcon-compatible debugger :)... Let me know if
you get yours so I know when to reasonably expect to see mine....Thanks,

Russ
 ------------
Category 33,  Topic 6
Message 164       Fri Dec 17, 1993
R.BURROWS1 [Roger@Anodyn]    at 22:43 EST

HISOFT (Dave N)
  Thanks for the info re stat() & localtime().  My "intermediate file error"
message problem went away when I resaved my preferences. Unfortunately, I
don't have a copy of the preference file that caused the problem.  As I always
tell _my_ users at the office: "no documentation, no problem"!

Regards, Roger

 ------------
Category 33,  Topic 6
Message 165       Mon Dec 20, 1993
ORA [Bob]                    at 12:26 EST

Russ,

Our first shipment of Upgrades sold out very quickly.  Your order is probably
waiting for the next load.  Should be soon.

Robb @ ORA
 ------------
Category 33,  Topic 6
Message 166       Wed Dec 22, 1993
R.LUNSFORD2                  at 09:59 EST

Robb,
   Thanks much for the info....If you're around and you think about it, let me
know when you expect the next shipment... Thanks,

Russ
 ------------
Category 33,  Topic 6
Message 167       Wed Dec 22, 1993
B.MCCORKLE                   at 19:12 EST

   I'm having a big problem trying to get a makefile to operate.  I keep
getting an intermediate file error with a .o file of zero length. I am using
the make that came with the 5.60 version of lattice.

this is the makefile:

# makefile for ups.prg

CFLAGS = -q.\ -+ -cf -ca -fl -m0 LIBS = lc.lib lcm.lib LDFLAGS = -Lv -l$(LIBS)
OBJS = first.o  check.o io.o SRC  = first.c  check.c io.c

ups.tos: $(OBJS)
         $(CC)  $(CFLAGS)  -o$% $(SRC)
         $(LD) -o$@ $(LDFLAGS) $(OBJS)

first.o: first.c ups.h check.o: check.c ups.h io.o: io.c ups.h

and this is the result:

    lcc -c -q.\ -+ -cf -ca -fl -m0 -ofirst.o first.c

Compiling first.c Pass 1 arguments... 0: "lc1" 1: "=16384" 2: "-ja" 3: "-c" 4:
"-cf" 5: "-ca" 6: "-fl" 7: "-." 8: "-o.\" 9: "first.c" Go arguments... 0: "go"
1: "=16384" 2: "-." 3: ".\first.c" Pass 2 arguments... 0: "lc2" 1: "=16384" 2:
"-m0" 3: "-." 4: "-ofirst.o" 5: ".\first.c" Intermediate file error Compiler
return code 12

Total files: 1, Compiled OK: 0, Failed to compile: 1

make: Error code 1 make: 'first.o' removed.


this works fine from a .prj and if I start with complete .o files, I can
complete the link.  Any help will be appreciated.

                        Thanks Brian


 ------------
Category 33,  Topic 6
Message 168       Thu Dec 23, 1993
ORA [Bob]                    at 11:13 EST

Russ & Mike,

I really do apologise for not shipping the orders when expected.  We did have
a minor mix-up in the backorder filing;  such minor problems can be expected
to happen once in a while.  Everything is flowing smoothly now, however, and
all backordered Lattice C & upgrades will ship as soon as we receive the
product, which should be the end of this week(24 Dec)

Once again, we are really sorry for the mix-up


Robb @ ORA

 ------------
Category 33,  Topic 6
Message 169       Thu Dec 23, 1993
R.LUNSFORD2                  at 23:42 EST

Robb,
   That makes me feel better :)...I was hoping to get my upgrade before going
back to school as I have a project to finish, and that sounds like it may
*just* catch me <grin>...

Russ
 ------------
Category 33,  Topic 6
Message 170       Fri Dec 24, 1993
M.HILL13 [Mike]              at 02:56 EST

Robb,

No problem, things do happen! :->  I do hope you get the Lattice upgrades out
this week.  Im on vacation for the holidays and it would be great to be able
to use that new profiler on that project I mentioned back a few messages ago.

Mike

 ------------
Category 33,  Topic 6
Message 171       Mon Dec 27, 1993
W.JAMES-STEI [Wayne]         at 21:41 EST

I've noticed that the Sub-Menus on the Hi-Soft editor for BASIC 2 and Lattice
do not work on my ST or Falcon. I have used sub-menus in other programs that
work. Has anyone else mentioned this?

Wayne

 ------------
Category 33,  Topic 6
Message 172       Tue Dec 28, 1993
ORA.TECH [OregonResrch]      at 15:50 EST

Wayne,

The sub-menu problem with the Falcon has been fixed on the current versions of
those programs.  Contact us for upgrade information.

Robb @ ORA
 ------------
Category 33,  Topic 6
Message 173       Wed Dec 29, 1993
M.HILL13 [Mike]              at 00:31 EST

Robb,

Did those Lattice 5.60 updates come in yet?

Mike

 ------------
Category 33,  Topic 6
Message 174       Wed Dec 29, 1993
W.JAMES-STEI [Wayne]         at 12:24 EST

Robb,

I sent the upgrade for HBASIC 2 and Lattice, so as soon as them babies is in,
sub-menus will be a flyin'.

Wayne - Wednesday, December 29, 1993 - 09:22 a.m.
 ------------
Category 33,  Topic 6
Message 175       Wed Dec 29, 1993
R.LUNSFORD2                  at 23:52 EST

Mike,
   I called them today, and they said they should be in tomorrow or Friday...

Russ <with crossed fingers>
 ------------
Category 33,  Topic 6
Message 176       Fri Dec 31, 1993
W.JAMES-STEI [Wayne]         at 22:35 EST

So... how's the weather out in Oregon?.. um what about them Dodgers... ermm...
ARE THE UPGRADES IN YET?!?

sorry... it slipped out...

wayne

Friday, December 31, 1993 - 07:37 p.m.
 ------------
Category 33,  Topic 6
Message 177       Sat Jan 01, 1994
A.STUDER1 [Andy]             at 02:18 EST

ORA has always supported my purchasing habits quite well.  I order from them
and rcv my product in less than a week (especially if the product has been
released).

Lattic 5.6 looks and feels great, and the menu's finally work on the Falcon,
now I can get back to work (I needed the break anyway).

 ------------
Category 33,  Topic 6
Message 178       Mon Jan 03, 1994
R.LUNSFORD2                  at 23:58 EST

Still no upgrade here...:(

Russ
 ------------
Category 33,  Topic 6
Message 179       Tue Jan 04, 1994
ORA [Bob]                    at 19:39 EST

Russ,

We should have a large quantity available this week (27 December)

Robb @ ORA
 ------------
Category 33,  Topic 6
Message 180       Wed Jan 05, 1994
W.JAMES-STEI [Wayne]         at 03:53 EST

Hi,

Anyone get their Lattice 5.6 upgrade yet? I _hope_ mine's on the way. If you
got it, was there toatally new manuals, or just more addendums? Also, how's
the Modern Atari Systems book? I almost bought it at my Atari shop before I
found out about the upgrade. Hmmm... maybe if I chant...........

    Wayne - Wednesday, January 05, 1994 - 00:54 a.m. PST
 ------------
Category 33,  Topic 6
Message 181       Wed Jan 05, 1994
M.HILL13 [Mike]              at 22:53 EST

 Atari-ST RoundTable
 Category 33,  Topic 6
 Message 179       Tue Jan 04, 1994
 ORA [Bob]                    at 19:39 EST

 Russ,

 We should have a large quantity available this week (27 December)

 Robb @ ORA
 -----------------------------------------------------------------

Huh?

You posted on January 4th?  Does this mean you have the Lattice Upgrades in
stock?

I would appreciate a note here if possible when you do get them in and start
shipping to those of us who were on backorder on our upgrades.

Thanks,

Mike


 ------------
Category 33,  Topic 6
Message 182       Thu Jan 06, 1994
B.KANTOR [Bruce]             at 00:09 EST

ORA,

Lattice C 5.60 submenus are not compatible with Geneva.  I've tried Geneva
with no auto progs and DAs and no luck.  The submenus popup but are not
selectable.  I've tried all versions of Geneva (even release 003; the one just
released).

By the way I'm using a Falcon 030 and everything works great from NewDesk.

        Regards, Bruce
 ------------
Category 33,  Topic 6
Message 183       Thu Jan 06, 1994
HISOFT                       at 13:22 EST

Wayne,

The Lattice C 5.60 upgrade includes a whole new manual set.

Dave Nutkins, HiSoft.

 ------------
Category 33,  Topic 6
Message 184       Thu Jan 06, 1994
E.MONACO [DataBasement]      at 20:14 EST

Bruce,

  I know that to get the submenu's of Lattice 5.52 working correctly I had to
disable the pulldown menu option in the task manager. I'm sure I missed it if
you stated you'd tried this already.

-=Erin @DataBasement Software

 ------------
Category 33,  Topic 6
Message 185       Fri Jan 07, 1994
A.STUDER1 [Andy]             at 00:14 EST

Is it possible to use an editable dialog (buttons and text entry) AND keep
access to the menu bar?

form_do() allows only current access to the dialog without being able to go to
the menu bar.

 ------------
Category 33,  Topic 6
Message 186       Fri Jan 07, 1994
T.GIRSCH [TJ @ S-Mart]       at 00:23 EST

Bruce -

I confirmed your problem on my MSTe with Lattice 5.60 -- no luck selecting
them, and I don't use the pulldowns either.  Ask Dan in the Geneva topic.
Perhaps he can suggest something.

- T.J.

P.S.  I forwarded your message to Dan.
 ------------
Category 33,  Topic 6
Message 187       Fri Jan 07, 1994
CBARRON                      at 03:12 EST

 Andy it is possible to rewrite form_do() do also handle messages, but it is a
bit long to try in a message. <grin>

 ------------
Category 33,  Topic 6
Message 188       Fri Jan 07, 1994
R.LUNSFORD2                  at 05:23 EST

One thing I found making 5.52 bearable.... If you highlight one pop-up, then
go to another, you can select it....wierd

Russ
 ------------
Category 33,  Topic 6
Message 189       Fri Jan 07, 1994
A.STUDER1 [Andy]             at 23:47 EST

You don't mean "re-write form_do()" do you? You mean write my own form_do to
do a do_form_do which will do as I do indeed need?  Hello?

 ------------
Category 33,  Topic 6
Message 190       Fri Jan 07, 1994
HEAD.TRIP [Wayne]            at 23:58 EST

Guess what? I called at 11 am PST on 1/7/94 and the upgrades are in. They'll
go out next week! Wheee-hooo. I've been putting off a Falcon program until the
upgrade comes in... wait - now I'll have no excuse! Darn!

    Wayne - Friday, January 07, 1994 - 08:57 p.m. PST
 ------------
Category 33,  Topic 6
Message 191       Sat Jan 08, 1994
CBARRON                      at 02:09 EST

  Precisely, write a form_do() function that does what you need. It probably
will not be easy without some trials and errors....

 ------------
Category 33,  Topic 6
Message 192       Sat Jan 08, 1994
S.SANDERS2 [Scott @ SDS]     at 16:17 EST

A.STUDER1:

Writing a replacement form_do() is a good idea if you ever want to do things
like place dialogs in windows. Use evnt_multi() with form_keybd(),
form_button(), and objc_edit(). The Lattice manuals have a good example under
the entry for form_button().

-Scott @ SDS
 ------------
Category 33,  Topic 6
Message 193       Fri Jan 14, 1994
R.LUNSFORD2                  at 00:05 EST

Mike
   BTW...my upgrade came to my home yesterday...I'll be getting it in another
day or so...

Russ
 ------------
Category 33,  Topic 6
Message 194       Fri Jan 14, 1994
M.HILL13 [Mike]              at 19:33 EST

Russ,

I got my Lattice upgrade Wednesday!

Looks pretty good.  Can't use the debugger under my setup though since it
doesn't support video cards.  Bummer.  Dont have an Atari monitor anymore.  I
might have to make a cable that lets me run Monochrome mode on my SVGA card
(it will handle that rez).

Hisoft (Or Oregon R.)

Is there any way while running under the LC5 integrated system to have the
profilers LSTAT program redirect the output to a file? I don't like running a
TOS shell and would like some route to redirect the output to a file or in one
of the LC5 gem windows.

Mike

 ------------
Category 33,  Topic 6
Message 195       Sat Jan 15, 1994
B.MCCORKLE                   at 12:46 EST

I'm having a problem with the Kvbdbase function and I hope someone can point
the way to a solution.  I've used the following code to get the value of the
vector table into the pointer kv.  I can not figure a way to access the
individual structure members i.e. the address of the mouse vector.

This is using version 5.60

/* test of xbios call 1-8-94 */

#include        <stdio.h> #include        <osbind.h>

int main(void) {

  struct kbdvecs /* from Lattice vol III p. 222*/
  {
   void (*midivec)(void);
   void (*vkbderr)(void);
   void (*vmiderr)(void);
   void (*statvec)(void);
   void (*mousevec)(void);
   void (*clockvec)(void);
   void (*joyvec)(void);
   void (*midisys)(void);
   void (*ikbdsys)(void);
   char ikbdstate;
  };

  struct kbvecs *kv = *Kbdvbase(); /* kv points to table */

  printf("\n%x \n", kv ); /* prints address of table */

return 0; }

Any help will be appreciated!  Thanks
        Brian


 ------------
Category 33,  Topic 6
Message 196       Sat Jan 15, 1994
M.HILL13 [Mike]              at 14:46 EST

Brian,

I threw this together real quick.  Hopefully it will help you out. It should
compile fine.

 #include<osbind.h>
 #include<dos.h>                 // KBDVBASE is defined here

 int main(void) {
   KBDVBASE *kv=(KBDVBASE *)Kbdvbase();

   printf("%x \n",kv);           // address of KBDVBASE structure
   printf("%x \n",kv->mousevec); // address of mousevec routine
   return(0);
 }

 // Just look in dos.h for info on the names of the
 // other entries in the KBDVBASE structure.
 // Just remember to store the original value
 // of any vector you replace so you can put it
 // back when you are done, or fall through to
 // it.

 ------------
Category 33,  Topic 6
Message 197       Wed Jan 19, 1994
M.HILL13 [Mike]              at 22:59 EST

Hisoft & OR,

Couple things about the new Lattice upgrade I don't like. (all and all I am
quite happy with the upgrade though)

 1) Profiler stat program.  Can it output the statistics file to disk
    without using a command line shell?

 2) Documentation is not spiral bound. Im sure money played a big
    roll here, but I like spiral bound.

 3) Organization of the books.  I don't like functions grouped
    alphabetically by header file.  I find this very annoying,
    especially for functions I have no idea what header file
    they are included in.  I know you can look at the index in
    the back, but I find it much easier (and nicer) to have the
    books grouped alphabetically by all functions like the original
    two books.

 4) The layout of function descriptions is tougher to make out for
    a couple reasons.  One is that your not keeping each function
    description's start on the top of the page.  I assume this was
    done to decrease manual size.  You also use the same bold type
    face for function name, description,synopsis, caveats, etc.  It
    makes it very tough to visually see the start of a description
    of a function when your scanning through the book.  Maybe use
    italics or something to make things standout better. Even better
    would be to go back to the old manual format.

 5) This one may be my lack of RTFM!  The readme file was basically
    empty of notes.  Is there something anywhere that documents
    features added in this release, and compiler/tools/etc bugs that
    have been fixed? Or known problems?

 6) Sure wish the debugger would support the Crazy Dots card.  When
    running the CD in 640X400 mono mode, the video memory is the
    same as a standard ST-Mono.  If there were someway the debugger
    could be set to use the extra memory of the CD Card for the
    other debugging screen.  The card (nova,cyrel too) have 1meg
    or more so the room is there on the card.  I know there may
    be other circumstances why this won't work, but I can't even
    use the debugger since I don't have an Atari monitor, or a cable
    to do St-Mono on my SVGA monitor.

Mike

 ------------
Category 33,  Topic 6
Message 198       Thu Jan 20, 1994
R.LUNSFORD2                  at 23:10 EST

I just got my upgrade yesteerday, and so far am very happy with it.  My
 *main* complaint is, as Mike has already pointed out, the new layout in the
reference books.  With the old layout, I could flip through a few pages, find
an entry, and be back to coding in a few very short seconds. Now, it is almost
*necessary* to look it up in the index first, just so I won't take the chance
of scanning past it...I'm not too upset, as the library and Atari library
manuals seem to be pretty much the same and (thank God) the Modern Atari
Systems book is bound the old way with easier to find function calls...

   Hopefully by the time you release any upgrades that make *major* changes to
the content of the reference books, you'll consider going to the old
style....'least til then, I can use my old ones :)

Still happy, Russ
 ------------
Category 33,  Topic 6
Message 199       Thu Jan 20, 1994
J.TRAUTSCHOL [jtrautschold]  at 23:54 EST

I agree with Mike Hill's assessment of LC 5.6's manuals.  Although I'm quite
happy with the upgrade, I find that I'm quite unhappy with the organization of
the manuals.

Although I'd prefer spiral binding, I'm not that concerned about the change
there.  I am concerned about the organization though, that Mike details in his
paragraphs 3 and 4.  I never needed to look in the index before for a function
- I could turn right to it.  Now I'm constantly looking at the index and even
then I find the function I'm looking for to be difficult to find, even though
I'm on the right page!

I'm glad I didn't throw away my old manuals.  They'll continue to get a lot of
use.

                                                John Trautschold
                                              Missionware Software

 ------------
Category 33,  Topic 6
Message 200       Sat Jan 22, 1994
S.JACOBS6                    at 14:01 EST

I too just got my compiler upgrade.  The default behavior of make  wrt to up-
to-date .o files seems odd (is it truncating the date or something?).  In
general, it won't try to re-make .o files successfully generated in this
session, but it will try to regenerate .o files generated in a previous
session, even if none of their dependencies have changed.  LC doesn't seem
useful from Batcher, although LCC works fine (but only with the -B
option...I'd consider that a bug in the documentation of the install program).
Right now I'm having a hellish time using MON on a program built from multiple
source files...I don't see symbols anywhere; I can't load the source of main.c
until after the startup code shrinks the program's block, so I don't know
where to set the first breakpoint...
    Hey, for all that, I'm quite happy, really.  It's fast, the library looks
good.  The little test programs I've done come out small and fast. Maybe next
week I'll have learned how to make it behave right.
 ------------
Category 33,  Topic 6
Message 201       Sun Jan 23, 1994
STEVE-J [DrHfuhruhurr]       at 07:16 EST

I'm hearing complaints from ALL OVER about the new manuals (badly organised
and, to a lesser extent, no longer spiral-bound) -- not ONE message POSITIVE
about them.
 ------------
Category 33,  Topic 6
Message 202       Sun Jan 23, 1994
T.GIRSCH [TJ @ S-Mart]       at 08:41 EST

STEVE-J:

If you look back to one of my first posts, I said that I thought the manual
CONTENT was improved, as was the organization.  I only complained about the
non-spiral bound aspect, and what I felt was an omission.  On the whole, I was
positive, however.

- T.J.
 ------------
Category 33,  Topic 6
Message 203       Sun Jan 23, 1994
L.WHITE17 [Lorne]            at 15:49 EST

I've got a couple problems with the upgrade myself. 1. I agree with the masses
that the documentation, improved as it is, could have been better formated and
spiral binds used. 2.  On a functional level I was disappointed that the main
shell still doesn't update the scroll bar position when you return from
running a program.  I resets itself once you start scrolling the text 3.  In
accordance with the Atari standards that are nicely documented, the program
doesn't make use of the Control C, V, etc for the cut paste, open, etc. and
still relies on the had to work with F keys. 4.  The resource editor has been
enhanced to support the new object states, but it doesn't seem to support the
new extended color resources. I hope I don't have to invest in something like
Gribnif's "Interface" at another $99 to get into the world of color icons. 5.
The debugger is still really an assemby debugger, contrary to  what the Fall
1993 says which is "source level debugging".  The manual is clearer and states
that a source level is still in the future. 6.  Lastly, I can't seem to be
able to run programs from the shell when I'm using MultiTos.  Please specify
what has to be set up to make this work properly.

Other than that, I'm looking forward to working with the enhancments and
program extensions.
 ------------