GEMini Atari/GEMini_Atari_CD-ROM_Walnut_Creek_December_1993.iso/zip/program/gfabas09.lzh/GFA_BAS9.TXT

Text File | 1991-10-07 | 172KB | 4,384 lines

================================================================================
(C) 1991 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 XJM11877,GEnie and hit RETURN.  The system will prompt you for your
information.
================================================================================

 ************
Topic 3         Mon Feb 06, 1989
DARLAH [RT~SYSOP]            (Forwarded)
Sub: GFA Basic 3.n

Questions and answers for GFA Basic.

249 message(s) total.
 ************
 ------------
Category 22,  Topic 3
Message 1         Tue Jul 02, 1991
A.FRIESEN                    at 00:21 EDT

I got a mail message from someone a few days ago who is having trouble getting
my checkbook program (version 2.0 the latest one) to work. (BTW it's file #
19783).  Apparently it boots up.  Displays the file selector box.  Attempts to
create a new file when it doesn't find any others, and then bombs.  The person
is still using TOS 1.0 and the  autoprgs/accs he uses are DeskCart, Notepad,
and QuickST.  Does a compiled 3.5 program have trouble with these accessories
or TOS 1.0?  Any help is greatly appreciated as I cannot duplicate the
problem.  And if I  can't duplicate it, I cannot correct it.  Thanks...

  Aric Friesen
 ------------
Category 22,  Topic 3
Message 2         Tue Jul 02, 1991
D.A.BRUMLEVE [kidprgs]       at 00:32 EDT

 Aric, ask your user to try it without Quick ST.
 ------------
Category 22,  Topic 3
Message 3         Tue Jul 02, 1991
MINDOVERMIDI                 at 04:23 EDT

Always suggest that your customer try your program without _any_ desk
accessories installed, after turning the computer off for a minute or ten, and
see if the problem persists. And you should really compile with BOMBS+ and
ERRORS TEXT, so that you will have more information as to the nature of the
problem. At least find out how many bombs occurred.

It sounds like the problem might be in your filepath parsing routine though,
as different fileselectors (in different versions of TOS or from third
parties) allow different kinds of crap to be returned in the filepath (such as
a:\\folder\file.img).
 ------------
Category 22,  Topic 3
Message 4         Tue Jul 02, 1991
D.HOLMES14 [David]           at 22:42 EDT

I just received the 3.5E upgrade and am having one problem with it.

Since it supports STE color, I had to go through the entire program and double
all of the numbers in the VSETCOLOR commands.  While this worked fine in the
interpreter, when compiled, all of the colors came out wrong.  If I set the
numbers to normal, they are too dim when interpreted, but work fine when
compiled.

Does any know of a reason for this?  How about a fix?

Thanks,
 David
 ------------
Category 22,  Topic 3
Message 5         Wed Jul 03, 1991
C.MULLER3                    (Forwarded)

This is a GFA Basic question but the GFA topic seems to be closed for some
reason.

I am trying to read a file in GFA Basic which has a record length  greater
than 254 bytes.  Is there anyway to do this using INPUT #n? If not then what
are other alternatives besides using the INP(#n) which only reads a byte at a
time?

Thanks,
  Chris
   (C.MULLER3)
 ------------
Category 22,  Topic 3
Message 6         Wed Jul 03, 1991
J.H.CARROLL [Jon]            (Forwarded)



C.MULLER3 --

You might try using GFA's INPUT$ command.  This will let you read a string of
up to 32000 characters in length.  If you're reading in number data, you could
convert it back numbers from the string by using somethibng like the VAL
function.

Jon

 ------------
Category 22,  Topic 3
Message 7         Wed Jul 03, 1991
D.A.BRUMLEVE [kidprgs]       at 14:01 EDT

 A ways back, someone asked about books for absolute beginners...My book,
 GFA Basic Training by MichTron, is one way to start.  Although it's out
 of print, Bare Bones Software of West Virginia is advertising a sellout
 price of only $9.95 on the copies they have in stock.  The ad appears in
 this month's ST Informer, and the number given is 800 638 1123.
 ------------
Category 22,  Topic 3
Message 8         Sat Jul 06, 1991
B.ROBINSON5 [BRIANMATE]      at 09:27 EDT

Under COMPARISON OPERATORS on page 82 of the GFA 3.0 User Manual, there are 2
examples that result in different answers than the manual states. I agree with
the computer, but am wondering if I am missing a point somewhere.

The first is using <= PRINT "AAA">="aaa"     ! Manual answer -1, Computer
answer 0

My interpretation:     "A" = asc65, "a" = asc97. So "aaa" is larger
                       so the answer is FALSE.

The second is using <> PRINT -1<>4-5          ! Manual answer 1, Computer
answer 0

My interpretation:     -1 is not unequal to -1 so the answer is FALSE.

Thank you for your replies to my last letter. My problem is that I live in
Durham, CA and my nearest dealer is in Sacremento approx. 100 miles south. It
seems everyone here is into IBM and Apple and the book stores don't have
anything on Atari. They tell me to "go to the toy store. (Geeez!!) I am still
looking for a good beginner's book on Atari GFA Basic, so if anyone out there
has one for sale, please leave me a message. I thought Calamus, Outline and
Dungeon Master were tough to get into but learning GFA from the user manual
makes them look easy.

              Thanks                          Phone [phone]
                       Brian Robinson         Fax   [phone]
 ------------
Category 22,  Topic 3
Message 9         Sat Jul 06, 1991
E.DAWLEY1                    at 19:54 EDT

This particular example is on page 112 of my  Antic manual.

The first is PRINT "AAA">"aaa"....answer 0 The second   PRINT -1<=4-
5........answer -1

There are alot of examples of typos in the manual when it comes to ones and
zeros (sometimes they leave the minus off the one).

Both of your interpretations are correct, they seem to have fixed them in my
manual since the above examples give the correct result.

Eric
 ------------
Category 22,  Topic 3
Message 10        Sun Jul 07, 1991
NIRANDRA                     at 03:58 EDT

Hello. I am currently working on a terminal program specifically for the GEnie
LiveWire Chat Lines. It is not yet finished. A few things still need to be
added. But I was wondering if anyone would like to help beta test this
terminal for me. Like I said, it is mostly for use in  the GEnie LiveWire Chat
lines (page 400) taking advantage of all of the GEnie prompts and messages
found in the Chat Lines. But you can use it anwhere on GEnie.
 ------------
Category 22,  Topic 3
Message 11        Sun Jul 07, 1991
NIRANDRA                     at 03:59 EDT

Oh, one other thing... for anyone who wishes to help beta test this terminal,
the first beta test version will be only for color monitors. Since I only have
a color monitor. After all the bugs are worked out of this version, I will add
monochrome support.
 ------------
Category 22,  Topic 3
Message 12        Sun Jul 07, 1991
J.SIEBEN [J.SIEBEN]          at 14:23 EDT

C.MULLER3

I was doing some fooling around with file input and output just the other day.
Maybe this code may help you out.  What it does is reads and saves the file in
1K blocks.  I realize the EOF shouldn't handle the case of a file that is not
even 1K file size.  I just happened to have this handy.


block$=SPACE$(1024) block_ptr%=VARPTR(block$) OPEN "I",#0,"H:\TESTFILE" OPEN
"O",#1,"A:\TESTFILE" ctr&=0 REPEAT
  INC ctr%
  PRINT AT(1,1);"counter = ";ctr%
  BGET #0,block_ptr%,1024
  BPUT #1,block_ptr%,1024 UNTIL EOF(#0) CLOSE #0 CLOSE #1


 ------------
Category 22,  Topic 3
Message 13        Thu Jul 11, 1991
JWC-OEO [Jon]                at 03:43 EDT

  Perhaps this is already well known, but in case it's not...

You can fix the "stuck window" problem that shows up after exiting GFA's
compiler shell MENU.PRG by changing the first line of PROCEDURE check(x%) from
MENU KILL to MENU OFF.  BUTTNFIX also eliminates this problem but this is a
more general solution. As far as I can tell, eliminating MENU KILL does not
introduce any new problems but if you want to keep the KILL command, just put
the OFF one BEFORE it.

Don't know what the "stuck window" problem is?  Perhaps it doesn't show up on
all machines or under all versions of TOS.  On my MEGA 2 with TOS 1.4/1.04
what happens is that after exiting MENU.PRG via a mouse click on the QUIT item
in the FILE menu, the active desktop window can't be moved or resized without
an extra mouse click.  It also takes an extra mouse click to change the active
window.  The problem does not appear if you exit by using ^C.

The compiler "manual" includes a caution that needs to be followed when
editing MENU.GFA.  It's on page 7 of the one I got form ANTIC.

Jon


 ------------
Category 22,  Topic 3
Message 14        Sun Jul 14, 1991
F.VUOTTO                     at 08:30 EDT

I have been implementing sliders with code that resembles this:
     sliderpos=GRAF_SLIDEBOX(adr,parent,slider,1)
     result=(1000-sliderpos)*maxvalue/1000
     redraw slider..show result..etc... This works but the result is not
available until the mouse button is released. Can anyone help with a slider
where the result is changed AS the slider is moved ? Frank Vuotto [F10]
 ------------
Category 22,  Topic 3
Message 15        Mon Jul 15, 1991
PRINCETON-U                  at 18:28 EDT

I have a problem I'm hoping someone can help me with. I've written a terminal
program that increases the size of both the input and output buffers for the
serial port. The only problem is, if I run this terminal after having ran
FLASH! or any other terminal program that changes the size of the serial port
buffers, it sometimes locks up. This happens on both my 1040ST and 1040STe.
Any clues why?
 ------------
Category 22,  Topic 3
Message  16       Mon Jul 15, 1991
M.GIGUERE1                   (Forwarded)

 Upgrade- The up grade paths have been mentioned above.  For 3.6,

add $10 dollars to the price(If you have 3.5 the upgrade is

$10 + 2.95 for S&H).





                                             John Barger

                                             Director of Support

                                             GFA-Software




 ------------
Category 22,  Topic 3
Message  17       Mon Jul 15, 1991
M.GIGUERE1                   (Forwarded)

 VSETCOLOR-  I haven't heard of that problem.  I will check it out.

Have you tested it with the SETCOLOR command?



BOOKS FOR GFA-BASIC- I suggest the "Advanced programming for

GFA-BASIC" and disk for 39.95.  It used to be called "The

GFA-BASIC Book" and is what I used to learn the "Ins and Outs"

of the language.  We also have "Software Development with

GFA-BASIC" and "The GFA-BASIC and ASSEMBLER book" which are very

good Intermediate - Advanced books.



                                             John Barger

                                             Director of Support

                                             GFA-Software





 ------------
Category 22,  Topic 3
Message 18        Mon Jul 15, 1991
DOUG.W                       at 23:15 EDT

Frank,
   To get "live" sliders, you need to make the objects into 'TOUCH-EXIT'
objects.  This will cause form_do to exit as soon as the mouse button is
pressed down over the object.  You can then adjust the slider as long as the
button is depressed.

 /\ Doug Wheeler
 \/ Member of the IAAD -- Serving the Atari Community
 ------------
Category 22,  Topic 3
Message 19        Tue Jul 16, 1991
H.JANOYAN3 [JANOYAN]         at 01:19 EDT

PRINCETON-U,

   I increase the buffer size in my terminal program, and my program doesn't
lock up after running another terminal program.  If you can, list the code
you're using so we can take a look at it.


-Hagop Janoyan (UCLA <grin>)

 ------------
Category 22,  Topic 3
Message 20        Tue Jul 16, 1991
PRINCETON-U                  at 03:52 EDT

Ok, I'll upload the code tomorrow, as it is NOW time for bed :) BUT! one more
question! :) Could someone tell me the memory address of the bell sound? I
know the memory address for the keyboard click, and so I can turn that off.
But I have NO idea where to peek/poke for the bell. Any ideas?
 ------------
Category 22,  Topic 3
Message 21        Tue Jul 16, 1991
PRINCETON-U                  at 18:06 EDT

 Ok, here is the code that I use to resize the i/o buffers for the
 serial port...

 DIM mbuffin|(2048)            !input buffer for serial port
 DIM mbuffout|(2048)           !output buffer for serial port
 '
 mbuffin%=V:mbuffin|(0)        !address of mbuffin|()
 mbuffout%=V:mbuffout|(0)      !address of mbuffout|()
 mbuff%=XBIOS(14,0)            !address of serial port
 '
 LPOKE mbuff%,mbuffin%         !pointer to the new input buffer
 DPOKE mbuff%+4,2048           !size of new input buffer
 DPOKE mbuff%+6,0              !header set at 0
 DPOKE mbuff%+8,0              !tail set at 0
 DPOKE mbuff%+10,128           !low water mark for input buffer
 DPOKE mbuff%+12,1920          !high water mark for input buffer
 '
 LPOKE mbuff%+14,mbuffout%     !pointer to new output buffer
 DPOKE mbuff%+18,2048          !size of new output buffer
 DPOKE mbuff%+20,0             !header set at 0
 DPOKE mbuff%+22,0             !tail set at 0
 DPOKE mbuff%+24,128           !low water mark for output buffer
 DPOKE mbuff%+26,1920          !high water mark for output buffer

 Any idea why any of that would cause my terminal to lock up after
 running FLASH! or any other program that resizes the i/o buffers
 for the serial port? I don't know, maybe this isn't what's
 causing it to lock up. But it didn't start locking up until after
 I started resizing the i/o buffers. Any help would be appreciated.
 ------------
Category 22,  Topic 3
Message 22        Tue Jul 16, 1991
H.JANOYAN3 [JANOYAN]         at 19:38 EDT

PRINCETON-U,

   To turn OFF the Bell, use the command SPOKE &H484,PEEK(&H484) AND NOT 4.
To turn ON the bell, use SPOKE &H484,PEEK(&H484) OR 4.


-Hagop Janoyan (info from the GFA Basic Book)
 ------------
Category 22,  Topic 3
Message 23        Tue Jul 16, 1991
PRINCETON-U                  at 20:41 EDT

Thanks, Hagop. I guess I should buy some GFA Basic books. Since the manual
doesn't cover very much.
 ------------
Category 22,  Topic 3
Message 24        Tue Jul 16, 1991
R.WATSON15 [Wayne Watson]    at 22:28 EDT

PRINCETON-U
  Try using a string in the place of the variables and see what happens.  I
too have experienced the lockup on certain systems. I have a program that will
display the users data via modem and it will lock up on the BBS's computer but
not on mine. There has to be something that is causing this. Maybe someone
that knows more about the input/output buffers can help us here. Flash alters
the input buffer but does not alter the output buffer but, it does not suffer
these symptoms. Maybe it is something in GFA that causes it. Atari, GFA, can
you help us in this. I can leave the buffers at default when I run the program
and it will not lock up. I have banged my head on this and if I find out
anything I will post it here.

 ------------
Category 22,  Topic 3
Message 25        Wed Jul 17, 1991
MINDOVERMIDI                 at 00:07 EDT

I've found that string and numeric variables move around in memory quite a
bit.  That is, Varptr will return a different address for that variable as
other variables are changed, added and deleted. I'm not sure that this is true
for arrays, but if so, this would certainly be the cause of many problems. I
always use Gemdos 48 for storage buffers when I don't want the location to
change.
 ------------
Category 22,  Topic 3
Message 26        Wed Jul 17, 1991
PRINCETON-U                  at 01:45 EDT

MINDOVERMIND:

GEMDOS 48? The GFA manual says that returns the GEMDOS-Version number.

I'll try using bufferin$=SPACE4(2048) and bufferout$=space$(2048)
 ------------
Category 22,  Topic 3
Message 27        Wed Jul 17, 1991
CBARRON                      at 02:47 EDT

GEMDOS(hex48) is Malloc call.  I forget the gfa syntax for hex nos.
  48 HEX IS 72 DECIMAL. So address=GEMDOS(72) returns the address of allocated
memory. 0 if not available.

 ------------
Category 22,  Topic 3
Message 28        Wed Jul 17, 1991
NIRANDRA                     at 08:57 EDT

I have a question about that. That always returns 16384 for me. And then after
that, it returns 0. What do I have to do to allocate a larger block of memory?
 ------------
Category 22,  Topic 3
Message 29        Wed Jul 17, 1991
R.WATSON15 [Wayne Watson]    at 18:25 EDT

PRINCETON-U
  I was playing around with my program today that locks up on me when I re-
size the input/output buffers. I think I may have a fix. It did not lock up on
me at all. What I did was replace the string that holds the buffer with a
MALLOCd section of memory. It goes like this:

  RESERVE 40*1024  ! This reserves enough memory for the program and
                   ! malloc sections. Mileage may vary.
  '
  in_buffer%=MALLOC(512)  ! I only use 256 but I put extra in there
                          ! to make sure it does not flow past the
                          ! end of the buffer.
  '
  in_size%=256     ! The actual size of the buffer.
  '
  out_buffer%=MALLOC(256) ! I only use 8 bytes but again have a safety
                          ! margin. What's a few bytes?
  out_size%=8      ! The actual size of the buffer
  '
  Just use the in_buffer% and out_buffer% where you LPOKE the address of the
buffer. When used with MALLOC like I did above, the program will return the
location of the buffer. If something has gone wrong, in_buffer% and
out_buffer% will return 0 or a negative number. When setting the high water
and low water marks, I use SIZE * .25 for low water and SIZE * .75. Even
though I do not use XON/XOFF, flow control may be turned on when using at high
speeds. Make sure you reset the buffers to their original size and location
when your program exits. You will also need to return the MALLOCd memory and
RESERVEd memory back to the system when your program exits. Below is how you
return the memory back. Hope this helps. Let me know what happens.

  ~MFREE(in_buffer%)      ! Returns the in_buffer, out_buffer and
  ~MFREE(out_buffer%)     ! RESERVEd section of memory back to the
  RESERVE                 ! memory pool.

  Also, make sure you use even numbers for the size of the buffer.

 ------------
Category 22,  Topic 3
Message 30        Wed Jul 17, 1991
R.WATSON15 [Wayne Watson]    at 19:21 EDT

The equavalent command in GFA is MALLOC(). If you place a negative 1 (-1) when
you execute the command, then it will return the largest unallocated
contiguous free area. Any positive number will cause MALLOC to return the
address of the allocated block of memory or an error message.

  address=MALLOC(-1)  ! Returns largest contiguous free area

  address=MALLOC(2048) ! Returns the address of the MALLOCd area.

  If address returns as a 0 or negative number, then the amount of memory
could not be allocated. MALLLOCd memory must always be returned to the memory
pool before you end a program. MALLOCd memory does not move around.

  Aladdin time warp. Don't ya just love it.

 ------------
Category 22,  Topic 3
Message 31        Wed Jul 17, 1991
PRINCETON-U                  at 20:27 EDT

Where can one find a detailed explanation of the RESERVE command? The GFA
manual doesn't explain this command very well. Are you reserving memory for
your program, for GFA or what? And what's the different between reserving a
negative amount?
 ------------
Category 22,  Topic 3
Message 32        Wed Jul 17, 1991
J.EIDSVOOG1 [CodeHead]       at 21:15 EDT

All the information given here about malloc has been correct with one
exception.  It is not mandatory to mfree allocated blocks upon exiting a
program.  All memory blocks "belonging" to a program (assignment is based on
basepage address) are automatically freed by Pterm.  Of course, a
consciencious programmer may want to mfree his blocks as a matter of
principle.  You'll also want to free up your blocks while running in the
interpretter or you'll gradually eat up all of your memory.

 /\  John Eidsvoog
 \/  Member of the IAAD -- Serving the Atari Community
 ------------
Category 22,  Topic 3
Message 33        Thu Jul 18, 1991
PRINCETON-U                  at 01:35 EDT

But how do you determine how much memory you need to RESERVE before using
MALLOC()?
 ------------
Category 22,  Topic 3
Message 34        Thu Jul 18, 1991
MINDOVERMIDI                 at 04:44 EDT

