GEMini Atari

home *** CD-ROM | disk | FTP | other *** search

/ GEMini Atari / GEMini_Atari_CD-ROM_Walnut_Creek_December_1993.iso / files / program / gfabas09 / gfa_bas9.txt

Wrap

Text File | 1991-10-07 | 167.8 KB | 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 (916) 891 4040 Brian Robinson Fax (916) 891 5453 ------------ 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 (919)885-6629 ------------ 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 ------------