A.C.E. 2

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

/ A.C.E. 2 / ACE CD 2.iso / FILES / DOCS / AMOSDOC.LHA / AmosV1.3Update.doc < prev next >

Wrap

Text File | 1994-11-27 | 30.7 KB | 788 lines

_____ _________________________ / / / \ / / / ____________ ___ \ / / / / / / \ \ / / / /_____ / / \ \ / / / \ / / \ \ / / \_____ / / / \ \ / / / / / / \ \ / /_________/ / / /_____________| | | / | | |__________________/ |________________________| AMOS VERSION 1.3 UPDATE WHAT'S NEW! Typed by SIDEWINDER of LSD. Manual supplied by SCOOTER. INTRODUCTION AMOS Basic has gone through a number of changes during the course of its existence. Rather than rest on our laurels, we've steadily updated the system to include many new features suggested by AMOS users. Incredibly enough, we've placed these improvements on the public domain. Special updater disks are available from the AMOS user group or your local PD library. So whatever your version of AMOS Basic, you can upgrade to the latest system for the price of a disk. Here's a list of the versions of AMOS Basic to date: AMOS 1.1 The original! AMOS 1.2 This includes several new commands such as BANK SWAP. There was also a whole new set of SPRITE flipping routines introduced which allowed you to display a single image in several orientations. The file-selector was completely reworked, and allowed you to change the current disk by pressing the RIGHT mouse button and simply clicking on the new device name with the mouse. The UP/DOWN arrows were repositioned at the top of the scroll bar for maximum speed, and the PARENT button was repositioned to the far left corner and reduced in size. AMOS 1.23 Added the SERIAL extension, SPRITE compactor and procedure locking utility. AMOS 1.3 The latest version of AMOS Basic is version 1.3. This comes with the compiler and includes a range of turbo-charged Bob and screen copy routines from the mind of Gary Symons. These optimise the performance of commands such as SCREEN COPY and PASTE BOB/ICON, leading to dramatic speed improvements in many games. All the above features from V1.1 onwards, exist in V1.3. This supplement manual will provide you with the information to access all these new additions to AMOS. BOB FLIPPING COMMANDS In a great number of games, the main character needs to animate left to right, and up and down. Up to now, you were obliged to keep in the sprite bank reversed copies of small animation sequences for the main character. As the main character usually has the best animation, you lose an enormous amount of space! For the game RanXerox, for which AMOS author Francois Lionet wrote the sprite routines, a flipping routine was developed which allowed just one copy of the main character to be kept in the bank. This routine has been enhanced and placed into AMOS. How does it work? Imagine your character is walking to the left and then back to the right. You would only have in your bank the image of him walking to the right. To display this right image, you simply refer to the image number in the bank as usual. To display the image reversed in the X axis (left walking image), you set bit number 15 of the image number to 1. Don't panic, you can simply do it with: $8000+Image number So: Bob 1,160,100,1 will display your character walking right, and: Bob 1,160,100,$8000+1 will display it walking left. The same principle is used for vertical reversing. For this, bit number 14 is used - add $4000 to the image number. To have vertical and horizontal reversing, use $C000. The symmetry is a full symmetry: The hot spot of the bob is also reversed. For example, if we put the hot spot in X under the feet of our character, the reversed version would also have it under his feet. So be careful if you set the hot spot on the top left corner on a bob, the reversed image will be displaced at the top left! You might say that $8000 and $C000 are a bit weird to use. We have provided special functions to give a better AMOS interface: =HREV(image) adds $8000 to the image =VREV(image) adds $4000 =REV(image) adds $C000 Use them in place of the hex values: Bob 1,160,100,10 Bob 1,160,100,HREV(10) Bob 1,160,100,VREV(10) Bob 1,160,100,REV(10) To allow easy use of the bob flipper in AMAL, we have implemented HEXADECIMAL evaluation. So you can use hex notation to refer easily to reversed bobs. If hex frightens you, just add $8000, $4000 or $C000 before all references in your AMAL strings. Example: Old AMAL string: "Anim 0,(1,2)(2,2)(3,2)(4,2)" New reversed string: "Anim 0,($8000+1,2)($8000+2)($8000+3)($8000+4)" or "Anim 0,($8001,2)($8002,2)($8003,2)($8004,2)" If you use a register to calculate the image number, do not try to modify the calculation itself, but only when you assign the register to the image. Old AMAL string: For R0=1 To 10; Let A=R0; Next R0 New one: For R0=1 To 10; Let A=$C000+R0; Next R0 HOW DOES THE FLIP ROUTINES WORK? It is really important for you to understand how it works internally, so that you do not ask this system to do things it is not designed to do. The reversing system is designed to free memory before trying to be fast (although we would not mind if it was actually fast, would we?). Concessions had to be made to have it fast, and at the same time easy and powerful. The routine actually works right in the middle of the bank, and does not use any extra memory. The bobs are flipped during the UPDATE process, just before a bob is redrawn on the screen. AMOS looks to see if the image needs to be flipped in the bank. If it does, it is flipped and a flag is set within the bank. On the next UPDATE, if the bob image has not changed, it will be flipped, thus saving a lot of time. If you understand the above, you will realize one BIG limitation. It is not wise to use more than one flipped bob pointing to the same image. Let's see the next example: Bob 1,160,100,1 Bob 2,160,150,$8001 Bob 3,20,20,$4001 Bob 4,20,100,$C001 Update During the UPDATE process, AMOS will first draw bob number 1. No problem, it is in the right position. Then bob number 2 - AMOS needs to reverse it in X. Bob number 3 needs a Y and an X reversing (to put the bobs back to normal in X!). Then bob number 4 needs an X flipping. On the next update, providing the bob's image has not changed, to display bob 1, AMOS will have to flip it in X and Y, then bob 2... As you can see, for each UPDATE, that is, every 50th of second, if the bobs move they need to be reversed! This will work, but will take a lot of processor time, and the animation will be disastrous. So the golden rule is, use the reversed bobs for object alone on a screen (or be sure that normal and reversed images are not displayed at the same time on the screen). If you want, you can have two bobs like this - experiment! We told you before that this system was for use with bobs. Yes, it is totally automatic with bobs. But as it directly affects the sprite bank, you can also use it with sprites. When a hardware computed sprite is calculated, AMOS looks into the sprite bank and gets the image from it. If the image is reversed at that moment, the hardware sprite will display a reversed image. You can therefore have reversed hardware sprites using this method. But you cannot do this for example: Sprite 1,200,200,$8001 PASTING FLIPPED BOBS PASTE BOB also accepts reversed images. A simple trick to reverse an image in the bank without having to display a bob, is to PASTE the reversed image outside of the screen. Example: Paste Bob 500,500,$C000 This will reverse image 4 in the bank, without any output (and quite fast). COLLISION DETECTION This is an important point, and you have to be very careful when you detect collisions with reversed bobs! The collision detection uses the shapes in the bank at the very moment it is called. Let's see an example that will never work: Bob 1,160,100,1 Do Bob 2,XScreen(XMouse),YScreen(YMouse),$8001 Wait Vbl Exit if Bob Col(1) Loop Why doesn't it work? We have two reversed images of the same definition in the bank. After the updating process, the image in the bank is left reversed. So the Bob Col instruction will take bob shape 1, the reversed image, and this will not work! So remember: THOU SHALT NEVER USE COLLISION DETECTION WITH MORE THAN ONE REVERSED IMAGE ON THE SCREEN! HOW IS IT CODED INTO THE SPRITE BANK? Two bits of each images X Hot Spot are used to flag the flipping (at SPRITE BASE+6). Bit number 15 for X 0 if normal, 1 if reversed Bit number 14 for Y 0 if normal, 1 if reversed Before RUN and SAVE, the bank is restored to its normal state, so that it is still compatible with version 1.1. BLOCK FLIPPING The flip routine can be used for blocks. HREV BLOCK (Flip a block horizontally) HREV BLOCK image Flips block number IMAGE horizontally. VREV BLOCK (Flip a block vertically) VREV BLOCK image Flips block number IMAGE vertically. SQUASH A BOB ROUTINE This routine was originally written for a Fun School 3 program called Letters. Each letter in the alphabet is displayed as a single large sprite. This requires a total of 52 separate images, taking up a massive 110k of memory. Since only a couple of images are displayed at a time, most of this space is actually wasted. So a small routine was written to pack the unused sprites into a spare memory bank. This allowed us to compress the entire sprite bank into just 26k! AMOS Squash is now available on the public domain. Feel free to use it in any of your own programs. It's especially useful for the massive Level Guardians in an arcade game. These can be compressed into a fraction of their normal size, and can be instantly retrieved at the appropriate point in your program. USING AMOS SQUASH The packer program comes in two separate parts. The first program loads a sprite bank into memory and compacts your images. It can be found in the file 'Squash_a_bob.AMOS' In order to use this routine, you need to perform the following simple procedure: * Load a sprite bank from the disk using the file-selector. * Enter the number of the FIRST sprite you wish to pack. * Enter the number of the FINAL sprite in your list. * Input the number of colours used by your sprite images. * Choose a new memory bank to hold your squashed images. The squasher routine will now be executed and your selected images will be quickly compressed. After it has concluded, you will be given an option to save your compacted images onto the disk. Note that NO colour information is saved with these images. So you may need to make a note of the current colour settings before proceeding any further. Once you've squashed your images, you can load them into your AMOS Basic programs with the help of three small procedures. These can be found in the file 'Squash_procs.AMOS' and can be incorporated using the MERGE command from the AMOS Editor menu. The squash routines are remarkably easy to use. The first stage is to load your original sprite bank from Direct mode and delete the images you have just compressed. Use a line like: Del Sprite start To finish This erases your old images from memory, saving you considerable amount of storage space. You can now enter your packed images from the disk with the LOAD command: Load "images.abk" At the start of your program, you should initialise the compaction system with a call to the PBOB_INIT procedure: PBOB_INIT[bank,cols,max_x,max_y] Where: bank is the bank number containing your compressed images cols holds the number of colours max_x stores the maximum width of your images max_y holds the maximum height of your images The action of this procedure is to prepare a temporary screen for the squasher utility. Your images can now be unpacked as and when they are required, using a simple call to the PBOB routine. PBOB[source,dest] 'source' is the number of the image to be unpacked. This is the original image number from the sprite bank. 'dest' is the number of the new image you wish to install in the sprite bank. Choose the number of the last sprite in the bank plus one. Once you've installed your image into memory, you can animate it directly with the various SPRITE or BOB commands. PBOB can be called as many times as you wish. So the same image number can be re-used again and again. Finally, add a call to the PBOB_END procedure towards the end of your program. This will erase the hidden screen created by PBOB_INIT. SERIAL PORT COMMANDS EXTENSION Welcome to the intriguing world of AMOS communications. The serial extension is intended for those of you who wish to transfer information between several different computers using the Amiga's serial port. The extension provides you with a total of 15 new commands. You can use these commands to create amazing multi-user games. It's also possible to access a Midi interface which has been plugged into the Amiga's serial port. So musicians will be able to control their instruments directly from AMOS Basic. Wow! As you would expect, full multitasking is supported. OPENING THE SERIAL PORT SERIAL OPEN (Opens a channel for Serial I/O) SERIAL OPEN Channel, Port_no [,Shared, Xdisabled, 7wires] Opens a communication channel to a serial device. 'Channel' This is an identification number which will be used for all subsequent communication commands. Allowable values range from 0 to 3. 'Port_no' Specifies the logical device number of the serial port. Normally, this value should be set to zero. However, if you've plugged a MULTI SERIAL card into your Amiga, you can access your additional ports using the numbers from one onwards. 'Shared' (optional) This is a flag which informs AMOS that the device can be shared with other tasks which are currently running on your Amiga. It's used in multitasking. A value of FALSE (zero) will grab the channel for AMOS Basic, and will deny access to any other programs. If it's set to TRUE (-1), the serial port can be shared between several programs in memory. Beware: This system must be used with extreme care or the Amiga could easily crash! 'Xdisabled' (optional) Toggles XON/XOFF checking during transmission of your data over the serial line. It's essential to set this flag when you are first opening the device, even if it will only be required later. The default value is FALSE (0) and disables the system. If you want to enable the checking, use the value of TRUE (-1). After the port has been opened, you'll then need to set the XON and XOFF characters using a seperate call to the SERIAL X command. '7wires' (optional) A value of TRUE (-1) tells the device to use the 7 wires system as explained in the official Commodore documentation. The default is FALSE (0). When you call the Serial Open command for the first time, it will automatically load the SERIAL.DEVICE library from your system disk. So make sure it's available from the current drive. Incidently, the default serial settings use the French Minitel protocol: 1200 Baud, 7 bits, 1 stop bit, Even parity. This can easily be changed using the SERIAL SPEED, SERIAL BIT or SERIAL PARITY instructions if required. CLOSING THE SERIAL PORT SERIAL CLOSE (Closes one or more serial channels) SERIAL CLOSE[Channel] If you don't include the channel number, SERIAL CLOSE will close all currently opened serial channels with absolutely no error checking. The optional channel number allows you to close a single channel and use all the normal error checks. NOTE: Whenever a program is RUN from AMOS Basic, any opened channels will be automatically closed for you. SENDING INFORMATION THROUGH THE SERIAL PORT SERIAL SEND (Output a string via a serial channel) SERIAL SEND Channel, t$ Sends the string t$ straight to the specified serial channel. It does not wait for the data to be transmitted through the actual port. You'll therefore need to use the =SERIAL CHECK(Channel) function to detect when the transmission has been completed. SERIAL OUT (Outputs a memory block via a serial channel) SERIAL OUT Channel, Address, Length This is identical to Serial Send except that it works with RAW data. 'Address' is the address of your data in memory. 'Length' is the number of bytes to be sent. READING INFORMATION FROM THE SERIAL PORT SERIAL GET (Gets a byte from a serial device) =SERIAL GET(Channel) Reads a single byte from the serial device. If nothing is available a value of -1 will be returned. SERIAL INPUT$ (Get a string from the serial port) =SERIAL INPUT$(Channel) Reads an entire string of characters from the serial port. If there's no data, the command will return an empty string "". Otherwise the string will contain all bytes which have been sent over the serial line up to the present time. Be careful when using this command with high speed transfers (such as MIDI). If you wait too long between each SERIAL INPUT$ command, you can overload the system completely, and generate annoying errors such as 'string too long' or 'serial device buffer overrun'. SETTING THE SERIAL PARAMETERS SERIAL SPEED (Sets the transfer baud rate for a serial channel) SERIAL SPEED Channel, Baud rate Sets the current transfer rate of the appropriate channel. The same values will be used for both reading and writing operations. Note that you can't set split baud rates for a single channel. If the baud rate you have specified is not supported by the current device, it may be rejected by the system. SERIAL BIT (Sets the Nbit & Stopbit part of a protocol) SERIAL BIT Channel, Nbits, Stopbits Assigns the number of bits which will be used for each character you transmit. 'Nbits' is the number of bits 'Stopbits' is the number of STOP bits SERIAL PARITY (Sets the parity checking) SERIAL PARITY Channel, Parity Sets the parity checking you are using for the current serial channel. Here's a list of the available options: Parity<0: No parity Parity>0: Only the first two bits of this value are significant. Bit 0: =0->EVEN =1->ODD Bit 1: =0->Normal parity =1->SPACE The paruty bit can be set using the BSET or BCLR function like so: P=0: Bset 0,P: Rem Odd parity Bclr 1,P: Rem Normal parity Serial Parity 1,P: Rem Set the parity using the value in P See the Commodore's documentation for a full explanation of this system. SERIAL X (Sets XON/XOFF) SERIAL X Channel, Xmode (Activates/deactivates the XON/XOFF handshaking system) A value of TRUE for Xmode disables handshaking. Any other value turns it on. Xmode should be loaded with the correct control characters. These must be specified in the following format: Xmode=XON*$10000000+XOFF*$10000 Check Commodore's documentation for more information. OTHER COMMANDS SERIAL BUFFER (Sets the size of the serial buffer) SERIAL BUFFER Channel, Length Allocates Length bytes of buffer space for the required channel. Note that the default value is 512 bytes and the minimum allocation is 64 bytes. It's a good idea to increase the buffer size for high speed transfers. SERIAL FAST (Switches on FAST transfer mode) SERIAL FAST Channel This sets a special fast flag in the current device and disables a lot of internal checking which would otherwise slow down the communication process. Use it for high speed transfers such as MIDI. WARNING: When you call this command, the protocol will be changed to: PARITY EVEN, NO XON/OFF and 8 bits. SERIAL SLOW (Switches serial transfer back into SLOW mode) SERIAL SLOW Channel Slows the serial device back to normal speed and reactivates all the error checks. SERIAL CHECK (Reports on current serial device activity) =SERIAL CHECK(Channel) Asks the device for a read-out of its current status. You can use it to check whether all the information you've transmitted with a previous SERIAL SEND command has been sent. CHECK=FALSE (0) -> if the last serial command is still being executed. CHECK=TRUE (-1) -> All done! SERIAL ERROR (Reports success or failure of last transfer) =SERIAL ERROR(Channel) Looks for the ERROR byte in the serial device. A value of zero indicates that everything is fine. Otherwise, the last transmission was faulty. SENDING LARGE STRINGS Transmitting a large string may taike quite a long time, especially at low baud rates. As AMOS is multitasking, your program will continue to run AFTER a SERIAL SEND instruction. It's essential to avoid provoking a garbage collection before the transfer has been completed, otherwise your data will be corrupt. So: * Use the =SERIAL CHECK function before doing a lot of string work. * Perform a garage collection using X=FREE to ensure that your program will not provoke one automatically. * Use the SERIAL OUT channel, address, length instruction with 'address' containing the location of a previously reserved memory bank. MORE INFORMATION More information about the Amiga's serial system can be found in the Commodore ROM KERNAL Referance Manual, Library and Devices. This will allow expert users to make maximum use of the serial device. MULTI TASKING IMPROVEMENTS MULTI WAIT (Force a multi-task wait vbl) MULTI WAIT To make effective multi-tasking programs, you must not grab most of the processor time, leaving only a limited amount of power for other tasks. MULTI WAIT does MULTI-TASK wait vbl. You should use it in your program's main loop, when you wait for example, for a menu unit item to be selected. Note that you should not use this instruction to make accurate screen synchronisation as it is designed to multi-task. This instruction is NOT consistant at all! It may skip many VBLs, depending on the number of running tasks at the time. If you missed it elsewhere in the manual, multitasking can be activated by pressing Amiga+A to flick between AMOS and the CLI or Workbench environments. This allows systems with at least 1 meg to run AMOS and programs like DPaint III at the same time! AMOS TO BACK (Hide AMOS from view and show the Workbench) AMOS TO BACK This will bring forward the Workbench display, allowing you to access other programs. AMOS TO FRONT (Switch AMOS to the display) AMOS TO FRONT AMOS is forced back onto the display with this command, leaving the Workbench hidden. AMOS HERE (Report which task is on display) AMOS HERE This returns TRUE if AMOS is currently displayed and FALSE if the Workbench is in view. LOAD AMOS FROM WITHIN A FOLDER AMOS does a number of housekeeping chores before fully loading up and presenting itself to you. One of these is to locate all its default files like the sprite pointer, default font and so on. The procedure and logic is as follows: 1 Check the current system to define if a PAL or NTSC screen is in use. 2 Depending on the system it will look for the AMOS1_3_PAL.Env or AMOS1_3_NTSC.Env. 3 Failing to find one of these files, it will look for the AMOS System folder in the root directory of the current drive. If this also fails, AMOS gives up trying to load and returns to the Workbench. 4 If AMOS picks up Default.Env at point 2, it will examine the environment file to find where the other files are located. This is the key to relocating AMOS anywhere on a disk. Let's assume we want to set up AMOS within a folder called UTILS on a hard disk. First we must copy across the following files from the AMOS Program disk to the hard disk path Dh0:UTILS/ AMOS_System A folder containing all the default files AMOS1.3 The main AMOS file The files AMOS1_3_PAL.Env and AMOS1_3_NTSC.Env must be moved from the AMOS System folder to the Utils folder. AMOS_System AMOS1.3 AMOS1_3_PAL.Env AMOS1_3_NTSC.Env Now we must change the Env files so that they tell AMOS where all the data files are. To do this you'll have to boot a normal copy of AMOS and run the Config.AMOS program. Simply ensure that the loaded extensions and default files have the correct path and filenames. In our example all the files are inside the directory AMOS_System. Just make sure that the extensions you have read as follows. 1-AMOS_System/Music 2-AMOS_System/Compact 3-AMOS_System/Request 4-AMOS_System/3D 5-AMOS_System/Compiler 6-AMOS_System/Serial The default filenames must be set as: 1-AMOS_System/Def_Icon 2-AMOS_System/Mouse.Abk 3-AMOS_System/Defaukt.Font 4-AMOS_System/Default.Key An important point to note is that only the extra part of the pathname is required. AMOS adds AMOS_System onto the current path (in this case Dh0:UTILS/AMOS_System/ Hard disk users will find this information very helpful and it will avoid having the AMOS_System folder stuck in the root directory of the hard disk. Anyone developing a CDTV application in AMOS will also need to use this feature. The above information is also true for the RAMOS runtime system, the only difference being that RAMOS doesn't require PAL or NTSC files. INTERLACED SCREEN MODE SUPPORT To open an interlaced screen use the following syntax: SCREEN OPEN 0,320,200,16,LACED [+HIRES][+LOWRES] LACED is a function that returns 4. Important: As soon as one screen is opened with interlace, all the other screens turn to interlace. The interlacing will only truly effect the screen actually opened with LACED. All the others will just have their vertical lines doubled on the screen to adjust to the special mode. Interlaced mode is perfect for displaying pictures, but animation runs at half normal speed. Games should not be written in Interlace! As soon as the last interlaced screen is closed the whole display returns to normal mode. Your TV monitor might not like lots of fast switching from normal mode to Interlace, so you are adviced not to do this excessively. All normal operations are available in interlaced screens: Screen Offset, Screen Display and so on. The only problem that arises is due to interlacing being software driven in AMOS. The bitplanes are changed during the vertical blank and this particular interlace process is forbidden during copper list calculation. So if you have a large copper list file (ie. four screens, one interlaced, and a rainbow), and have a copper calculation to do, the interlaced screen will display only half of the picture during the calculation. Nothing can be done to solve this, it is simply a limitation of the whole system. There are two extra screen commands in AMOS now. These allow a program to work out what type of display it is being run on: DISPLAY HEIGHT (Report how tall a screen can be) =DISPLAY HEIGHT This command returns 311 in PAL and 263 in NTSC. NTSC (Flags the type of display in operation) =NTSC This returns TRUE if the system is in NTSC mode or FALSE if in PAL. Ideal for international software development! NTSC refreshes the screen at 60 times a second whereas PAL refreshes at only 50 times a second. However, AMOS1.3 compensates for this and now music runs at exactly the same speed in PAL and NTSC AMAL also relies on the interrupt routine but is not slowed down to comply with PAL speeds. You must therefore be careful not to synchronise music and animations by just relying on the speed they run at. Check that an animation frame has been reached or the music has played a certain note. Using this technique you'll ensure the software executes at the right point on all systems. OTHER NEW AMOS COMMANDS NEW SYSTEM REQUESTER EXTENSION REQUEST (Generates a requester routine) REQUEST ON This will make AMOS generate its own requester routine and is the default. REQUEST OFF AMOS will always select CANCEL button of the requester if this command is used. The actual requester will not be displayed, so this ideal for error trapping within a program. REQUEST WB This tells AMOS to switch back to Workbench's system requester. You'll come back to AMOS as soon as you have chosen one of the options. Note: If you don't load up the Requester (by deleting it from the extension list using the config file), the normal Workbench requester will be used for displaying messages. This does have a bad side-effect though, AMOS will seem to have crashed when a requester appears. If this happens you simply press Amiga+A to return to the Workbench, answer the question and press Amiga+A once again to return to AMOS. It's only best to avoid loading the requester when the memory is very low! ALTERING THE BOB DRAWING ORDER PRIORITY REVERSE ON/OFF (Change the order in which Bobs are printed to the screen) PRIORITY REVERSE ON PRIORITY REVERSE OFF PRIORITY REVERSE ON, reverse the entire bob's priority table. This means that bob number 1 will be the first one drawn in front of all other bobs, 2 will come in second etc... This priority list is compatable with STOS. This instruction has another feature when used in conjection with the PRIORITY ON command. The bobs are not printed from TOP to BOTTOM any more, but from BOTTOM to TOP! The highest bob on the screen will be displayed in front of the others. SWAPPING BANKS A new and very needed instruction: Bank Swap number1, number2 This instruction will swap the pointers of the two banks. Useful if you want to turn an icon bank into a sprite bank. Example: Bank Swap 1,2 or have more than one music bank at the same time, for example: Bank Swap 3,5 SEARCHING FOR THE CURRENT DEVICES AMOS can report back to you the current list of devices using the following commands. =DEV FIRST$ (Get first device from current device list) dev$=DEV FIRST$("filter") Works the same as Dir First$ and Dir Next$, but reports back the device list. Note that you should remove the spaces with - "" to get the right name. =DEV NEXT$ (get the next device satisfying the filter) dev$=DEV NEXT$ Gets the next device from the device list. A null string indicates the end of the list has been reached. Example: Print Dev First$ Do A$=Dev Next$ A$=A$-"" If A$=""then End Print A$ Loop THE FUTURE OF AMOS AMOS will constantly be updated so that it keeps up-to-date with new trends on the Amiga scene. For the latest AMOS update information contact: Sandra Sharkey of the AMOS PD Library: 25 Park Road, Wigan, WN6 7AA, England. Telephone 10am to 3pm on (0942) 495261 End.