Check Fre(0) before running your program. Then, run your program so that most
of the routines with large variable assignments get run, break your program,
then check Fre(0) again. The difference between the second Fre(0) and the
first should be approximately how much memory your program is using for
variables. Alternately, you could physically add up the sizes of all your
strings, floating point and integer variables, and arrays with a calculator.
Add 10 or 20 kbytes just to be safe. Then type;

Reserve n

at the beginning of your program, where n is the amount of memory GFA needs
for the strings, arrays and variables you are using.

This MSHRINKS the amount of memory that the GFA code has MALLOC'd. Now, your
MALLOC(-1) call will return the amount of memory you have available for your
own MALLOC calls. Note that you should always leave the 16384 bytes free, as
GEM needs free memory in the system. So if you want to MALLOC all the
remaining memory, type;

 N=Var_requirements
 Reserve N
 Let buf_size=Malloc(-1)-16384
 if buf_size<=0
   End                  ; with some error message
 endif
 Our_buffer=Malloc(buf_size)

in your exit routine, type;

MFREE(our_buffer)

This is not GFA's recommended usage of the RESERVE call, but works more
efficiently for aquiring Malloc space.

 /\  Darren Stevens
 \/  Member of the IAAD -- Serving the Atari Community
 ------------
Category 22,  Topic 3
Message 35        Thu Jul 18, 1991
R.WATSON15 [Wayne Watson]    at 05:26 EDT

RESERVE is defined on page 89 of the Michtron manual. If the number is
positive, then that amount is reserved for the interpreter and the remainder
of memory is released. If the number is negative, then all of memory - that
amount is reserved. The memory area reserved should be in 256 byte blocks. The
RESERVE command by itself will release all memory RESERVED. You should place
the reserve command at the beginning of the program. You should also leave at
least 16k of memory available if you are going to take all of free memory so
that the system has enough memory for fileselectors, etc. Normally, the
program will use all of available memory for itself but sometimes this is not
desired.

  As far as determining how much memory to reserve, follow what MINDOVERMIDI
said.

  It is true that you do not need to release the memory back when exiting a
compiled program but, I always do. You have to in the interpreter so I just
leave it in there when I compile the program. I just like to clean up my mess
when I am done and not depend on the system to do it for me.

 ------------
Category 22,  Topic 3
Message 36        Thu Jul 18, 1991
MIKE-FULTON [Mike @ Atari]   at 15:32 EDT

GEMDOS $48 (72 decimal) is Malloc()

GEMDOS $30 (48 decimal) is Sversion()



Mike

 ------------
Category 22,  Topic 3
Message 37        Thu Jul 18, 1991
TOWNS [John@Atari]           at 18:28 EDT

I would rather have programmers think that they HAVE to free their memory
after they are done with it.

Doing things the right way is important, I think.

-- John Townsend
   Atari Corp.

 ------------
Category 22,  Topic 3
Message 38        Thu Jul 18, 1991
PRINCETON-U                  at 19:01 EDT

Geeze, this is a wonderful place. If I had to rely on the GFA manual from
antic for my programming needs, I'd end up giving up in frustration. Thanks,
everyone.
 ------------
Category 22,  Topic 3
Message 39        Thu Jul 18, 1991
E.DAWLEY1                    at 20:32 EDT

Arrays may sometimes be moved by GFA. Thus it is important to put all static
data in an area that GFA wont touch. Most everything that you want to stay put
should be put in a MALLOC'ed area. GFA initially claims all free memory except
16K for your programs. The 16k is for GEM (resource files, windows etc).
Normally however you will want to leave about 32k for GEM if your program uses
windows. Note that the manual says that the FILESECT needs 32k of free memory
also, but this doesnt necessarily have to be allocated. If your RSC files are
over 16k, you will have to reduce the amount of memory GFA claims with the
RESERVE command in order for them to load.

It is absolutly imperative that you free all MALLOC's at the end of your
program and un-reserve all memory when in the intrepreter. Otherwise the
program will run once, and the next time hang up.

Also, you should not make to many MALLOC calls, the COMPUTE Reference TOS
version suggests that you add up all that you need and just do one MALLOC
call.

Window titles and alternate screens are other examples of static data.

Eric
 ------------
Category 22,  Topic 3
Message 40        Fri Jul 19, 1991
CBARRON                      at 02:45 EDT

Easier if the areas needed are fixed in size is INLINE. No reserves no
mallocs, no frees.  Or is this broken??

 ------------
Category 22,  Topic 3
Message 41        Fri Jul 19, 1991
PRINCETON-U                  at 06:28 EDT

Yeah, I had thought about using INLINE's. That would make things a heck of a
lot easier. What's the word on INLINE?
 ------------
Category 22,  Topic 3
Message 42        Fri Jul 19, 1991
PRINCETON-U                  at 07:24 EDT

 There's only ONE problem with using INLINE. It works fine 'cept if you
 use ...
 INLINE buffer%,4096
 you just added 4096 bytes to the size of your program. INLINE reserves
 room in your program for loading files from disk into a memory location.
 So it actually increasing the size of your code by the amount of bytes
 you're reserving. Oh well, I'll stick to RESERVE and MALLOC() :)
 ------------
Category 22,  Topic 3
Message 43        Fri Jul 19, 1991
E.DAWLEY1                    at 20:27 EDT

I wouldnt call that a 'problem' with INLINE. If you dont use INLINE but use
MALLOC, the amount of memory used by your program and its data area are still
the same. INLINE is an excellent feature, although its limit is 32k.

Eric
 ------------
Category 22,  Topic 3
Message 44        Fri Jul 19, 1991
PRINCETON-U                  at 20:48 EDT

No, INLINE actually increases the size of your program on disk. A one line
program that consists of nothing but ... INLINE A%,32000 saved on disk is over
32K bytes. But I was fooling around with RESERVE and MALLOC() last night and
pretty much figured it out, so that's the path I'll go. Thanks for all your
help, everyone.
 ------------
Category 22,  Topic 3
Message 45        Wed Jul 24, 1991
P.STONE [Xorcist]            at 06:35 EDT

Hello there GFA'ers...

I have had a need to write some MIDI applications which are a bit out of the
norm (not a sequencer mind you), but never the less, I am writing it in this
ancient form of GFA basic I got used. It's got NO version number. NO compiler
and I think it's version 1.0 or something like that...

My question is that before I run out and buy the new 3.5, I would like to know
if upon compilation, the following is true... you see, I am not new to
compilers, and want to make sure that the compiling process will speed up
functions which are already subroutines through the interpreter...

Does anyone know the speed increase for the commands:

SPUT
 SETCOLOR
 OUT

I am running a loop, and checking a port for activity, upon which I am re-
drawing the screen each time this happens... If this happens slowly, there is
no lag... but a flurry of activity, and my screens take time to catch up.
We're not talking tons of activity... just a screen re-draw for every byte and
when more then 10 bytes come in at a time, there is a queue of screen SPUTS.

Would this SPUT'ing be greatly, a little, or not at all sped up if one
compiled with 3.5?

Anyways... thanks again...

Peter

 ------------
Category 22,  Topic 3
Message 46        Wed Jul 24, 1991
D.A.BRUMLEVE [kidprgs]       at 09:42 EDT

 Peter, it's been a long time since I've done timing loops.  I remember
 comparing SPUT to PUT once though (in 2.X), and the difference was
 phenomenal.  The latest version is fast in the interpreter and generally
 faster in the compiler.  If it gets to be _too_ fast for my purposes,
 I sprinkle my code with PAUSEs.  This happens more often than you would
 guess.
 ------------
Category 22,  Topic 3
Message 47        Thu Jul 25, 1991
RHFACTOR                     at 04:00 EDT

If you upload the screen redraw loop you want timed with 3.5 compiler, I'm
sure we can do that for you.
   Also remember, the 3.5 version can handle assembly language 'implants' when
needed.
                   RHFactor
 ------------
Category 22,  Topic 3
Message 48        Thu Jul 25, 1991
P.STONE [Xorcist]            at 22:41 EDT

Well ok.. I broke down and picked up the NEW 3.6 GFA for the ST...
 It's definately faster then my older version. I am not disappointed...
initially...

I have found a few bugs though and have posted them on the Tech Support
board....

<X>

 ------------
Category 22,  Topic 3
Message 49        Fri Jul 26, 1991
P.STONE [Xorcist]            at 02:29 EDT

Ok...

