ICTARI USER GROUP ISSUE 31 February 1996 ___ ______ ___ _________ _________ ___ \__\ \ __\ \ \__ \______ \ \ _____\ \__\ ___ \ \ \ __\ _____\ \ \ \ ___ \ \ \ \ \ \ \ ____ \ \ \ \ \ \ \ \ \_____ \ \____ \ \__\ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \__\ \_______\ \______\ \________\ \__\ \__\ * m a g a z i n e * =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= I C T A R I U S E R G R O U P 63 Woolsbridge Road, Ringwood, Hants, BH24 2LX Tel. 01425-474415 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= INDEX FOR ISSUE 31 ================== ASSEMBLY Saucers game source code. Line drawing routines source code. C SCSI Interface Library for C programmers. GFA GFA Interface dialog utility code & program. STOS Polygon demo program. Stock Controller data files. MISC Pexec function Cook-Book. Current membership list. In next months issue of ICTARI (this may change) :- ASSEMBLY Non-modal dialog box code. C Dictionary game source code. BASIC Card shuffling techniques. GFA Text adventure game source code. STOS Starfield screen code. Disk manager program. MISC Ottos Resource Construction Set (ORCS) program. ORCS review. ---------------------------------------------------------------------- EDITORIAL ========= MEMBERSHIP ---------- Another two members have joined the group this month, welcome to them. Also some members addresses have changed this month so it is advisable to always use the current membership list when contacting fellow members. KEYBOARD SHORT CUTS ------------------- In this months Atari World, Jon Ellis mentions the GEM Standard keyboard short cuts that programmers should use for GEM type programs. This information which is available on Compulink (at address gemkeys@ogal.compulink.co.uk) may be useful for Ictari members who do not have access to the Internet. If any member with access would like to download it and send me a copy I will publish it in next months issue. There is a similar list published in the Atari Compendium but I don't know whether they are the same. SAUCERS GAME ------------ In the ASSEMBLY folder is a Saucers game source file. I can't get it to work on my machine, perhaps someone could have a look at it and find out why. I have had a quick look and it seems that the problem (the first problem anyway) is the stack pointer position, the programmer seems to have set the stack pointer address to the bottom of the hidden screen which seems a bit odd. Maybe it only works properly on a 1M or 500K machine. Anyway, if anyone can get it working, send it in to me for a later issue. Of course, whether the game is any good is another matter. ---------------------------------------------------------------------- CORRESPONDENCE ============== To: Jason Railton From: David Seaman Thanks for at least trying to help with Stoc Controller. To the best of my knowledge, the only commands I used in it from the Misty extension where MOUSE ON and MOUSE OFF, which I used to try and speed up certain routines by disabling the mouse pointer. I would love to submit the MISTY extension for ICTARI to put on this disk, but unfortunately Top Notch are a bit, erm, touchy about people putting their stuff on disks without asking first. I know it's a pain, but if you delete all the occurrences of the commands, the program will still work just as well, only a tiny bit slower. Or, of course, you could get the Misty extension from a PD library... I'll try to remember to put what extensions I've used in future, too! To: David Preston Regarding the Squasher extension, perhaps my comments were a bit unfair since I haven't really used it much, as I use my trusty Pack- Ice and the Missing Link to decompact it. If you find pleasure in using the Squasher, then all the best to you! STock Controller... well, there are basically two problems. I can't remember which version I gave Peter; there's the original version, and a version that I'd fixed to bypass the disk problem, which always used the default directory. By the way, if you don't have a hard drive this problem wouldn't have occurred anyway so that is maybe why you didn't notice it! Here's a bit more information on the disk problem: The only two commands which cause a disc error (after successfully performing the operation) are: DIR DRIVE$ Commands which do not cause a disc error include: PREVIOUS DIR$= DIR FIRST$ OPEN IN #1, ETC, ETC. This problem has only existed since I got a hard drive. STOS is run from drive H, the drive (a Gasteiner 270 meg) is partitioned C-P. (DRVMAP=65535) The extensions I have installed are as follows: BLITTER COMPACT COMPILER CONTROL EXTRA GBP THE MISSING LINK MIDI MISTY NINJA TRACKER STOS TRACKER 14KHZ The other problem is related to the sort code. Although I'd spent absolutely AGES getting it to work perfectly (it was on an issue of ICTARI even.... oops!), it seems not to work properly still and I can't find what's wrong with it. I've also sent some sample STC files (which are hopefully on this disk) with the corresponding STOCK.DAT file. Try printing a stock take or price list and you can see what I mean. HELP!!!!!!!! */ See STOS\STOC_CON folder /* From: David Seaman (for the last time this issue, I promise!) To: Everyone Also on this disk (or soon, anyway) is Disk Manager 2.0, which is hopefully both useful and a good example of structured code. It's certainly the tidiest, most structured code I've ever written, and, best of all, gets round the disc problem mentioned earlier (has anyone else had problems getting STOS to behave on a hard drive?!) by using the file selector. I hopefully can use the same sort of technique in STC, but I'd rather not have to resort to such drastic measures... (I still hope to avoid doing a nearly complete re- write...) */ See next month /* Finally, while I'm on the subject of STOS extensions (well, I wasn't actually, but still..), could anyone do a deflation routine for ZIPed files? I know it would be mega-slow in BASIC, but surely it's a practical possibility? If you do it, please let me know! ---------------------------------------------------------------------- To: All From: Jim MacLeod By way of intro, this being my first letter, I am a self!! taught assembly programmer crashing merrily about the system but not, as yet, producing anything of note. I have tried writing an extremely basic non-modal dialog, ie only one window on screen, and include a working version + listing. Although in M/C code it uses macros and I have put notes before each section so that hopefully anyone should be able to make sense of it. */ See next month. /* If anyone wants to write/ring be glad to hear from you. To: Marten Form_keybd,tree,ed_obj,key,ed_obj In your excellent & informative articles, for which thank you, you advised that the second ed_obj should be set to '1'. After various experiments I believe I now see why. If 'key' is Up/Down arrow keys, Tab/shift+Tab or the Return key, int_out(2) returns the relative object number. However if 'key' is alpha-numeric then int_out(2) returns whatever value is placed in the second ed_obj. So, call form_keybd, compare ed_obj and int_out(2). As long as they are the same then go straight to objc_edit function 2 (validate/update). Obviously if different, user is changing ed_obj's or exiting the dialog so handle accordingly. To: David Preston Object redraws Calling objc_offset for obj_n returns the X/Y co-ordinates of that object which is actually the offset relative to the screen. In fact the X/Y of obj_0 will always be screen relative, while its children all have offsets relative to it. All the AES probably does is add them to those of the object you want to give the result. Each object data is 24 bytes long held sequentially in memory. If you get the tree address, the X/Y/W/H are held in 2-byte blocks at offsets of 16, (for X), 18 (for Y), 20(W) & 22(H), ie if you called objc_offset for obj_0 the returned values should be the same as those at tree+16 & 18. To find the W/H for any object add 24*obj_number to the tree start address and then read the data at offsets 20 & 22. As you see, it could be just as quick to read the X/Y of obj_0, read X/Y/W/H of obj_n and add the X's & Y's to get the result. To: Owen Rogers Reading GFA editable objects Somewhere I have some GFA v2 routines which I will try and dig out for you. Meantime here are a couple but I can't guarantee that they won't bring things to a halt. Basically you need the start address of the tree, a manual should show you how, which is shown as T% below. The object number is N%. Tv$="" Space for the returned string @G_text(T%,N%,*Tv$) Tree start addr, editable object number Procedure G_text(T_%,N_%,Tx%) Local X_$ X_$=Space$(80) T_%=Lpeek(Lpeek(T_%+24*N_%+12)) Get editable object address Tx_len%=Dpeek(Lpeek(T_%+24*N_%+12)+24) Get text length Bmove T_%,Varptr(X_$),Tx_len% Read string into variable *Tx%=Left$(X_$,Instr(X_$,Chr$(0))-1 Get string length Return If you want to try something safer first, try changing an object's status from Normal (0) to Selected (1) and back. Procedure G_state(T%,N%,X%) *X%=Dpeek(T%+24*N%+10) Object status flags are offset by 10 Return X% holds current status of object N% Procedure S_state(T%,N%,X%) Dpoke(T%+24*N%+10),X% Return X% is the status to set eg 0 or 1 To: Jonathan Double linked lists I've got a book with single & double linked lists in it, but they're in assembler. If they could be of help ring/write & I'll be happy to send/fax them to you To: John Oakes 68000 programming If you're totally new to 68K I found quite a good book is "First Steps in 68000 Assembly Language" by Robert Erskine, Glentop Press Ltd Standfast House, Bath Place, Barnet, Herts EN5 5XE. I've also got odd mag articles which may be of interest, glad to help. To: Peter TSR's Again somewhere I had a TSR routine which used one of the spare Traps. It set itself up on boot-up and then ran when the Trap was called from within a program. I had an idea though that TSR's were supposed to be completely self-contained, ie no M_alloc calls etc, so I don't know how that would affect loading a file? */ See letter from Jason Railton below. PDH /* ---------------------------------------------------------------------- To: All From: Mark Foot Does anybody have any useful information on using LISP/XLISP on the Atari. I have the XLISP v2.1 disk from FloppyShop but would like more information. ---------------------------------------------------------------------- To: ICTARI / Jonathan Leckie From: David Preston File conversion utilities Having had a quick look through my Atari Worlds (all bar No.1, regrettably), I couldn't find the program Jonathan referred to in Ictari 30. However there was a program on ST Format coverdisk #62 called TUC which might (probably with some work) do some or all of the the jobs you wanted. I've included it (\TUC102), though whether or not you put it on the Ictari disk is up to you. Another possibility as I understand it is that Protext can be programmed to do all sorts of clever things (see Mark Baines' article in Atari World #8), but only having the coverdisk version 4.3 of Protext (in truth 90% of my software is from coverdisks! sad but true...) so I'm no expert on the finer points of its use. */ I'll try and include the TUC program on a later disk as it may be of interest to some programmers, if Jonathan or anyone else needs a copy urgently, please send a disk and I will return a copy. ICTARI /* To: Owen Rogers I think the problem with your editable strings is that the second parameter to form_do should be the index of the first editable text object in the form ie. ex%=FORM_DO(tree%,comline%) if that's the first editable item. To: Jason Railton Seapest Nice game, nice code. However, the executable (PRG) locked up and didn't seem to accept any mouse input. The BAS file loaded, ran & compiled fine. It's not terribly important, but I thought you should know. I have a 1meg STe if that has any bearing on the problem. ---------------------------------------------------------------------- To: Peter Hibbs From: Jason J Railton Re: TSR programs Last month's TSR listing was fairly straightforward, and you shouldn't have any problems basing your code on that. However, you could do things a bit neater so that if you make a few mistakes you don't bring the whole system down. 1. Firstly, if you intend to intercept (i.e. steal) an existing vector, it's a good idea to make the first command of your function a jump, to skip over the next few bytes. Next you put a copy of the original vector, then a key word (such as the name of your program in eight characters), as follows: new_routine: BRA do_stuff old_vec: DS.L 1 my_id: DC.B "MY_PROG " EVEN do_stuff: Your routine... Then, your program can take the value of the sum: (my_id - new_routine) and add the current value of the vector you intend to redirect. Compare the eight bytes starting at this address with the eight bytes held at 'my_id'. Thus your program can tell if it's already been installed. (Don't forget the EVEN command, just in case your key word has an odd number of letters). I don't know if you can get one TSR routine to wipe out another and free up its memory, but if you store the original contents of the vector at 'old_vec', just before the key word, then your installation program can not only identify previously installed routines, but it can kill them off by picking up the original vector, and re-installing it. This is useful in development, so you don't have to keep resetting the machine when you want to try a new version of your program. Also, if you do this at the start of all your routines (rather than at the end), the data is always in the same place, relative to the modified vector, so your programs can identify each other. 2. Another safety device is to give your routine its own stack space. Do this by adding some extra space to the amount of memory you tell the system to preserve around your TSR program. Calculate the address of the end of this free space, and use that as your stack pointer. Save this address in four bytes reserved at the end of your program. When your routine is called, it should save the current registers to the normal stack, then copy the value of the stack pointer to four bytes reserved at the end of your program. Then, load your new stack pointer and carry on. When you come to exit your program, you don't need to tidy up the stack. You can save the new stack pointer, or you can just lose it and start from the top again next time your program is called (safest). Then, load the stack pointer value you saved on entry, and restore the registers from there. The memory preserved around your program consists of the program itself, 256 bytes preceding it, called the basepage, plus any data space after your program that you want to keep free for your program to use. If the TSR program needs a lot of spare RAM, you can't rely on being able to request it from the system when activated. If your routine is triggered whilst another program is running, that program may not have freed the RAM it doesn't need, so all the memory will be allocated to it with none available for the system to allocate on demand. 3. If your installation program is fairly large, you can always put your new routine first in the listing, with a jump to the installer just beforehand (below). Then, you need only tell the system to preserve the memory up to the end of the TSR routine, and its data, and cut off the installer code. After all, you don't need it once the TSR code is installed. start: BRA installer new_routine: This is your new routine, followed by its variable storage area. cut_off: installer: This is the procedure that installs 'new_routine', and is programmed to exit, preserving the amount of memory between 'start' and 'cut_off', plus 256 bytes plus data space. If you reserve extra memory for workspace, some of the installer routine could end up as part of this workspace. Don't worry about over-writing it once it's done its job. 4. If you're going to have an installation message, put a keypress pause after displaying it, so at least it can be read. test_space_bar: CMP.B #$39,$fffffc02.w BNE test_space_bar ...is an old favourite, which waits for someone to press the SPACE bar. It's also very useful if you're playing around with vectors, since it enquires of the keyboard chip directly - it doesn't rely on system keyboard interrupts. Switch all the interrupts off, and it still works. By the way, "COMPUTE!'s Technical Reference Guide ATARI ST VOLUME THREE TOS by Sheldon Leemon" ISBN 0-87455-149-8 $24.95, or œ22.95 from Foyle's, Charing Cross road, London - where I got my copy - ...is a brilliant book on this sort of thing. I mean, I've never written a TSR routine myself, but look at all the stuff I've managed to come up with... And hunting round Foyle's is a great day out in itself... */ Thanks for the extra info Jason. Actually I seem to remember reading somewhere that it is not possible to use any GEM/VDI calls (which I need to do) from an Auto folder program because GEM hasn't been initialised at that point in the boot up sequence. If this is the case I will probably have to install the program as a standard accessory first and then hook into the keyboard vector so that the user can call up my program with a key combination (even if the main program does not allow access to the menu bar) which is what ImageCopy does. Any further information on this subject from anyone would be very interesting. I have got the Compute series of books, the problem with them is that there is so much information in them that I tend to just read the chapters that I am interested in, I will have to have another look through them. I actually visited Foyles myself a couple of weeks ago and purchased a book called 'Practical Algorithms for Programmers' which looks very interesting although it is not Atari specific, in fact the number of Atari books available there, seems to be getting less each year. PDH /* ---------------------------------------------------------------------- To: ICTARI. From: C Singleton Can anyone tell me how to send a FORM FEED code to a printer using Lattice C5.6. All I seem to get for my effort is a printing of the control code 'FF'. Thanking someone in anticipation of a reply. ---------------------------------------------------------------------- To: All From: Peter Hibbs Are you good at drawing graphics ? I am in the process of writing a Dungeon Master type game (in fact it is almost identical to DM) and while the basic layout of the dungeon will be the same, I would like to add some different monsters to the game. If anyone is interested in designing some new monsters, please let me know (or telephone) and I will send you a disk with some example images (in Degas .PC1 format) and information on what is needed. There is no fee payable I'm afraid although you would get a free copy of the game, of course, when it is finished. ------------------------------ End of file ---------------------------