========================================================================= (C) 1993 by Atari Corporation, GEnie, and the Atari Roundtables. May be reprinted only with this notice intact. The Atari Roundtables on GEnie are *official* information services of Atari Corporation. To sign up for GEnie service, call (with modem) 800-638-8369. Upon connection type HHH (RETURN after that). Wait for the U#= prompt.Type XTX99437,GENIE and press [RETURN]. The system will prompt you for your information. ========================================================================== ************ Topic 3 Mon Feb 06, 1989 DARLAH [RT~SYSOP] (Forwarded) Sub: GFA Basic 3.n Questions and answers for GFA Basic. 200 message(s) total. ************ ------------ Category 22, Topic 3 Message 1 Sat Jun 19, 1993 M.SILVERSTE3 [SYNCHRON] at 01:11 EDT Can somebody explain how RESERVE works again. I've written a MIDI program which "Loads" a file via an EXEC call to LHA (LZH tool) to extract a 64 byte file from an LZH and BLOAD it into a 64 byte buffer that I've MALLOCed. Once it goes into my allocated space, I delete the extracted file. The problem is in order to get it to work with Neodesk or other TSRs, I have to RESERVE - 400000 bytes, do the EXEC, and do 1 more RESERVE as explained in the manual. I also should have at least 500K of memory free as well, else I'll get an error 61 which I think is an Error on Reserve. Why can't I reserve -100000 for LHA.TPP?? I can't believe it takes that much memory!! I have 2Megs TOS 1.4 and with all my DA's, + Neodesk, this is most annoying! I've never upgraded since I don't own an STe (using ver. 3.07) which also bombs (bus error) when trying to use GFA BASIC after 1 session (that's using the Interpreter and Compiler in 1 session). If somebody knows a better way of doing this, this would be greatly appreciated!! Be in Synch with the Synchron from Camarillo, CA!! Datestamp: Friday, June 18, 1993 Timestamp: 10:04:06 pm ------------ Category 22, Topic 3 Message 2 Sat Jun 19, 1993 V.VALENTI at 02:16 EDT I use RESERVE only when I am in GFA Basic. When compiled I remove the RESERVE command and use the $m compiler option. In GFA, you might want to RESERVE a positive number. Calculate how much memory your program requires to run. You do not have to include GFA code, becuse it is already subtracted by the computer. So if you only require 4k for the program RESERVE 4096. When you are done debugging the program delete the RESERVE 4096 and add $m4096 This is a compiler option that is similar to the RESERVE command. The main difference is that with RESERVE command, GFA consume all memory in the computer and THEN releases with the RESERVE. $m only allocates x bytes of memory from the beginning. Hope this helps. Vince ------------ Category 22, Topic 3 Message 3 Sat Jun 19, 1993 C.ROUNTREE2 [RoadKill] at 02:52 EDT I've heard of a program that converts GFA basic to C code. Any heard of this? Is it PD or Commerical? If so, how much and how do I get it? Thanks for your help. ------------ Category 22, Topic 3 Message 4 Sat Jun 19, 1993 REALM [Joey] at 03:54 EDT Randy, I think Wayne covered it pretty much.:-) I use XBIOS and VDI calls where ever possible. I'm trying to use the VDI functions for everything as they seem to work the best in all these resolutions. ------------ Category 22, Topic 3 Message 5 Sat Jun 19, 1993 R.WATSON15 [Wayne Watson] at 09:59 EDT Synchron, The RESERVE statement in GFA works like this. If you do a RESERVE -100000, you are RESERVing 100000 bytes for the program and the rest is returned to the system. If you do a RESERVE 100000, then you are RESERVing ALL of free RAM and returning 100000 bytes back to the system. My manual is backwards. When running a program from GFA, you have to give the called program enough memory to run under. It's more like running a subroutine in GFA. This is the method I use for my programs for my use as it ensures the program I am going to execute has enough memory to do what it needs to do. Stay away from doing a lot of RESERVEs and unRESERVEs. This will cause problems anywhere from lockups to crashes. Do one RESERVE at the beginning of your program and one unRESERVE at the end before your program exits. ------------ Category 22, Topic 3 Message 6 Sat Jun 19, 1993 R.WATSON15 [Wayne Watson] at 10:03 EDT Synchron, Also note that if you plan on using RESERVE xxx (positive value) and you are using TOS 2.05/2.06 (not sure about 3.0x), and you are going to do disk IO and/or executing external programs, you need to leave the system with about 150000 bytes or your programs will crash or lock up. ------------ Category 22, Topic 3 Message 7 Sat Jun 19, 1993 R.HOEKSTRA1 [RandyH] at 12:50 EDT Thanks Wayne, the work_out(0) and work_out(1) make sense for the resolution size in pixels, but what about the font information? Don't I need to know the height and width of the font or can this be assumed to be some given value. I need to know this for my calculations for bitblit and just to know where draw a given line of text on the screen. Do work_out(47) and work_out(48) do what I need? Right now I use small modifiers depending on what resolution I am in (ie I need to add, say, 2 pixels to the area being blitted if I am in ST high in order to grab the right amount screen to scroll the text up), but I would really like to get to something more generic (ie a formula which could be used in any resolution). I'm probably making this more complicated than it really is. Sure would be nice to have a Falcon so I just experiment and *SEE* it for myself :). Randy ------------ Category 22, Topic 3 Message 8 Sat Jun 19, 1993 R.WATSON15 [Wayne Watson] at 17:16 EDT RandyH, I am not sure about WORK_OUT(47) and (48). I have never used those. ------------ Category 22, Topic 3 Message 9 Tue Jun 22, 1993 HUTCH [FAIR-DINKUM] at 00:52 EDT Just a note of explanation and an apology (boy, I'm doing that a LOT lately)... due to a very limited response from my call for donations of GFA routines and functions, my proposed book 'The GFA BASIC Toolkit, Volume II" has been put on indefinite hold. The little input I did receive was very good and I thank those who sent it to me, but it's just not enough to warrant another book at this time. Thanks again and sorry for the cancellation of this project. -Hutch- @ Fair Dinkum Tech ------------ Category 22, Topic 3 Message 10 Tue Jun 22, 1993 R.WATSON15 [Wayne Watson] at 04:42 EDT Hutch, What type of routines were you looking for? ------------ Category 22, Topic 3 Message 11 Wed Jun 23, 1993 DMJ [dmj] at 01:28 EDT Yes, what sort of routines would you like? I've got a reasonable collection of GFA routines that I use myself, as well as a bunch of assembly routine I call from GFA. Graphics tricks, sound tricks, disk tricks... whatever. -dmj ------------ Category 22, Topic 3 Message 12 Wed Jun 23, 1993 HUTCH [FAIR-DINKUM] at 01:57 EDT Wayne -- I was in "collection" mode for any and all GFA routines, procedures, functions and even short utilities for the next edition of 'The GFA BASIC Toolkit.' Unfortunately, input was just insufficient to justify the work involved in bringing the book and collection of routines to press. Let's see what the Atari market does for the rest of the year and then maybe we'll try again. Cheers, -Hutch- @ Fair Dinkum Tech ------------ Category 22, Topic 3 Message 13 Wed Jun 23, 1993 HUTCH [FAIR-DINKUM] at 02:04 EDT DMJ -- The routines you mentioned are precisely the kind I was looking for, given they don't duplicate anything that was previously published in Volume I of the GFA Toolkit, of course. Geez... rags to riches around here. Tell you what, I've got the Kansas City AtariFest this weekend but after I return let me contemplate the possibility of sending out the "call" for GFA routines again. Maybe with a better response it would be viable. Thanks! -Hutch- @ Fair Dinkum Tech ------------ Category 22, Topic 3 Message 14 Wed Jun 23, 1993 R.HOEKSTRA1 [RandyH] at 23:47 EDT Well, WORK_OUT(47) and (48) are no good for font information. I get the same values regardless of what resolution I am in. So, for now I am just checking WORK_OUT(1) for resolution height and assuming that if it is less than 200 then the font height is 8 and if greater than 200 the font height is 16. This works for ST High, ST Med, and on the MonSter big screen emulator. It works, but it sure seems sloppy to me. Surely there's a better way. RandyH ------------ Category 22, Topic 3 Message 15 Thu Jun 24, 1993 M.SILVERSTE3 [SYNCHRON] at 01:27 EDT Vince, Wayne: Thanx for informing me about the uses and abuses of the RESERVE command. I have redone my program and just declare a $m50000 at the beginning (after experimentation). I guess what thru me off was that I thought a RESERVE/unRESERVE was REQUIRED when doing an EXEC which is what the manual tends to lead you to believe. The 50K I reserve for the compiler is fine for both my program and the program I'm calling (LHA.TTP) and a free mem DA reports 150K or so less memory than before running my program from the desktop. Whenever I executed a routine which used the RESERVE - 400000, EXEC, RESERVE - memory available was something like 37K free (within my program, of course). With no more RESERVES, my program doesn't bomb now at all! If memory is real low (Say, 100K or so at the time you run my program), the EXEC call to LHA.TTP may not work. But at least the program doesn't bomb. Thanx for the tips! ------------ Category 22, Topic 3 Message 16 Fri Jun 25, 1993 R.WATSON15 [Wayne Watson] at 18:02 EDT I had the same problem using $mxxxxx as I did with the RESERVE statement on the MSTE (TOS 2.05/2.06). I had to leave the system 150,000 bytes. I only tested this once and bomb city. It is much easier to figure out how much memory one has using the RESERVE command so that it works on TOS 2.0x. I just wished GFA would get an update out. This is getting to be a pain. That's one reason I am in the process of learning C and will turn towards C. Lattice C is very well supported for the Atari computers. I can't say that about GFA. ------------ Category 22, Topic 3 Message 17 Fri Jun 25, 1993 DMJ [dmj] at 21:14 EDT Memory handling in GFA using either the $m or RESERVE methods is always dicey. ReNameIt!, which runs as an accessory or program, has a $m200000 at the top (yes, 200K... or maybe it was 150. Anyway, it was a lot.) Anything less and it wouldn't run on a Mega STe. GFA's memory management needs a complete overhaul. We all hear rumors and sightings of a "new GFA"... but I don't believe a word of it until I have the product in hand. I for one could use a "fixed" GFA, but I still like it better than C. (Personal bias.) -dmj ------------ Category 22, Topic 3 Message 18 Sat Jun 26, 1993 A.HAJNAL [Axel] at 02:54 EDT Hello everyone! I've got a couple of questions about accessories. First, is it possibe to run programs from within an accesory? The GFA manual is unclear on the subject, but the way I see it, I would first have to use the $mXXXXX command to allocate memory for the accessory, and then RESERVE memory for the program I want to run. However, if I do this, the my accessory will end up using an unacceptable amount of memory. I was also wondering whether it is possible to have an accessory open its window when the computer is switched on. When I tried running my accessory, the window opened on the desktop, but none of the controls (move-bar, slider bars,etc.) worked. Also, nothing that I tried to display in the window would appear. Does anyone out there know how to solve either of these problems? Thanks- Axel A.HAJNAL ------------ Category 22, Topic 3 Message 19 Sat Jun 26, 1993 J.NESS [Jim] at 09:22 EDT Wayne - I only experienced the memory problems in v3.5. As soon as I upgraded to v3.6, the problem went away. However, Bob Wilson has reported several ON ERROR -style problems with v3.6. -JN ------------ Category 22, Topic 3 Message 20 Sat Jun 26, 1993 R.WATSON15 [Wayne Watson] at 10:31 EDT The ON ERROR problem is why I can't upgrade to 3.6. It would be nice if I knew how to make my own ON ERROR interupt in assembly or something. The memory management problems with 3.5 gives me headaches with support for my program. The program has to be able to recover from most errors as the Sysops don't want their system left hanging. Since I have figured out these problem areas though, the program is more stable and rarely gets errors. John at GFA said that ON ERROR was the major bug in 3.6. ------------ Category 22, Topic 3 Message 21 Sat Jun 26, 1993 DMJ [dmj] at 18:52 EDT You can't run programs from an accessory. That's a major no-no. If you're desperate, consider embedding the required routine in your own program. (That may not be too clear... that's what happens when you're only half-awake when you write messages.) -dmj P.S. Almost forgot... don't open a window immediately either. ------------ Category 22, Topic 3 Message 22 Sat Jun 26, 1993 A.HAJNAL [Axel] at 20:08 EDT DMJ- O.K., so I can't run a program from an ACC. Anyone got any ideas on loop- holes to this rule? Could I do something like running a short TTP from my accessory and use that to execute a program (the file-name would be sent to the TTP)? Oh, by the way I got the memory problem solved, I just needed to get rid of a couple of RESERVEs in by code. -Axel A.HAJNAL ------------ Category 22, Topic 3 Message 23 Sat Jun 26, 1993 A.HAJNAL [Axel] at 20:21 EDT Whoops, forgot to include something in my last message. Can anyone explain the EVNT_MULTI command? I am trying to have my accessory reconise both mouse clicks and window events(ACC opened, slider bars moved, etc.) How caan I have it wait for the occurance of either of these? Thanks -Axel A.HAJNAL ------------ Category 22, Topic 3 Message 24 Sun Jun 27, 1993 DMJ [dmj] at 00:11 EDT The only loopholes to the "Don't run PRGs from ACCs" that I know of involve detailed knowledge of the program you want to run. This can get rather hairy, and is the sort of thing /I'd/ only try to do in assembly. The problem isn't GFA--it's GEM refusing to do a pexec (GEMDOS 75) call from within an accessory. The EVNT_MULTI call is a doozy. Basically, take all of the GEM EVNT_ calls and roll them into one. The trick here is to set the appropriate flags in the first parameter--a 1 bit indicates an event you want to wait for, a 0 bit indicates an event you want to ignore. The return value from the EVNT_MULTI is also bit-oriented--each 1 bit indicates an event of that type that actually occurred. To use EVNT_MULTI, set the bits for the events you want to wait for, passing any necessary parameters in their appropriate positions. You can pass dummy values for the other, unused parameters. Save the return value, and check each of the bits for the events you're interested in. If they occurred, handle them. As your program becomes more sophisticated, you can add more types of events to the EVNT_MULTI call and handle them fairly simply. The View 2.1 config program (which is almost completely redesigned to use a window and menu) uses keyboard, mouse button, message, and timer events. That's all. GEM does a lot of the work. For more information on EVNT_MULTI, see the GFA BASIC manual, page 387. (At least, that's the page number in MY manual!) -dmj ------------ Category 22, Topic 3 Message 26 Wed Jun 30, 1993 A.HAJNAL [Axel] at 02:55 EDT dmj- I quess I should just about give up on trying to run my program as an ACC... however, this is not so much of a loss, as it is just about as effective as an auto-booting PRG. I've got V1.0 finished, and I'll upload it as soon as I get around to finishing the documentation. In case I didn't mention it in a previous message, what the program does is search the all the folders on your disk, and display only those with PRG,APP,etc. extentions, you can then select the program you want to run from the menu. I don't know about the rest of you, but my disks are a mess of directories. The only problem with running it as a PRG, is that I have to duplicate many of the functions usually handled by the desktop (Deleting files for example.) Anyway... enough relentless chatter from me, thanks to all who helped. -Axel A.HAJNAL ------------ Category 22, Topic 3 Message 27 Fri Jul 02, 1993 JWC-OEO [Jon] at 01:44 EDT RandyH, Reference you message of Jun 23 (just saw it) regarding font height. I don't remember your earlier messages on this; what are you doing that GRAF_HANDLE does not work? There are probably some situations where it won't return the proper character and cell dimensions but I haven't run into any yet. Jon ------------ Category 22, Topic 3 Message 28 Sun Jul 04, 1993 R.HOEKSTRA1 [RandyH] at 12:42 EDT Jon, Yes, GRAF_HANDLE is what I was looking for. Guess I just never noticed this one before. Thanks. BTW, what are the cell height and width good for. I get 19 for both in ST High and this doesn't seem to make sense, but then I don't know what they are really used for. RandyH ------------ Category 22, Topic 3 Message 29 Sun Jul 04, 1993 JWC-OEO [Jon] at 22:06 EDT RandyH, Cell height and cell width includes the "white space" on the tops and sides of a fonts characters so their use is mainly aligning text with other graphic objects. The only one I use regularly is cell height. The cell height of a resolution's stardard font is also the height of the menu bar. To align the top of a dialog box with the bottom of the menu bar for example, set its y coordinate to be the cell height +1. Jon ------------ Category 22, Topic 3 Message 30 Fri Jul 09, 1993 BALKCOM [Devin] at 19:50 EDT Does anybody know how to 'force' an accessory closed before exiting a GFA program? Thanks, -Devin ------------ Category 22, Topic 3 Message 31 Fri Jul 09, 1993 J.NESS [Jim] at 22:19 EDT Devin - Well, you could try sending a AC_Close message via the GEM message pipe. This is the reverse of the call that opens an accessory, AC_Open. Accessories are supposed to respond also to AC_Close, but that's up to the programmer. If the programmer does not build that in, AC_Close will be ignored. ------------ Category 22, Topic 3 Message 32 Fri Jul 09, 1993 DMJ [dmj] at 23:08 EDT Devin: If you want to force a specific accessory closed, you should use APPL_FIND() to get the application ID of the accessory. Then use APPL_WRITE() to send an AC_CLOSE (41) message to the accessory. You shouldn't have to specifically request an accessory to close before your program exits. Any properly-written accessory should do this anyway. -dmj ------------ Category 22, Topic 3 Message 33 Sun Jul 11, 1993 BALKCOM [Devin] at 14:05 EDT Thanks for the quick response. Unfortunately I have found what seems to be an improperly-written accessory. When my program exits, the control panel accessory does close. However, if the TNPCALC accesory is open, the desktop does not fully redraw itself and the mouse cannot be used. It seems to me if one accesory does this, others might too. Is this the case? If it is, how can it be fixed? Thanks, Devin ------------ Category 22, Topic 3 Message 34 Sun Jul 11, 1993 DMJ [dmj] at 23:11 EDT One way to verify it's the accessory is to run a GEM program, call up the calculator, and then exit the GEM program without closing the accessory. If the same symptoms appear, it's the calculator's fault, not yours; there's very little you can do to remedy the situation. If, however, trying to duplicate the symptoms with another program doesn't produce the same results, then say so! I (and probably most of the other regular posters here) will look for another explanation. -dmj ------------ Category 22, Topic 3 Message 35 Sun Jul 18, 1993 T.MAGEE1 [Todd] at 21:35 EDT On an OPEN command, you must supply a channel #. Is there a way to tell whether or not that channel is in use at the moment? I want to write an ACC to go along with Aladdin, but I THINK (could be wrong) that Aladdin keeps some channels (files...) open until you quit Aladdin. If wrong, then let me know. If I am correct, then let me know if I can check to see what channels are in use. Thank you, Todd ------------ Category 22, Topic 3 Message 36 Sun Jul 18, 1993 DMJ [dmj] at 23:03 EDT Todd: The GFA channel numbers are an artifact of GFA BASIC. This may take some explaining, so here goes. The GEMDOS contains files for accessing files. Whenever you open a file through the GEMDOS, you get back a file "handle"; this is just an ID number GEMDOS can use to get information about the open file. Every time you do a file operation (after the file is open) you have to tell GEMDOS the file handle. This way you can have different files open at the same time--each one with its own "handle". The GFA BASIC OPEN command allows you to specify a channel number. When this command is executed, though, GFA opens the file with the GEMDOS call--saving you the trouble of doing it yourself. Any time you access the file, GFA BASIC translates the channel number to the actual GEMDOS file handle, again saving you the trouble of messing with the handles yourself. If you're writing an accessory, you don't need to worry about which files Aladdin is using. GEMDOS won't get things confused. Open the files you need, as you need them. -dmj ------------ Category 22, Topic 3 Message 37 Mon Jul 19, 1993 T.MAGEE1 [Todd] at 20:50 EDT Thank you DMJ for asnwering that so quickly and undersatndably. I still have a few questions then: If open a file (input OR output), I just use whatever channel (through GFA basic) that I want to? Even if other files are open (like in Aladdin)? AND can i leave them open (files) while entering or leaving programs? Or must files be closed prior to this? I highly doubt ever doing this, but I may as well ask now. That is for an ACC example of course. Also, if I want two open files at once (input or output), can I just use another channel then, and not have stuff get confused with Aladdin or something, or should I just stick to one at a time? thanks Todd ------------ Category 22, Topic 3 Message 38 Mon Jul 19, 1993 DMJ [dmj] at 22:02 EDT Todd: You can indeed choose any GFA channel number you feel like. It doesn't matter what other files are open, as GEMDOS keeps them all straight with unique handles. You can leave files open while programs load or unload, but as a general rule I'd recommend not doing so, _especially_ if the files are on a floppy disk. Close the file whenever you're not using it; you can always reopen it. You can open as many files with GFA as you need (up to 100, of course), and they can each be opened for a different operation (read, write, or both). Remember that GFA channel numbers matter ONLY to your program. They are not shared with other programs. When your program (or accessory) loads, GFA BASIC creates a table, with an entry for each channel. When you open a file on a given channel, GFA BASIC records the handle GEMDOS gives it in this table. Whenever you perform a file operation--read, write, or seek--GFA looks in this table to get the file handle, then gives that handle to GEMDOS when it tells it to do the file operation. (All of those file operations are actually GEMDOS routines.) This file-handle table is *unique* to your program. If another compiled GFA BASIC program were run, it would have its own table. Basically, open the files you want. GEMDOS will keep everything straight for you. -dmj ------------ Category 22, Topic 3 Message 39 Tue Jul 20, 1993 T.MAGEE1 [Todd] at 01:20 EDT DMJ, Once again thank you! I understand I can have only (no that I want to do this) 100 files open at one time with GFA Basic, but how many files can GEMDOS have open at once? Just curious. Everything I just asked, is it explained in the GFA manual? I have 3.5E, which version do you have? I could not find this stuff in there, and have been wondering these questions for a while. GFA Basic appears to mak everything so simple, but do you pay a price for this simplicity? l8r Todd ------------ Category 22, Topic 3 Message 40 Tue Jul 20, 1993 DMJ [dmj] at 21:28 EDT Todd: I'm not sure how many files GEMDOS can have open at once. I can't imagine you hitting the limit with just a few files. Everything I explained is most definitely not covered in the GFA BASIC manual. At least, not in one lump. From playing around with GEMDOS file access in assembly, and looking at how GFA does things, I've learned how GFA works to some extent. (BTW, I also have 3.5E.) GFA BASIC does make things simple, and yes, it has a price. GFA BASIC's file handling commands make error handling harder, since GFA expects to take care of that for you. If you're concerned about having your program trap disk errors (sort of important for desk accessories, since GFA's error traps screw things up for accessories) then you should use the GEMDOS file handling functions instead of the GFA BASIC ones. You can find the GEMDOS functions listed in your GFA BASIC manual, in the Appendix. The functions you want start with GEMDOS call #60. If you'd like a brief explanation of the GEMDOS functions, let me know; they're not really much harder than the GFA BASIC commands. -dmj ------------ Category 22, Topic 3 Message 41 Wed Jul 21, 1993 T.MAGEE1 [Todd] at 04:24 EDT DMJ, Okay, looking at GEMDOS calls, #60 and #61 don't seem to tell you what the handle of the file you just opened is though. Or is this where #69 and #70 come in? Also, is there a GFA call that has the same effect as GEMDOS(67)? I could not find one, but that could be useful. Otherwise they seem to make sense, just need to know the address of your filename (plenty of GFA commands to do that, wouldn't L:blahblah do that, or is it LPEEK?, or neither!?), then make sure the last byte is 0 (does GFA use that as the filename ender? That would make it easier...). Also, is checking the GEMDOS version (#48) of any importance? Hope these have made sense, since i am more than half asleep :) Also, YES, I am definetely archiving all of these, thanks! Todd ------------ Category 22, Topic 3 Message 42 Wed Jul 21, 1993 DMJ [dmj] at 19:55 EDT Todd: [Long message warning] Looks like I get to do that GEMDOS file access explanation after all. ;-) Please keep in mind that I'm typing this code in Aladdin, not GFA, so it's possible for me to screw something up. But I do this sort of thing all the time. Also note that I tend to use the _names_ of the functions (also provided in the GFA Appendix) as it makes the explanations easier to follow. fcreate (GEMDOS 60) and fopen (GEMDOS 61) are the low-level equivalents of the GFA OPEN command. Use fcreate when you want to write to a new file, or overwrite an existing file. Use fopen if you want to read or modify an existing file. In either case, the function _returns_ a file handle--opening or creating a file tells GEMDOS to set aside a new file handle for your file. Also remember to insure your filename ends in a null character, or things won't work right. Do this by adding CHR$(0) to the end of the string containing the filename. Example: file$="TEST.D8A"+CHR$(0) ! Filename. handle&=GEMDOS(61,L:V:file$,0) ! Open file for reading. fclose (GEMDOS 62) is the equivalent of GFA's CLOSE command. This releases the GEMDOS handle, so the handle should NOT be used after this call. Example: ~GEMDOS(handle&) ! Close file. fread (GEMDOS 63) and fwrite (GEMDOS 64) are roughly equivalent to the GFA commands BGET and BPUT. You'll need to tell GEMDOS how many bytes to load; by specifying 1, 2, or 4, you can simulate the INP(#), INP&(#), and INP%(#) functions (or their output variations). Examples: r%=GEMDOS(63,handle&,L:2,V:rez&) ' Equivalent to rez&=INP&(#). r%=GEMDOS(63,handle&,L:32,V:palette$) ' Equivalent to BGET #,V:palette$,32 fdelete (GEMDOS 65) will delete a file--it's about the same as the KILL command. The file does _not_ have to be open for this function to work; as a matter of fact, _don't_ delete an open file. It doesn't make sense. Example: file$="TEMP.D8A"+CHR$(0) ! Filename. e&=GEMDOS(65,L:V:file$) ! Delete file. fseek (GEMDOS 66) corresponds to the GFA SEEK and RELSEEK commands. The file does have to be open for this (of course). Example: e%=GEMDOS(66,L:pos%,handle&,mode&) ' Equivalent to SEEK #,pos% (if mode&=0), or ' RELSEEK #,pos% (if mode&=1) fattrib (GEMDOS 67) changes the attributes of files after they've been opened. You will probably never need this function. The same goes for fdup (GEMDOS 69) and fforce (GEMDOS 70). A few notes on these functions: _every_ GEMDOS file function call returns a value. If the value is less than zero, it indicates some sort of error; zero or greater means the function succeeded. In the case of opening files, a value greater than zero is the handle of the file just opened (you don't know it before the file is opened, but you need to keep track of it for subsequent file access!) For fread and fwrite, the value returned is the actual amount of data that is read or written. If you didn't read as much as you asked for, it means the file is shorter than you expected. If you didn't write as much as you asked for, it means the disk is full. I have found no practical use for sversion (GEMDOS 48). To get the address of a string, you use either VARPTR(a$) or V:a$. I tend to use the V: notation as it's more compact. Note that some GEMDOS parameters require a longword (4 bytes), so you need to prefix them with an L: to indicate a longword parameter. Usually these are addresses, but not always. It's *important* that you not forget which parameters are which; making a mistake along these lines can easily crash the system. If this doesn't help, holler... and I'll try again. -dmj ------------ Category 22, Topic 3 Message 43 Thu Jul 22, 1993 K.HOUSER [Kevin MQ Def] at 01:57 EDT Also remember that when GFA does some garbage collection your variables often get shifted around in memory & your original pointers will be incorrect. That can result in hard to track down errors. --Kevin ------------ Category 22, Topic 3 Message 44 Thu Jul 22, 1993 DMJ [dmj] at 19:49 EDT Kevin: Good point. Here are a two rules of thumb with regard to variable addresses: o A numeric (byte, word, integer, or float) variable's address doesn't change unless you use the ABSOLUTE command. o A string variable's address can change after _any_ string function. The following code is usually reliable, but not always: t$=SPACE$(32000) ! Space for a screen. t%=V:t$ ! Address of that space. u$=SPACE$(32000) ! Space for another screen. u%=V:u$ ! Address of that space. Since defining u$ is a string function, it's *possible* that it may trigger a garbage collection--which will move the strings around in memory, making t% invalid. If you must store the addresses of string variables in other variables, make sure you re-define them if you do string functions. Better yet, don't store the addresses in variables--use V: to look up the address every time you need it. Hope this doesn't muddy the water. -dmj ------------ Category 22, Topic 3 Message 45 Fri Jul 23, 1993 CBARRON at 02:27 EDT dmj tt resolutions are not 32000 bytes long, try 153000 bytes. Falcon 'true color' and other boards 'enhanced' resolutions' are greater yet!! Writing code that assumes a screen memory size is not a good idea now-a-days in any language. The 'basic' technique is ok, provided you calculate somehow what the size of the required memory is, and GFA does not mind 153K+strings!! ------------ Category 22, Topic 3 Message 46 Fri Jul 23, 1993 V.VALENTI at 03:28 EDT I have been assigning all my data to arrays. like video%(8000) for a 32k graphics screen. although you could use a larger array for larger data. I use mine for graphics and use a BITBLT or my Assembly routines to copy the graphics. Vince ------------ Category 22, Topic 3 Message 47 Fri Jul 23, 1993 D.MUNSIE [DSA] at 04:37 EDT DMJ - Thanks for the nice GEMDOS tutorial!! Very useful... :) ------------ Category 22, Topic 3 Message 48 Fri Jul 23, 1993 OFFY [OFFY] at 18:18 EDT I am in dire need of some assistance with the FORM_KEYBD command. As I understand the command, I should be able to use it to loop through a form until it has been exited with a click on an EXIT or TOUCHEXIT item. My first problem is that it does not operate as listed in the GFA 3.5e manual. It shows the command receiving 6 parms, and it only operates if given 4. Can someone give me some idea of how to use it correctly? What I have is a screen with a few editable boxes. I want to be able to hit RETURN and advance from box to box through the form. It seemed that this command would be what I needed. Don't take this wrong, but reciting the manual won't help me, I need to know exact examples of how to use this command. Lee ------------ Category 22, Topic 3 Message 49 Fri Jul 23, 1993 DMJ [dmj] at 20:16 EDT CBARRON: The code was written to illustrate the caveats of _strings_ and _addresses_, not graphics. I'm well aware that TT resolutions are 153600 (not, as you stated, 153000) and other resolutions have varying sizes. You can't use a GFA BASIC string to hold these because GFA strings are limited to 32767 bytes in length. For reference, the "best" way to grab a screen shot like that is to first calculate the screen size, second reserve enough memory for the screen, and third, blit the code into the reserved memory. A simple memory move doesn't always work with some oddball graphics cards. Vince: Why use an integer array, when you can use a byte array, like video|(32000)? This makes the code a bit more readable. But then, I'm just nitpicking. ;-) Good choice on using BITBLT. Be careful with the custom assembly routines. Dave: No problem--happy to help. I enjoyed Frogger & Kaboom, BTW. And all those other wonderful games. One of these days I'll even get around to taking care of the "donation" part. Offy: I know what you mean about the GFA manual. If you know what you're doing, it's fine, but if you're just learning, it's abysmal. Now that I've vented my opinion, let's get on with taking care of the problem. To make sure I understand your problem, you have a dialog with several editable boxes. Normally you'd use FORM_DO to handle the dirty work of managing the editing stuff, but FORM_DO interprets the RETURN key as selecting the default button, not as a DOWN ARROW. You're trying to circumvent this by using FORM_KEYBD. I have never been able to get FORM_KEYBD to do anything useful. What you really want to do is write your own FORM_DO routine. Don't panic! It's not as hard as it sounds. It also offers _lots_ of advantages... Basically, make an endless loop that calls EVNT_MULTI. You only need to fill in the mouseclick and keypress info, since those are the only two events you're concerned with. (You can add more events later, but start with the simple stuff.) Check the return value from EVNT_MULTI to see what event you have. If it's a keypress, use OBJC_EDIT to handle the keypress. You'll need to keep track of which object is being edited, so make sure you initialize that variable (and turn the edit cursor on!) before you enter your custom FORM_DO loop. If the event was a mouseclick, use OBJC_FIND to figure out which button the mouseclick was in. If the click was outside the box (OBJC_FIND will return - 1) ring the bell. Otherwise, it was inside; if the object clicked is selectable, select it. (You may want to GRAF_WATCHBOX on buttons that aren't TOUCHEXIT, to give the user a chance to change their mind about selecting the button.) That's really all there is to it. You'll have to check for the RETURN key and move the edit cursor yourself, but it allows you to do _really_ cool things with keyboard input. Things like SHIFT ARROW to move the edit cursor to the top or bottom edit field, or TAB & RETURN to move to the next field, or even... HOT KEYS. I have a very nice custom FORM_DO which I'm using in ReNameIt!, DMJ GIF 4, and View II's Config program. Unfortunately, it's based on Tom Hayslett's code, so I can't upload it here without his permission. Maybe I can talk him into letting me... but don't hold your breath, he's still in Germany for a few more months. Besides, writing your own is good practice at GEM code. -dmj ------------ Category 22, Topic 3 Message 50 Sat Jul 24, 1993 D.LIVINGST11 [ErnestBovine] at 03:59 EDT > t$=SPACE$(32000) ! Space for a screen. > t%=V:t$ ! Address of that space. > > Since defining u$ is a string function, it's *possible* that > it may trigger a garbage collection--which will move the strings > around in memory, making t% invalid. If you must store the > addresses of string variables in other variables, make sure you > re-define them if you do string functions. Better yet, don't > store the addresses in variables--use V: to look up the address > every time you need it. Another solution is to use arrays, rather than strings, to reserve space for a screen buffer, or any other buffer (e.g., larger iorec etc) DIM screenbuf%(screensize%/4) ' elements are 4 bytes each sbuf%=V:screenbuf(0) These arrays can be as big as you like, unlike strings, which can be 32767 bytes max. Also, arrays don't get moved around by garbage collection, so sb% will always be valid. Don't use DIM screenbuf|(screensize%) ' elements are 1 byte each since the array of bytes may be on an odd address. Actually I think that screens have to be on a 256-byte boundary, so if you're assigning the physical or logical screen to this address, you should set aside more memory, and use an address aligned to 256 bytes. At least for older STs this is required. DIM screenbuf%((screensize%+256)/4) ' 256 extra bytes sbuf%=(V:screenbuf(0)+256) AND &XFFFFFF00 ' move up to 256-byte boundary ------------ Category 22, Topic 3 Message 51 Sat Jul 24, 1993 DMJ [dmj] at 15:24 EDT ErnestBovine: - Don't use - DIM screenbuf|(screensize%) - since the array of bytes may be on an odd address. Actually, that's not true. This is a "feature" of GFA; whenever you create an array, it is ALWAYS at an even address. Sorry if I forgot to mention that. For STs, the screen address does have to be at a 256-byte boundary. STes and higher can use any even address. (The fine scrolling is handled differently.) BTW, the last line of your message should read: sbuf%=(V:screenbuf%(0)+256) AND &FFFFFF00 ^ You left out the marked %. If your default variable type is float (real, or whatever) then leaving this out will cause problems. -dmj ------------ Category 22, Topic 3 Message 52 Sat Jul 24, 1993 OFFY [OFFY] at 21:47 EDT The only problem is that I am not really into practicing GEM code. I'd rather get on with my program code. I will re-read your message and see if I want to stray out into the event check or not. I have seen some custom form_do routines, that I might check out. Would definitely be nice to have a core product already written that I could bastardize into something I can use in my package. If it is as usual, I'll end up writing one of my own just to have it do what I want. Grin. I just understood the FORM_KEYBD to be a command that could use an existing form and allow you to tell it where to go based on what key was hit. Maybe I'm not using it right, but it sure seems worthless to me. Thanks for the prompt reply, and I would really like to see that custom FORM_DO you are using. Who is Tom Hayslett anyway? Could I maybe get it directly from you instead of uploading it to the service? I would swear to not directly import it, just examine it to see how I do it. I've already got several things going in the program, such as 3-d buttons (with stick-tion) using standard RSC files. May have been done before, but I've never noticed it. I would simply like to be able to have a form filled out by hitting return to go through the form line by line instead of using it for default. Lee ------------ Category 22, Topic 3 Message 53 Sat Jul 24, 1993 DMJ [dmj] at 23:21 EDT Lee: Prompt replies are what I do best. ;-) Tom Hayslett is the author of TLC programs (Shareware). These include a bundle of various utilities (address book, formatter, sound player, and others) for a single registration price of just $20. We have collaborated on ReNameIt!, which is now at version 1.5. Working with him has been an interesting experience. Tom is the guy who got me started in GEM programming. I was having a hard time piecing together information out of the GFA BASIC manual, so he took the time to explain it all to me. I've since learned a great deal through experimentation, including reworking his FORM_DO routine so it puts the dialogs in a window. (This was NOT simple.) However, the basic code is still his. We have discussed sharing the ReNameIt! source code, but neither one of us feels like divulging our parts of the program. (He did most of the work on the GEM interface, while the file-rename code is mostly my work.) Perhaps after he returns to the US (in a few months) and becomes active online here he will look at it differently, but for now I must respect his wishes with regards to his work; this means I can't even let you look at the code. Sorry. After that last paragraph, I don't see how I can ask you to share how you did your 3D buttons with standard RSC files. But I'd be interested in seeing it. Ah well... -dmj ------------ Category 22, Topic 3 Message 54 Sun Jul 25, 1993 D.LIVINGST11 [ErnestBovine] at 06:06 EDT DMJ Hmm, you're right about byte arrays starting at even addresses. I just tried it. I think it wasn't always so; I seem to remember a warning in an old GFA book. ------------ Category 22, Topic 3 Message 55 Sun Jul 25, 1993 D.LIVINGST11 [ErnestBovine] at 06:06 EDT OFFY, The original form_do replacement was by Tim Oren, one if the Digital Research guys who ported GEM to the ST about 10 years ago. He did good work, so of course he lasted about 2 months at Atari, but that's another story. Tim wrote about 15 articles about using GEM on the ST. One of them is a form_do replacement routine. All his examples are in C of course but the text is worth reading even if you don't follow the C. I think the collection is called PROGEM.ZIP or ARC or something and it must be in the library here. His form_do probably doesn't have all the functionality that you'd want, but it'll show you what's involved. (You may decide to give up!) Also, some GFA nut ported the whole thing to GFA. From the Genie Libraries: It looks like you want 25065 and 960 at least. They're all worth reading. 25065 FRM_DO.LZH X RANDYB 920728 18560 81 3 Desc: Replacement FORM_DO in GFA Basic 963 PROGEM.IND X JAKOB 860825 1260 282 3 Desc: An Index to the ProGEm series 962 GEMDOS.TXT X JAKOB 860825 20160 175 3 Desc: ProGEM by Tim Oren Column #15 961 INTFACE2.TXT X JAKOB 860825 25200 123 3 Desc: ProGEM by Tim Oren Column #15 960 FORM_MAN.TXT X JAKOB 860825 45360 153 3 Desc: ProGEM by Tim Oren Column #13 959 EVENTS.TXT X JAKOB 860825 20160 139 3 Desc: ProGEM by Tim Oren Column #12 958 GEMHACKS.TXT X JAKOB 860825 28980 156 3 Desc: ProGEM by Tim Oren Column #11 957 VDI_GRA2.TXT X JAKOB 860825 16380 148 3 Desc: ProGEM by Tim Oren Column #10 956 VDI_GRA1.TXT X JAKOB 860825 26460 151 3 Desc: ProGEM by Tim Oren Column #9 955 INTFACE1.TXT X JAKOB 860825 28980 125 3 Desc: ProGEM by Tim Oren Column #8 954 MENU_STR.TXT X JAKOB 860825 26460 150 3 Desc: ProGEM by Tim Oren Column #7 953 RASTER.TXT X JAKOB 860825 30240 139 3 Desc: ProGEM by Tim Oren Column #6 952 TES_TREE.TXT X JAKOB 860825 26460 158 3 Desc: ProGEM by Tim Oren Column #5 951 RESOURCE.TXT X JAKOB 860825 34020 172 3 Desc: ProGEM by Tim Oren Column #4 950 DIALOG.TXT X JAKOB 860825 22680 152 3 Desc: ProGEM by Tim Oren Column #3 949 WINDOWS2.TXT X JAKOB 860825 28980 149 3 Desc: ProGEM by Tim Oren Column #2 948 WINDOWS1.TXT X JAKOB 860825 18900 177 3 Desc: ProGEM by Tim Oren Column #1 Here's some more; this looks like everything in 3 files. 2943 PRO_SRC.ARC X J.CHEN 870524 56700 350 3 Desc: Tim Oren's Professional GEM 2942 PRO_GEM2.ARC X J.CHEN 870524 85680 314 3 Desc: Tim Oren's Professional GEM 2941 PRO_GEM1.ARC X J.CHEN 870523 99540 356 3 Desc: Tim Oren's Professional GEM ------------ Category 22, Topic 3 Message 56 Sun Jul 25, 1993 RANDYB [Randy] at 11:36 EDT >Also, some GFA nut ported the whole thing to GFA. Hmmm... I resemble that remark :-) C-ya! Randy ------------ Category 22, Topic 3 Message 57 Sun Jul 25, 1993 M.SILVERSTE3 [SYNCHRON] at 13:38 EDT I've been playing with my GFA Midi program - my latest version kind of crashed after receiving Midi from my Yamaha synth - that is, my help dialog boxes wouldn't function (I'd get Error 8 memory full) and you couldn't quit since I am restoring the old system 128 byte midi buffer - to me that's a crash even if there's no bombs because you can't leave the program. My older version used RESERVE when dealing with memory allocation and I got rid of them and used the $m compiler option. I set it to 50K which I thought was enough but somehow my MIDI receive routine conflicted with it - increasing to 75K solved the problem with the dialogs but you still couldn't quit. So I got rid of the routines which changed the system buffer size and now use MIDIINIT (from the Stalker disk) in my AUTO folder. Any clues as to the reasons for this?? Also, I compiled this newer version with the Interrupts option set. Now my receive routine doesn't get any Midi data until 3-4 seconds after I send the SYSEX from my synth under certain conditions like within Hotwire or Neodesk. From the desktop, the data is received almost immediately after I send it (as it did before I used the interrupt option). In a way, this is good since my checksum routine would pick up errors with Codekeys installed. This is due to both Codekeys and MIDI sharing the same ACIA chip/interrupt service routines. With the interrupts set in the compiler, the Codekeys conflict goes away so long as I am running under Hotwire or Neodesk (probably TOS 2.06 if I have it - I am running under Rainbow 1.4). I'd appreciate any ideas as to what the interrupts option in the GFA compiler is actually doing in relation to MIDI I/O - I pretty much use INP/OUT 3 and/or INPMID$ in several areas within my program. Be in Synch with the Synchron from Camarillo, CA!! Datestamp: Sunday, July 25, 1993 Timestamp: 10:39:38 am ------------ Category 22, Topic 3 Message 58 Sun Jul 25, 1993 DMJ [dmj] at 22:21 EDT Synchron: Do you save the screen behind your dialogs? GFA's Error 8 is a _GFA_ error, not a system error--it means you tried something (dimensioning an array or creating a string, usually) and GFA hadn't reserved enough memory for it. Also, although GFA provides an ERASE command to delete arrays, it doesn't work quite right and should not be used. To make matters even worse, GFA's $m compiler option doesn't work right _either_. Remember that strings use GFA memory, as does the FILESELECT command (this last uses 32K!) I'm curious as to why you're enabling interrupts in your program. After looking at the list of things this option adds, I can't see how it relates to the program you've described. -dmj ------------ Category 22, Topic 3 Message 59 Mon Jul 26, 1993 T.MAGEE1 [Todd] at 01:34 EDT DMJ, Since we are talking about GFA programming, I was curious about your Fireworks demo from a couple years back. It seemed pretty slow, especially at the one part (don't remember where) where you have like five icons circling on the screen, and an arrow pointer, but everything was moving so slow and awkward that it is almost impossible to control, and at times you can't find the mouse pointer. What happened? I assume there is stuff you know now you didn't then. What I mean is it just didn't seem DMJ-like. I know you use GFA with a lot of assembly routines (you still use GFA right?, or is completely assembly these days?), but was Fireworks in ALL GFA code? Lastly, wasn't the very first version of View on that disk? Keep it up! Todd ------------ Category 22, Topic 3 Message 60 Mon Jul 26, 1993 OFFY [OFFY] at 13:35 EDT An example of the 3-d buttons is already in the downloads. I think I called it VIEWER3D.LZH. Just a simple program to show how it works. I've added a few extras since then. Lee D.LIVINGST11 I'll grab those files. Believe it or not, I didn't even think of looking for things like that here. Actually, after review, I think I have the FRM_DO package. Will have to review it. DMJ, Now you've got my ears perked up. ERASE doesn't work properly eh? I use that extensively in my CWAC program up here. I've got one user who's getting bombs while the rest of us don't. The only variable is his TOS version. What do you suggest, leaving the array intact and not clearing it? If not, how do I clear the array to recover the memory for later in my program. What I'm doing is to try to operate in a given amount of memory and using and clearing variables is the best option to do that. Hep me! Hep me! As for enabling interrupts, the only way I found to be able to use the EVERY xxx GOSUB command was to enable the interrupts. It works fine in the interpreter, but as soon as you compile without enabling interrupts, it's gone. Am I going about this correctly by enabling interrupts to get the EVERY xxx GOSUB to work after compiling? Lee (again) Do you feel like a large leech just sucked onto your frontal lobe? ------------ Category 22, Topic 3 Message 61 Mon Jul 26, 1993 DMJ [dmj] at 19:50 EDT Todd: You mean you actually _remember_ that Fireworks demo? Amazing... The main fireworks program is almost 100% GFA code. I didn't know a whole lot back then--virtually no assembly, and only a little on graphics acceleration tricks. If I were to do it all over again _now_, it'd probably be flicker- free 50 frames per second animation. Normally I use a _lot_ of GFA code, with very high-speed assembly routines to help make it run quickly. Sound Lab, for instance, is about 10,000 lines of GFA code, and about 2,000 assembly lines. That 2,000 lines sounds like more than it really is. And yes, the first version of View _was_ on the Fireworks demo disk. If anyone is interested, I can upload the source code to the Fireworks demo. It's kinda old, kinda slow, but... oh well. Offy: Um, I guess I didn't associate "OFFY" with "VIEWER3D.LZH". Sometimes that happens to me. I'll swipe a copy soon, when I have more than 50K free space on my hard drive. (Aladdin just _barely_ runs!) What happens with ERASE is that it seems to erase the array, but not all of the overhead involved with the array. After a number of DIM-ERASE cycles, GFA will crash. How many DIM-ERASE cycles it takes depends on a multitude of things, but this isn't related to the 40-folder bug (as far as I know). I suggest DIMming the array once and never erasing it. What I did in DMJ GIF 3 was exactly that--use a nice big DIM to grab all the memory, then keep track of how much I was using internally. With version 4 I've got a complete memory management routine in there. Sounds like overkill, huh? If you need to use the array for several different things, then do. Just remember not to use it for two different things at a time. If you need to leave 32K free for GFA's FILESELECT command, don't; use the FSEL_INPUT function instead (it doesn't need 32K). If you need more help with this, say so. If you check your GFA compiler manual, it should _tell_ you that you need the I+ option to make EVERY and AFTER work. However, this makes your program MUCH bigger (and a bit slower, too). Here's how EVERY _really_ works. In the interpreter, after every command is executed, the interpreter checks to see if the time has expired. If it has, it calls the EVERY routine. If not, it executes the next command. In a compiled program, with the I+ option enabled, EVERY works the same way. But here's the catch: because GFA is the one checking for the timer, the EVERY routine can _only_ be called when your program is actually running on the CPU. For an accessory, this isn't too often, unless you program it that way. TOS decides when to run your accessory, based on what events it's waiting for. To use an accessory with EVERY and AFTER, you need to make sure you're using a TIMER event in your AES loop--which means using EVNT_MULTI. If you don't use a timer event, your accessory doesn't get to run much, which means your "interrupt" is never called. Make sense? Goodness, that leech on my forehead is really swelling up... -dmj ------------ Category 22, Topic 3 Message 62 Mon Jul 26, 1993 R.WATSON15 [Wayne Watson] at 21:34 EDT Synchron, If you used strings to hold the data with the new buffer, you will get lockups and such. For a new buffer, you should use an INLINE statement. It is much cleaner and will not move around. I uploaded a file to the libraries that gave an example of changing the serial port buffers. It works the same with the Midi port. You just use a different number. ------------ Category 22, Topic 3 Message 63 Mon Jul 26, 1993 BALKCOM [Devin] at 21:50 EDT It sounds from past messages that most people are using event_multi to wait for GEM messages and events. Could somebody please explain to me how this works? The manual has about a page defining the variables without much explanation, and I'm having a hard time figuring out what I should use for user input when programming GEM. Thanks, Devin ------------ Category 22, Topic 3 Message 64 Mon Jul 26, 1993 DMJ [dmj] at 22:15 EDT Devin: EVNT_MULTI looks very intimidating, even after you're used to it. Basically, it allows you to wait for any type of event you want--mouse click, keypress, timer, whatever. The other EVNT_ functions allow you to wait for _one_ event. When you use, for example, EVNT_MESAG, your program will stop until a message is sent to your program. If you want your program to stop running and wait for a certain amount of time, you could use EVNT_TIMER. If you wanted to wait for _either_one_, you have to use EVNT_MULTI; it basically rolls all the other EVNT_ calls into a single, integrated call. That's why there are so many variables-- EVNT_MULTI can do so many different things. The good news is that you don't have to put anything meaningful into most of those parameters. The first EVNT_MULTI parameter is called "flags". Each bit corresponds to one of the events that EVNT_MULTI can wait for; if you want EVNT_MULTI to return if that event happens, you set that particular bit to 1. Parameters for events you're not worried about can be filled in with meaningless numbers--0 is a good choice. You have to fill them with _something_, but it doesn't have to be anything meaningful. Fill in the variables you want with the important information. One of the nice things about EVNT_MULTI is that you can change your program to accept a new event just by setting the appropriate bit and filling in the appropriate parameters. Everything else will probably already be in place. One other thing: EVNT_MULTI returns a bit-coded value that tells you _which_ event occurred; use the BTST function to figure out which event happened. -dmj ------------ Category 22, Topic 3 Message 65 Tue Jul 27, 1993 T.MAGEE1 [Todd] at 02:29 EDT DMJ - fireworks being almost all GFA code makes it more understandable on why it was that way. I know assembly code lines add up real fast. I have not messed with 680x0 assembly, but I remember stuff ont he 6502, and the assembly listing could get long for seemingly simple stuff in BASIC. Clearing the screen adn printing your name in BASIC was two commands, or even one if you wanted to add that clear screen char to the start of you string (name) to print. In assembly becomes a lot more, as you use the OS routines to display it. Appeared to be easier to just write your own routines for displaying stuff. Does the ST work that way also? I have done little programming (LITTLE) on the STe I have. Just looks intimidating. I would hate to write somethng that ghad to use windows. Looks awkward and complicated and confusing. l8r Todd PS - DMJ, have you been in contact with MAL? Last I knew he was enjoying himself in learning 680x0 assembly, and had a few small demos. ------------ Category 22, Topic 3 Message 66 Tue Jul 27, 1993 DMJ [dmj] at 19:58 EDT Todd: For the most part, TOS is a pretty good operating system. It's easy to use, easy to modify, and easy to get around when it doesn't do what you want. MS-DOS and Windows are a real nightmare, compared to TOS. I used to think TOS wasn't all that great, until I started programming PCs. Not a day goes by that I don't curse Microsoft for hobbling PCs with Windows. I *really* appreciate TOS now! On the ST, clearing the screen and printing your name would take about, oh, five lines of code. That's not including stuff to wait for a keypress and then exit the program, which would take another five lines. Sounds nice, huh? Doing GEM stuff in assembly _is_ a nuisance, but with the right collection of routines it becomes much simpler. For the most part I don't recommend writing large programs in assembly unless there's a very good reason to do so. Note that I still use GFA, and _plan_ to still use it. -dmj ------------ Category 22, Topic 3 Message 67 Thu Jul 29, 1993 V.VALENTI at 01:10 EDT DMJ, Tell me about it! I was tempted to throw the Clone right out the window when I had to struggle with it. I too, appreciate the TOS environment. Vince. ------------ Category 22, Topic 3 Message 68 Sat Jul 31, 1993 M.SILVERSTE3 [SYNCHRON] at 00:37 EDT Dmj: Thank you for your memory explanation (although I'm still a bit confused). My help dialog boxes were string arrays using DIM/ERASE, SPUT/SGET for every time a help box was called. This worked before receiving any MIDI - which eventually processes the buffer also using DIM/ERASE SPUT/SGET. I've had no problems, thus far, increasing $m by 25K. And I am having no problems using my program for long periods of time since almost every function will dimension a buffer and then erase it. (Of course, this is usually only done to about 72 bytes of MIDI data and 200 bytes to hold text strings of data - you may be talking about much larger amounts). By enabling interrupts, this must be doing something to make the internal MIDI interrupt service routine have a higher priority than before (at least thats what it seems under certain conditions). The ST will not process MIDI until all 13K has been dumped from the synth. Without the I+ option, the ST will process data in packets (much like the Kermit protocol but with out any error checking) and my own checksum routine will catch any errors. Now, why this happens is beyond me but I may go as far as deciphering my code in Devpack to see what the I+ option is really doing during MIDI send/receive. Be in Synch with the Synchron from Camarillo, CA!! Datestamp: Friday, July 30, 1993 Timestamp: 9:32:50 pm ------------ Category 22, Topic 3 Message 69 Sat Jul 31, 1993 DMJ [dmj] at 13:41 EDT Synchron: Don't use SPUT and SGET. They don't work on the Falcon. I don't even think they work in the TT's graphic modes. When I was talking about DIM/ERASE, I experienced the problem with _very_ large arrays--usually about 200K. It also depends on how much memory you have and a million other things. It's still not a good idea, though. "Enabling interrupts" is a bad description for what that option really does. It doesn't change ANYTHING about how the interrupts work. What it DOES do is add "polling" code to your program that forces your compiled program to check on various things periodically. There is _no_ interrupt code involved. For example, it might appear that when you press CTRL-SHIFT-ALT, your program is "interrupted". This is not the case. What really happens is that, between GFA BASIC commands, your program _looks_ to see if CTRL-SHIFT-ALT is being pressed. If so, it jumps to the break routine, otherwise it continues normally. _Every_ GFA interrupt works this way, including EVERY/AFTER. This is why compiling a program with interrupts on makes a substantially larger program. The practical upshot of all of this is that if your program doesn't get executed, it can't check to see if any timers have expired, or if there's MIDI input, or whatever. TOS will buffer the MIDI input for you until you can process it, but if you're writing an accessory and using EVNT_MULTI, your program won't continue running until GEM decides to run it again. If another program is doing something and doesn't give control back to GEM, your program can't run. The I+ option _isn't_ changing anything about the real interrupts on the ST... just how often your compiled program "polls" them to see if it needs to do something about them. I hope this is making sense. Maybe I lost the point of the original problem somewhere. -dmj ------------ Category 22, Topic 3 Message 70 Tue Aug 03, 1993 J.FOUCH [JIM FOUCH] at 20:26 EDT For anyone who needs to do GET/PUT or SGET/SPUT on an TT (or even a Falcon I think.) I have some code I wrote. It replaces the standard GET/PUT commands. The reason the GET/PUT command does not work in TT resolutions, is that it uses a string to store the screen block. It works fine for small blocks, but not for anything larger than about 32,000 bytes. My code will allow you to set up a block of memory, what ever size you want. Then all you have to do is call a procedure to GET or PUT. Works in all resolutions ST & TT. I have not tested it on a Falcon, but it should work. Just send me E-Mail if you want a copy. Thanks Jim Fouch @ Fouch Software ------------ Category 22, Topic 3 Message 71 Thu Aug 05, 1993 D.LIVINGST11 [ErnestBovine] at 06:00 EDT SYNCHRON, > The ST will not process MIDI until all 13K has been > dumped from the synth. Without the I+ option, > the ST will process data in packets What do you mean by "will not process MIDI"? There are ways to get big MIDI dumps, even in the GFA interpreter, without having to enlarge the iorec buffer. DMJ > The I+ option _isn't_ changing anything about the real > interrupts on the ST... just how often your compiled > program "polls" them to see if it needs to do something I just tried $I+ on a little program, and found the opposite. $I+ points two OS system interrupt vectors into GFA's code, and doesn't do any polling at all. The 2 vectors are GEM event vector ($400) ikbdsys vector (kbdvbase+$20) Actually GFA vectors each of these thru the same code, after jsr-ing each of them thru their original vector. GFA checks for Control-Alt-Lshift, looks in the keyboard iorec, checks for certain keys there, and does some other stuff. Pretty early on in the GFA interrupt routine, it locks out all other interrupts. This could definitely interfere with servicing the MIDI interrupt. (If you got there thru ikbdsys, midi can't be serviced anyway until the GFA routine returns.) You can see it by compiling with symbols, then run your program from MON or MONST2, and look at the code pointed to by the GEM vector ($400) or by the ikbdsys handler at kbdvbase+$20. You'll see or.w $700,sr followed by lots of stuff that compares timers etc. ------------ Category 22, Topic 3 Message 72 Thu Aug 05, 1993 DMJ [dmj] at 23:21 EDT Ernest: I stand corrected on what GFA does with the $I+ option. I'll look through it again this weekend to see if I can figure out exactly what it's doing. This would explain quite a few things. Guess I don't know everything about everything, huh? -dmj ------------ Category 22, Topic 3 Message 73 Sun Aug 08, 1993 A.HAJNAL [Axel] at 23:55 EDT Greetings! I have some large multi color sprites that I want to place on the screen using the PUT statement. I have hust one slight problem... the backround I'm using is multi-coloured and I can't PUT the sprite on the screen without messing up the background. A while ago I managed to use some combination of PUT modes to put a sprite against a background without losing the background. Unfortunately, I have lost the routine. Can anyone out there help? Thanks- Axel A.HAJNAL ------------ Category 22, Topic 3 Message 74 Mon Aug 09, 1993 DMJ [dmj] at 21:58 EDT Axel: What you need is a MASK of the sprite. I'm going to assume you're working in low rez, since I can't imagine doing anything like this with less color... ahem. The MASK is just a copy of your image, except it uses color 15 where you want the background to show through, and color 0 where you want your sprite to appear. You can create this with the same paint program you used to create the sprite; if you used a sprite editor, it probably has an option to make the mask for you. To draw your sprite, you draw with the MASK first, with PUT mode 1 (s AND d). This will zero out the screen in exactly the right places. You can now draw your sprite in the same place as the MASK using PUT mode 7 (s OR d). If you're using a sprite editor, and it uses color 0 in the MASK for the transparent parts of the sprite, use PUT mode 4 (NOT s AND d) to draw the MASK. This will effectively invert the mask so it does what you want. Hope this helps. -dmj ------------ Category 22, Topic 3 Message 75 Mon Aug 09, 1993 BALKCOM [Devin] at 22:56 EDT I've been using BIT_BLT in low resolution recently and I've noticed an interesting "feature?". When I place a new screen over the old one, there is a brief flash and the old screen changes color before the new screen appears. For example, if there is a blue circle on the screen and I BIT_BLT an all black screen onto it (with black being what color 0 is set to), the circle flashes green for an instant before being replaced. If I modify the color of what was green to red, then there is a red flash. The same colors when bitblitted over flash the same colors every time. Has anyone else encountered this problem? Is there any way to fix it? Thanks, Devin P.S - I've already tried VSYNCing before the BIT_BLT call. ------------ Category 22, Topic 3 Message 76 Tue Aug 10, 1993 V.VALENTI at 03:45 EDT Devin, This is known as a 'snow affect'. If your BIT_BLT is large enough, it requires more time to draw, than it takes to do a VSYNC. Remember, VSYNCs only give you a short period of time when the electron gun turns off and move back to the upper right hand corner of the TV. If while you are BIT_BLTing and the Gun starts to trace the screen, it will catch part of the BIT_BLTs work. There are two ways to fix it. A) draw off on a buffer, and then BMOVE the entire screen over to the Physical address. Or B) Separate the logical and Physical addresses in XBIOS(5). Draw on the logical then SWAP the variables then XBIOS(5) again. The logical now becomes the physical and displays your screen. When setting up option B, you only need to create a buffer for the logical address. like logical|(32256). On the ST you need to make sure that the logical address pointer stats on a 256 byte boundry. log_addr%=AND(V:logical|(256),&HFFFFFF00) Hope this helps. Vince ------------ Category 22, Topic 3 Message 77 Tue Aug 10, 1993 BALKCOM [Devin] at 21:05 EDT Vince, Thanks for the help. I didn't think of using a BMOVE - it will probably take care of the problem. I didn't want to use XBIOS 5 because I would then have to create another screen buffer. I've been considering doing this but I'm not sure I want to waste the memory, especially since I'm trying to make the program compatible with the TT as well as the ST resolutions. Thanks, Devin ------------ Category 22, Topic 3 Message 78 Wed Aug 11, 1993 R.HOEKSTRA1 [RandyH] at 23:45 EDT I recently had a complaint about one of my programs not working well with the 'Let Em Fly' utility. The problem appears to be that when a dialog is moved, the next time it is drawn it will only partially show up on the screen. I am using dialogs in a resource file and after I load the resources I use FORM_CENTER to center and find the x,y,w,h values. Later, when it is time to use the dialog, I use FORM_DIAL to reserve the screen space and draw the expanding rectangle. I plug in the x,y,w,h values obtained from FORM_CENTER on all the FORM_DIAL commands and the OBJC_DRAW command. I would guess that this results in clipping the dialog after it has been moved by Let Em Fly. Should I be getting new x,y,w,h values just before the FORM_DIALs and OBJC_DRAW and what is the best way to do this? The person who brought this to my attention indicated that most other programs work fine with Let Em Fly. Any suggestions? Thanks, RandyH ------------ Category 22, Topic 3 Message 79 Thu Aug 12, 1993 DMJ [dmj] at 22:02 EDT RandyH: You can use the OB_X, OB_Y, OB_W, and OB_H functions to get the coordinates of the dialog box before it is moved. Just give these functions the address of the object tree, and use item number 0 (the actual BOX for the dialog): x&=OB_X(tree%,0) y&=OB_Y(tree%,0) w&=OB_W(tree%,0) h&=OB_H(tree%,0) If you use this to obtain the coordinates of the dialog just prior to displaying it, you should be okay. Note that this also relieves you of having to record the positions of all the dialogs--they are always available just by using the above functions. -dmj ------------ Category 22, Topic 3 Message 80 Fri Aug 13, 1993 R.HOEKSTRA1 [RandyH] at 22:11 EDT DMJ, Thanks for the OB_X info. That's what I had suspected and was planning to do, but just wanted a second opinion. On another topic, does anyone know how they are doing the pop-up menus and 3D objects in the recent programs coming out. Is there a resource construction set to help with these or are the programmers doing it all on their own? Thanks, RandyH ------------ Category 22, Topic 3 Message 81 Sat Aug 14, 1993 DMJ [dmj] at 11:20 EDT RandyH: I don't know how anyone else does pop-up menus, but I know how I do it. I thought about using a resource editor to make the box, but then I realized that meant I would have to define EVERY box. Too much of a nuisance, especially if I want to change the contents of the popup menu easily. So what I did was write a routine that builds a complete resource tree from a text string that contains the popup menu items (separated by |'s). It works pretty well. This wasn't as hard as it sounds. The OBJC_ADD function was especially useful here. -dmj ------------ Category 22, Topic 3 Message 82 Sat Aug 14, 1993 M.SILVERSTE3 [SYNCHRON] at 17:54 EDT Dmj: My compiled GFA MIDI program was tested on a Falcon and it works fine in regular ST med/hi rez modes. It even works in 256 color alhough it's text oriented, therefore, 640 X 480 is fine. The point is, I use SGET and SPUT all the time (not sure about the TT). My only requirement is that it should be run in ST med/res modes on later platforms since that's what I used to develop it. I guess this "polling code" makes a difference in MIDI tansmission and reliability. At any rate, I'm glad this I+ option was available and am a happy camper. Thanx for your thoughtful analysis! Be in Synch with the Synchron from Camarillo, CA!! Datestamp: Saturday, August 14, 1993 Timestamp: 2:56:40 pm ------------ Category 22, Topic 3 Message 83 Sun Aug 15, 1993 DMJ [dmj] at 00:27 EDT Synchron: Using SGET and SPUT in any non-ST resolution will not crash the computer. Rather, GFA assumes that all screens are 32,000 bytes long, no matter what the resolution. If you were running in 640x480x256 (which is a 300K screen) then using SGET and SPUT would only save and restore the top 10% or so of the screen. As long as you are aware of this, you should have no problems. If you require your program to run in ST medium res, then you _really_ have nothing to worry about, as it's the resolution you're running in that counts, not what the hardware is capable of. (In this situation, anyway.) - Thanx for your thoughtful analysis! If it was of some value, great. I still haven't had a chance to delve into what those routines are doing, though. Too much other work going on. -dmj ------------ Category 22, Topic 3 Message 84 Sun Aug 15, 1993 REALM [Joey] at 03:58 EDT DMJ, I seem to remember getting error messages when using SGET and SPUT on a screen section larger then 32K. I think they work as long as you don't move more then a 32K section of the screen. BITBLT works the best, it just takes a couple hours to master it.:-) ------------ Category 22, Topic 3 Message 85 Sun Aug 15, 1993 DMJ [dmj] at 15:04 EDT Joey: I think you're confusing GET/PUT with SGET/SPUT. GET and PUT take a section of the screen, so they have to calculate the size of that section. If this size exceeds 32K, you've gone beyond the largest possible string size, which will cause GFA problems. SGET and SPUT take the entire screen, no questions asked. They _assume_ the screen is 32K, so when they move the screen into a string, all they move is 32K. They don't bother to check the screen resolution first. (GFA assumes in a _lot_ of places that screens are always 32K.) Solution: don't use SGET/SPUT, and don't use GET/PUT if the chunk you're grabbing might exceed 32K. BITBLT probably works best, with arrays as bulk storage variables. BITBLT does take some figuring out, since the examples in the GFA manual aren't exactly illustrative, but once mastered, it's a powerful tool that has a lot of hidden power. -dmj ------------ Category 22, Topic 3 Message 86 Mon Aug 16, 1993 S.GARRIGUS [Scotty] at 00:59 EDT Does anyone know why, when using EVNT_MULTI and waiting for a timer event (along with a few others like button), I get mouse droppings on the screen? I removed the timer event just to make sure and it's definitely the culprit. Is this another GFA bug? Anyone else find this problem? Scotty CMC & SRG Software ------------ Category 22, Topic 3 Message 87 Mon Aug 16, 1993 REALM [Joey] at 04:44 EDT DMJ, Your right, I was confused or half asleep!:-) It was GET and PUT causing me problems and forcing me to learn how to use BITBLT. ------------ Category 22, Topic 3 Message 88 Mon Aug 16, 1993 R.WATSON15 [Wayne Watson] at 05:15 EDT Scotty, Assuming you have your EVNT_MULTI call in a loop of some sort (Repeat..Until, etc.), then place this in the loop. It should clear it up. It is definately a GFA thing. FOR x=1 TO 5 ! <-- You may be able to use a lower value. ~WIND_UPDATE(1) ~WIND_UPDATE(0) NEXT x ------------ Category 22, Topic 3 Message 89 Mon Aug 16, 1993 DMJ [dmj] at 19:11 EDT Scotty: Mouse droppings are just another "feature" of GEM programming in GFA... For the most part, the custom form_do I use gets around the mouse droppings, but if I try really hard (with the help of some accessories) I can still cause a few. I'd love to eliminate them completely. -dmj ------------ Category 22, Topic 3 Message 90 Mon Aug 16, 1993 BALKCOM [Devin] at 21:34 EDT Vince, Thanks for the help with the BIT_BLT "snow effect". I was skeptical about using xbios(5), but it hasn't given me any problems now that I've got it set up! Thanks, Devin ------------ Category 22, Topic 3 Message 91 Tue Aug 17, 1993 S.GARRIGUS [Scotty] at 18:58 EDT Wayne, Thanks for tip! I'll give it a try and see what happens... ------------- Dmj, Yeah, what a great "feature"! I'm hoping I can get rid of it too... We'll see... Scotty CMC & SRG Software ------------ Category 22, Topic 3 Message 92 Tue Aug 17, 1993 JWC-OEO [Jon] at 22:03 EDT I've just done battle with MultiTOS which was not getting along with a program of mine if I had memory protection turned on (using a Falcon). After much hair pulling and gnashing of teeth I found out what the problem was: The compiler option "I+". My program works fine if I don't use it. I loose to mouse pointer during disk errors of course, that's why I was using it in the first place, but that's not a MultiTOS problem as such. I am using 3.5e. Has anyone tried the "I+" option under the same conditions but with 3.6? Jon ------------ Category 22, Topic 3 Message 93 Tue Aug 17, 1993 JWC-OEO [Jon] at 22:12 EDT Scotty, Another thing you might try is using longer timeout values in your EVNT_MULTI call. I got rid of most of them by just use 100 where I had been using lower numbers. The one place I have not been able to cure the mouse droppings is with the EDHACK accessory on the screen. Neither the longer timeout values or WIND_OUT()'s help with it. I'm not sure why. Jon ------------ Category 22, Topic 3 Message 94 Thu Aug 19, 1993 S.GARRIGUS [Scotty] at 20:05 EDT Hi Jon! Thanks for the advice! I'll give that a try too. Unfortunately I think mouse droppings are inevitable with GFA. It's a shame really. Scotty CMC & SRG Software ------------ Category 22, Topic 3 Message 95 Tue Aug 24, 1993 JWC-OEO [Jon] at 22:21 EDT Hi again, Reference my recent message on using the compliler I+ option with MultiTOS, memory protection, a Falcon, and GFA 3.5e... As it turns out, it is not the "$I+" option by itself that brings down the program. Things will still run fine with it _until_ a "$u" is encountered. Then everything freezes up. Experimentation shows that I do not need any $u's for simple disk stuff (write protected, etc) so this is good news to me. I get the mouse cursor for the system generated disk error alert boxes and my programs still run with memory protection on under MultiTOS. I'm still curious though, has anyone had success with _both_ the I+ and the $u compiler options and GFA 3.6? Jon ------------ Category 22, Topic 3 Message 96 Wed Aug 25, 1993 R.WILSON36 [Bob Wilson] at 18:07 EDT Jon, you can't even use $U with 3.6 reliably let alone combining it with anything. ------------ Category 22, Topic 3 Message 97 Wed Aug 25, 1993 JWC-OEO [Jon] at 23:45 EDT Bob, I see. Thanks for the reply. No need to send away for 3.6 I guess. I've fiddled a little more with the $I but no $U method of "getting along with MultiTOS and memory protection. It seems to work reliably only when the file is set for global memory access. The "no $I+ at all" method does not require this but you get the "no mouse cursor during system disk errors" problem. I think I'll go with the former for now. Jon ------------ Category 22, Topic 3 Message 98 Thu Aug 26, 1993 JWC-OEO [Jon] at 23:06 EDT The Saga of GFA BASIC and the Falcon, continued... For some reason, I can't get LPRINT to work on the Falcon. I'm hooked to a HP Deskjet 500 which works fine otherwise (it can even be turned on after the computer). In addition to LPRINT, opening a channel to "PRN:" does not work either but "LST:" does. I have v3.5e. Has anybody else had a similar problem? Jon ------------ Category 22, Topic 3 Message 99 Fri Aug 27, 1993 HUTCH [FAIR-DINKUM] at 03:27 EDT Jon -- I dunno for sure but are you positive your printer is on-line and ready for data when it is turned on _after_ the Falcon boots? All I can say is that my GFA code prints just fine printing through an OPENed channel with a Falcon. Try using OPEN "o",#1,"lst:" -Hutch- @ Fair Dinkum Tech ------------ Category 22, Topic 3 Message 100 Sat Aug 28, 1993 JWC-OEO [Jon] at 00:14 EDT Hutch, Ah, err... I'm not sure what to say except, did my message upload OK? :) At least we are in agreement. Jon ------------ Category 22, Topic 3 Message 101 Sat Aug 28, 1993 C.ROUNTREE2 [RoadKill] at 01:39 EDT I have that problem with my Desk Jet; if it isn't turned on before the computer, it wont accept any data A-tal. ------------ Category 22, Topic 3 Message 102 Sat Aug 28, 1993 V.VALENTI at 03:23 EDT Jon, I have no problem getting a mouse after a system error. All I do is activate the mouse before I do a disk call or something. Then is there is an error the mouse is already there. After the disk call I turn off the mouse again. My problem lies with the System error exiting my program when I hit Cancel, instead of continuing when its compiled. Vince ------------ Category 22, Topic 3 Message 103 Sat Aug 28, 1993 R.WILSON36 [Bob Wilson] at 10:24 EDT Hutch LST: is the parallel port according to the docs. What if teh printer is serial or the ATARI laser? How does the program handle that? I would think that LPRINT not working is a preety serious error. Given teh state of ATARI sales I doubt that it will ever be fixed either. ------------ Category 22, Topic 3 Message 104 Sat Aug 28, 1993 JWC-OEO [Jon] at 16:47 EDT C.ROUNTREE2, This problem is fixed on the Falcon. At least on my Falcon. Vince, Interesting. I have never been able to get the mouse cursor to show up for system error alert boxes on compiled programs unless the I+ option is in effect. This fits GFA's documentation (at least for versions <3.6 which I have not tried). The procedure specified in your latest ON ERROR gosub command gets called after you return from a Cancel. Bob, The fact that LPRINT and PRINT to channel "PRN:" don't work on a Falcon is a pain. You can use XBIOS(33,-1) to check if the printer is connected to the serial port instead of the parallel port and open AUX instead of LST if it is. I'm not sure how to handle the ATARI laser though. For now it cannot be connected to Falcon so you could get away with one print routine for Falcons and another one for other computers. Jon ------------ Category 22, Topic 3 Message 105 Sat Aug 28, 1993 HUTCH [FAIR-DINKUM] at 22:35 EDT Jon -- I'm not sure I know what uploaded message you are talking about. Maybe you should send me email? Bob -- Yeh, LST: is for the parallel port. How many people you know use a serial printer on their Atari? And since the Atari laser doesn't work with the Falcon anyway, it's a moot problem for now. It would be better if LPRINT worked properly, granted, but who knows if we will EVER see any more GFA updates for Atari? -Hutch- @ Fair Dinkum Tech ------------ Category 22, Topic 3 Message 106 Thu Sep 02, 1993 J.FOUCH [JIM FOUCH] at 21:19 EDT Just a note to others using GFA 3.6 on a TT. I purchased my TT a few months back (Feb. 93). I was told by a few people that I should upgrade to the new version 3.6 to take advantage of the TT's new screen resolutions and such. I do like the fact that the editor works correctly in all TT resolutions. However, the compiler is very unstable with catching errors (Great bug to have in a compiler!!). I have been using version 3.5e for about two years, and have had no real problems. I write professional business applications and can not afford to have my programs unstable. A simple solution to this problem is to return to using version 3.5e if you do not need the new screen resolutions. Note: GFA 3.5e will access the new screens, you just have to be carefull when using the GET/SGET commands. Only problem is my programs do use the GET/PUT commands. So instead of taking a chance with an unstable program, I decided to write my own code to rework the GET/PUT commands with GFA v 3.5e. Therefore, I continue to use the compiler version 3.5e. But, do all my editing of my source code with the v3.6 editor. (As to access my large screen moniterm monitor.) I have been using this method for about 3-4 months with no side-effects. Note: If anyone wants the code to rework the GET/PUT commands, send me e-mail for a free copy. Thanks, Jim Fouch Fouch Software Erie, PA ------------ Category 22, Topic 3 Message 107 Fri Sep 03, 1993 REALM [Joey] at 05:35 EDT Jim, I've never had any problem with 3.6 on my TT... but then I do all my own bug watching.:-) I know it has trouble with ERROR commands. You can use GET and PUT as long as the size of the screen piece your grabbing doesn't exceed 32K. In which cas eyou can use several PUT and GET... BITBLT seems to work much better though. ------------ Category 22, Topic 3 Message 108 Sun Sep 05, 1993 HUTCH [FAIR-DINKUM] at 01:43 EDT Jim and Joey -- What we really need is a reliable replacement for the SPUT and SGET commands. I mean, GET and PUT are great for smaller screen areas but when you have the memory and/or you need to capture or restore large blocks, SPUT and SGET are tough to beat. -Hutch- @ Fair Dinkum Tech ------------ Category 22, Topic 3 Message 109 Sun Sep 05, 1993 DMJ [dmj] at 17:25 EDT Hutch: - What we really need is a reliable replacement for the SPUT and - SGET commands. Reliable in what sense? A simple screen size calculation, malloc, and BMOVE will do the job. Things only get tricky when you try to run screen size calculations on graphics cards. A well-written GEM application, though, isn't supposed to need SGET and SPUT. Just an opinion, of course. -dmj ------------ Category 22, Topic 3 Message 110 Tue Sep 07, 1993 HUTCH [FAIR-DINKUM] at 01:34 EDT DMJ -- Well, I do not concede that "difficult" and "well written" have to be synonomous when one speaks about writing GEM code. Hey, I'm a lazy programmer... I freely admit that. That's why I never write the same piece of code twice, if I can help it, and why I also enjoy and make use of shortcuts like SPUT and SGET when the application permits. If doing so makes my program break on the 'ACME 2000GX 24-bit color card' of which there are maybe 2 or 3 users of which who would EVER try to use my software, then sorry. I guess I'll just have to live with the loss of those 2 sales. :) -Hutch- @ Fair Dinkum Tech ------------ Category 22, Topic 3 Message 111 Tue Sep 07, 1993 DMJ [dmj] at 22:11 EDT Hutch: I know what you mean about supporting _very_small_numbers_ of graphics cards. Sometimes I feel the same way. It's just that with the new work I'm doing on View II, I'm finding resolution-dependence to be a real nuisance; it gets in the way of Falcon compatibility, and I think there will be a large percentage of Falcon users who have Screen Blasters... which eliminates any dependence you might have had on Falcon hardware. Like you, though, I use shortcuts whenever I can get away with it. It makes programming _so_ much easier. I was simply pointing out that SGET and SPUT aren't exactly the best way to write an app if you want it to run on a Falcon, let alone a graphics card. -dmj ------------ Category 22, Topic 3 Message 112 Thu Sep 09, 1993 OFFY [OFFY] at 15:55 EDT What do I open to get at modem port 2 on my Mega STE? I know to open AUX: to get port 1, but I need to know how to open port 2. I've tried everything I can think of and can't get it to work. Of course, the Atari manual on the computer does not offer any assistance, and no book I have tells me either. Speak up, oh gurus of code... ------------ Category 22, Topic 3 Message 113 Thu Sep 09, 1993 J.NESS [Jim] at 17:11 EDT Offy - There is no provision in GFA for OPENing the 2nd aux port (only port, if you have a Falcon). No device name (AUX2:, for instance) has been assigned. If you're willing to go the BIOS route, you'd be dealing with with a device ID of 9. wait%=BIOS(1,9) checks whether there is a byte waiting to be read chrs%=BIOS(2,9) reads that byte BIOS(3,9,chrs%) sends one byte etc. You can also use OUT 9 and INP 9. -JN ------------ Category 22, Topic 3 Message 114 Thu Sep 09, 1993 R.WATSON15 [Wayne Watson] at 19:59 EDT OFFY, You don't have to even open the modem port to get to modem 1. All you have to do is use the OUT command, the BIOS(3,...) command or the GEMDOS(4,..) command. That is what I use and the Modem 2 port on the MSTE is device # 7. Here is a list of the other ports. | Device # | TT ST/STE MSTE Port --------------------------- 1/6 1 1/6 Modem 1 7 - 7 Modem 2 8 - - Serial 1 9 - 9 Serial 2 The 1/6 is device 1 or device 6. Either one will work on the MSTE/TT. Not sure about the regular ST. I use 1 for modem 1. Also, if you use 1 and have the modem CPX setup to use Moedm 2/Serial 2, it will redirect input/output to those ports. This works for me in GFA basic. I have seen text that gives different device numbers for the different ports but, I know that using BIOS(3,7,x) sends data out to modem 2 on my MSTE. The only advantage with using the OPEN #x, "AUX:" command is sending a whole string but, you loose the flexability of going to different device numbers (ports). ------------ Category 22, Topic 3 Message 115 Thu Sep 09, 1993 R.MAGDICH [Pizza Dude] at 20:54 EDT While using the command 'EXIST' to check for the existance of a file, I was wondering if there is a way to check for the existance of a path? I tried to use 'IF EXIST' with a folder path only (C:\TEST\) and with a wildcard attached (C:\TEST\*.*) to no avail. (Creating a file and then testing for it is out, so...) Ideas, anyone? ------------ Category 22, Topic 3 Message 116 Thu Sep 09, 1993 HUTCH [FAIR-DINKUM] at 23:52 EDT DMJ -- Right you are, 100% about resolution-independent programming. It really is _the_ way to go nowadays, what with so many different resolutions available and it all ties into the MultiTOS requirements as well. And I agreee... SPUT and SGET are non-starters for Falcon application programming. Ah, technology is grand, ain't it? :) Cheers, -Hutch- @ Fair Dinkum Tech ------------ Category 22, Topic 3 Message 117 Fri Sep 10, 1993 CBARRON at 01:32 EDT Perhaps examining the results of looking for it, via gemdos's fsfirst() function. fsfirst("C:\TEST",16) will return an error code if there is no C:\TEST. If there is you might have to check the attr. bit of the DTA.... How to do it efficiently in gfa, not my bag... ------------ Category 22, Topic 3 Message 118 Fri Sep 10, 1993 R.WATSON15 [Wayne Watson] at 05:36 EDT There are at least 2 ways to find a folder. One is to create a dummy file and then test for it. The other is to use the FSFIRST and FSNEXT commands. FUNCTION test(f$) f$=f$+CHR$(0) ~FSETDTA(BASEPAGE+128) e%=FSFIRST(f$,16) DO UNTIL e% e%=FSNEXT() LOOP RETURN e% ENDFUNC PROCEDURE call_test f$="K:\TEMP" a%=@test(f$) ! a% will be -49 if it found the folder and ' ! -33 if it did not. -33 because the file TEMP ' ! was not found. ' f$="K:\TEMP\*.*" ! a% will be -49 if it did found a file in the a%=@test(f$) ! folder and -34 if it did not. -34 because the RETURN ! path was not found. Hope that helps. ------------ Category 22, Topic 3 Message 119 Fri Sep 10, 1993 DMJ [dmj] at 22:45 EDT Pizza Dude: You can use the fsfirst() call to search for a directory with a given name. It's not as convenient as a simple EXIST function, but it does work. -dmj ------------ Category 22, Topic 3 Message 120 Sat Sep 11, 1993 RANDYB [Randy] at 10:37 EDT Pizza Dude, You can also use x%=GEMDOS(59,L:V:path$). Just be sure that path$ is terminated with a CHR$(0). If the folder is found, x%=0, otherwise x=-34. The side effect to this is that you end up in the folder you were looking for if it was found (same as CHDIR). CHDIR however just returns an error if the folder isn't found. Hope this helps. C-ya! Randy ------------ Category 22, Topic 3 Message 121 Sat Sep 11, 1993 OCEANBLUE [Cerulean] at 15:12 EDT I have some questions about the XBIOS(15) (Rsconf) call. GFA doesn't do much of a job in documentin the XBIOS calls in the manual. I USED to have some info I got from the Michtron RT, but seem to have misplaced it. Anyway, could someone post detailed info on the XBIOS(15) call? Like how to set parity, baud rate, etc? ------------ Category 22, Topic 3 Message 122 Fri Sep 24, 1993 JWC-OEO [Jon] at 23:54 EDT Hi all, I am having trouble finding a data file for a program of mine when it's run as a TOS/TTP program under MultiTOS. It's kept in the same path as the program. In other circumstances I can just use SHELL_READ() to look for the path of my program but this way what shows up is C:\MULTITOS\MINWIN.APP. I tried looking at the environment strings (BASEPAGE + 44) using the example in the Michtron 3.0 manual and found my program's path near the end showing as something like AGEV=xxxxx. Unfortunaltly, this method only works without memory protection on my Falcon. With memory protection on the program gets killed by MultiTOS for PID 11 OR 12ing (whatever those are). Does anyone know a reliable way to find a programs own path when launched this way (TOS/TTP under MultiTOS)? Jon ------------ Category 22, Topic 3 Message 123 Sat Sep 25, 1993 M.SLAGELL [Mark] at 10:40 EDT Jon, to get around memory protection you might try WIND_UPDATE(3) first, then WIND_UPDATE(2) after you're done peeking in the 'prohibited' areas. I'm not sure this always works, but it's worth a try. Also -- if you install the program in question as "application/full path" insead of "top window/file name only" then your program need only look in the default directory, DIR$(0). ------------ Category 22, Topic 3 Message 124 Sat Sep 25, 1993 JWC-OEO [Jon] at 15:24 EDT Mark, Thanks for the reply. DIR$(0) and GEMDOS(&H19) do continue to function but can't be counted on to return the program's path during drag and drop operation. Using "application" instead of "top window" does not help here either because with TOS & TTP programs the application reported (at least by SHEL_READ) is MINWIN.APP, not my program. I'll tried your WIND_UPDATE suggestion but it did not help. Jon ------------ Category 22, Topic 3 Message 125 Sat Sep 25, 1993 OCEANBLUE [Cerulean] at 16:08 EDT I have some questions about the XBIOS(15) (Rsconf) call. GFA doesn't do much of a job in documentin the XBIOS calls in the manual. I USED to have some info I got from the Michtron RT, but seem to have misplaced it. Anyway, could someone post detailed info on the XBIOS(15) call? Like how to set parity, baud rate, etc? ------------ Category 22, Topic 3 Message 126 Sat Sep 25, 1993 JWC-OEO [Jon] at 16:15 EDT Hi again, It seems that I've solved the problem I was having getting to the "AGRV=" part of the envirnment string under MultiTOS with memory protection. My test program was not only checking the env string in my programs base page but also that of the calling program (in this case MINWIN.APP). I had thrown this in out of curiosity sometime earlier and forgotten about it and that is where the error was coming from. Anyway, my question now becomes; what's the best way to determing if MultiTOS is running, and what's the most reliable way to get at the ARGV information? Jon ------------ Category 22, Topic 3 Message 127 Sat Sep 25, 1993 M.SLAGELL [Mark] at 20:21 EDT Jon, unless MINWIN has a facility to tell programs where they've been run from, it looks like you're stuck. All I can think of at this point is to write something to search for the program filename, and that's a pretty desparate and unreliable measure. As for the WIND_UPDATE thing, it was part of a group of mods I did to something I wrote for a Falcon user. I was able to overcome the problem but I'm not sure which change did it; and not owning a Falcon myself, I won't be able to trace it down further. Sorry it didn't work. And it was in C anyway as I recall, not GFA.... ------------ Category 22, Topic 3 Message 128 Sat Sep 25, 1993 JWC-OEO [Jon] at 20:54 EDT Mark, Thanks again for your feedback. As you probably saw when you uploaded message 127, message 126 explains how I more or less solved the problem (or actually, eliminated the extra dumb stuff that was preventing the already valid solution from working). By the way, I left out an "I" in my previous messages. The program that runs TOS/TTP programs in a window under MultiTOS is minIwin.app. Jon ------------ Category 22, Topic 3 Message 129 Sat Sep 25, 1993 R.BOWEN1 [Bob, SLC, UT] at 22:59 EDT Cerulean, merge this .LST to change baud rates. PROCEDURE baud(rate%) ' *** change baudrate LOCAL bd% SELECT rate% CASE 19200 bd%=0 CASE 9600 bd%=1 CASE 4800 bd%=2 CASE 3600 bd%=3 CASE 2400 bd%=4 CASE 2000 bd%=5 CASE 1800 bd%=6 CASE 1200 bd%=7 CASE 600 bd%=8 CASE 300 bd%=9 CASE 200 bd%=10 CASE 150 bd%=11 CASE 134 bd%=12 CASE 110 bd%=13 CASE 75 bd%=14 ! old TOS (bug) : results in 120 baud instead of 75 baud !! CASE 50 bd%=15 ! old TOS (bug) : results in 80 baud instead of 50 baud !! ENDSELECT ~XBIOS(15,bd%,-1,-1,-1,-1,-1) RETURN ------------ Category 22, Topic 3 Message 130 Sun Sep 26, 1993 V.VALENTI at 03:41 EDT Jon, I believe you can check the cookie for MiNT to determine Version and if it is in the system. Hopes this helps Vince Valenti ------------ Category 22, Topic 3 Message 131 Sun Sep 26, 1993 DMJ [dmj] at 11:20 EDT Jon: To see if you have GEMDOS-level multitasking, look for a "MiNT" cookie. All of the MiNT multitasking functions calls are documented in the Compendium. To see if you have AES-level multitasking, check the second (I think) word of the AES global array. It will be -1 if you have multitasking at an AES level. If you want to shut off multitasking for a while, use supervisor mode. You can do this in GFA by using the GEMDOS(32) call: ssp%=GEMDOS(32,L:0) ! Go into supervisor mode... ' ' Stuff you don't want interrupted goes here... ' ~GEMDOS(32,L:ssp%) ! Exit supervisor mode. The MiNT/AES thing was posted by someone else (Eric Smith?) in another topic just a few days ago... hopefully I didn't garble the information. -dmj ------------ Category 22, Topic 3 Message 132 Wed Sep 29, 1993 JWC-OEO [Jon] at 23:07 EDT Vince and DMJ, Thanks for the info. I think I'm going to have to see if I can get hold of a copy of the Atari Compendium somewhere. Jon ------------ Category 22, Topic 3 Message 133 Thu Sep 30, 1993 B.LIKENS at 02:13 EDT Hello all, I'm interested in the code required to copy a file from a directory to a disk drive. I want to copy all programming files to an external ramdisk which initializes after GEM, HotWire, etc. Am probably overlooking the obvious, but thanks on frontend. ------------ Category 22, Topic 3 Message 134 Thu Sep 30, 1993 A.HAJNAL [Axel] at 04:29 EDT Greeting! I'm trying to figure out a way to tell if the computer has an external drive attached, or if it has only an internal drive. I do this to some extent using the BIOS(11) call, but it shows drive "B" as being connected. (I don't have any eternal drives.) Is there any way to determine whether drive "B" is real? Also, does anyone know the structure and contents of the drive parameter block [BIOS(11)]? Thanks -Axel A.HAJNAL P.S. DMJ- A very belated thanks for help with the PUT command. I've been out of town for a while. Your explanation cleared everything up. ------------ Category 22, Topic 3 Message 135 Thu Sep 30, 1993 R.BOWEN1 [Bob, SLC, UT] at 05:28 EDT B.LIKENS, I hope this is what you are looking for, if you want all files from a given directory that is a bit more work. If your file names are constant then just call the procedure for each one. filecopy("C:\source.txt","D:\dest.txt") PROCEDURE filecopy(source$,destination$) OPEN "I",#1,source$ OPEN "O",#2,destination$ lof%=LOF(#1) WHILE lof%>32000 ! 32k read\writes PRINT #2,INPUT$(32000,#1); SUB lof%,32000 WEND PRINT #2,INPUT$(lof%,#1); CLOSE #1 CLOSE #2 RETURN A bit happy, Robert Bowen ------------ Category 22, Topic 3 Message 136 Thu Sep 30, 1993 J.FOUCH [JIM FOUCH] at 21:16 EDT Axel, Try this; FUNCTION drive.mask LOCAL drive.mask% drive.mask%=BIOS(10) ! set up drive mask IF DPEEK(&H4A6)=1 ! only one physical drive connected drive.mask%=BCLR(drive.mask%,1) ! clear bit for drive "B" ENDIF RETURN drive.mask% ENDFUNC This should work on all versions of TOS. ------------ Category 22, Topic 3 Message 137 Fri Oct 01, 1993 DMJ [dmj] at 00:19 EDT Axel: [Long message warning] You can check for the _real_ number of floppy drives connected by looking in the nflops system variable, like this: nflops&=DPEEK(&H4A6) If this value is 1, there is no "real" B drive. If it's 2, then the B drive is actually there. By the way, BIOS(11) is the kbshift() function, which returns the status of the various shift keys. BIOS(10) is drvmap(), which returns a bit map of connected drives. Originally this was just a word-size value, since only drives A-P were allowed, but with MultiTOS drive letters were extended all the way to Z, so be sure to check twenty-six bits, rather than just 16. And remember that the U drive is the special "MiNT" drive. As for the "drive parameter block"... I presume you mean the BIOS parameter block, the address of which is returned from BIOS(7)? Here it is: +0 [2 bytes] Bytes per sector. +2 [2 bytes] Sectors per cluster. +4 [2 bytes] Bytes per cluster. +6 [2 bytes] Sectors in root directory. +8 [2 bytes] Sectors per FAT. +10 [2 bytes] Sector number of second FAT. +12 [2 bytes] Sector number of first data sector. +14 [2 bytes] Clusters on disk. +16 [2 bytes] Flags - bit 0 determines FAT type: 0: 12-bit FAT 1: 16-bit FAT After calling this function, a media change MUST be forced; failure to do so may cause GEMDOS not to recognize when a disk is swapped, resulting in corruption of the inserted disk. (I've lost disks this way, it IS important.) Here's how you do force a media change in GFA: Procedure Force_mediach(Drive&) ! Force media change. Local F$ ' Drive& = drive number (0 = A) to force media change on. ' Inline Mediach%,12 ' F$=Chr$(Drive&+65)+":\*.*"+Chr$(0) ! Search mask (anything). {Mediach%+2}=Lpeek(&H47E) ! Insert old hdv_mediach ' vector in routine. ' Slpoke &H47E,Mediach% ! Set vector to our routine. ~Gemdos(78,L:V:F$,-1) ! fsfirst search (forces OS to read Bios(9)). F$="" ! Clean up local variable. ' Return The INLINE contains the following short assembly language routine: * Media Change routine for ReNameIt! 1.3 (and 1.4, 1.5). begin move.l #0,$47E.w ; Restore original vector. moveq #2,d0 ; Return the fact that it HAS changed. rts ; Done, return. It assembles into the following code (listed as HEX words): 21FC 0000 0000 047E 7002 4E75 Just stick those six words into the INLINE and you're ready to go. Now, here's basically how this routine works. In the system variables of TOS, there's a pointer to the actual BIOS(9) mediach() routine. When a BIOS(9) is called, the BIOS looks at $47E to see where the routine is. Hard drives and other media patch into this "vector" and check if the requested drive is theirs; if so, they process the call how they want to, but if the requested drive is not theirs they just pass it back to the original vector. (The other hdv_ vectors also work this way, but that's another story...) The Force_mediach procedure above replaces the $47E hdv_mediach vector with a short routine that will always return 2 for BIOS(9) and then restore the original pointer. Once installed, all that remains is to call some GEMDOS function that will, internally, call BIOS(9). That's what the GEMDOS(78) call (fsfirst) does. The replacement routine re-installs the original routine, so the GFA program doesn't have to do that once the GEMDOS call is made. This routine might not work under MultiTOS, since it's possible another program might interrupt with a disk function between the time the hdv_mediach vector was changed and the time the GFA program issues the fsfirst (which will cause GEMDOS to do a BIOS(9), resetting the drive). This can be alleviated in two ways: make sure the entire Force_mediach runs in supervisor mode (MultiTOS won't interrupt a program running in supervisor mode), or change the short assembly routine so it checks for the drive before returning 2 (jumping to the original vector if the drive isn't the one that needs forcing). This was probably more than you wanted to know, but there it is. The Compendium has a wonderful two-page listing which shows how to do the force media change, but it's all assembly... not too useful to a lot of GFA programmers. I used the short assembly routine above because you can't DO this entirely in GFA. -dmj ------------ Category 22, Topic 3 Message 138 Fri Oct 01, 1993 A.HAJNAL [Axel] at 03:33 EDT Jim, dmj- Thanks for the speedy response. I've almost finished some software that uses a non GEM interface, so I've been trying to avoid GEM's intrusion, since it can cause problems when 'warning boxes'(i.e.Disk error alerts, Disk change alerts,etc.) appear on screen. The problem is, the user never sees the alert, since I am using the XBIOS(5) call to switch between two different screens. When the alert box comes up, it does so on the hidden screen, causing the system to apparently 'hang' until tyhe RETURN key is pressed. Anyway, to get back to the original point, if the existance of drive B acn be determined, I can both avoid apparent system 'hang', and also keep the alert boxes consistent throughout. Thanks :) -Axel A.HAJNAL P.S. Did I say BIOS(11) in my original post? I meant BIOS(10). ------------ Category 22, Topic 3 Message 139 Sat Oct 02, 1993 B.POSTON [Barney] at 00:56 EDT I'm having trouble getting a GFA 3.5 program to print when run on a Falcon. Is extra code needed to get the Falcon to talk to the printer? Thanks in advance! Barney ------------ Category 22, Topic 3 Message 140 Sat Oct 02, 1993 OCEANBLUE [Cerulean] at 01:48 EDT Thanks, Bob... actually, I KNOW how to change baud rates... I used to have some code I got from the Michtron RT that showed me everything I need to know, but at the time I only needed to set baud rates, and I've misplaced the other information. I need to know how to set the parity, stop bits, etc. Anyone have detailed information on how to use XBIOS(15)? ------------ Category 22, Topic 3 Message 141 Sat Oct 02, 1993 DMJ [dmj] at 11:25 EDT Axel: Checking for the physical presence of drive B will eliminate the disk- switching alerts, but it won't eliminate "disk-error" alerts. To do that you need to redirect the etv_critic vector to a routine that simply returns -1. Here's how you do this in GFA: etv_critic%=LPEEK(&H404) ! Save old vector. new_critic%=&H70FF4E75 ! New routine for etv_critic. SLPOKE &H404,new_critic% ! Install new routine. ' ' Do file access without worrying about "disk-error" alerts. ' SLPOKE &H404,etv_critic% ! Restore old routine. The assembly-language routine in new_critic% is just this: moveq #-1,d0 ; Return -1 (abort). rts ; All done. This method is not guaranteed to work with MultiTOS, as changing etv_critic affects ALL programs. And what if two programs tried to do this at once? MultiTOS sure can be a nuisance sometimes. -dmj ------------ Category 22, Topic 3 Message 142 Sun Oct 03, 1993 R.BOWEN1 [Bob, SLC, UT] at 01:23 EDT Cerulean, More I was able to dig up on XBIOS(15) ~XBIOS(15,b%,f%,u%,r%,t%,s%) f%= Hanshake mode 0=None, 1=XON/XOFF, 2=RTS/CTS, 3=BOTH?? u%= MFP registers in binary format &x.....0.. No parity &x.....10. Odd parity &x.....11. Even Parity &x...01... 1 stop bit &x...10... 1.5 stop bits &x...11... 2 stop bits &x.00..... 8 data bits &x.01..... 7 data bits &x.10..... 6 data bits &x.11..... 5 data bits &x0..00... Synchronized, frenquency form TC/RC &x1..00... Synchronized, divided by 16 r%,t%,s%= MFP-registers rsr,tsr,scr No info available Can anyone fill in the gaps here..? Robert Bowen ------------ Category 22, Topic 3 Message 143 Sun Oct 03, 1993 JWC-OEO [Jon] at 20:04 EDT Barney, LPRINT does not work on the Falcon. A simple alternative is to open a channel to the "LST:" device (parallel port) and use PRINT # instead. Don't use the "PRN:" device, that's the same one GFA is failing to open properly for LPRINT. (see the section in the manual on the OPEN command for more info) The easiest way to do this might be to add an lprint proceedure to your program such as: PROCEDURE lprint(txt$) OPEN "O",#5,"LST:" PRINT #5,txt$ CLOSE #5 RETURN Then just put a "@" in front of all your current LPRINTs and parentheses (sp?) around the stuff being printed. You can use XBIOS(33...) to check if the printer is hooked to the serial port instead of the parallel port and print to "AUX:" if it is. Jon ------------ Category 22, Topic 3 Message 144 Mon Oct 04, 1993 B.POSTON [Barney] at 00:09 EDT Jon, Thanks a bunch for the Falcon/GFA printing info. I'll try what you suggested and get back to you. I'm not sure what you are suggesting with the XBIOS(33....) and AUX: but maybe I wont need that. Is this something else peculiar to the Falcon? What happens to the hundreds of GFA programs out there with LPRINTs? Barney ------------ Category 22, Topic 3 Message 145 Mon Oct 04, 1993 B.POSTON [Barney] at 19:49 EDT Jon, Using your idea on my Falcon/LPRINT/GFA problem, what do I do with escape sequences like: "LPRINT CHR$(27)+CHR$(65);" Thanks, Barney ------------ Category 22, Topic 3 Message 146 Mon Oct 04, 1993 DMJ [dmj] at 22:33 EDT Barney: - What happens to the hundreds of GFA programs out there with - LPRINTs? They die on the Falcon. They're not alone... lots of programs don't like the Falcon for one reason or another. It was the same with the TT; GFA needed updating because it "assumed" too much, and when those assumptions became invalid, GFA programs started dying. While I don't think it's likely GFA will get updated to use the Falcon, because GFA allows you access to all of the operating system, you can get to the new features of the machine. This includes all the new AES functions, MiNT calls, and XBIOS. It is, of course, possible to write GFA programs that work on the Falcon without doing anything special. ReNameIt!, which is hardly more than stock AES calls in GFA, runs on the Falcon. -dmj ------------ Category 22, Topic 3 Message 147 Tue Oct 05, 1993 RHFACTOR at 00:54 EDT Hi DMJ Does the 'media change' code that you posted clear the 'folder count' previously accessed. (For those of use with TOS 1.2 or < ) ?? RJH ------------ Category 22, Topic 3 Message 148 Tue Oct 05, 1993 B.LIKENS at 02:29 EDT To all who responded so incredibly quickly to my request for help. THANKS! I've got to go off-line to exam the code but I know I've got what I need to do the job now. Thanks again. ------------ Category 22, Topic 3 Message 149 Tue Oct 05, 1993 V.VALENTI at 21:16 EDT Does anybody have any code or know how to do wireframe, polygon, or texture map graphics animations... Any help would be appreciated. Vince /s ------------ Category 22, Topic 3 Message 150 Wed Oct 06, 1993 DMJ [dmj] at 00:51 EDT RJH: No, the media change code doesn't reset the folder count. To do that requires some serious playing around with GEM's memory allocation. If you're having a problem running out of "folders", all I can suggest (short of upgrading to TOS 1.4, or better yet, 2.06) is to run FOLDRXXX.PRG in your AUTO folder. Before I upgraded, I ran it with 80 folders... and never had a problem. Usually the only reason to worry about the folder count is if you're doing some sort of recursive directory searching on a hard drive. Most applications shouldn't have to worry about it. -dmj ------------ Category 22, Topic 3 Message 151 Wed Oct 06, 1993 M.HASKINS2 [SkyRider] at 10:54 EDT >Does anybody have any code or know how to do wireframe, polygon, or >texture map graphics animations... Vince - the wire frame model is a series of 3D cordinates. The computer screen is 2D. Using trigonometry, the screen coordinates are calculated, then lines drawn between these points. For larger number of points, this takes time. One speed up solution, if the application allows, is save the series of pictures and play them back - long time creating but nice show. if it is like game peices shown from various angles, you can also create them first, then save the series and PUT the required one on the screen as needed. This stuff needs FAST processors, BASIC -(even GFA) is too slow to do it in real time, unless the objects have small number of polygons. I created a nice map of USA that can be rotated & scaled -- but it takes up to 1 second to recalculate/redraw on a 40 MHz 386DX in QuickBasic - MUCH longer on 8MHz ST using GFA. - Mike - ------------ Category 22, Topic 3 Message 152 Wed Oct 06, 1993 DMJ [dmj] at 19:15 EDT Vince: What you want is a complete 3D animation engine, correct? I have a book I bought in England that explains 3D solid polygon animation on the ST. The only problem is, it's all in assembly. And I haven't had time to type in all the code, and I was too cheap to buy the disk. As for texture mapping... that's a whole new ball of wax. 3D graphics programming is hard enough (loads of matrix math) without throwing in the texture mapping. -dmj ------------ Category 22, Topic 3 Message 153 Thu Oct 07, 1993 V.VALENTI at 00:55 EDT 'DMJ and Mike, Thanks for your help. I found an old book over at my local atari dealer, by Abacus on 3D wireframe. I think I have a way to do the Texture one . But, I need to know how to manipulate vectors (simple vectors) before I can 'fill' it with the texture. I think the book has what I need. However if I still have trouble figuring it out I may still need some source. (Assembly or 'C' is fine) Thanks, Vince ------------ Category 22, Topic 3 Message 154 Thu Oct 07, 1993 V.VALENTI at 00:59 EDT Hello, I have recently finished tearing apart the interrupt sample player for GFA. I uploaded a sample player a while ago "DO_SOUND", and wonder if anybody would be interested if I uploaded the new version. New version Features: Serial port does not lock-up anymore. Works in monochome without hanging. Requires 33% less CPU time to play at the same freq. Is now falcon compatible. And, I have included a loop mode function. Let me know... Vince ------------ Category 22, Topic 3 Message 155 Thu Oct 07, 1993 S.GARRIGUS [Scotty] at 19:52 EDT Vince, If your able to, you might want to check out Start Magazine w/Disk, May through July 1989. They feature both GFA Object and GFA Vector, programs used to create and animate 3D objects for use in GFA Basic. And I would definitely like to see your new version of DO SOUND! Scotty CMC * SRG Music * SRG Software * Processor Direct * GEnie Lamp ------------ Category 22, Topic 3 Message 156 Thu Oct 07, 1993 DMJ [dmj] at 20:59 EDT Vince: I'm not familiar with DO SOUND. It's code to play digitized sound in the background of GFA programs? ST or STe (or both)? Just curious... -dmj ------------ Category 22, Topic 3 Message 157 Thu Oct 07, 1993 K.OLSON10 [KenO.] at 22:54 EDT Vince, Sense I dusted off my copy of GFA to fix a printer problem. Yes send up the the new version of DO_SOUND. KenO. :) ------------ Category 22, Topic 3 Message 158 Fri Oct 08, 1993 V.VALENTI at 02:36 EDT Great! Let me archive it and I'll upload it tomorrow. DMJ, The routine was designed by 2-Bit systems to be used with the Replay cartridge. Later, it was modified by Doug at Michtron (about 2 years ago) so it would work in an interrupt (Timer A). As we started to use it many bugs started to show themselves, so I decided it was time to dig in. The routine is designed to use the Yamaha sound chip to produce digitized sounds. It will work on any Atari computer. Yes, it is designed to play in the background. There are two versions, one that uses signed numbers and one that uses unsigned numbers. Vince ------------ Category 22, Topic 3 Message 159 Fri Oct 08, 1993 R.BOWEN1 [Bob, SLC, UT] at 06:43 EDT I am pleased that V.BALENTI helped me out with my compression needs with a simple explanation on howto compress pictures. However I still need something to compress TEXT files. Anythin..? P.S. Valenti, I improved that sample a few ways! Thanks again. ------------ Category 22, Topic 3 Message 160 Fri Oct 08, 1993 DMJ [dmj] at 20:31 EDT Vince: It's actually very easy to use a single routine to play signed and unsigned samples... that's how the sound viewer in View II works. To convert signed to unsigned (or vice versa) just toggle the high bit of every byte. Then you only have one routine, plus a routine to convert signed to unsigned (or the other way around). FWIW, the sound routines I used in Sound Lab are loosely (very loosely) based on some 2-Bit Systems routines I stumbled across a long time ago. -dmj ------------ Category 22, Topic 3 Message 161 Sat Oct 09, 1993 V.VALENTI at 03:43 EDT Dmj, When I modified the routine, I was looking to trim any code to speed up the interrupt call. One thing I found was that before the routine called the table, it signed the value first. It was only 4 extra clocks, but I figured I could shave that also and only use signed values in my program + I could use the STE's DMA and Falcon's SMDA without any conversions to the sample for the old ST. I kept a version with unsigned, just so I could replace that player with my previous programs which used unsigned values. vince PS the file is in the Library #30326 ------------ Category 22, Topic 3 Message 162 Sat Oct 09, 1993 V.VALENTI at 03:47 EDT Bob, I would be interest to see what you did with that commpression routine for graphics. As far as text, is not the most common value, 32 for a SPACE. Maybe you could use that to drop the size of the text file. Vince ------------ Category 22, Topic 3 Message 163 Sat Oct 09, 1993 DMJ [dmj] at 12:20 EDT Vince: I think you misunderstand. Converting the sample from unsigned to signed shouldn't be done during the playback routine; it should be done when the sample is first loaded into memory. That way it's only converted _once_, but can be played many times. -dmj ------------ Category 22, Topic 3 Message 164 Sat Oct 09, 1993 R.BOWEN1 [Bob, SLC, UT] at 16:49 EDT Vince, I just analyzed the pic for most popular value as some dark pictures had more 255 values than 0, first byte in a file is the value replaced by the flag byte. Rob ------------ Category 22, Topic 3 Message 165 Sat Oct 09, 1993 R.LUNSFORD2 at 21:09 EDT Anybody know how to use Xbtimer to set an interrupt in GFA? I tried, but I don't know what to pass as the address of the routine to be called on the interrupt. Any other method would be fine, I just want some code that will interrupt and play a sample at the end of the previous sample. Russ ------------ Category 22, Topic 3 Message 166 Sat Oct 09, 1993 DMJ [dmj] at 23:04 EDT Russ: You can't have a GFA routine run from an interrupt. GFA procedures expect certain things to be in certain CPU registers, and so on... this makes it hard or almost impossible to have anything call a GFA BASIC subroutine except a GFA program. (You can't write a Warp 9 Extend-O-Save module in GFA for similar reasons.) If you want to do Xbtimer programming, learn assembly. -dmj ------------ Category 22, Topic 3 Message 167 Sun Oct 10, 1993 V.VALENTI at 00:16 EDT DMJ, Ohh, ok. All the sounds I have had have been dedicated to use the Signed routine now and I dont play unsigned samples anymore. That way I did not have to modify the sample I just press Control-I in the Replay Editor Russ, Try to download D_SOUND2. And tell me exactly what you need to do. D_sound controls the xtimer (TIMER A) in assembly to run the sample. You could control the progress through POKES in GFA. Vince ------------ Category 22, Topic 3 Message 168 Sun Oct 10, 1993 DMJ [dmj] at 12:10 EDT Vince: You're still using the Replay Editor? Ack... I can't stand the Replay Editor, now that I have some "real" software. -dmj ------------ Category 22, Topic 3 Message 169 Sun Oct 10, 1993 R.LUNSFORD2 at 14:01 EDT Dmj, Already know a little assembly, was just hoping it could be done in GFA. What about C? Vince, Will check it out. Thanks, Russ ------------ Category 22, Topic 3 Message 170 Sun Oct 10, 1993 JWC-OEO [Jon] at 15:59 EDT Barney, You probably have worked out something like this for yourself by now but just in case... The lprint proceedure I suggested _should_ have been something like: PROCEDURE lprint(txt$,return!) OPEN "O",#5,"LST:" IF return! PRINT #5,txt$ ELSE PRINT #5,txt$; ENDIF RETURN This properly handles those cases that you do not want a return and line feed at the end of your printed line. So, the answer to your question would be: @lprint(CHR$(27)+CHR$(65),FALSE) Jon ------------ Category 22, Topic 3 Message 171 Sun Oct 10, 1993 B.POSTON [Barney] at 18:25 EDT Jon, Yes sir, I did work it out but not quite as elegantly as you did. Had to create several procedures to handle text, with and without returns, calculated numbers, with and without returns, one to set tabs, and one for print using. A real programmer could have done it much more efficiently, I'm sure, but now it's working and I appreciate you for getting me on the right track. What does JWC-OEO stand for? Are you the sysop here? Barney ------------ Category 22, Topic 3 Message 172 Sun Oct 10, 1993 R.LUNSFORD2 at 20:49 EDT Vince, I downloaded your source and can't get it to work. I have a Falcon and I keep getting bombs. First I get two bombs (I think), then if I run it again, I get quite a nice line of bombs...the samples do play, however... Russ ------------ Category 22, Topic 3 Message 173 Mon Oct 11, 1993 DMJ [dmj] at 22:08 EDT Vince: I've found my own digital sample routines didn't work properly on the Falcon... I had to check for Falcon hardware and use a different routine if they were available. -dmj ------------ Category 22, Topic 3 Message 174 Tue Oct 12, 1993 R.LUNSFORD2 at 02:35 EDT dmj, Do you know how GFA does it's joystick routines? I've been trying to figure out how to use the joystick in C or assembler, and have had no luck so far. Russ ------------ Category 22, Topic 3 Message 175 Tue Oct 12, 1993 V.VALENTI at 03:28 EDT dmj and russ, That is strange, maybe the EXEs I have sent you are the wrong ones. I fixed the problem with the Falcon. The two bombs, came from the way Two-bit addressed the sound chip. they used MOVEP.L and started at $ff8800. ff8800 +0 and +2 are for the Sound Chip. +4 is the shadow of +0 and +6 is shadow of +2. These worked fine up to the TT. The falcon does not have shadow registers on the sound chip, so you must not use the shadow or TWO BOMBS (bus error). I removed the MOVEP.L and replaced it with two MOVEP.W . That cleared it up. I have tested it on several falcons, including some at the gendale show. Vince PS. You did download DSOUND2.ARC not DSOUND.ARC correct? ------------ Category 22, Topic 3 Message 176 Tue Oct 12, 1993 DABRUMLEVE [kidprgs] at 08:59 EDT Russ, GFA 3.x and up have STICKx commands which return the positions of joystick 1 & 2 effectively. In versions prior to 3.x, you can PEEK into the information you need. It's so easy, I had a 7-year-old writing joystick arcades. ------------ Category 22, Topic 3 Message 177 Tue Oct 12, 1993 BALKCOM [Devin] at 20:54 EDT Does anybody know how to print a file using GDOS through GFA? I've been trying to use v_output_window, but there is no effect. I haven't had any trouble printing circles, boxes, etc, but I'd like to be able to print a bit image file. I don't want to use v_bit_image because that seems to require saving the file as an image first. Thanks, Devin ------------ Category 22, Topic 3 Message 178 Wed Oct 13, 1993 R.LUNSFORD2 at 00:37 EDT DABrumleve, I know GFA's stick commands are easy, I've been using them for quite a while. That's why I wanted to know some C or Assembler to address it in generally the same manner. I've seen a few routines, but they broke with the falcon...GFA's didn't. Russ ------------ Category 22, Topic 3 Message 179 Wed Oct 13, 1993 DMJ [dmj] at 19:08 EDT Vince: Thanks for the tip on the shadow registers not being present on the Falcon... I wondered what was causing the foulup. I could rewrite the routines to avoid using the shadow register... at the cost of slowing it down quite a bit. I don't if it's worth it, if I have Falcon sound routines available as well. Guess I was too pressed for time when writing the code to figure out why it wasn't working. I did download DSOUND2, but being incredibly busy recently I haven't had a chance to look at it yet. -dmj ------------ Category 22, Topic 3 Message 180 Wed Oct 13, 1993 R.LUNSFORD2 at 19:48 EDT Vince, Not sure if I already responded, but I did download Dsound2.. Russ ------------ Category 22, Topic 3 Message 181 Thu Oct 14, 1993 JWC-OEO [Jon] at 00:28 EDT Barney, No, I'm not a sysop. JWC-OEO is just (are just?) initials. Jon ------------ Category 22, Topic 3 Message 182 Thu Oct 14, 1993 V.VALENTI at 15:26 EDT Russ, Hmm, maybe it doen't like GFA interp. on the Falcon. All the tests I have tried have been compiled. Vince ------------ Category 22, Topic 3 Message 183 Thu Oct 14, 1993 R.LUNSFORD2 at 18:20 EDT Vince, I'll test it compiled and let you know what happens... Russ ------------ Category 22, Topic 3 Message 184 Thu Oct 14, 1993 V.VALENTI at 21:33 EDT Russ, I was thinking, do you want to use the Yamaha sound chip with your falcon, or would you like to use the SDMA. Vince ------------ Category 22, Topic 3 Message 185 Fri Oct 15, 1993 R.LUNSFORD2 at 00:24 EDT Vince, preferably, the SDMA.. Russ ------------ Category 22, Topic 3 Message 186 Fri Oct 15, 1993 R.LUNSFORD2 at 00:30 EDT Vince, both programs in the archive did fine compiled, but still bomb in the interpreter... Russ ------------ Category 22, Topic 3 Message 187 Fri Oct 15, 1993 V.VALENTI at 21:40 EDT Russ, That's funny that it bombs in the interpreter. AAbout the SDMA. It is a series of XBIOS calls that you can use directly from GFA Basic. I will have to fetch them but this is roughly how it would work. -lock the sound (so other programs cannot use the sound commands.) -connect the desired input to the desired output. -set rate -run sample -unlock sound (when exiting program or when trying to create a multi tasking program so other programs can now use sound) If you have the Compendium, it is all in there. If not, just leave me a note on what you want to do, and I'll look it up. Vince ------------ Category 22, Topic 3 Message 188 Wed Oct 27, 1993 JWC-OEO [Jon] at 23:38 EDT Whoever, I think I have found a reliable way to detect a write protected floppy without doing something that would result in a GEMDOS error. G.GRAHAM9 posted a possible solution here last June but I've found that it does not work on a Falcon. What I discovered is that a call to BIOS 9 after a file is selected using the file selector will show a 1 if the floppy is write protected and a 0 if it's not. BIOS 9 checks if a file has been changed; 1 means "maybe", 0 means no. I let someone else explain why this might work. Try using a dummy "EXIST?" check if you are not using the file selector ( ~EXIST("A:\DMY.TXT") ). I have not tested this as much as the post file selector version but it seems to work pretty well. I needed to work this out because the way I had been doing this sort of thing broke on my Falcon under MultiTOS. To get my programs to work at all with this combination I had to drop all $I's and $U's from my code and without them the mouse cursor does not show up during GEMDOS erros. As for other potential disk error stuff, you can use GEMDOS 67 to check if a file is write protected and the file selector will handle the "disk not responding" situations. If anyone wants an actual listing of all this let me know and I'll post something here. Jon ------------ Category 22, Topic 3 Message 189 Thu Oct 28, 1993 DMJ [dmj] at 19:45 EDT Jon: The BIOS(9) call actually determines whether or not a _disk_ has been changed. TOS checks this by frequently checking the position of the write-protect "tab" on the disks. If the tab was in "write" mode, TOS knows there's a disk in the drive; if the tab should suddenly pop into "read-only" mode, TOS assumes you've removed a disk. It can't tell if you put a write-protected disk back in the drive, but if you already know there's a disk in the drive with _certainty_, then BIOS(9) does give you the write-protect state. What method were you using before? I'd be curious to see... -dmj ------------ Category 22, Topic 3 Message 190 Thu Oct 28, 1993 JWC-OEO [Jon] at 21:49 EDT dmj, You do know that a disk is in the drive for sure because the file selector has dealt with that problem. You do need to check if the user selected Cancel though. The way I used to check this is much simpler and would be prefered if it were not for the serious MultiTOS problems. Its basicly to let the OS do it. An example: ON ERROR GOSUB FIX_IT $I+ $U (disk operation) $U $I- PROCEDURE FIX_IT SELECT ERR CASE 37 'full disk CASE -33 'file not found CASE -34 'path not found CASE -36 'write protected . . . ENDSELECT RETURN If the user selects "Cancel" an error is generated and you branch to your error handling routine. If he/she fixes the problem your program never knows about it. Without the $I's and $U's the user does not get any choice but RETRY from the GEMDOS error alert box (no mouse cursor). This comes from the lack of the I+ option. One benefit of not having the I+ option on is that the compiled program ends up a little smaller. Jon ------------ Category 22, Topic 3 Message 191 Tue Nov 02, 1993 R.WILSON36 [Bob Wilson] at 18:26 EST Could anyone with an assembler give me the data statements to put into GFA for the following move.l # -2,d0 trap # 2 RTS ------------ Category 22, Topic 3 Message 192 Tue Nov 02, 1993 DMJ [dmj] at 20:10 EST Bob: moveq #-2,d0 ; Shorter than move.l trap #2 ; Call AES/VDI rts ; Return. In GFA, do this: dummy=0 ! Must be FLOAT, add # suffix if necessary. {V:dummy}=&H70FE4E42 ! Insert first two instructions. INT{V:dummy+4}=&H4E75 ! Last instruction. check_gdos%=V:dummy ! Address of subroutine. type_gdos%=C:check_gdos%() ! Call subroutine. This is probably the easiest, simplest method to check for the type of GDOS. The return values for this are discussed in the Compendium, which is where I assume you got the assembly code from. -dmj ------------ Category 22, Topic 3 Message 193 Wed Nov 03, 1993 R.WILSON36 [Bob Wilson] at 18:22 EST DMJ thanks for the code. Yep, I got it from the Compendium. God, I wish I had had a copy of that a couple of years ago. It would have saved some of my hair. The ATARI developer docs really were badly organised. ------------ Category 22, Topic 3 Message 194 Thu Nov 04, 1993 DMJ [dmj] at 19:20 EST Bob: You wish YOU had a copy of the Compendium? At least you had developer docs... back when I started, getting ANY sort of information was next to impossible. Be sure to get the errata sheet Scott uploaded to the library. -dmj ------------ Category 22, Topic 3 Message 195 Sat Nov 06, 1993 A.WATSON6 [Anthony] at 02:15 EST Damien, Thanks for the CheckGDOS routine... That may come in handy! Though, I would probably do it differently: INLINE check_gdos%,6 long{check_gdos%}=&H70FE4E42 word{check_gdos%}=&H4E75 type_gdos%=c:check_gdos%() As usual, I'm sure there are other solutions. But this is a bit easier to read than your solution, as well as a bit faster. (Though I had to do this in a loop about 100 times to see a difference! Ha. Ha. Sorry, this just seemed like a challenge? Ha. Ha.) Of course, if you were really a Speed Freak (You assembly types!), you could eliminate the LONG and WORD lines, and just store the data in the INLINE in the first place. I store assembly routines in them all the time (as well as Graphics, Sound samples, etc...). Handy little item to have! Anyway, thanks for the assembly to data conversion! Anthony ------------ Category 22, Topic 3 Message 196 Sat Nov 06, 1993 DMJ [dmj] at 13:07 EST Anthony, Yes, normally I would just stick the code in an INLINE and be done with it. I use INLINEs all the time; as a matter of fact, all of the assembly routines in Sound Lab were written with Devpac 3, assembled, and stashed in INLINEs. I also put fonts in there, but not large graphics. Remember that INLINEs are limited to 32K. The reason for coding the GDOS check routine in assembly is that you can't do it from GFA. If you have a need for any other little assembly routines, just ask. -dmj ------------ Category 22, Topic 3 Message 197 Sat Nov 06, 1993 A.WATSON6 [Anthony] at 19:19 EST Damien, Yep, that stupid 32K limit is one of the dummest limitations of GFA! Ha. Ha. Actually, the few assembly routines I've written have been a couple hundred bytes or less, so that hasn't been a problem. Also, the graphics and fonts I've stored in INLINES are usually around 2000 to 4000 bytes in size, so they fit fine too. About the only time the 32K limit became a problem was when I was working on Tuzzle and trying to store sound samples in them. Your average Bonk and Clink fit just fine, but some of the longer ones exceed that! I was finally able to just break up the longer samples so that they fit in two INLINES. (At 6khz they would have fit, but the darn Falcon doesn't support that DMA speed, so I had to go to 12khz, nearly doubling their size!) I've slowly been trying to delve into assembly myself, though only when necessary. With virtually no documentation on assembly, and only using an old copy of the GENST assembler I've managed to whip up a few routines when necessary. But I'm a LONG way from going 100% assembly! By the way, how do you like Devpac 3? If I ever get a 'toughie' I may indeed ask. Though I'd probably end up spending 3 weeks working on a simple routine, just for the learning 'experience'. Ha. Ha. Later, Anthony ------------ Category 22, Topic 3 Message 198 Sat Nov 06, 1993 DMJ [dmj] at 23:28 EST Anthony, - Yep, that stupid 32K limit is one of the dummest limitations - of GFA! Only about as silly as Messy-DOS/Windoze 64K limits. If I know I'm going to load a large chunk of data (like sound), I do it in one of two ways. Either dimension an array big enough to hold it (making sure my RESERVE leaves enough room for it) or malloc() a block for it. Breaking up the data into two INLINEs is more trouble than it's worth, for me. - With virtually no documentation on assembly, and only using - an old copy of the GENST assembler... Buy Devpac 3. The manual is good, and you also get a little book that lists most of the information you want on the 68000. The assembler and debugger are first-rate as you would expect from HiSoft. And don't forget to read the assembly column in AEO-PJ. - But I'm a LONG way from going 100% assembly! Me too. Writing things in 100% assembly is not done without good reasons. - Though I'd probably end up spending 3 weeks working on a simple - routine, just for the learning 'experience'. That's the best way to learn. If you actually code the code, sweat the sweat, and debug the bugs, you learn in a way that simple book reading cannot match. There is NO substitute for experience. -dmj ------------ Category 22, Topic 3 Message 199 Thu Nov 11, 1993 P.MCCANDLESS [PLONKER] at 21:10 EST I need to know a short routine of how to "FILL" an area under a curve with GFA BASIC 3.5E. Unfortunatley, this curve has "invisible boundaries" both below and to the sides (a FILL color that is the same as the background itself). Anyone have suggestions on how to do this? _(curve)_ / \ / | | \ ____/ | | \____(curve)_____ / | | | \ / (FILL) | | | | \ | | | | (Fill) | (Fill) | | | (FILL) | | | | | | V V V V V V (Bottom of desired fill region) (note: no color boundary) ------------ Category 22, Topic 3 Message 200 Fri Nov 12, 1993 DMJ [dmj] at 00:14 EST Plonker: If your curve is already on-screen, you can draw both sides and the bottom and use the FILL command. Better yet, if you have some sort of formula for the curve (i.e. if your program drew the curve in the first place), instead of drawing the curve as a bunch of points, draw it as a series of vertical lines, with one end always the same height (the bottom of the filled area). Hope this makes sense... I know there's a reason I don't answer messages after 10PM, but for the life of me I can't remember what it is right now... ;-) -dmj ------------