I've uploaded what I RAN out to by GFA 3.6 for here... It's a MIDI application
called MapIt!. (File #20289).

It was interesting converting from GFA 0.0 to 3.6

<X>orcist

 ------------
Category 22,  Topic 3
Message 50        Mon Jul 29, 1991
PRINCETON-U                  at 01:49 EDT

Hi.. I have a small problem. I'm an avid user of the LiveWire Chat lines. And
since there's no terminal programs with a decent chat mode, I decided to write
my own, not to mention a few chat lines games such as Trivia and Trivia II. My
problem is that sometimes, because I live at home with my parents and my
sister, someone will pick up another extension in the house and the line noise
will disconnect me. Sometime when this happens, I'm no longer able to send
anything out to the modem. I'm usually still able to RECEIVE data.. just can't
send. This has never happened while using Flash. Only when using my own
terminal. Any idea why line noise sometimes locks up my serial port?
 ------------
Category 22,  Topic 3
Message 51        Mon Jul 29, 1991
TOWNS [John@Atari]           at 17:12 EDT

Hmmm.. not sure about the Serial Ports.. but, you really should look at
STalker and STeno. It's a great program and has a really neat type-ahead.

Also, in the future, you will be able to program in a C-like script language
where you could write your own games!

-- John

 ------------
Category 22,  Topic 3
Message 52        Mon Jul 29, 1991
J.NESS [Jim]                 at 19:47 EDT

PRINCETON-U

Your ST has flow control set to XON/XOFF, and your burst of random garbage
just happens to include an XOFF character.  The ST will patiently sit and wait
for an XON, before it will transmit any more chars.

There is at least one utility available that clears the clogged port, when it
happens.  Enlightened terminal software will do it automatically, or on
command, or not use the built-in flow control at all.

                                 -JN

 ------------
Category 22,  Topic 3
Message 53        Mon Jul 29, 1991
D.HOLMES14 [David]           at 23:01 EDT

I just encountered a problem with GFA BASIC 3.5E.  (Luckily, one of the
first.)

I was using the new _DATA command and wrote some code that relies on it.  When
I tried to compile it, the linker didn't recognize it.  It simply printed,
"GETDATA?  SETDATA?" etc.  Does anyone know what's wrong, and if this has been
corrected?  This code is pretty important for my new program, and I'd like to
get it to work.

Thanks in advance.

David
 ------------
Category 22,  Topic 3
Message 54        Tue Jul 30, 1991
D.A.BRUMLEVE [kidprgs]       at 01:04 EDT

 David, not sure if this is what's happening in your situation, but
 chances are good.  When I was beta-testing the first 3.x compiler, I
 found that commands that the compiler didn't recognize were handled
 in exactly this way, with question mark and all.  If this is the case
 with _DATA (I haven't tried it with 3.5E), then you'll have to use
 an alternative command/subroutine.
 ------------
Category 22,  Topic 3
Message 55        Tue Jul 30, 1991
D.HOLMES14 [David]           at 23:21 EDT

Well, I'd hate to not get to use _DATA, since I've found so many uses for it.
Hopefully this will be fixed.  (Any official word?)

David
 ------------
Category 22,  Topic 3
Message 56        Wed Jul 31, 1991
R.WATSON15 [Wayne Watson]    at 01:31 EDT

David,
  I tried the new _DATA command and it Compiled and Linked just fine. Did you
copy the new version of the compiler and linker over to another drive. If so,
recopy the files over. You may have missed one or got a bad copy.

 ------------
Category 22,  Topic 3
Message 57        Wed Jul 31, 1991
D.HOLMES14 [David]           at 22:35 EDT

I doubt it was a bad copy, since that is the only problem I've had with it,
but it's worth a try.

BTW, is it illegal to run another program from a desk accessory? I've written
a DA that works, but I'm just wondering if I'm allowed to do that.  The
external program simply runs and terminates; output is placed in a window.
Should I be doing this?

David
 ------------
Category 22,  Topic 3
Message 58        Thu Aug 01, 1991
MINDOVERMIDI                 at 06:09 EDT

D.HOLMES: You cannot exec a program from a desk accessory, without doing
serious system hacking, else the system will eventually (or immediatly) crash.
Even with complete O/S documentation from Atari, the word is that it's not
impossible, but very tricky. Sorry I can't enlighten you more, I haven't spent
much time trying.
 ------------
Category 22,  Topic 3
Message 59        Fri Aug 02, 1991
R.RIMKEVICUS                 at 00:18 EDT

Just got GFA basic 3.5 today, it took only one week after I sent the order in.
Now, that's fast. Wish Atari was that fast. Oh, well, anyways now I need a
manual so I know what the commands are. Are the 2 books w/ disk, listed on the
price sheet that came with my order the manuals I'll need? That is the GFA s/w
dev and Adv prog books and disks.
 ------------
Category 22,  Topic 3
Message 60        Sun Aug 04, 1991
PRINCETON-U                  at 01:25 EDT

 HELP!!!! The routines I've used to increase the size of my serial port are
 causing my terminal to lock up. Can someone tell me if I'm doing something
 wrong???

 mres%=MALLOC(-1)
 IF mres%<73216
   mres%=73216-mres%
   mres%=mres%+255 AND &HFFFF00
   RESERVE -mres%
 ENDIF
 mblock%=MALLOC(73216)
 '
 mbuff%=XBIOS(14,0)
 mbuffin%=mblock%+255 AND &HFFFF00
 mbuffout%=(mblock%+4352)+255 AND &HFFFF00
 screen1%=(mblock%+8704)+255 AND &HFFFF00
 screen2%=(mblock%+40960)+255 AND &HFFFF00
 '
 LPOKE mbuff%,mbuffin%
 DPOKE mbuff%+4,4096
 DPOKE mbuff%+6,0
 DPOKE mbuff%+8,0
 DPOKE mbuff%+10,256
 DPOKE mbuff%+12,3840
   '
 LPOKE mbuff%+14,mbuffout%
 DPOKE mbuff%+18,4096
 DPOKE mbuff%+20,0
 DPOKE mbuff%+22,0
 DPOKE mbuff%+24,256
 DPOKE mbuff%+26,3840
 '
 OPEN "",#1,"AUX:"
 VOID XBIOS(15,4,-1,-1,-1,-1,-1)
 '
 It doesn't lock up immediately... usually it takes about an hour. But it
 does NOT lock up if I don't resize the serial port. I used to just resize
 the serial port using arrays, and it locked up then, too. Someone told me
 to use MALLOC() and RESERVE. But it's STILL locking up. Am I doing
 something wrong here???
 ------------
Category 22,  Topic 3
Message 61        Sun Aug 04, 1991
J.SIEBEN [J.SIEBEN]          at 13:27 EDT

R.Rimkevicus

Funny I recieved my upgrade on the 2nd of Aug too.  I had (still do) the
Michtron Manual for GFA 3.0.  I ordered the new manual as well when I
upgraded.  I am not really disapointed with it but it pretty much is the
Michtron manual with most (?) of the typos removed.  When I looked at the
manual change file I noticed those changes where included in the new manual
(reprinted May, 1991).  It does come with a nice binder.  At least now I have
the interpreter and compiler docs in one book.


For the benifit of GFA Software Technologies,

You stamped the invoice saying it was shipped on the 26th of July. Now you
know how long UPS takes to get it to Calif.

Thanks for your service.
 ------------
Category 22,  Topic 3
Message 62        Sun Aug 04, 1991
R.RIMKEVICUS                 at 17:51 EDT

Well how much is the latest GFA basic manual?? I need to get one.
 ------------
Category 22,  Topic 3
Message 63        Sun Aug 04, 1991
J.NESS [Jim]                 at 18:23 EDT

I was charged $25 for a new manual, when I purchased the v3.5e upgrade.

Seemed expensive, but I went ahead anyway.

                                    -JN
 ------------
Category 22,  Topic 3
Message 64        Sun Aug 04, 1991
E.DAWLEY1                    at 20:20 EDT

PRINCTON-U........

Im not sure if this is the reason for the lokc-up, but there is one peculiar
note about the code you provided. It has to do with the procedure for RESERVE
and MALLOC. Normally GFA claims all of free memory except 16k at startup for
your program. Therefore an immediate MALLOC(-1) will always result in the
value of 16k. You must use the RESERVE command before you MALLOC more than
this amount. From the looks of your code, and following this procedure, you
are reserving (73k-16k) ..(or 57k) and then MALLOC(73k). Now this leaves no
room for GEM, which is what the 16k is left free for.

Another good procedure to follow when you are using MALLOC is to test the
return code before you continue on. I.E. check the value of mblock% to make
sure its the value you wanted. IF its a zero or some negative number then the
command failed.

At the end of your program, you should MFREE before RESERVE. As mentioned
before, this is mainly while in the intrepreter.

 ------------
Category 22,  Topic 3
Message 65        Sun Aug 04, 1991
PRINCETON-U                  at 23:10 EDT

Yes, I do use MFREE and RESERVE to return the memory I reserved and allocated.
I wasn't aware though that the 16K made available to me through the initial
MALLOC(-1) was something I wasn't supppose to use for myself. I'll try it with
leavin ghe initial 16K alone and see what happens.
 ------------
Category 22,  Topic 3
Message 66        Mon Aug 05, 1991
B.BILLJONES2 [Bill Jones]    at 04:32 EDT

Hi,

        I desperately need help with this,  Hope someone can help!  I need to
know how to get at the value of a number stored in Microsoft Basic MKS$
format.  It's a 4 byte string, but GFA's CVL function gives back incorrect
data.  (I want to convert this value to a byte location pointing to a file.)
Incidentally, using the GFA CVS funtion gives me back "0" consistantly.  CVL
at least give me some kind of numerical figure.

        Is there some kind of bit conversion I have to do here before or after
I use the GFA CV? function?  Since PC GFA is now out, perhaps someone has run
into this.  The file in question, is an .NDX (Index) pointer file generated by
the Markmail offline reader system.

        Many thanks for ANY help!

Bill Jones



 ------------
Category 22,  Topic 3
Message 67        Mon Aug 05, 1991
J.NESS [Jim]                 at 19:58 EDT

Using v3.5e, I wrote a program today which ran fine in the interpreter and
using GFABASRO, but which errored out in the compiler, with error #0008.

The error occured whether running from within MENU.PRG or from the desktop.
The error listing I find in the new manual says #0008 is an out of memory
error.  That can't be possible, since I have the program set up to use all
available memory.  I also tried setting the compiler Mxxxx value, to limit the
amount of memory.

Anybody got any clues?

                                -JN

 ------------
Category 22,  Topic 3
Message 68        Mon Aug 05, 1991
R.WATSON15 [Wayne Watson]    at 23:10 EDT

PRINCETON-U
   You are using a lot of things in your calculations you do not need and may
be screwing things up. By writing your code the way you have, you make it
harder to follow. It also makes it harder for you and others to decode. Why do
you need the AND &HFFFF00?

   As mentioned in prior message, MALLOC(-1) returns the largest amount of
contiguous free memory and not FREE memory. Contiguous free memory is memory
that is in memory blocks that continue un-interupted. There is a big
difference between the MALLOC(-1) and free memory. You end up reserving (on my
system) all but 27932 bytes of memory and then Malloc 73216. 27392 bytes is
enough for the system but it is not enough for the MALLOC and the system.

   When I ran the program (which printed out the results of the calculations
and such), MALLOC(73216) returned a 0 which meant that the malloc command did
not take. Now, since mblock% was 0, the program ended up using zero as the
base address in which to store the buffer and such. A BIG NO NO.

   Here is a reprint of your code and what my system returned for results.

  mres%=MALLOC(-1)    ! Returned the value of 45828
  IF mres%<73216      ! mres% will always be <73216 on my system
    mres%=73216-mres% ! got the value of 27388
    mres%=mres%+255 AND &HFFFFF00  ! Got the value of 27932 which is
                                   ! only 4 bytes larger than mres%.
    RESERVE -mres%    ! Reserved all but 27392 bytes of memory for
                      ! your program
  ENDIF
  mblock%=MALLOC(73216)  ! Resulted in a return value of 0 (zero)
   because you only left 27392 bytes of system meory available.

  mbuff%=XBIOS(14,0)  ! Got 3184
  mbuffin%=mblock%+255 AND &HFFFF00  ! Equals to '0+255 AND &HFFFF00'
   Which equaled 0. This meant that the INPUT buffer would be
   redirected to address 0.

  mbuffout%=(mblock%+4352)+255 AND &HFFFF00
  Same as mbuffin% except it started at address 0+4352

  screen1%=(mblock%+8704)+255 AND &HFFFF00  ! Resulted in address of
  0+8704.

  scrren2%=(mblock%+40960)+255 AND &HFFFF00  ! Resulted in address of
  0+40960.

  In other words, you end up invading other territory that is being used by
other stuff including your own buffers. It is a wonder that anything worked as
long as it did.

  I am going to upload a text file to the library tonight that will show how
to resize the RS232 ports without getting lockups. I think I put it in a
message here earlier but, I am not sure if it is still here. Your program
would work if, you did not end up with a return value of 0 when you do the
MALLOC. There are some things that are not needed in your program though. 255
AND &HFFFF00 ends up canceling each other out so why put it there. If you want
to skip 255 bytes then start the next buffer, drop the 'AND &HFFFF00'. Even if
this is what you wanted to do, you end up outside of your 73216 range.

  Base Address+255+4096+255+4096+32256+255+32256+255 = 73724 bytes of buffer
starting at base address.

  Remember, if you are going to use MALLOC, then you need to leave that amount
of memory available to the system. RESERVE -16384 will reserve all available
memory minus 16384. RESERVE 16384 will reserve 16384 and leave the rest for
the system. MALLOC uses system memory, NOT program memory.

  I will also add a section of code to the file that will show how to use one
large buffer for everything.

  Hope this helps figure out what is going wrong.

  Wayne Watson


 ------------
Category 22,  Topic 3
Message 69        Mon Aug 05, 1991
R.WATSON15 [Wayne Watson]    at 23:26 EDT

Jim,
  There must be something in your code that either uses something outside the
memory set aside for the program or you have DIMmed something too big, etc.
There are many possible causes for this and without the code in question, it
is hard to say. I am not sure if commands inside the program override the
Mxxxx command. I think that is mostly for use when writing .ACC programs.
Leave me E-mail if you do not want to post the code or give some more info
here and I will try to help.

 ------------
Category 22,  Topic 3
Message 70        Tue Aug 06, 1991
PRINCETON-U                  at 01:39 EDT

Wayne, I'm NOT reserving all but 27392. When using a negative number with
reserve, you are reserving THAT amount of memory. And while you may have
gotten 45828 returned with MALLOC(-1), I got 16384. I was wanting to reserve
73216. Thus, I was RESERVE'ing 73216-MALLOC(-1). And the reason I was using
+255 AND &HFFF00, that makes sure the address is on a 256 byte boarder. That's
all that does. 4095 + 255 AND &HFFFF00 = 4096. Frankly, I don't believe my
RESERVE's and MALLOC()'s are the cause of the problem. I think it's the way
I'm resizing the serial port. Because I used to use arrays for this, but it
locked up then, too.
 ------------
Category 22,  Topic 3
Message 71        Tue Aug 06, 1991
J.NESS [Jim]                 at 20:07 EDT

Wayne -

I do DIM an array of 512 strings.  Being used to Pascal, I was figuring 80
bytes per string, but I suppose in Basic it's 255 bytes each.

Still, that's only about 130k.  I have 2 megs in my machine.  And, again, it
works fine in the interpreter, but not when compiled.

The program is long enough to be a pain to have in the message base here, but
what I'll do is edit it to only the first 10 lines or so, and see if it still
errors out.  If so, I'll paste it into Alladin and stick it here.

Thanks for response.

                                       -JN
 ------------
Category 22,  Topic 3
Message 72        Tue Aug 06, 1991
R.WATSON15 [Wayne Watson]    at 20:32 EDT

Princeton,
  According to the manual and from my own experience, when you use a negative
number with RESERVE, you are RESERVING ALL of FREE memory MINUS the number you
specify. Page 89 of my manual. As I said, those were my figures. You MALLOC'd
73216 and was using in your buffers, more than that according to the numbers
you provided. Because the MALLOC failed and returned a 0, you were trying to
place data in the wrong places.  I understand about the 255 AND &HFFFF00 now.
The main problem with your program is that when you RESERVED -mres%, you only
left 16K for the system and then tried to MALLOC 73216. MALLOC failed and
returned a 0, the program then used 0 as a base address. I tried the section
of code out the way you gave it and I got 0 as a return. I then fixed it so
that it would leave 100K free in the system memory and I got back a valid
address. Using a MALLOC'd section of memory does work for resizing the
buffers. It fixed my problem and should fix most others.


 ------------
Category 22,  Topic 3
Message 74        Tue Aug 06, 1991
PRINCETON-U                  at 20:51 EDT

 Wayne, here's what I get...

 PRINT FRE(0)                    ' I got 584764
 RESERVE -73216                  ' reserving 73216 bytes
 PRINT FRE(0)                    ' I now get 512548
 RESERVE                         ' free the memory I reserved
 PRINT FRE(0)                    ' I now get 585764

 GFA reserves ALL of memory for itself. So, in a way, yes RESERVE -73216
 is saying let GFA Basic reserve all BUT 73216. Thus, I'll have that
 73216 bytes to MALLOC(). Before using RESERVE -73216, GFA is reserving
 ALL of memory, 'cept for about 16384. With RESERVE -73216, it's freeing
 up an additional 73216 bytes. And I ran what I sent, and I'm not getting
 a 0 when using MALLOC().
 ------------
Category 22,  Topic 3
Message 75        Tue Aug 06, 1991
DOUG.W                       at 23:25 EDT

Let's take this the other way...  You should be doing something like this
instead:

  RESERVE 20000

The idea here is that you should only be stealing as much memory as you
actually NEED.  When someone tries to run your program under MultiGEM, MIDI-
Tasking, Juggler, etc., they'll be mighty unhappy that your program is hogging
all available memory and not leaving any for other applications.

The rule of thumb is only to keep what you need for storage during the entire
life of the program, and use Malloc to get buffers that aren't needed all the
time.

--Doug
 ------------
Category 22,  Topic 3
Message 76        Wed Aug 07, 1991
PRINCETON-U                  at 00:20 EDT

But what about programs that don't use RESERVE or MALLOC() at all? All of the
memory is still being taken up by GFA. So you're telling us that we should
always immediately RESERVE just what the program needs?
 ------------
Category 22,  Topic 3
Message 77        Wed Aug 07, 1991
R.WATSON15 [Wayne Watson]    at 00:41 EDT

Princeton,
  You are right. That will teach me to trust manuals. I was going to leave
this message before I read yours. I got to playing around and found that the
manual was wrong and so was I. RESERVE with a negative number will reserve
that amount for program use. RESERVE with a positive number will leave that
much for the system. So, it seems that you may want to check you calculations
now. That is the only thing I can see that may be wrong. Your code did return
a 0 on my system. Who knows. Anyway, let me know what you find out. I also
found out that if you do a RESERVE before the MALLOC, you will get a Error
While RESERVE error.

  Doug,
    The reason for me using all of available memory is because I have written
a transfer program and I use all available memory as a buffer so that it will
not write the block to the disk everytime. Sort of like several Zmodem
programs do. The program is for a BBS and I am sorry if someone using MultiGem
doesn't like it. I guess they would have to load it as a last program or
whatever they do. I guess XYZ and other transfer programs will have to re-
written also.

 ------------
Category 22,  Topic 3
Message 78        Wed Aug 07, 1991
PRINCETON-U                  at 02:49 EDT

Hmmm, I RESERVE my memory, then use MALLOC() to allocate it... then I have to
MFREE what I MALLOC()'ed before I use RESERVE to release the  memory. Oh
well.. I wish the manual would go into further detail on this :/
 ------------
Category 22,  Topic 3
Message 79        Wed Aug 07, 1991
MINDOVERMIDI                 at 04:04 EDT

Wayne - in your program default section, it is nice to have a "maximum memory"
parameter. Your program runs, loads it's user default file, and reserves no
more memory (but maybe less) than the user wants.

Jim - GFABASIC strings can be up to 32767 bytes.
 ------------
Category 22,  Topic 3
Message 80        Wed Aug 07, 1991
J.EIDSVOOG1 [CodeHead]       at 10:59 EDT

Princeton,

Yes, as Doug said it is wise for _all_ GFA programs to use only that memory
which they need (although I think his example should have been RESERVE -
20000), whether they previously used RESERVE and MALLOC or not.  It is common
practice in other programming languages to do an Mshrink (RESERVE) at the
beginning of the program.  There's no reason that GFA programmers shouldn't
follow the same rules (although I'm as guilty as the next guy in some of my
GFA programs <grin>).  If a program needs to ensure a 100K buffer for
transfers, there's no reason for it to use 3.5 meg (or more).

     John Eidsvoog  /|\  Member of the IAAD
 CodeHead Software  \|/  Serving the Atari Community
 ------------
Category 22,  Topic 3
Message 81        Wed Aug 07, 1991
PRINCETON-U                  at 20:23 EDT

Ok, that sounds cool.. I'll definitely start doing that. 'Cept I WILL want to
use all available memory in my terminal so that the capture buffer can be as
large as memory permits.
 ------------
Category 22,  Topic 3
Message 82        Wed Aug 07, 1991
J.NESS [Jim]                 at 20:38 EDT

Better yet (I get smarter, the more I read the manual), use the Mxxxxx command
within the compiler.  This is the equivelant of RESERVE, but it assigns data
space to the program from within the startup code - the method John described.

Using M20000 for GEM programs, and a smaller number for non-GEM should be
sufficient for most programs.  If you know that your data will take more
space, then assign more.  If you don't NEED the space, don't hog it.  You
don't know what other programs will be doing 2 years from now.

                                  -JN


 ------------
Category 22,  Topic 3
Message 83        Wed Aug 07, 1991
E.DAWLEY1                    at 21:21 EDT

At start up you cannont MALLOC more than 16k, to do so, you must use the
RESERVE command. The format of RESERVE is..... RESERVE -x% (reduces the amount
of memory calaimed by GFA by x%. A postive amount returns x% back to GFA.

If PRINCTON-U's program does not use GEM, then his memory initialization code
should be ok.

If the program crashes only after one hour of use, then its probably something
else. Without seeing the rest of the code its hard to speculate. Are you using
error strings instead of bombs when compiled? This may lead you to they type
of error that causes the crash. One possibility is that you are not reading
the serial buffer properly so that the tail catches up with the head and gives
it a bite.

Computes TOS recommends that applications return any memory not needed by the
application back to the system. Of course this is a purely personal decision.
If your program does not allow another program to be be executed, then theres
no need to return unused memory. Since the ST's and TT's are not multi-tasking
computers, its really a mute point.

Eric
 ------------
Category 22,  Topic 3
Message 84        Wed Aug 07, 1991
PRINCETON-U                  at 23:01 EDT

It's not CRASHING or BOMBING.... it's locking up. So, there is no error code
or bombs returned. And this ONLY happens when I resize the serial port
buffers. But it doesn't ALWAYS happen.
 ------------
Category 22,  Topic 3
Message 85        Thu Aug 08, 1991
TOWNS [John@Atari]           at 18:33 EDT

At some point in the very near future, there will be a TOS based machine that
will have multitasking. If you free the memory you don't need, this will help
multitasking quite a bit.

-- John

 ------------
Category 22,  Topic 3
Message 86        Thu Aug 08, 1991
J.NESS [Jim]                 at 19:52 EDT

Anyone volunteer to compile the following?


DIM A$(2)                 <--  actually, any value within the ()


Nothing else, just that.  Compile it and try to run it.  Compile ANYTHING,
with that at the top, and try to run it.

If you can get it to run, tell me how.  Runs fine in the interpreter, but
error #0008 when compiled.  This was the problem I mentioned in previous
messages, and it has been narrowed to the DIM statement, using a string array.

In my program, if I remove the DIM, the program runs - until it errors out
because of the undeclared array.

I am probably missing something obvious.

                                   -JN
 ------------
Category 22,  Topic 3
Message 87        Thu Aug 08, 1991
D.A.BRUMLEVE [kidprgs]       at 20:59 EDT

 Jim, this is majorly wierd.  I have _lots_ of string arrays and my
 programs have all been compiling just fine.  I will take on this
 challenge...Maybe between us, we can zero in on the problem.  It makes
 it really tough when you can narrow it down like that and it's a
 perfectly legal operation.
 ------------
Category 22,  Topic 3
Message 88        Thu Aug 08, 1991
D.A.BRUMLEVE [kidprgs]       at 21:09 EDT

 Well, Jim, I don't have an explanation, but I do have a solution:
 rename the string.  For example DIM abc$(2) compiles just fine!
 Wieeeeerd, eh?

 Rather clearly, it's not a coding puzzle.
 ------------
Category 22,  Topic 3
Message 89        Thu Aug 08, 1991
E.DAWLEY1                    at 21:15 EDT

I believe that the mininum size of an array must be 256 bytes. Try it with DIM
a$(256) and I'll bet it works.

PRINCTON-U, I have never resized the serial port, but the kind of lock-up you
described happens when you try to read a byte from the port when there was
nothing there. If you change all the buffer vectors, dont you need to keep
track of the hihg and low water marks manually? And why go to the bother of re-
sizing the buffer? If you read the buffer in a tight loop, I cant imagine why
the default buffer wouldnt be sufficient.

Eric
 ------------
Category 22,  Topic 3
Message 91        Thu Aug 08, 1991
T.SAVINO [2-BIT SOFT]        at 23:30 EDT

J.NESS, I tried this interpreted & compiled - no problem dim a$(2)
a$(1)="hello" a$(2)="goodbye" for x%=1 to 2
   PRINT A$(X%) NEXT x%

...TS
 ------------
Category 22,  Topic 3
Message 92        Thu Aug 08, 1991
D.A.BRUMLEVE [kidprgs]       at 23:36 EDT

 TS: it seems to make a difference which version you are using.  I couldn't
 get it to compile in 3.5E or whatever it's called.

 Eric, the figure in parentheses following the string variable name is
 used to indicate the number of _elements_ in the array, not the byte
 size of the string.  a$(256) doesn't compile in my 3.5E either.
 ------------
Category 22,  Topic 3
Message 93        Fri Aug 09, 1991
D.A.BRUMLEVE [kidprgs]       at 00:02 EDT

 OK, Jim, been playing quite a bit, and it's curiouser and
 curiouser...

 Recently I compiled a program that returned the same out of
 memory accusation in 3.5E.  I went back and saved it a second
 time and recompiled and voila! it ran!  I had forgotten that
 experience until tonight, when the same thing happened with this
 code:

 DIM a$(2)
 a$(1)="good"
 PRINT a$(1)
 END

 As reported earlier, I'd tried this code in 3.5E and it wouldn't
 compile correctly.  I had loaded MENU.PRG and selected
 Interpreter and typed it and saved it in that way.  Clicked on
 Quit and back in the MENU.PRG screen I Compiled it and failed.
 In a later experiment, I ran GFABASIC.PRG from the _desktop_ and
 typed the same code anew and Quit.  Then I ran MENU.PRG (3.5E)
 and Compiled and it worked!  Tried this same scenario twice and
 it went the same way each time.  But then the next time it worked
 both ways...And the next time.  Go figure.  Three times does not
 a rule make, but I would say that there is a _chance_ you'd do
 better if you resave the program from GFABASIC.PRG run from the
 desktop...or, at least, resave the program over and over until it
 works.

 By the way, the program created from within the 3.5E MENU.PRG and
 the program created from GFABASIC.PRG 3.5E run from the desktop
 _both_ were willing to function when compiled with my copy of
 3.02.

 So, here's an alternative suggestion: resave your program over
 and over again until the compiler accepts it...or go back to
 3.02, whichever works for you.  ;-)  Very strange problem.
 Anybody have a guess as to what's going on?

 ------------
Category 22,  Topic 3
Message 94        Fri Aug 09, 1991
A.WESTON [Alan]              at 00:26 EDT

Does GFA support the fsel_exinput call in Tos 1.4 and above?  I can't find any
mention of it in my manual.  Maybe it's in a later version.

And how would I go about checking the TOS version number from GFA?

-Alan

 ------------
Category 22,  Topic 3
Message 95        Fri Aug 09, 1991
D.A.BRUMLEVE [kidprgs]       at 01:30 EDT

 Alan, don't know about fsel_exinput, but you can check the TOS version
 number this way:

 PRINT STR$(PEEK(PEEK(&H4F2)+2))+"."+STR$(PEEK(PEEK(&H4F2)+3))

 --D.A. Brumleve, IAAD
 ------------
Category 22,  Topic 3
Message 96        Fri Aug 09, 1991
J.EIDSVOOG1 [CodeHead]       at 02:04 EDT

Eric (and Princeton-U and everyone else),

But in a sense, the ST has _always_ been multi-tasking.  If you use GEM, the
user has access to accessories.  An accessory may wish to use more than 16K.
(MaxiFile must use a limited viewing mode if there's not enough memory
available).

Once again there's no reason, no matter _what_ your program does, to steal
_all_ of the available memory.  Do not burden the user with the inability to
configure your program.  Using Flash, I only exceed 200K in my capture buffer
about 1% of the time.  It's very selfish of a program to grab megabytes of
memory when the maximum ever needed is a couple of hundred kilobytes.  Let the
user decide...PLEASE!!

Even Flash, although it grabs all of memory, lets the user reserve some memory
via the FREE command.  This is not at nice as being able to set the amount of
memory _used_, but it still allows me to execute other programs from within
Flash.

For anyone writing programs which need memory, do yourself and your users a
favor.  Coding a user-configurable memory size will be one of the least
difficult routines in your program.  Do it!  As I write this message in
Aladdin I have 2.7 meg of memory available.  Thank you, Tim.  (Now close those
files <grin>).

     John Eidsvoog  /|\  Member of the IAAD
 CodeHead Software  \|/  Serving the Atari Community

P.S.  In previous programs, I am as guilty as the next guy of not following
this advice (look at GenPatch or CodeCopy).  But this is my advice for today
and the future.  Don't be selfish.
 ------------
Category 22,  Topic 3
Message 97        Fri Aug 09, 1991
J.EIDSVOOG1 [CodeHead]       at 03:05 EDT

Well, I wasn't able to cause any errors whatsoever compiling just the single
line:

 DIM a$(2)

It compiled fine (with 3.5E) and ran fine.  Perhaps this is because I always
compile and link with HotWire as my shell, and as Dorothy pointed out, there
seems to be some problem when running the interpreter from MENU.PRG.  I never
could stand using that program.

With HotWire I simply select a work file for the project I want to work on.
Then when I click on the interpreter, the source code is automatically loaded
(without executing).  Compiling is as simple as a single mouse click (or just
pressing "C").  And I never have to bother with renaming TEST.PRG to the
program name I want.  Call me spoiled.  If any HotWire users are interested,
I'll expound.

John
 ------------
Category 22,  Topic 3
Message 98        Fri Aug 09, 1991
D.A.BRUMLEVE [kidprgs]       at 04:14 EDT

 Expound, please.  Found the manual, you know.  ;-)
 ------------
Category 22,  Topic 3
Message 99        Fri Aug 09, 1991
PRINCETON-U                  at 19:28 EDT

I'm using INPAUX$ to read the serial port. So, that would NOT be the  cause of
the lockup. And when it locks up, EVERYTHING locksup. No keyclick, no mouse
movement. Zilch. And believe me, for my purposes, I HAVE to resize the serial
port.
 ------------
Category 22,  Topic 3
Message 100       Fri Aug 09, 1991
E.DAWLEY1                    at 19:47 EDT

At initialization GFA reserves 6 bytes for each element in a string array.
Therefore DIM a$(2) would require 18 bytes (including the 6 byte header).
However, using MENU.PRG and the 3.5E compiler, I had no problem whatsoever  in
compiling a$(2) -- (at the top of the code).

I cant recall what triggers the GFA error 'Array to small < 256'. I believe
this may only be for integer arrays.

CodeHead -- The ST is not a multi-tasking computer. Just becouse Accessories
can be loaded into memory doesnt make it one. Accessories should naturally
only claim the memory that they need. Applications however need not follow
this rule. If a user tells FLASH to reduce the amount of memory it uses, what
can that free memory accomplish? Since FLASH cannot EXEC another program, the
memory would just be dormant.

However, I do agree that there is no reason for a program to hog memory that
it doesnt use, becouse as you said, you never know whats going to be happening
a few years down the road.

Eric
 ------------
Category 22,  Topic 3
Message 101       Fri Aug 09, 1991
PRINCETON-U                  at 20:38 EDT

Eric, FLASH! CAN execute another program. In the command line, just type EXEC
program_name. You can also pass parameters through FLASH! by typing EXEC
program_name parameter list.
 ------------
Category 22,  Topic 3
Message 102       Fri Aug 09, 1991
T.SAVINO [2-BIT SOFT]        at 21:12 EDT

D.A.: I was using 3.5E to compile A$(2),etc.  _But_, I always run MENU.PRG
from the desktop.  I just don't like switching between the  two. (because I
renamed GFABASIC.PRG to GFABAS35.PRG to distinguish it from other versions &
was too lazy to fix the MENU.PRG source & re-compile it.  I do stuff like
that...             ...TS
 ------------
Category 22,  Topic 3
Message 103       Fri Aug 09, 1991
T.SAVINO [2-BIT SOFT]        at 21:16 EDT

)   ... and sometimes forget to close parenthesis.   8-]
 ------------
Category 22,  Topic 3
Message 104       Fri Aug 09, 1991
J.NESS [Jim]                 at 23:02 EDT

Dorothy -

Thanks for taking the time to test things out.

Since some folks find no problem, you find intermittent problems, and I find
it NEVER compiles, I guess I am going to try to do it with nothing in AUTO or
ACCs.

I had already been running the interpreter and compiler seperately. I did go
back and run both from MENU.PRG, with the same results.

Guess I'll give GFA a call on Monday, and let Barger figure it out.

                                   -JN

 ------------
Category 22,  Topic 3
Message 105       Sat Aug 10, 1991
R.WILSON36                   at 10:18 EDT

Jim, I tried the DIM a$(2). No problem using 3.6. Who knows  it might be a
sometimes bug which is hopefully fixed in 3.6
 ------------
Category 22,  Topic 3
Message 106       Sat Aug 10, 1991
MINDOVERMIDI                 at 16:06 EDT

E. Dawley: We have two brand new applications for the Atari ST which will be
released within the next 2-3 months, both are fully multitasking. Both can run
as applications or accessories, just by renaming the file. Both load MIDI
files and play them in a background proccess. Both can continue playing,
running, or proccessing when you close the desk accessory or quit the program
(gotta go grab a phone number from my data base while I'm putting this
sequence to tape). Both benefit greatly from variable buffer size - sometimes
I'm working on a 1k handwritten sysex file (and have Cubase and my sample
editor both in memory, plus a Ram disk) in it, other times I may want to
transmit a 2 meg sample in the background while I'm working in my word
processor. In spite of it's design, the Atari is *becoming* a multi-tasking
computer.
 ------------
Category 22,  Topic 3
Message 107       Sat Aug 10, 1991
R.WATSON15 [Wayne Watson]    at 17:11 EDT

E.DAWLEY,
  Nope. TOS or whatever takes care of all the high and low water marks, etc.
All you are really doing is telling the system to look for the buffer
somewhere else and what size it is. It takes care of the rest.

Alan,
  Try FILESELECT #"Title","Path","Default",file$. It was in the MANUAL.DOC
file that came on my disk.

Jim,
  I tried the DIM A$(2) and it ran fine. I ran the interpreter from MENU.PRG
and compiled the program from there also. You might want to check your auto
and ACC programs. Version 3.5E used.

 ------------
Category 22,  Topic 3
Message 108       Sat Aug 10, 1991
E.DAWLEY1                    at 19:51 EDT

I stand corrected, I didnt know that FLASH could EXEC another program.

MINDOVERMIDI --> multi-tasking You must be up to some serious hacking again!

Do you have to run some kind of a shell program that replaces the Desktop in
order to keep your MIDI stuff alive? Sounds like a great programming
accomplishment.

HIGH water LOW water --> well that eliminates that possiblity as a cause for
the crash. Myabe it has to do with the INPUAX$ command, have you tried it with
the slower reading method?

Eric
 ------------
Category 22,  Topic 3
Message 109       Sat Aug 10, 1991
J.EIDSVOOG1 [CodeHead]       at 20:31 EDT

Eric,

Shhh....please don't tell my copy of Flash that it can't exec programs.  It
happily runs programs for me all the time and I'd be lost without this
feature.  <grin>

I said, "in a sense, the ST has _always_ been multi-tasking".  There are a lot
of so-called multi-tasking systems and in my opinion, GEM's screen manager
fits the description most generally applied.  To me, true multi-tasking
requires parallel processors.  In that sense, none of the popular "multi-
tasking" systems (Windows, Mac, Amiga) are multi-tasking, they are merely task
switchers, sharing the same processor at a (debatably) usable speed.  Just
because GEM doesn't multi-task applications does not mean that it can't handle
multiple tasks, given software by considerate authors.

You say "accessories should naturally only claim the memory that they need".
This would imply that you think that they should allocate the maximum required
memory at init time even if some of that memory would only be used
occasionally.  This may fit in with your programming scheme but we try to
treat our users to more flexibility than that.

You are free to write your software in whatever manner you please, but I would
hope that some of the other readers will heed my advice so they don't make
some of the same mistakes I've made.

John

P.S. Dorothy, I'll be "expounding" about HotWire GFA shells shortly. <grin>
 ------------
Category 22,  Topic 3
Message 110       Sat Aug 10, 1991
J.NESS [Jim]                 at 21:14 EDT

Well, I renamed all my AUTO and ACC files, and rebooted.  Went to GFA, loaded
MENU.PRG, Selected my .GFA file and hit F10.

Same problem.  Any DIM of a string array of any size triggers error #8 as soon
as the program gets to the DIM instruction.  If I move the DIM around, I can
change where the error occurs, but it ALWAYS occurs.

I have recompiled a hundred different ways.

Good thing I don't really NEED this program.  I was just playing around, when
I discovered the bug.

                                   -JN

 ------------
Category 22,  Topic 3
Message 111       Sat Aug 10, 1991
J.EIDSVOOG1 [CodeHead]       at 21:51 EDT

For all GFA / HotWire users.

HotWire makes an excellent shell for development under GFA.  Version 3.0 (of
HotWire) has a new feature in the environment variables that solves some GFA-
specific problems.  To create a HotWire GFA shell, you'll need to set up some
work files.  You can create a work file for each of your projects.  The work
file is simple...just click on "~1" and locate the .GFA file, then click on
"~2" and enter the .PRG name to which you'd like to compile.  Then save the
WRK file (the best place to keep them is in your HOTSTUFF folder along with
your HOT files.

A sample work file for our HotEditor program looks like this:

  ~1: HOTEDIT3.GFA     ~5:
  ~2: HOT_EDIT.PRG     ~6:
  ~3:                  ~7:
  ~4:                  ~8:

NOTE:  Internally, HotWire keeps the full paths for each of the work list
entries.

The HOT file itself is also quite simple.  One entry calls the GFA
Interpreter, loading the source code but not executing it.  Install
GFABASIC.PRG as a GEM program with a Command Line and a hot key of "I".  The
command line should be simply "- ~1" (without the quotes). If you like, you
can chain the interpreter to the compiler so compiling will be automatic when
exiting.  I prefer not to do this and simply hit "C" to compile.  You may also
want to install another entry for the interpreter without a command line for
those times when you don't want any source code loaded.

The compiler (GFA_BCOM.PRG) is installed as a TTP with a Command Line and a
hot key of "C".  My command line is "~1 $S% S< F<", but you may want different
compiler options.  The important part is the "~1" at the beginning.  HotWire
will replace this with your source code's filename.

The compiler is chained to the linker.  See your manual if you don't know how
to chain.  The linker (GL.PRG) is installed as a TTP with no command line.

The real magic doesn't begin until you install the proper environment
variables.  To implement this fully, you'll need HotWire 3.0.  There are three
environment variables.  With HotWire 3.0, you can enter them all on the same
line:

G3OBJ=TEST.O|G3LIB=GFA3BLIB|G3PRG=~2

The "~2" on the end is the real key.  HotWire replaces that with your output
filename so that you end up with a PRG named what you want. Don't forget to
save your HotWire Configuration after changing the environment variables.

Once you get this set up correctly, you can forget all about the command lines
unless you want to change the options.  You can install your various .WRK
files directly in the other slots of your HotWire menu (live it up...devote an
entire HOT file to GFA).  When you want to work on a program, just click on
its work file entry and hit "I".

When you get the program the way you want it, exit the interpreter and hit
"C".  Your compiled program will be created and spit out into whatever
directory you desire (defined by your work file). Ahhhh...life is easy on the
HotWire ranch.

     John Eidsvoog  /|\  Member of the IAAD
 CodeHead Software  \|/  Serving the Atari Community

P.S.  I fully realize that some people resent it whenever we describe features
of our programs and expound on their more powerful features. To those of you
who don't like it, I'm sorry, but I feel that there will be some people who
will benefit from this description.  I don't feel this message is out-of-line
nor off-topic and I will only mention HotWire further if there are specific
questions about its use in this regard.
 ------------
Category 22,  Topic 3
Message 112       Sat Aug 10, 1991
D.HOLMES14 [David]           at 22:36 EDT

If you don't use HotWire, there's always my shell. <g> (file #17102)

BTW, would any of you here be interested in an updated GFA Shell?  I was
planning to re-do it with my new EDM interface, which should make it fast and
easy-to-use.

I finally finished my TX2 Text Processor (be sure to buy that <g>), and so I'm
free to go onto another project.

Any comments on EDM?  It was written entirely in GFA BASIC, using resolution
independant code.  Would anyone be interested in using it? Either reply here,
or in my EDM topic, Cat 2, Top 6.

David
 ------------
Category 22,  Topic 3
Message 113       Sat Aug 10, 1991
D.A.BRUMLEVE [kidprgs]       at 22:44 EDT

 Thanks, John.
 ------------
Category 22,  Topic 3
Message 114       Sat Aug 10, 1991
H.WOOTAN [Harry]             at 23:13 EDT

John,

Thanks for providing the GFA/HotWire setup info.  (Besides, you were asked to
do so.)

 -- Harry
 ------------
Category 22,  Topic 3
Message 115       Sun Aug 11, 1991
RHFACTOR                     at 04:55 EDT

The problem with the DIM a$(2) in the compiler.  Works fine on my system.

  If you hadn't already,  maybe somethings gone bad with your backup copies.
Try making a new copy from the master and see if that could be the solution.
           RHFactor
 ------------
Category 22,  Topic 3
Message 116       Sun Aug 11, 1991
J.SIEBEN [J.SIEBEN]          at 14:35 EDT

J.Eidsvoog,

You got the hammer out lets use it to hit the nail on the head, Multitasking
is nothing more than time sharing, unless you have two processors and even
then it depends on how they are used.  A good example of this is GEnie.  It's
got people all over the country (world) tied in at the same time.  When it
starts to slow down these users are competing for one processor that can't
keep up.

Thanks for the HotWire! info.


 ------------
Category 22,  Topic 3
Message 117       Sun Aug 11, 1991
G.STOLLMAN [Gary]            at 16:08 EDT

I just bought the Software Development Book with disk for GFA 3.0...I have
already gone through the GFA Training Reboot book, and realized only AFTER I
had bought the 3.0 book that it is useless without going through the 2.0 book
and disk first...What I would like to know is there anyone out there who is
writing REAL programs for the ST or IBM in GFA???  And if so, how long did it
take you to learn to program "well"...???  I have heard it said that GFA is as
"good" as C, but what has/is being written in it??

     Thnx,
     Gary

 ------------
Category 22,  Topic 3
Message 118       Sun Aug 11, 1991
T.SAVINO [2-BIT SOFT]        at 16:10 EDT

This is sort of a general question but... I've got a database I've been using
for over a year (written in basic) and now I need to add a couple of new
fields to it.  How can I do this and still keep the data I've been storing for
the past year.  If I just add the new  fields and increase the size of each
record, then when I use the .DAT file with all my old info it gets all screwed
up.  I understand why this is so, but how can I alter the old file to
accomidate  the newer fields (and the larger record size)?  Is there perhaps
some sample code somewhere that shows how to do this?  I'm sure this is not a
new problem.   ...TS
 ------------
Category 22,  Topic 3
Message 119       Sun Aug 11, 1991
D.A.BRUMLEVE [kidprgs]       at 16:54 EDT

 TS: Simplify the conversion by writing a little conversion program to
 put your old files in the new format.  Read in the old file, and then
 print it to disk with the addition of the new fields.  Voila!  Instant
 database file!  You could cause your program to recognize the old data
 fields and react according to whether a record is of the old type or new,
 but that's the _hard_ way.

 --D.A. Brumleve, IAAD

 And, Gary, yes, real programmers are writing real programs for the ST
 and IBM in GFA Basic.
 ------------
Category 22,  Topic 3
Message 120       Sun Aug 11, 1991
MINDOVERMIDI                 at 20:40 EDT

Eric, our programs multitask with whatever else you are running on your
computer. They won't make Sound Designer multitask with Calamus, for instance.
They consist of a program that goes in your auto folder (or run from the
desktop), and an application which will run as an accessory or a program,
depending on how it is started. When run as a desk accessory, they can be
installed and removed by programs such as Chameleon, or whatever Codehead
program installs and removes desk accessories (apologetic grin to Charles and
John - hey, if you promo'd me a copy I'd know what it was called :). I didn't
have to rewrite the GEM desktop, just the system's interrupt infrastructure,
the BIOS, XBIOS, GEMDOS, AES/VDI handlers, and occasionally have an interrupt
dissassemble and modify an uncooperative application's running code. :) I'll
be uploading a (PD? Shareware? Demo?) version of our MIDI file editor, which
(for the free version) simply displays all of the information in a MIDI file,
and plays it in the background. Watch for info in the MIDI cat of this RT.
 ------------
Category 22,  Topic 3
Message 121       Sun Aug 11, 1991
R.HARRINGTO1                 at 21:06 EDT

 '
 '
 '  This post for a special friend, but may help others - who are re-sizing
 '  their RS-232 buffers - to avoid some of the pitfalls.  The buffer in
 '  discussion has been increased to 4096 bytes.
 '
 '
 '
 '
 '
 '  You are setting your 'high-water' too high.  Never go higher than
 '  3/4 ths. of your buffer.  When your computer sends an X/OFF command
 '  to the main frame, it may take a while before the request is acknowledged.
 '  With a 4096 buffer and a 3840 'high-water' you only have room for 256
 '  more bytes before your buffer will bite itself in the tail.  At 2400 baud
 '  you are receiving 300 characters per second.  Thus you have less than
 '  one second to process some of the buffered characters before your buffer
 '  ring wraps itself.
 '
 '  The premise of the 'low/high' marks are that your program will continue
 '  processing the data so that you will not reach the end of your buffer
 '  before the X/OFF command is acknowledged.  If you set your 'high-water'
 '  at 3072 or so, then pole the buffer with a 3 second timer you will
 '  prevent a wrap.
 '  Why a 3 second timer?
 '         4096 minus a high-water of 3072 leaves room for 1024 characters.
 '         At 300 characters per second, this gives you 3.odd seconds to
 '         begin clearing the buffer.
 '
 '  You may not need to poll.  The X/OFF really should manage to get through
 '  to the main frame and halt tranmission before all 1024 bytes are filled.
 '
 '
 '  As an alternative to processing with a 3 second poll, you might do your
own
 '  high-water by polling directly into the buffer memory at
 '          - say buffer-start plus 2000 - and on a 6 second timer.
 '  If the polled memory contains active data branch to a sub-routine to
 '  process a thousand of so characters through the buffer.
 '
 '
 '  Also, you may wish to try an alternative method to RESERVE & MALLOC.
 '  The INLINE command may be used to prevent memory shifting.  Try something
 '  like INLINE buffer%,4096.  The address of the reserved memory will
 '  be written into the address of buffer% and the same reserved memory
 '  location will be loaded each time you execute your program.  Nor do you
 '  have to worry about an even byte boundry -- INLINE will automatically
 '  handle that.  Note, however, that I haven't tried this with a
 '  communications program so there may be some problems to work around.
 '
 '        Example:
 '             INLINE buffer%,4096
 '             address%=varptr(buffer%)
 '             myreserved_address%=lpeek(address%)
 '
 '  This is not to imply that RESERVE & MALLOC will not do the trick, but the
 '  INLINE method is cleaner and takes less concern.
 '
 '
 '                                        Mike Harrington
 '                                        Genie Address: R.HARRINGTO1
 '
 '
 '
 '  Full example of resizing RS-232 buffer using INLINE
 '  ---------------------------------------------------
 '
 '  set INLINE for length of two 4096 byte buffers with a few spare bytes.
 INLINE buffer%,8212
 address%=VARPTR(buffer%)
 myreserved_address%=LPEEK(address%)
 mbuff%=XBIOS(14,0)
 ' set incoming buffer to start of INLINE memory
 mbuffin%=myreserved_address%
 ' set out going buffer to start of INLINE memory + 4098
 mbuffout%=(myreserved_address%+4098)
 GOSUB opencomport
 ' do your thing.
 GOSUB closecomport
 END
 '
 PROCEDURE opencomport
   '
   ' get the orginal values.
   '
   oinpointer%=LPEEK(mbuff%)
   oinsize%=DPEEK(mbuff%+4)
   oinlow%=DPEEK(mbuff%+10)
   oinhi%=DPEEK(mbuff%+12)
   '
   ooutpointer%=LPEEK(mbuff%+14)
   ooutsize%=DPEEK(mbuff%+18)
   ooutlow%=DPEEK(mbuff%+24)
   oouthi%=DPEEK(mbuff%+26)
   '
   '
   ' poke the new pointers.
   '
   LPOKE mbuff%,mbuffin%
   DPOKE mbuff%+4,4096
   DPOKE mbuff%+6,0
   DPOKE mbuff%+8,0
   DPOKE mbuff%+10,256
   DPOKE mbuff%+12,3072
   '
   LPOKE mbuff%+14,mbuffout%
   DPOKE mbuff%+18,4096
   DPOKE mbuff%+20,0
   DPOKE mbuff%+22,0
   DPOKE mbuff%+24,256
   DPOKE mbuff%+26,3072
   '
   OPEN "",#1,"AUX:"
   VOID XBIOS(15,4,-1,-1,-1,-1,-1)
 RETURN
 '
 PROCEDURE closecomport
   '
   CLOSE #1
   '
   ' reset the pointers to orginal values.
   '
   LPOKE mbuff%,oinpointer%
   DPOKE mbuff%+4,oinsize%
   DPOKE mbuff%+6,0
   DPOKE mbuff%+8,0
   DPOKE mbuff%+10,oinlow%
   DPOKE mbuff%+12,oinhi%
   '
   LPOKE mbuff%+14,ooutpointer%
   DPOKE mbuff%+18,ooutsize%
   DPOKE mbuff%+20,0
   DPOKE mbuff%+22,0
   DPOKE mbuff%+24,ooutlow%
   DPOKE mbuff%+26,oouthi%
   '
 RETURN
 ?
 ------------
Category 22,  Topic 3
Message 122       Sun Aug 11, 1991
T.SAVINO [2-BIT SOFT]        at 22:26 EDT

D.A.: I think I understand what you are saying re: the database conversion.
Basically, I should read each record into an array (say a$(1) through a$(8)),
then add a$(9) and a$(10) to each record, and write the _new_ file to disk.
Is that what you're saying?
 ------------
Category 22,  Topic 3
Message 123       Sun Aug 11, 1991
D.A.BRUMLEVE [kidprgs]       at 23:46 EDT

 TS: Exactly...Start with dummy info for fields 9 & 10, write them to
 disk, and edit them later in your newly-expanded database so they'll
 be truly complete...But they'll look "complete" to the computer as
 soon as you do the conversion -- and of course convert your program
 so it expects these new fields!  You caught on for sure.
 ------------
Category 22,  Topic 3
Message 124       Mon Aug 12, 1991
PRINCETON-U                  at 02:17 EDT

::smile:: Thanx Mike... that's what I needed :) And I had thought about using
INLINE, but the only drawback to using it is that it actually  increases the
size of your program by the amount you specify. If I used INLINE buffer%,8192
the program itself would increase by 8192 bytes. Granted, this is not a LOT,
but I'm using RESERVE and MALLOC() for my alternate screens, also.. and the
total amount I'm reserving is 72960. And that DOES make a big difference :)
Would boost my program size from 68K to 140K :)
 ------------
Category 22,  Topic 3
Message 125       Mon Aug 12, 1991
R.WATSON15 [Wayne Watson]    at 04:05 EDT

Jim,
  Try another copy of your GFA files. I have often solved wierd problems this
way. Ya never know.

In a previous message I mentioned that MALLOC uses system memory and not
RESERVEd memory. Well, again it is sometimes not a good idea to totally rely
on information given by someone else. I must have been really tired the night
I tried it out. Anyway, MALLOC DOES use RESERVEd memory. I am going to re-
upload the file RS232BUF.LZH to the libraries tonight. It contains new and
revised information that has come about due to the discussions here. I
apologize to those that have already downloaded the provious file.

 ------------
Category 22,  Topic 3
Message 126       Mon Aug 12, 1991
H.SARBER [RANGERST]          at 22:44 EDT

    Wayne,
        *%&#^$@ (not printable, grin) Aladdin downloaded the previous version
'JUST BEFORE' it got this message.  Oh, well, it wasn't that big anyway.  I'm
going to pick it up after I finish typing this message.  Not a problem.

    To all,
     A couple of questions.  Since the current thread seems to be about memory
allocation, what is the 'most correct way' to allocate memory prior to EXECing
and returning from a program?  I'm working on a Menu type program and it
'appears' to be functioning normally, but I'd like to be sure it's not going
to bomb from memory problems.
     Secondly, how do you turn off all colors in mono.  I have a screen saver
in my program that works fine in color by:
     for i%=0 to 15
       setcolor i%,0
     next i%
     This works fine in color, but not in mono.  Hmmmmmmm....

 ------------
Category 22,  Topic 3
Message 127       Mon Aug 12, 1991
T.SAVINO [2-BIT SOFT]        at 23:24 EDT

Thanks D.A., I did the conversion and it worked perfectly.  I was  stuck
before because I was thinking in terms of modifying the existing file (yuck).
...TS
 ------------
Category 22,  Topic 3
Message 128       Mon Aug 12, 1991
D.A.BRUMLEVE [kidprgs]       at 23:28 EDT

 Congratulations, TS!
 ------------
Category 22,  Topic 3
Message 129       Tue Aug 13, 1991
R.WATSON15 [Wayne Watson]    at 00:21 EDT

RangerST,
  All I do before I EXECute a program is RESERVE enough memory for the program
to run with some extra for whatever it does. You may or maynot want to RESERVE
all of available memory so it will have enough to run and all. Then EXECute
the program. When you exit the program and return to the GFA program, release
that memory you RESERVEd. If you are writing this for yourself, then RESERVE
whatever you like but, as John mentioned, if you are writing it for other
people to use, you may want to give them the option of setting the amount of
memory to allocate for EXECution of other programs.

 ------------
Category 22,  Topic 3
Message 130       Tue Aug 13, 1991
A.FRIESEN                    at 21:23 EDT

If I remember right, RangerST, the mono mode onthe ST is more of an XOR mode.
You cannot turn the colors off.  The only way to blank out the screen is to
draw a filled black box over the whole thing.  But to restore the previous
screen, you will have to use something like GET to get the screen before you
draw over it.  This will take up 32K of RAM (quite a lot for a little screen
saver utility) to hold the original screen image.  Then when you want the
screen to turn back on paste it back with PUT.  Of course, I could be
completely wrong too.

   Aric Friesen
 ------------
Category 22,  Topic 3
Message 131       Tue Aug 13, 1991
R.WATSON15 [Wayne Watson]    at 23:22 EDT

Well, I finally got the last version of RS232BUF.LZH (#20495) uploaded. The
change fixes the comments on the RESERVE statement that someone screwed up in
the manual and some comments on the MALLOC command. I had it uploaded the
other night but had to pull it because of a typo that Larry pointed out.
Anyway, this method of resizing the buffers has totally fixed my problems with
the lockup I was experiencing. Hope it helps. It should be up as soon as the
Sysop(s) release it.

 ------------
Category 22,  Topic 3
Message 132       Wed Aug 14, 1991
J.NESS [Jim]                 at 21:46 EDT

The best way to "screen save" with a mono screen is to reverse the colors of
the bits.  White=Black, Black=White.  Do it every couple of minutes, to
prevent the White pixels from burning in.

                                      -JN
 ------------
Category 22,  Topic 3
Message 133       Thu Aug 15, 1991
D.HOLMES14 [David]           at 22:49 EDT

Is it possible to write a TOS program in GFA BASIC?  I tried changing the
extention of one of my programs, but it didn't use any less memory.  I though
it was running faster, but it's difficult to tell. Can GFA BASIC make pure TOS
programs?

David
 ------------
Category 22,  Topic 3
Message 134       Fri Aug 16, 1991
J.EIDSVOOG1 [CodeHead]       at 14:43 EDT

David,

There really is no strict definition of a "TOS" program.  I'm not sure what
you're looking for but it seems you want to eliminate the GEM routines from
your memory to make it smaller.  When the desktop (or HotWire) runs a TOS
program, the only differences in execution are that the screen is cleared, the
mouse is turned off, and the text cursor is turned on.  Your program could
also do these things so that it would "act" like a TOS program, even if run as
a GEM program.

As far as GFA compiling with the GEM library, I'm not sure how intelligent it
is regarding the inclusion of unneeded routines.  I believe that it always
opens a VDI workstation whether you ask it to or not, but I might be mistaken
about this.

John
 ------------
Category 22,  Topic 3
Message 135       Fri Aug 16, 1991
D.HOLMES14 [David]           at 23:00 EDT

John,

Thanks.  Yes, all I want to do is free up memory by not accessing GEM, but
that doesn't seem to be working.  Oh, well, I guess I'll just have to get more
memory, since my own programs are getting so large.

David
 ------------
Category 22,  Topic 3
Message 136       Sat Aug 17, 1991
R.WATSON15 [Wayne Watson]    at 10:17 EDT

David,
  I have seen a difference in memory usage by changing the extension to TOS.
The BBS program that I use gives me more free memory when I rename it to a TOS
program. If you have ANYthing in the program that calls for GEM usage, you may
not see a difference.

 ------------
Category 22,  Topic 3
Message 137       Sun Aug 18, 1991
B.BRESNIK                    at 20:37 EDT

Hope I'm not beating a dead horse, but... when trying to compile a VERY short
and simple program (finding Armstrong numbers) that ran perfectly interpreted,
I kept getting 008 (out of memory errors) though the compiler/linker gave ZERO
error reports on compile! The error always cropped up in the .PRG compiled
version after dimensioning a small array. When I added a line to RESERVE 2000,
not needed in the interpreted version, it compiled and ran perfectly.
 Moral: Use RESERVE in the compiler to leave space for arrays, etc.
 ------------
Category 22,  Topic 3
Message 138       Mon Aug 19, 1991
J.NESS [Jim]                 at 11:22 EDT

B.BRESNIK -

Thank you, thank you , thank you.

I had relegated GFA Basic 3.5e to the "It does wierd things, forget it" bin,
until your message suggesting adding RESERVE xxxx ahead of the DIM statement.

I added the RESERVE statement, and my test program runs like a champ.

GFA has now been moved to the "It does wierd things, but I can still use it"
bin.

Besides this particular "bug," (at least *I* consider it a bug), the menu
program also returns my desktop colors to their default values, rather than
the DESKTOP.INF values.  Aggravating.

Here's hoping for v3.5f, or better.

What ever happened to John Barger showing up here (and on CIS, for that
matter)?

                                    -JN

 ------------
Category 22,  Topic 3
Message 139       Mon Aug 19, 1991
D.A.BRUMLEVE [kidprgs]       at 14:58 EDT

 Jim, I'm annoyed by the color palette reset by the compiler, also.  Odd
 that they would not restore the user's palette selections.  And the
 RESERVE thing would indeed seem to be the key to your a$(2) oddity.
 ------------
Category 22,  Topic 3
Message 140       Tue Aug 20, 1991
A.FRIESEN                    at 01:12 EDT

Stranger even...I have written a program (my checkbook program somewhere here
on GEnie) that uses multiple HUGE (well, 1,000+elements) and don't have any
problems with the compiled versions and I never used the  reserve command.
Why the inconsitancy.  I am going to try that A$(2) on my computer and see
what happens.  Oh BTW, my arrays vary from binary, real, and string arrays.

   Aric Friesen
 ------------
Category 22,  Topic 3
Message 141       Tue Aug 20, 1991
R.WATSON15 [Wayne Watson]    at 05:48 EDT

That is interesting since my compiled programs run fine without the RESERVE
command with small DIMed variables. Hmmmm.... I also wish John would show up
here. He popped in once or twice and now seems to have forgotten us.

 ------------
Category 22,  Topic 3
Message 142       Tue Aug 20, 1991
OUTRIDER [Terry @ T2]        at 09:47 EDT

     Add me to the list of people who've had no problems DIMing variables
without using the RESERVE command...

                                  - Terry -

 ------------
Category 22,  Topic 3
Message 143       Thu Aug 22, 1991
NIRANDRA                     at 22:17 EDT

I have a terminal written in GFA Basic. But I'm having a problem. Sometimes it
will crash. I get 2 bombs. What else causes 2 bombs besides "peek or poke
possibly wrong"? I have no peeks or pokes in my terminal.
 ------------
Category 22,  Topic 3
Message 144       Fri Aug 23, 1991
L.HARTWELL [Larry H.]        at 01:11 EDT

Well, add me to the list of people who've had massive problems with programs
compiled without the RESERVE command.  After repeatedly getting the out of
memory error I got out the book.  It didn't make sense but I tried the RESERVE
command and everything worked fine.  I finally decided to check here to see if
I was the only one with the problem... well at least I'm not alone...

 ------------
Category 22,  Topic 3
Message 145       Fri Aug 23, 1991
B.BRESNIK                    at 18:34 EDT

In addition to reserve, the command $m n   will reserve n bytes of memory
during compiling, but is ignored by the interpreter.  For example, $m 4000
reserves enough memory for an array of 500 floating- point numbers as in 'DIM
x(499)'.  Without RESERVing memory, my compiled programs invariably crash with
error 008.
 ------------
Category 22,  Topic 3
Message 146       Fri Aug 23, 1991
J.NESS [Jim]                 at 19:57 EDT

Well, I did try the $mxxxx command without success, but not internal to the
source code.  I used it in the compiler command line.  I never did try it in
the source.

                                     -JN
 ------------
Category 22,  Topic 3
Message 147       Fri Aug 23, 1991
J.SIEBEN [J.SIEBEN]          at 22:08 EDT

NIRANDRA,

Maybe you are referencing an address with a word size variable 'var&' instead
of double word 'var%'.  Or using 'W:' where your should have 'L:'

All

I have uploaded a small clock setting utility (as if we don't have enough) to
show how to use Resource Construction Set Dialogs.  The source is fully
commented to explain what is going on.  I have had this laying around for some
time and thought it may be of some use to someone trying to figure out how to
do it.  If I only had this kind of example way back when I first wrote
it...file number 20603.

 ------------
Category 22,  Topic 3
Message 148       Sat Aug 24, 1991
R.HARRINGTO1                 at 21:25 EDT

 NIRANDRA:
 '
 '   Looked over the listings.  Can't see anything that is obviously
 '   incorrect.  Since 2 bombs represent a BUS error, I assumed that a
 '   LPOKE, DPOKE, or SPOKE was busting the memory, but I searched out
 '   each occurance and can't spot any errors.
 '
 '   An off the wall idea.
 '   Check out your XBIOS 7 call.  Notice that you are passing the
 '   whiteout variable as a word.  GFA manual requires a 4 byte interger
 '   that GFA then converts into a 2 byte word.
 '   Now, assume that the whiteout variable is moved into memory that contains
 '   odd data in the trailing two bytes.  Since GFA is looking for a four
 '   byte parimeter, what will it find in the whiteout variable.
 '
 '   Glance at the following code.  Note that I am poking an odd value into
 '   the address of whiteout&+2.  Run the code and watch what happens to the
 '   value of whiteout&.  A glance at the assembly lang. output of the code
 '   reveals that whiteout& is indeed handled as a long.
 '
 '   How this could create a BUS error, I don't know.  If it creates a BUS
 '   error, I can not reproduce it.  Perhaps it is causing data to overwrite
 '   memory that you are using later for a DPOKE or LPOKE.  Maybe it doesn't
 '   cause any kind of problem.
 '
 '   Still, it is curious that the first loop listed below will terminate
 '   itself after a few moments of some very interesting screen popping.
 '   Yet you must press a key to end the second loop.
 '
 '   Hey, even if this doesn't solve your problem, its interesting to note
 '   such wierd programming examples.
 '
 '                                 Mike Harrington
 '                                 R.HARRINGTO1
 '
 '
 ' p/s:  I didn't take time to worry about resetting colors; you will
 '       have to reboot if you execute the routines as is.
 '
 '
 '
 '
 '
 FOR whiteout&=0 TO 20
   a%=VARPTR(whiteout&)
   POKE a%+2,32
   FOR t%=0 TO 3
     ~XBIOS(7,t%,whiteout&)
   NEXT t%
 NEXT whiteout&
 '
 '
 ~XBIOS(7,3,3)
 FOR whiteout&=0 TO 20
   a%=VARPTR(whiteout&)
   POKE a%+2,32
   PRINT whiteout&
   IF INKEY$<>"" THEN
     END
   ENDIF
 NEXT whiteout&
 '
 END
 ------------
Category 22,  Topic 3
Message 149       Sun Aug 25, 1991
PRINCETON-U                  at 01:48 EDT

WHY WON'T IT WORK? WHY WON'T IT WORK? WHY WON'T IT WORK???  (screaming,
pulling out hair, throw a general-all-purpose-GFA Basic-tantrum)
 ------------
Category 22,  Topic 3
Message 150       Sun Aug 25, 1991
J.SIEBEN [J.SIEBEN]          at 12:45 EDT

Correction to filename SETTIME.ARC.

Well I made a boo boo in my source SETTIME.GFA.  The 2 lines that start with
~OBJC_DRAW are incorrect.  The first one should read

~OBJC_DRAW(input%,0,1,x%,y%,w%,h%)

The reference to "tree1&" is incorrect, should be 0.  This tells the system to
start drawing the tree starting with the first object in the tree.

The second one should read

~OBJC_DRAW(output%,0,1,x%,y%,w%,h%)

The reference to "tree2&" is incorrect, should be 1.  This tells the system to
draw the tree to the first set of children only.

The funny thing is the program works because the values of the tree variables
were correct for OBJC_DRAW.

Sorry if this confused anyone,

J.Sieben



 ------------
Category 22,  Topic 3
Message 151       Sun Aug 25, 1991
E.SLICK [Eric]               at 18:09 EDT

Nirandra,

 Are you using alternate screens, particularly as strings? It seems that I
remember this was part of a problem I also had some time ago.

Eric S.
 ------------
Category 22,  Topic 3
Message 152       Sun Aug 25, 1991
E.DAWLEY1                    at 20:00 EDT

Princton U--->

Why dont you upload the porblem code here and we can take a look and see if we
can spot the problem...

Eric
 ------------
Category 22,  Topic 3
Message 153       Mon Aug 26, 1991
PRINCETON-U                  at 20:10 EDT

I do have alternate screens, but I simply redraw them. I store the  terminal
screen's text in an array. It is not an actually picture of the screen. I just
redraw the screen and re-print the text. And I have NO idea where in the
program the problem exists. And the program is over 4000 lines long. I DO know
that one string variable in particular is becoming corrupted, but it's just
the string variable I use to store what is being typed.
 ------------
Category 22,  Topic 3
Message 154       Mon Aug 26, 1991
P.STONE [Xorcist]            at 22:24 EDT

Hello all..

I finished my MapIt program (which is in this library and the MIDI library),
and I also have a version that when it get's a MIDI note, it displays a
picture assigned to that note. (Degas/Uncompressed).

Basically, I've got this array, ( notepic$(127) ), and for whatever note, I
assign the picture... <display picture...sget notepic$(note)
 and then save the according pallette>...

Now this all works fine, but I have begun to have a problem. After I load say,
12 pictures or so, and the program remaps the incoming MIDI data and displays
the according picture when that note comes in, after about 2000 displays (less
on a machine with less memory), the entire program crashes and exits to the
desktop...

Now I'm only SPUTing really... Does anyone have any initial ideas about this?

There used to be a stupid bug in the Apple // line of computers in which you
would need to put a dummy X=FRE(0) in the loop of things as doing that would
free memory up, reset dummy pointers, etc...

Could this be the problem here? Is displaying all those pictures over and over
incrementing some internal pointer that is hitting the top and crashing?

Anyways... haven't tried it with the normal MAPIT version here, (the version
here does not have the picture function...), but I assume it would might do
the same thing ... still have to test it... but just thought that someone
might of recognized this situation...

<X>orcist

 ------------
Category 22,  Topic 3
Message 155       Tue Aug 27, 1991
J.SIEBEN [J.SIEBEN]          at 22:05 EDT

Try this:

a$="" CHAR{{V:a$}}="test"

On my 3.5e returns peek poke possibly wrong.

when a$=" " it's OK.

 ------------
Category 22,  Topic 3
Message 156       Wed Aug 28, 1991
PRINCETON-U                  at 01:06 EDT

That's because when a string variable equals "" it has no memory location.
 ------------
Category 22,  Topic 3
Message 157       Wed Aug 28, 1991
PRINCETON-U                  at 18:30 EDT

 I think I've figured out the reason for my 2 bombs... has anyone out there
 had a problem using RC_COPY? I'm using this to scroll  my screen...

 RC_COPY lsbase%,0,8,640,168 TO lsbase%,0,0,3

 where lsbase% = XBIOS(3) of course. For some reason, this is corrupting
 other places in memory. But I don't understand WHY. I've now switched
 to using GET and PUT, which is slower, but doesn't give me 2 bombs.
 Is there any problem using RC_COPY when the source and destination
 are the same place in memory? I also get the same problem using...

 BMOVE lsbase%+1280,lsbase%,26880

 Anyone know WHY this happens?
 ------------
Category 22,  Topic 3
Message 158       Wed Aug 28, 1991
E.DAWLEY1                    at 20:33 EDT

CHAR{{V:a$}}="test" bombs becouse you are using two sets of parentheses. GFA
does not attach an address to a null string. Therefore you are trying to write
your string to address 0. CHAR{V:a$}="test" should give you no problems. The
double parentheses means the address of the address.

I have not had any problems with the RC_COPY command. However, how was your
alternate screen memory reserved, with an array or with the RESERVE command? I
have found that unless you use RESERVE for the alternate screen memory, GFA
may move it around and then your lsbase% variable is no longer any good. You
could re-establish the position of lsbase before each RC_COPY by using
lasbase%=V:array|(0) etc. Oh! your x width should be 639, and not 640 also.

Eric (glad you finnally found the culprit!)
 ------------
Category 22,  Topic 3
Message 159       Thu Aug 29, 1991
PRINCETON-U                  at 01:02 EDT

I'm not using alternate screens... lsbase% = XBIOS(3). That doesn't  change
unless you use XBIOS(5), which I'm not. And yes, I had 640, not 639 in my
program. It's just when I changed to another method, other than RC_COPY, it
required 639, the actual pixel location, not 640, the number of pixels. So, it
was just a typo.
 ------------
Category 22,  Topic 3
Message 160       Thu Aug 29, 1991
E.DAWLEY1                    at 20:13 EDT

Try to clip the area before you RC_COPY to make sure that memory outside the
screen area is not affected. As I said, Ive never had problems with it though.
BMOVE should definately not be effected if the memory area overlaps, Im not
sure about RC_COPY however.

Eric
 ------------
Category 22,  Topic 3
Message 161       Thu Aug 29, 1991
PRINCETON-U                  at 20:39 EDT

But I'm NOT going outside of the screen area when I'm using RC_COPY OR BMOVE.
And there HAS to be something wrong, because now that I've removed every
RC_COPY and BMOVE and simply replaced them with GET and PUT's, everything is
working fine. Granted, GET and PUT is slower, but if they won't make my
program crash, fine.. I'll use them.
 ------------
Category 22,  Topic 3
Message 162       Thu Aug 29, 1991
B.BRESNIK                    at 23:31 EDT

According to John Barger, a very few GFA BASIC 3.5e upgrades have been shipped
with corrupted compiler (or COMPLIER, as it's spelled) files which produce the
#008 "out of memory" bug when compiling DIM and other statements... Check with
GFA about disk replacement, though using the $m kluge seems to work for me.
John has been VERY responsive to the Atari community!
 ------------
Category 22,  Topic 3
Message 163       Fri Aug 30, 1991
RHFACTOR                     at 01:13 EDT

Hi Gang!!
  I have a programming situation that I need some advice on. please.
   I am using both mouse and keyboard for inputing info into the program. The
program must be HI/MED rez compatiable.
   I have implemented the SELECT CASE command to keep track of mouse/BOX
locations  then on to the subroutine etc etc.
   Here's the problem.  Using Select/Case,  I wanted to take all the 'Y'
coordinates and MUL them by the REZ.
   This would allow me to use only ONE moduale and basically one set of 'X',
'Y' coordinates to handle.
   The problem is that CASE will not 'seem' to allow any type of 'math' to
take place within it's command line.  I'm having to assemble two, nearly
duplicate routines to make this work. And Select/Case  DOES seem to be the
natural command of choice.

   So guys,   any ideas or suggestions?   If so,  how 'bout a short example
piece of code on this.   OR is there a totally better way to handle MOUSE AND
Keyboard inputs???   I am NOT using resource (RCS).

    Thanks for any help.                 RHFactor
 ------------
Category 22,  Topic 3
Message 164       Fri Aug 30, 1991
E.DAWLEY1                    at 19:19 EDT

RHF ---> med/high rez...

This might seem overly simplified, but you might try reading the mouse co-
ordiantes and then multiplying the y variable by a factor that would adjust it
to one set resolution, then do your CASE stuff.

Have you tried SELECT my%*rez% ?

Eric
 ------------
Category 22,  Topic 3
Message 165       Fri Aug 30, 1991
B.BRESNIK                    at 19:19 EDT

CASE expects an integer (byte) answer: have you tried:
   res%=XBIOS(4)
   SELECT res%
   CASE 0
     hor=319
     ver=199
   CASE 1
     hor=639
     ver=199
   CASE 2
     hor=639
     ver=399
   DEFAULT
     ! you have TT resolutions
   ENDSELECT
 ------------
Category 22,  Topic 3
Message 166       Fri Aug 30, 1991
G.T.GRAY [Gary Gray]         at 19:19 EDT

I just want to comment that GFA 3.6 crashes on the TT/Matrix video card combo.

Thanks Gary Gray Megabyte Plus

 ------------
Category 22,  Topic 3
Message 167       Sat Aug 31, 1991
RHFACTOR                     at 01:26 EDT

Thanks guys for the SELECT CASE for REZ examples.    It's funny, ONLY in the
aftermath,  when one realizes that sometimes taking a brief pause, when trying
to find a solution, upon ones' return.... the OBVIOUS shows itself.

   So after going out and 'beating up' a tennis ball, I decided to see if the
SELECT portion would mind if I put conditions on it.... sure nuff that be spot
to put it.
    Still,  thanks for the postings !!!          RHFactor
 ------------
Category 22,  Topic 3
Message 169       Sat Aug 31, 1991
PRINCETON-U                  at 18:33 EDT

 Hmm, about that RC_COPY bug I had. I was using....

 RC_COPY lsbase%,0,8,640,152 TO lsbase%,0,0,3

 and lsbase%=XBIOS(3). Well, I couldn't get that to work, so I switched to

 GET 0,0,639,159,screen$
 PUT 0,8,screen$,3

 Then just for the heck of it, I went BACK to RC_COPY, but I plugged in
 XBIOS(3) directly instead of using lsbase%. It immediately locked up
 again. So, just for the heck of it, I tried XBIOS(2) and it works perfectly.
 Now, both XBIOS(3) and XBIOS(2) are returning the same value since I am
 NOT using XBIOS(5) to move the logical and/or physical screen bases around.
 Anyone know why the heck XBIOS(2) would work when XBIOS(3) wouldn't?
 ------------
Category 22,  Topic 3
Message 170       Sun Sep 01, 1991
N.WEINRESS [IAAD Member]     at 01:20 EDT

RHF, I have used a multiplying factor to adjust for the difference betwwen
high and medium res. and very successfully. If you do that, the CASE case is
superfluous.

Norm
 ------------
Category 22,  Topic 3
Message 171       Sun Sep 01, 1991
RHFACTOR                     at 05:13 EDT

Thanks NORM,   I have been adding the 'factor' for rez into all my  programs.
   The BIG thing I'm trying to solve has to do with TEXT and BOXES (again!)
  But this time, I've borrowed the color ST from the studio and now have both
computers running GFA so that I can test code.
   One of the FIRST big discoveries came when doing font size switching, that
the overall length of the text line did NOT cover the X plane at  quite the
same distance as the reference font size did.    So NOW I'm going in and using
the 3rd parameter in the TEXT command that adjust the 'spread' of the text$
(based on the LEN(txt$)).  That seems to work very well EXCEPT when I try to
place the text into a 'white' box,  then I can see all the black spaces
inbetween the letters........  so... we're not done with that part yet.
                                         RHFactor
 ------------
Category 22,  Topic 3
Message 172       Sun Sep 01, 1991
R.WATSON15 [Wayne Watson]    at 05:22 EDT

J.SIEBEN,
  I ran into the same problem about a yaer ago when I was working on a
checkbook program. I was wanting to use the same Dialog Box for several
functions and just needed to change the text of the buttons. I tried the
CHAR{{V:a$}}="test" method and was having problems. I read somewhere or
someone told me that when you change the data like that, the string needs to
be the same length or larger.

EXAMPLE:

a$="This is a test" CHAR{{V:a$}}="test"  ! This will work

a$="T" CHAR{{V:a$}}="test"  ! This will not work

Also, what the others said. An empty string will give you problems in this
instance. If you are going to change a$ in this fashion, you need to set the
initial string length to the maximum size that will modify it to later.

I hope I got this right. If it is wrong, someone please say so. This is on
information that I have. From the experiences with my checkbook program, this
method seems to hold true.

Also, I have noticed another problem with GFA 3.5E. If someone else could try
this and see what happens I would appreciated it.

  a$="Q"
  If a$<>"Q" OR a$<>"N"
    b$="Test"
  ENDIF
  PRINT B$

What happens is that when there is an OR placed in the check with a '<>' on a
string, it always returns false and thus b$ will equal "Test".
 ------------
Category 22,  Topic 3
Message 173       Sun Sep 01, 1991
PRINCETON-U                  at 11:24 EDT

Wayne, it's working right... a$ DOES equal "Q". You're then saying IF a$ does
NOT equal "Q" *OR* a$ does NOT equal "N" then b$ equals "Test". In that case,
b$ will ALWAYS equal "Test". You're testing if a$ doesn't equal ONE or the
OTHER. Not BOTH. And, since a$ doesn't equal "N", it's returning TRUE
therefore, b$ equals "Test". Did I explain that well? :) If you use IF a$<>"Q"
AND a$<>"N" THEN it will return false and b$ will not equal "Test".
 ------------
Category 22,  Topic 3
Message 174       Sun Sep 01, 1991
E.DAWLEY1                    at 12:27 EDT

Princeton-U, yes you explained that well. I often find myself confusing OR &
AND as in the above example. Its usefull to sit back and think carefully about
what your code is doing and then you can see the error. Remember that (True OR
False)=True.

RE changing strings with CHAR{}... If you are changing TENDINFO's that are
part of a RCS tree, you are correct that you cannot change the string to a
length that is longer than the original string. The reason is that RSC_GADDR
packs all the data very tightly into memory and does no allow any extra room
for longer strings. Therefore create your strings to the maximum length that
will be needed when you create your RCS files.

This problem will not arise with GFA strings since GFA will move the strings
around in memory to accomidate the new lengths. I probably did not explain the
problem with the example CHAR{{v:a$}}='"test" well. Lets break it down...
a$="".....GFA stores a value of 0 at the address V:a$
CHAR{{V:a$}}="test"...GFA now tries to write this string at address 0!
(becouse of the double parentheses).

a$=" "....GFA stores a value of 32 at the address V:a$
CHAR{{V:a$}}="test"...GFA writes to address 32, you just over wrote supervisor
memory!

Eric
 ------------
Category 22,  Topic 3
Message 175       Sun Sep 01, 1991
PRINCETON-U                  at 13:54 EDT

Actually, V:a$ returns 0 when a$="" because a$ doesn't exist. Therefore it has
no memory address.
 ------------
Category 22,  Topic 3
Message 176       Sun Sep 01, 1991
P.STONE [Xorcist]            at 14:50 EDT

Maybe my post never made it here...

Question:

Is there a need to constantly call a line like x=fre(0) to reset
 internal pointer stacks, etc., (like the Apple //s require).?

I am loading pictures (degas) and constantly displaying them, but after a
while of displaying or loading, I get 2 bombs and the program exits... it's
completely frustrating. It works fine for an hour and then dies...

It's symptomatic of the x=fre(0) syndrome of that on the Apples...
 Does this sound familure?

<X>

 ------------
Category 22,  Topic 3
Message 178       Sun Sep 01, 1991
PRINCETON-U                  at 19:38 EDT

Xorcist, are you loading the degas pictures in by loading before screen ram so
that the picture begins at the beginning of screen ram and the color values
are off the screen? This could cause some problems. If you're doing that, you
might want to try BGET instead of BLOAD to load just the PICTURE part of the
file into screen memory.
 ------------
Category 22,  Topic 3
Message 179       Mon Sep 02, 1991
NIRANDRA                     at 12:45 EDT

How can you tell when an ACC has been selected? I'm having problems with a few
ACC's that don't redraw the part fo the screen they land on after they are
finished.
 ------------
Category 22,  Topic 3
Message 180       Mon Sep 02, 1991
J.NESS [Jim]                 at 22:54 EDT

Niranda -

Your problem with screen redraws is symptomatic of another discussion going on
earlier in the message base.

There is no documented way to know when a Desk ACC has been exitted. What you
need to do is to coordinate YOUR background with the GEM background.  Then,
when an ACC exits, the backgrounds will match.

There are GEM calls that will let you change the GEM background, if you must
have it different from the default.  Then, when your program ends, you can
return it to its previous state (not necessary, but it's the smooth thing to
do.  I believe GEM does the change-back itself anyway).

There are also calls that will force GEM to redraw its background, so that you
can use that background in your program.  Either the default, or some special
that you assign.

                                    -JN

 ------------
Category 22,  Topic 3
Message 181       Tue Sep 03, 1991
N.WEINRESS [IAAD Member]     at 00:19 EDT

RHF, I solved the Text problems by doing DEFTEXT with a factor, t%, in the
parameters. I set t% at initialization at the same time I set the  resolution
factor. I would have to look it up, but I think it was set at 6 or 8 for
medium res. and 13 for mono. I know it solves the problem n nicely.

Norm
 ------------
Category 22,  Topic 3
Message 182       Tue Sep 03, 1991
RHFACTOR                     at 02:58 EDT

Thanks NORM,   I had the opportunity of working with 2 ST systems, one mono ,
the other color.  Had a productive first round.
   The point of the problem that I was finding, had to do with putting some
boxes around text.  Doesn't sound that difficult.  Still,  thanks to everyone
suggestions,  especially in the use of ~extend  call.
   Still problems where visible,  in that the 'placement' of the text in the
box was DIFFERENT between the REZ modes.  The color text tend to 'fill' the
entire box,  instead of being placed neatly inside the mono bo x, wioth nice
head and bottom coverage.  ALSO, it seems that using some of the various font
sizes showed similar 'placement' problems.
   One of the BIG challenges was in trying to work a font size for size
conversion between the two rez.   13 to 6,  and 6 to 4  (sounds like a
Chicago tune),  was fine,  however, we MONO guys can use size 4.... what to do
for the color rez  (trust me, size 3 on the color was some specs and globs).
    The next major problem had to do with the horizontal length of a box
between the two rez modes.  And here is where having both systems running
together helped focus in on the interaction of the 3rd optional parameter of
the TEXT command.  (You see, some of the problems I was asking about where not
just of the vertical placement, but rather, the interaction of every cell.
    Anyways,  I have a bunch of quickly thrown together moduals that I can now
review, so that I can prepare for I hope another go of it.

     As usual,  thanks for sharing your ideas....  we be listenin'

                                 RHFactor
 ------------
Category 22,  Topic 3
Message 183       Tue Sep 03, 1991
E.DAWLEY1                    at 21:53 EDT

I bought my system with a mono-monitor, and added a color monitor about a year
ago. I usually write my code for the mono screen first and then add in the
factors for the color version afterwards.

It never seems to fail that the conversion is not a simple multiplication (or
division) by a single factor. If you have started with mono co-ordinates and
divided them by 2 for the medium rez screen, you cannot always access the
right spot since sometimes there is a remiander of 1/2. I usually have to
establish up to 4 more variables that equal 1,2,3 and 4 for the color systems
and all equal 0 for the mono system, then I add these factors in where fine
tunning is required.

And your right RHF, anything less than text size 4 on the medium rez screen is
garbage, so I try to avoid using 4's on the mono all together.

Eric
 ------------
Category 22,  Topic 3
Message 184       Wed Sep 04, 1991
RHFACTOR                     at 00:52 EDT

  Thanks E.DAWLEY,  for confirming some of my frustrations regarding multi-
ple rez writting.   And it's not as simple rto write two separate programs.
Especially if one does not have access to both systems to verify screen
layouts, NOR color. (which coming from the land of MONO drove me crazy!! I
believe I had better screen color commands and CONTROL with a C-64 than I
found I could do with a vastly better ST)  of course I only had time to
quickly experiment with color stuff, hope to check it out again later.

   I do use one of the color EMULATORS,  but even the latest version I can
find is still tempermental, ususally giving me the temper!

SOMEBODY SOMEWHERE please develope some time of coordinator between the MONO
and MED REZ mode.

  I remember that BILL over at ATARI mentioned that he was going to upload
some commented code for his all rez screen scrolling routines.... WHERE ARE
YOU BILL.....  WE NEED YOU !!!
                                              RHFactor
 ------------
Category 22,  Topic 3
Message 185       Wed Sep 04, 1991
NIRANDRA                     at 01:46 EDT

IS there an emulator for users with monochrome monitors to allow them to run
color programs? I mean one besides the one that requires a 200K screen cache.
 ------------
Category 22,  Topic 3
Message 186       Wed Sep 04, 1991
J.SIEBEN [J.SIEBEN]          at 21:09 EDT

Hi all,

I got a problem using OBJC_EDIT and/or FORM_KEYBD.  From the explainations in
the manual I am to understand these routines allow for editing individual
objects.  I would like to be able to do this. Is my understanding correct?
What I am trying to do is edit an item out of 30 and validate the input before
going to the next object. FORM_DO is not what I want to do.  What's the best
way to go about this?  If OBJC_EDIT and/or FORM_KEYBD is the way to go I would
like an example as I am having no luck with it now.

Thanks

 ------------
Category 22,  Topic 3
Message 187       Wed Sep 04, 1991
H.SARBER [RANGERST]          at 23:29 EDT

     I bought my system with a color monitor.  I use a Mono emulator to test
my programs in mono.  It's a little fuzzy, but it works.  If you start your
program in color then all you have to do is multiply by 2 for the resolution
factor for mono.  That way you don't have to worry about the remainder problem
when you do it the other way around.
     As a matter of fact I usually imbed my resource files into my programs.
I use a filter program I wrote to convert the listed resource file to run in
both color and mono.  I actually have two filter programs.  One converts the
resource file to med/hi rez and one converts the resource file to low/med/hi
rez.  The first I just add a 'yf%=xbios(2)' to adjust the 'y' coordinates.
The other I have to do a little more for, but it's easier than making 2 or 3
separate resource files.  One for each resolution.

Harry

 ------------
Category 22,  Topic 3
Message 188       Thu Sep 05, 1991
ELROD                        at 20:43 EDT

 A friend of mine is haveing some trouble. He needs a fast way to do some
graphic calls. The following is a message from him telling his problems. Any
help will be welcome.

                  Thanks

Quick Graphics!                 9-5-91 ===============
     Programmers!  I need your help!
     This is what I need... Quick Graphics!  I am writing a game that
     needs a fast graphics update each time the player moves.
     My method works, but is noticeably slow.  It is, after all, written
     in GFA Basic.  Do not get me wrong... GFA is a fast basic, but not
     fast enough for me in this application!  I need your help to write
     this routine in Assembler or C. My Routine... =============
     Right now I am using a loop to draw the graphics.  The graphics
     screen is a 11 by 7 map, for a total of 77 graphic "icons".  I have
     an array called ICON$() that stores icon images.  These images were
     BSAVEd to disk, and are loaded back into my GFA and stored with the
     INLINE command.  This way the graphics are saved within my code.
     Now, the 1st line is read in.  There are a total of 11 characters.
     After that, the 1st character in that line is read.  I take the
     ASCii value of that character, and that value is the icon I put on
     the screen (ie: Put x,y,ICON$(value) ).  Then the next character in
     line 1 is read, and so on.  By the time we are done, we have placed
     77 "icons" on the screen to form a map.
     Here is my loop code:
     ###################################################################
          Icon$(1)=land$           !This is a graphic of some land
          Icon$(2)=water$          !This is a graphic of some water
            .
            .
          Icon$(255)=whatever$     !Each graphic is 17 wide by 19 high
                                   !(Notice the offsets below in the PUT
                                   ! statement)
          Height%=7
          Width%=11
          For Lines|=1 To Height%
            Map_line$=Mid$(Map$(By|),X%,Width%)
            For Col|=1 To Width%
              Value%=Asc(Mid$(Map_line$,Col|,1))
              Put 8+((Col|-1)*17),8+((Lines|-1)*19),Icon$(Value%)
            Next Col|
            Inc By|
          Next Lines|
     ###################################################################
     Now, this works ok, but I would love for it to be faster.  I am
     seeking a routine written is Assembler or C.  I know either would
     be much faster.
     The variables to be passed would be the Height%, Width%, X%,
     the location of the map data in Map$(), and the icon data in
     Icon$().
     This is basically the deal (no pun intended).  I do not know
     how easy or how hard this task will be, but I do challenge you if
     you program in Assembly or C (or GFA Basic for that matter- if you
     have a better way!). Let Me Know... ==============
     If you can help, please write -or- call me.  I would be most
     gracious!
                                Dave Stelljes
                              1404 Bragg Avenue
                            High Point, NC 27265
                                [phone]

 ------------
Category 22,  Topic 3
Message 189       Thu Sep 05, 1991
ELROD                        at 20:47 EDT

  It's me again, sorry about the formating of the message, but that was the he
sent it to me and I forgot to set the correct format. ;)

 ------------
Category 22,  Topic 3
Message 190       Fri Sep 06, 1991
RHFACTOR                     at 02:10 EDT

I don't know if 'C' can do faster graphics than GFA,  but assembler can remove
all doubts.
   I picked up the new book on assembly language programming for GFA,  but I
do not have the new GFA ASSEMBLER with it's book (although that looks very
tempting)  ESPECIALLY since the word on A-LINE graphic !!!  would be nice if
we could get a set of ML routines to tie into GFA to replace all the A-line
calls.   How 'bout it !!!???
                                                   RHFactor
 ------------
Category 22,  Topic 3
Message 191       Fri Sep 06, 1991
CBARRON                      at 02:37 EDT

ELROD - You say each character is 17 wide. Why 17?? If you mean pixels then I
suggests 16 wide characters as this will probably reduce the time for your
basic code to work by a large amount. 16 is a magic # since 16 bits can be
transferred with one instruction and no bit twidling. 17 bits guarantees that
only the first 16 bits can be stored without masking operations.  Try a sample
with 16 pixel wide characters and see if it makes a big difference.

 ------------
Category 22,  Topic 3
Message 192       Fri Sep 06, 1991
E.DAWLEY1                    at 20:10 EDT

Making the Icons 16 pixels wide instead of 17 would definately speed up the
drawing. To make full use of the new 16 pixels wide sizes, you should also
draw them on a word boundary (IE at an x co-ordiante evenly divisible by 16).
If you make both of these changes you could see your drawing time cut in half
or eevn more.

If thats not enough, you may want to consider not redrawing the whole map
unless its absolutely necessary. Im guessing, but say a player moves north by
one square, then you could shift the lower 6 lines down with one BMOVE or
RC_COPY and then just redraw the top line. (If thats what your program does)

Re FORM_KEYBD and OBJC_EDIT, I never could get these to work, and the manual
doesnt give any clues. (Other than FORM_KEYBD is a sub-routine of FORM_DO). If
no one can help you figure this out I have one other solution for you. Put
your FORM_DO loop inside of another DO..LOOP UNTIL error!=FALSE. Then when an
exit button is selected check the fields one by one for allowable input and
set error!=TRUE if one is found that isnt correct (and pop up an alert box
indicating the error). If all strings are acceptable, set error!=FALSE.

If you try to create some code that will duplicate FORM_DO, your bound to be
hitting that reset button alot. The above theory is how I handle dialogs where
I will not let the user exit until the input is acceptable.

Eric
 ------------
Category 22,  Topic 3
Message 193       Sat Sep 07, 1991
J.EIDSVOOG1 [CodeHead]       at 09:37 EDT

Folks,

If you want your GFA programs to work in any resolution, please do not use
Getrez to determine your factors for multiplying, etc.  There are already some
large screen monitors that use rez 0 or 1 with completely different screen
sizes.  You can get all the information you need from the line-A variables.

 character_height=CARD{L~A-46}
 vertical_res=CARD{L~A-4}
 nlines=CARD{L~A-4}/character_height   ! number of lines of text
 horizontal_res=CARD{L~A-12}
 bytes_per_scan_line=CARD{L~A+2}

Or you can get the character width and height from graf_handle:

 ~GRAF_HANDLE(wchar,ychar,wbox,hbox)

These values will be correct in any resolution, on any ST/TT.  And there's a
lot more variables that you can if you look in the table of line-A variables.
Relying on Getrez will only hinder the usefulness of your program for users of
different resolutions.

(Yes, I know that Atari told us not to use line-A but they have yet to
complete the discussion as to exactly which line-A "things" will not work.  I
believe that the important variables will always remain intact, and you will
be much closer to complete resolution independence than by using Getrez.)

RHFactor,

Regarding a set of assembly routines to replace the line-A calls, it wouldn't
make much sense.  The line-A calls are already assembly routines which are
quite effecient.  While it might be possible to get 5-10% speed improvement
over them, I doubt that much more could be obtained.

     John Eidsvoog  /|\  Member of the IAAD
 CodeHead Software  \|/  Serving the Atari Community
 ------------
Category 22,  Topic 3
Message 194       Sat Sep 07, 1991
E.SLICK [Eric]               at 10:38 EDT

  Also, using BITBLT would speed things up noticeably. Between 16 pixels wide
and this command he should get at least a doubling of speed.

Eric S.
 ------------
Category 22,  Topic 3
Message 195       Sat Sep 07, 1991
CBARRON                      at 21:49 EDT

 Does not the follow 'pseudo' gfa code do the trick without using line A.
Seem so to me. I could be wrong but I don't see much of a speed loss of
calling this procedure ONCE and using the results later as needed.  I'd advise
staying away from line A.
 procedure
 get_screen_stuff(char_ht,vert_res,nlines,hor_res,bytes_scan)
 local handle,wc,hc,wb,hb,x,y,w,h,ext&(57)
        rem since this only enquires the vdi workstation using aes's
        rem handle should be ok
        rem if we were going to do anything with it a virtual
        rem workstation probably is needed.
        handle=graf_handle( wc,hc,wb,hb): rem aes vdi handle
        char_ht=hb                      : rem char ht = box ht
        ~vq_extnd(handle,9,ext&())      : rem get size of screen
        vert_res=ext&(0)
        hor_res=ext&(1)
        nlines=hor_res/char_ht          : rem nlines is total/lines of one
        ~vq_extnd(handle,1,ext&())      : rem  enquire for # of planes
        nplanes=ext&(4)
        bytes_per_scan=hor_res*nplanes/8: rem calc bytes per scan line
 end procedure



 ------------
Category 22,  Topic 3
Message 196       Sun Sep 08, 1991
RHFACTOR                     at 01:56 EDT

Hi John Eidsvoog,
    Thanks for generating some response on the REZ and other handy stuff.
  I know I hate to bring up the LINE-A stuff.  I was figuring that 'certain'
graphics calls like LINES and BOXES might get the ML treatment.
   Not being a 'DEVELOPER' member has put us in the 'we told you not to use
them, so there'  catagory,  with really no idea as to what alternative to
follow.   When I read thru some of the scarce lit,  I thought I have seen
commands or system calls that in some way access Line-A functions , even
though they are not specifically mentioned in the L-A chapter. (please don't
hold me to an example).
   Can you tell us for today,  what machine out there WILL NOT handle a LINE-A
call.
    I have even seen an address location that checks to see where the LA's are
located....  what's the deal there,  I thought we were told that there are no
look-up tables.
    Please, I'm not trying to pretend like I know alot about this area.
basically I'm working with GFA,  trying to write fast, efficient code.

   Speaking of which,  has anyone heard of a 'code analyzer'  program for GFA,
that would give a graphic output of the code structure (flow-chart)??

                  Thanks,       RHFactor
 ------------
Category 22,  Topic 3
Message 197       Sun Sep 08, 1991
E.DAWLEY1                    at 12:03 EDT

Havent heard of any RHF, though would be nice. This would seem to be a good
project for GFA to write, along with a serious debugger. They could put
together a utilities package that would include these and other nice programs.

The debugger I am looking for would alow 'stepping' through the program in a
split window. The top half of the window would display the GFA code being
processed and the bottom half would have an area where you could typein
variables that you want to monitor. A function key could be used to bring up a
new screen where you could look at entries within an array.

As far as getrez is concerned, I took the advise along time ago not to use it.
In lieu of this, I have been using the WORK_OUT variables to determine the
vertical and horizontal resolution. Is this correct? These variables are
available if you open a VDI workstation (which GFA does automatically)
similiar to CBARRON's code right?

Eric
 ------------
Category 22,  Topic 3
Message 198       Mon Sep 09, 1991
CBARRON                      at 00:30 EDT

E.DAWLEY1 - As long as work_out is what is returned by the 'open virtual
workstation' already done by gfa the values of the work_out area include the
max x pixel coordinate and the max y pixel coordinate of the device.  That is
what atari wants people to use the very verisatile device independent
approach.  To get the # of bit planes an extended equiry is needed as I have
shown.
 ------------
Category 22,  Topic 3
Message 199       Mon Sep 09, 1991
J.EIDSVOOG1 [CodeHead]       at 02:31 EDT

Regarding an address location and lookup tables, that's exactly what the line-
A variables are.  The expression x%=CARD{L~A+2} will fetch a word value from
two byte into the line-A table.  This address will vary from TOS to TOS.  The
equivalent machine language routine would be:

     dc.w    $A000      ; This puts the line-A address in A0
     move.w  2(A0),x

Although, we've failed to get any concrete answer from the Atari officials,
there are certain line-A variables that will always be valid (such as
horizontal and vertical resolutions and who-knows what else) in my opinion.
As for the line-A routines, it might be better to steer clear of them if you
want your software to work on future machines.  Up until now though, line-A
seems to work on all existing resolutions with one exception.

One of the definite limitations of line-A is caused by the variables COLBIT0-3
(line-A + 24 through 31).  Here there are four words, one for each of four
color planes.  Problems will arise (although so far I have yet to encounter
any) in TT-low res, which has 8 planes, and any other resolution greater than
four planes.

We've been told to use the VDI, so it's still best to get this information
from the VDI open-workstation.  Atari guarantees that anything written using
the VDI will work on future machines, no matter what kind of fancy video they
might come up with (ve haff herdt rumors).

     John Eidsvoog  /|\  Member of the IAAD
 CodeHead Software  \|/  Serving the Atari Community
 ------------
Category 22,  Topic 3
Message 200       Mon Sep 09, 1991
P.STONE [Xorcist]            at 03:12 EDT

Well,


..... although I changed my Degas picture loading to accomodate BGET instead
of a BLOAD, I still am having strange crashes and no one has said a thing
about the X=FRE(0) calls that I inquired about...


WELL!

After hours of testing, X=FRE(0) has THE OPPOSITE EFFECT that it did on the
Apple computer... IT CRASHES THE ATARI!

3 Bombs...

Any ideas why?

How else can one obtain the amount of MEM free 'safely'... wear a BIT COMDOM?

<X>

 ------------
Category 22,  Topic 3
Message 201       Mon Sep 09, 1991
RHFACTOR                     at 03:53 EDT

Doesn't a   PRINT FRE(x)  do the trick  ???

RHFactor
 ------------
Category 22,  Topic 3
Message 202       Mon Sep 09, 1991
J.EIDSVOOG1 [CodeHead]       at 16:08 EDT

Xorcist,

If X=FRE(0) is crashing your computer, then you've got some strange stuff
installed.  I'd advise removing your resident programs and accessories and
trying again.  It shouldn't be crashing.

John
 ------------
Category 22,  Topic 3
Message 203       Mon Sep 09, 1991
D.A.BRUMLEVE [kidprgs]       at 18:49 EDT

 I haven't had any trouble with free%=FRE(0)...I use it in every redundant
 loop and have since version 1.x of GFA.  I'd look elsewhere in the code
 if you continue to have trouble even on a cold-booted machine.
 ------------
Category 22,  Topic 3
Message 204       Tue Sep 10, 1991
P.STONE [Xorcist]            at 01:08 EDT

Hmmm... I have a mouse accellorator (the one that comes with Dr. T's) as well
as the Dr. T's new GEM file handling interceptor...

I really have nothing strange going on but I will try a cold boot...

When I removed the fre(0)'s, all has gone well.

It's strange, but it has something to do with loading Degas pictures, scanning
and getting input from INP(3) (MIDI), as well as sending MIDI, and then doing
a simple PRINT FRE(0)...

Even with DA's, a FRE(0) should work...

<X>

 ------------
Category 22,  Topic 3
Message 205       Thu Sep 12, 1991
E.SLICK [Eric]               at 22:48 EDT

  Does anyone have a short solution to the following?

Determine n number of x/y coordinates around the screen for any given radius

For example:

I want to determine 7 equidistant x,y coordinates around the perimeter of a
circle with a radius of 30.

Thanks,

Eric S.
 ------------
Category 22,  Topic 3
Message 206       Fri Sep 13, 1991
CBARRON                      at 02:05 EDT

  tpi=3.1415928*2:rem two *pi
  for i=0 to 6
        theta=tpi*i/7
        x(i)=r*cos(theta)
        y(i)=r*sin(theta)
  next i
  for graphics i think the is a quick sine and cosine using table lookup and
less accuracy. but the above pairs x(i),y(i) are a solution.  Trig identities
can reduce the computation.

 ------------
Category 22,  Topic 3
Message 207       Fri Sep 13, 1991
PRINCETON-U                  at 20:38 EDT

I have a question about the proper way to execute TSR's from a GFA program
using EXEC. What I have been doing to run external programs is using

RESERVE -(FRE(0)-32768) EXEC 0,filename$,cmd$,env$ RESERVE

But when using that to run a TSR, the TSR runs, but I get a ERROR WHILE
RESERVE upon returning to my GFA program. Can someone help?
 ------------
Category 22,  Topic 3
Message 208       Sat Sep 14, 1991
E.DAWLEY1                    at 13:15 EDT

As Ive mentioned before, FRE(0) will always return 16384 when your program is
frist run under GFA. Now if you changed your RESERVE command to  -
(FRE(0)+32768) it makes more senese. You might check how much is Free after
you do your version of the reserve command. Since by your formula you are
reserving a -(-16384), im not sure what GFA is doing....maybe nothing.

Eric
 ------------
Category 22,  Topic 3
Message 209       Sat Sep 14, 1991
E.SLICK [Eric]               at 23:30 EDT

CBARRON,

Thanks for the routine. I hate to admit it but my math is pretty thin beyond
percentages. :(

Eric S.
 ------------
Category 22,  Topic 3
Message 210       Sun Sep 15, 1991
D.FEENEY                     at 11:12 EDT

I am beginning to work with random access files and I have created a need to
do something beyond the scope of the manual. I have created a file consisting
of several records, each with several fields.  What I would like to do is to
go to a record and read only one field and then later replace that field with
a new value. Page 177 of the 3.5 manual isn't any help.  Any ideas?   Thanks
 ------------
Category 22,  Topic 3
Message 211       Sun Sep 15, 1991
J.NESS [Jim]                 at 17:24 EDT

D.FEENEY -

If page 177 of the manual is no help, how about pages 178 and 179, which show
examples?

You have to open a file in random access mode, telling GFA how long each
record is, in bytes.

Then, you use one or more FIELD commands to break each record into data
fields, or variables.

Once GFA knows how long each record is, and what variables exist within each
record, you just have to read in a record, and the variables automatically are
filled with data from that record.

You can store the data from the field you need into another variable, if
necessary.  Later, you can put that variable back into the field variable, and
store the record back into the file.

In "pidgeon," you:

 OPEN "r"             [open the file]
 FIELD                [declare the various fields within each record]
 GET                  [load a record from disk, filling your variables]
 this=that            [store a copy of your variable]
 stuff
 stuff
 stuff
 that=this            [put your value back into your variable]
 PUT                  [store to disk at appropriate location]


If you need more detail, let me know, but this is the basic (pun intended)
outline of what you have to do.

                                  -JN

 ------------
Category 22,  Topic 3
Message 212       Mon Sep 16, 1991
PRINCETON-U                  at 19:17 EDT

E.DAWLEY1, MALLOC(-1) returns 16384, not FRE(0). And besides, it's not the
amount of memory I'm reserving that's causing the problem. The TSR programs
ARE executing... it's the RESERVE by itself, which is the only way that I know
to return the RESERVE'ed memory that is causing the problem. All NON-TSR
programs execute and terminate and the memory that was RESERVED before the
EXEC call is returned. No problems. It's only when the program being EXEC'ed
is a TSR. THEN I get an ERROR WHILE RESERVE after the TSR has terminated.
 ------------
Category 22,  Topic 3
Message 213       Tue Sep 17, 1991
A.WESTON [Alan]              at 20:03 EDT


 ------------
Category 22,  Topic 3
Message 214       Wed Sep 18, 1991
J.KLEISER                    at 01:30 EDT

 Dear Nathan:
 *h
 I hope someone can help with this:
 I have a problem that I don't remember seeing discussed here.  I have an
 old GFA Basic 2.0 program that I'm trying to compile in GFA 3.5e.  I've
 loaded it as a .LST file into the GFA 3.5e interpreter, where it runs
 fine.  I've saved it as, say, TRYIT.GFA, the GFA 3.5 tokenized Basic
 file.  Then I compiled it (without any options; and no errors shown):
 TRYIT.PRG won't run.  I get a "Pointer (*x) Error" (Error #64).  It
 seems connected with a programming structure from GFA 2.0 with which I'm
 not familiar:
 ..
 ...
 @solvitnow(*aa)
 ..
 ...
 PROCEDURE solvitnow(a%)
 v=..
 ss=..
 ...
 *tt=t%     <== HERE'S WHERE GFA 3.5 CHOKES...
 RETURN

 I don't see what this structure is supposed to be doing, though I'm sure
 it has something to do with the address of the variable tt.  I want to
 replace it with a GFA 3.5 structure, but the books/manuals with 3.5
 don't mention this older structure.

 Anyone know what this is and what simple procedure structure would
 replace it? (Running speed is not important here.)

 -=Jim=-
 ------------
Category 22,  Topic 3
Message 215       Wed Sep 18, 1991
H.SARBER [RANGERST]          at 21:12 EDT

     Can someone give me the screen sizes from 520ST to TT in pixels?  I know
what low, med., and high rez are for the ST, but the newer resolutions are
unknown.  I'm taking a suggestion from J.SIEBEN and attempting to write a flow
charter for the ST.  I would like it to be compatible with ALL ST's and not
just what I have (which is a 2.5 meg mutant 520ST)

     Secondly, has anyone managed to EXEC a program from an accessory?  I've
allocated as much as 1/2 meg for the program to reside in and gotten it to
work, but only ONCE.  The second time, boom goes the bombs.  I haven't seen
this many bombs since I first started programming.  Sheesh!

     Harry

 ------------
Category 22,  Topic 3
Message 216       Wed Sep 18, 1991
T2.LTD [Rick Taylor]         at 22:13 EDT

 Jim,

   Your hunch is right -- the asterisk is used by GFA Basic (and other
 languages such as C) as a pointer symbol.  However, the line of code
 that "chokes" GFA 3.5 would do the same to any previous version, I'm
 sure.  The "*tt = t%" should be reversed to read "t% = *tt" in order
 to compile (or even run).

   If you want to change a variable that is sent to a procedure as a
 parameter, a clean way to do this in the 3.x series is:

   my_age% = 35
   @fountain_of_youth (my_age%)      ! Roll back the years...
   PRINT my_number%                  ! Voila! I'm 29 again.
   '
   PROCEDURE fountain_of_youth (VAR n%)
     n% = 29
   RETURN

   When you type "VAR" in the parameter list of a procedure, all parms
 that follow that word can be changed within the procedure (that is
 they will return to the calling code with the new value).  It's a lot
 easier than using the asterisk method.
 --Rick
 ------------
Category 22,  Topic 3
Message 217       Wed Sep 18, 1991
J.SIEBEN [J.SIEBEN]          at 23:05 EDT

Harry,

Glad to see your going with it...full speed ahead right<grin>

 ------------
Category 22,  Topic 3
Message 218       Thu Sep 19, 1991
J.EIDSVOOG1 [CodeHead]       at 10:43 EDT

Harry,

As I recommended only last week in this topic, and others have mentioned
numerous times, please do not make your program resolution specific.  A list
of screen sizes from 520ST to TT will restrict your program's use to just
those resolutions.  Why limit yourself and others?

Open a workstation and get the screen size from the information returned by
GEM, or get the screen size from line_a...please!

John
 ------------
Category 22,  Topic 3
Message 219       Thu Sep 19, 1991
G.T.GRAY [Gary Gray]         at 19:16 EDT

Please everybody write VDI compliant code. There are so many video hardware
thingees coming to market, many replace the standard VDI resolution with their
own drivers, if you want your software to work at 1024x768 and 256 colors you
gotta follow the rules. You cant assume anything about what video is ruuning
anymore. The Germans, the Americans, the Canadians, and the Brits all got
video board coming at us with more different display modes than you can shake
a stick at. Open a workstation and get the info.

From somebody struggling with a high rez card

Thanks Gary Gray Megabyte Plus
 ------------
Category 22,  Topic 3
Message 220       Thu Sep 19, 1991
J.H.CARROLL [Jon]            at 23:04 EDT

I've got a couple of questions before I upgrade my GFA BASIC from 3.07 to 3.5
or 3.5.

Will 3.5 run in resolutions greater than 640X400-- the interpreter I mean.
Will V3.6 (That's the TT one right?) run on an ST.  I'd imagine V3.6 has no
trouble running in expanded resolutions right?

Jon

 ------------
Category 22,  Topic 3
Message 221       Thu Sep 19, 1991
H.SARBER [RANGERST]          at 23:23 EDT

     John,

     I took your recommendations from previous messages and I already
incorporate them into my present programs.  The reason I ask about the present
resolutions is to get a baseline to go by.  The flow chart program WILL be
upwards compatible to other resolutions.  Since I only have a 520 to go by I'd
like to know what others are available to determine how monumental this
program might develope into.

     Harry

 ------------
Category 22,  Topic 3
Message 222       Fri Sep 20, 1991
J.NESS [Jim]                 at 19:38 EDT

Harry -

As I recall, GEM can handle resolutions up to 32k x 32k pixels.  If you want
to be able to handle ANYTHING, there's your target.  Of course, a screen rez
that high would require over a meg of video mem, just for monochrome.  I don't
even want to think how much memory it would require for true color.

                                    -JN

 ------------
Category 22,  Topic 3
Message 223       Sat Sep 21, 1991
DOUG.W                       at 00:02 EDT

"Over a meg of video mem"??  Try 128 MB!!

--Doug

 ------------
Category 22,  Topic 3
Message 224       Sat Sep 21, 1991
J.NESS [Jim]                 at 12:54 EDT

Doug -

You're right, 128mb.  But, jeez, it IS over a meg, isn't it?

Heh heh.

                                 -JN

 ------------
Category 22,  Topic 3
Message 225       Sat Sep 21, 1991
E.SLICK [Eric]               at 18:38 EDT

Princeton-U

Reading your post, I remembered something that might help. Make sure you are
freeing up memory in the correct order. I'm not sure which comes before which
but if you are using MFREE and RESERVE they should be done in opposite order
from how when MALLOC and RESERVE -##### were excecuted. Otherwise you get an
error when you try to free up the reserve memory.

Eric S.
 ------------
Category 22,  Topic 3
Message 226       Sun Sep 22, 1991
PRINCETON-U                  at 13:22 EDT

 I have no other RESERVE or MALLOC's in my program. And as I said, the
 memory IS being reserved... and the TSR IS being executed and the TSR DOES
 terminate... it's when control is returned to my program and reaches the
 this line...

 RESERVE

 that I get ERRROR WHILE RESERVE. Again, this only happens when I execute
 a program that reserves a portion of memory and KEEPS it. Non-TSR programs
 execute, terminal and return control to my program and I have NO problems
 whatsoever. I even have the same amount of free memory as I had BEFORE
 I ran the program. But when I run a TSR I guess RESERVE is trying to
 return the same amount of memory that I reserved, and since the TSR
 KEPT some of that memory, I'm getting the ERROR WHILE RESERVE. But I
 don't know of any way to return ONLY the memory that is available. Can
 ANYONE out there help??
 ------------
Category 22,  Topic 3
Message 227       Sun Sep 22, 1991
J.EIDSVOOG1 [CodeHead]       at 14:40 EDT

Harry,

I'm glad to hear that you are aiming at res-independent operation. As a reward
<grin>, and for others that are interested, here's a list of the ST/TT
resolutions (they're listed on page 29 of the CodeKeys manual for those that
have it):

 Screen size 32,000:
  res 0 - ST Low  320x200 - 4 planes
  res 1 - ST Med  640x200 - 2 planes
  res 2 - ST High 640x400 - 1 plane

 Screen size 153,600:
  res 4 - TT Med  640x480 - 4 planes
  res 6 - TT High 1280x960- 1 plane
  res 7 - TT Low  320x480 - 8 planes

Note that TT Low has the highest Getrez number.  It's also a very strange
looking resolution, with a greater horizontal resolution than vertical.

Once again, folks, use these hard numbers only for your own reference (don't
let your program know they exist <grin>).  There may actually be occasion to
use this info, though.  For instance, in CodeKeys and MultiDesk Deluxe we use
the res number to determine which default file to load, thus allowing the user
to have different setups for different resolutions.  But we also look for a
default filename of CODEBIG or MULTIBIG if the resolution is larger than
640x480 and it's not TT High.

     John Eidsvoog  /|\  Member of the IAAD
 CodeHead Software  \|/  Serving the Atari Community
 ------------
Category 22,  Topic 3
Message 228       Mon Sep 23, 1991
H.SARBER [RANGERST]          at 19:56 EDT

     John,
     Thanks for the numbers.  I wasn't aware that a TT gobbles up so much
memory for a screen.  Since I don't have a TT I didn't even think about it.
     I'm still working on the prelims for the flow charter.  Since I'm also
trying to remodel my bathroom it may be some time before a beta version shows
up.

     New question.  EXEC has the ability to load a program without running it.
How do you get the program to run after you load it?

     Harry

 ------------
Category 22,  Topic 3
Message 229       Mon Sep 23, 1991
J.EIDSVOOG1 [CodeHead]       at 21:00 EDT

Harry,

GFA's documentation of the EXEC call seems a bit skimpy.  I assume that EXEC
handles thing exactly the same as GEMDOS's P_exec but I haven't tested it.
The following information is definitely valid for the P_exec call, though.

P_exec "load only" (mode 3) creates a base page, loads and relocates the
program, and returns the address of the basepage (in D0).  Mode 4 is "execute
only".  In this mode the command line pointer should point to the basepage
address that you wish to execute.  Mode 5 is "create basepage".  It is
possible to use mode 5 to create a basepage, insert the address of some
executable code into the "text segment address" (8 bytes into the basepage),
and use mode 4 to execute it.  Here are some examples (untested off the top of
my head):

 bp%=EXEC(3,"ARC.TTP","x TEST.ARC *.*","")  ! load ARC.TTP
 ~EXEC(4,"DOESN'T_MATTER",bp%,"")           ! execute it

 BLOAD "MODULE.OVL",buf%        ! load a piece of pc-relative code
                                ! into a predetermined memory buffer
 bp%=EXEC(5,"DUMMY","","")      ! create basepage
 LONG{bp%+8}=buf%               ! insert address of code
 ~EXEC(4,"YO_CATS",bp%,"")      ! just go

Remember that code executed this way must terminate with a P_term.

John
 ------------
Category 22,  Topic 3
Message 230       Mon Sep 23, 1991
R.WATSON15 [Wayne Watson]    at 21:47 EDT

This is just a thought but, when your RESERVE memory in GFA (and possibly
others), GFA wants all that memory free again when you try to unreserve it.
When you try to run a TSR program, it will stay in memory (Terminate and Stay
Resident) thus not freeing up memory that was originally RESERVEd. You can
duplicate this (have the same results) if you:

  RESERVE -10240
  A%=MALLOC(4096)
  RESERVE

  GFA should respond with the same alert box. TSRs are normally ran at bootup.
GFA wants all the memory you reserved back when you try to un-reserve it.

 ------------
Category 22,  Topic 3
Message 231       Tue Sep 24, 1991
B.BILLJONES2 [Bill Jones]    at 06:03 EDT

  Hi,

        I'm writing a program that I want to be installed as an application.
I'm looking at the BASEPAGE to determine the file I want to manipulate, and
that works fine.  I have a configuration file that will not load into my
program after I call it as an application. This is because GEM has changed my
default directory, to the directory the file I want to work on resides.  My
resource file, however, loads in just fine, and I use IF EXIST("PROGRAM.RSC")
to find it.

        Is there a way to around this dilemma?  Would the directory of my
program exist somewhere in the basepage?

Thanks!

 ------------
Category 22,  Topic 3
Message 232       Tue Sep 24, 1991
J.NESS [Jim]                 at 19:06 EDT

Bill -

There are probably a couple of ways to get this info.  One is to check the DTA
of the parent's BASEPAGE.  The parent would be the desktop, and its DTA should
contain the filename/path of the program it just executed - yours.

Another novel way would be to use the SHEL_GET() command, which returns the
entire contents of DESKTOP.INF, as it exists in ram. This, of course, contains
the installed application info you need in one of its lines, and you should be
able to decipher your home path from that.

One thing I found interesting about reading out this buffer is that it gives
you the CURRENT condition of the desktop, rather than the stored condition.
So, it shows you what directory windows are currently open, what the desktop
colors are, etc.  And, you can change these within your program, with
SHEL_PUT().

                                  -JN
 ------------
Category 22,  Topic 3
Message 233       Wed Sep 25, 1991
J.EIDSVOOG1 [CodeHead]       at 05:13 EDT

Bill,

In TOS 1.4 and later, your command line will contain the full path. With
earlier TOSes, there's nothing you can do other than making sure the document
is in the same directory as the program, or using something that fixes this
problem like HotWire, which will add the path for you if the program is
installed in your HotWire menu (even if you double-click from the desktop).

John
 ------------
Category 22,  Topic 3
Message 234       Sun Sep 29, 1991
M.ALLEN16 [Michael]          (Forwarded)

O.k.  I have been experiencing a problem with GFA Basic ver 3.5E.  I have a
1040ST with TOS 1.4.  This bug is only active in a compiled program.  If you
try and print a string longer than 80 characters then the string is never
wrapped onto the next line rather jammed into the wall.  This also happens
when you use the FORM INPUT statement.  The form input statement when used
with the AS parameter and the string loaded to more than 80 characters.  I
have contacted GFA in MASS.  to report the problem and they said they would
pass it on.  Well, whatever that means...  The only way to fix the problem
that I have found is to run Neodesk (2.0).  The problem dissappears even after
you exit NeoDesk.  I thought maybe I had a TOS bug but I don't think so.  Here
is something that is easy to type in and will show the bug, that is if the bug
is not another TOS 1.4 bug.

CLS
 a$=STRING$(255,"F")  'Assign String
 PRINT a$             'Print string
 ~INP(2)              'Wait for keypress

Any help I could get would be appreciated.  Thanks Michael Allen
                                                   (M.ALLEN16)
 ------------
Category 22,  Topic 3
Message 235       Sun Sep 29, 1991
J.NESS [Jim]                 at 21:40 EDT

Michael -

Try adding:

PRINT chr$(27);chr$(118)

to your program, before you print anything else.  Those two characters make up
the VT52 "ESC v" command, which turns on the word wrap when printing to the
standard TOS screen.

I have not tested this, but I am fairly confident that it will do the trick.
It looks as though the default condition is "word wrap OFF," and that you need
to explicitely turn it on.

When a window has been displayed by GFA, some flag is set, and the PRINT
command changes to a GEM format, and will automatically word wrap.  The word
wrap and string print location are automatically controlled by underlying GFA
routines.

                                  -JN


 ------------
Category 22,  Topic 3
Message 236       Sun Sep 29, 1991
J.EIDSVOOG1 [CodeHead]       at 23:07 EDT

Michael,

I assume that your 80 character, no-wrap problem is with screen display.  It's
not a bug, it's a feature.  There are two VT-52 command strings which affect
the way characters are handled once the right edge of the screen is reached:

  Esc "v" - Wrap at end of line and scroll up if necessary
  Esc "w" - Overprint line end character with the next character

I would assume that when you run Neodesk it is configuring VT-52 with the Esc
"v" command and that's why it appears to fix your problem. To solve it in your
own code you can just add the line (before doing your printing):

 PRINT CHR$(27);"v";

There are many other useful VT-52 commands as well.  In my GFA manual, they're
on page 476.  Take a look.

     John Eidsvoog  /|\  Member of the IAAD
 CodeHead Software  \|/  Serving the Atari Community
 ------------
Category 22,  Topic 3
Message 237       Tue Oct 01, 1991
D.SEBERG [Ice Berg]          at 03:06 EDT

    I agree whole heartedly about the usefulness of the VT-52 commands, I use
them ALOT in most all of my programs.

    An alternate method of using the VT-52 commands is to use them in
conjunction with the OUT command.  The following lines of code are
functionally equivalent:

    PRINT CHR$(27);"v";
    OUT 2,27,118          ! Where 118 is the ascii value of "v"

    The code, to me, just seems to be a bit more organized when using the OUT
command.  It's just an alternative though, everything works the same.

         Dave


 ------------
Category 22,  Topic 3
Message 238       Tue Oct 01, 1991
B.BILLJONES2 [Bill Jones]    at 23:06 EDT

  A big thank you to Jim N. and John E. for giving me some sound ideas
cocerning Basepages and where to find some hidden directory info!

I'm in need of some wizzard assistance in a similar area.  I'm calling the
program as an installed application, looking at the basepage and all that.  It
works fine.  However, when I try to do directory search using FSFIRST() and
FSNEXT() starting at BASEPAGE 128, I find that it gets confused because of the
commandline being in there I guess.  I'm searching to see if there is a folder
present when I want to write one.  I'm using CHAR{BASEPAGE+149} AND 16 to see
if the folder in my search parameter is indeed there, and true. (printing the
BASEPAGE+158 to get a look at it if I want)

The short routine (straight out of the ANTIC manual... typos fixed) will not
work at all when calling the program as an installed application with command
line present.

Any suggestions?  Many thanks in advance.  Help in this area is invaluable,
and I'm just starting to actually "ask" questions instead of strickly reading
the base (though that's informative also).

Bill Jones


 ------------
Category 22,  Topic 3
Message 239       Wed Oct 02, 1991
J.EIDSVOOG1 [CodeHead]       at 10:04 EDT

Dave,

Yes, using OUT is another alternative.  Also, how about something like this:

 ! Init section
 no_wrap$=CHR$(27)+"v"

 ! Later
 PRINT no_wrap$;

You could define a number of the other VT-52 commands this way, too.

John
 ------------
Category 22,  Topic 3
Message 240       Wed Oct 02, 1991
J.EIDSVOOG1 [CodeHead]       at 11:36 EDT

Bill,

I'm not sure why GFA has always used the command line area in their examples
for Fsfirst/next.  Maybe it's bcause it's there and it's (seemingly)
available.  My suggestion is to just set your own DTA.  I know that I've used
"dta$=STRING$(44,0)" before, although this might be assuming that a string
will always start at an even address (if the DTA really requires this, I don't
know).  It might be safer to use "DIM dta%(11)".  This will create a long word
array.

After that, just set DTA to "V:dta$" or "V:dta%(0)".  You won't have any more
conflicts with your command line.

John
 ------------
Category 22,  Topic 3
Message 241       Wed Oct 02, 1991
B.BILLJONES2 [Bill Jones]    at 19:41 EDT

Atari-ST RoundTable Category 22,  Topic 3 Message 240       Wed Oct 02, 1991
J.EIDSVOOG1 [CodeHead]       at 11:36 EDT

Bill,


JE |After that, just set DTA to "V:dta$" or "V:dta%(0)".  You won't have any
JE |more conflicts with your command line.

John E

        Thanks again.  It never occurred to me you could do this.  It does
make sense actually "seeing" it before me.  While we're talking about the
BASEPAGE, when writing a program that accesses it should I be concerned how
other programs like HOTWIRE might possibly deal with it?  I know you are
supposed to be able to pass command lines to programs and such.

        Many thanks!

        Bill

 ------------
Category 22,  Topic 3
Message 243       Thu Oct 03, 1991
ELROD                        at 07:28 EDT

Recently I asked about making graphics in a GFA program faster. (See message
#188)

I have some more questions.  Someone mentioned using the BITBLT command of GFA
Basic instead of the screen GET & PUT, as it is faster.  This is great idea,
however, I can not figure out how to use the BITBLT command. The GFA manual
gives a small demo (page 359-361 in the 3.0 manual), but all I really need is
the equiv of:

     GET x,y,x2,y2,item$
     PUT x,y,item$

in using the BITBLT command.  Please let me know.

 ------------
Category 22,  Topic 3
Message 244       Thu Oct 03, 1991
D.SEBERG [Ice Berg]          at 23:49 EDT

    John,

    Yep!, that's another alternative and an especially good one if
readablility of the code is necessary.

         Dave


 ------------
Category 22,  Topic 3
Message 245       Fri Oct 04, 1991
J.EIDSVOOG1 [CodeHead]       at 02:09 EDT

Bill,

As long as your command line parsing is able to handle both full pathnames and
pathless filenames you needn't worry about any special handling for HotWire,
etc.  The correct way to do it is also the easiest way to do it.  The standard
thing for an installed application to do is load the file passed on the
command line. Shells will either pass a user defined command line or else the
filename of the document starting the application.  If you want to do more
complex things, you can create a command line syntax.  Otherwise you'll only
be concerned with a filename (or multiple filenames).  If you're trying to
open a file, don't bother doing any parsing.  Just use the name given to you,
short or long:

 f$=CHAR{BASEPAGE+129}
 IF f$<>""
   OPEN "I",#1,f$
   etc....
 ENDIF

As for HotWire's special handling, it involves adding the full path to the
command line on TOSes which did not provide it, and HotWire let's you choose
either method.

John
 ------------
Category 22,  Topic 3
Message 246       Sun Oct 06, 1991
JWC-OEO [Jon]                at 22:44 EDT

  Hello everyone,

I wonder if someone might be able to tell me if the location for turning the
key click on/off has changed in later versions of TOS (beyond v1.4).  SPOKE
&H484,BCLR(PEEK(&H484),0) as per the GFA BASIC 3 manual from Michtron turns
the key click off my MEGA 2/TOS 1.4... will it do the same on STE's and MEGA
STE's?

Also, does XBIOS 35 have the same effect on the key repeat and delay rates
with TOS>1.4 as it does with earlier versions?

Finally, I will be needing someone with a STE and/or a MEGA STE to do a quick
BETA test on a silly PD arcade game I am writing.  Let me know if you would be
interested.

Jon

 ------------
Category 22,  Topic 3
Message 247       Sun Oct 06, 1991
D.A.BRUMLEVE [kidprgs]       at 22:53 EDT

 Jon, I've tried the code on a 1040STe and it does indeed turn the
 keyclick off/on.  I have not tried it on a MegaSTe or TT; perhaps
 someone else could elaborate, but I suspect it would work fine.
 XBIOS(35...) does set the key repeat and delay rates on the 1040STe
 also.  Ask me when I feel better, and I'll be able to tell you if
 this stuff all works on the MegaSTe.  I just got a loaner from Atari
 in order to provide complete compatibility for Kidpublisher Professional,
 but I've been too sick to get much done with it yet.  I use both these
 routines in that program.
 ------------
Category 22,  Topic 3
Message 248       Mon Oct 07, 1991
T2.LTD [Rick Taylor]         at 09:42 EDT

Hope you get to feeling better soon, Dot!

--Rick
 ------------
Category 22,  Topic 3
Message 249       Mon Oct 07, 1991
J.EIDSVOOG1 [CodeHead]       at 12:47 EDT

Jon,

The variables on the $400 page have been documented by Atari since day one.  I
don't think they'll be changing them.  You should be able to rely on &484 on
all future versions of TOS.

Of course, they also documented line_A and have since retracted it and told us
not to use it.  Lately there's even a widespread believe that if a program is
not "VDI-compliant", it is somehow programmed incorrectly.

So who knows?  Maybe someday down the road, people will be saying to you, "Oh,
are you still using that 400 page stuff?  No wonder your software crashes on
the new mind-link interface".  (Just kidding, I think you're safe <grin>).

John
 ------------